[Ietf-not43] Comments on draft-ietf-crisp-iris-areg-02.txt

[Andrew Newton]

Ginny,

My responses are in-line:


ginny at arin.net wrote:
>>3.1.3 <findNetworkByAddress>
>>
>>   The <findNetworkByAddress> element is a query for a network given the
>>   IP address.  It contains one of the two elements <ipv4Address> and
>>   <ipv6Address>, which contain an IPv4 and IPv6 address, respectively.
>>
>>   The results from this query MUST be either the <ipv4Network> result
>>   or the <ipv6Network> result.  More than one network result MAY be
>>   returned.
> 
> 
> The format of the address should be specified. CIDR, short-form, fully- 
> qualified presentations of IPv4 and IPv6 addresses need to be supported.
> Support of short-form becomes a bigger issue with v6. Also, are 
> <beginsWith> queries permitted?

Good point on the specification for the IPv4 and IPv6 addresses.  As for 
short-form vs. qualified, if the it were always qualified and the client 
was responsible for converting from short form to qualified, this would 
be less work for the server.  However, the protocol can be made to do 
either.

As for a beginsWith, I hadn't thought of that.  Good point.

>>3.2.1 <nameServer> Result
>>
>>   The <nameServer> element represents a name server.  It contains
>>   elements for the fully qualified domain name of the name server, the
>>   IP addresses of the name server, and references to the name server
>>   contacts.
>>
>>   The <nameServerContacts> element contains multiple children.  Each
>>   child is an <iris:entity> element as described by IRIS [9].  The
>>   referent of each <iris:entity> element MUST be a <contact> (Section
>>   3.2.5) result.
>>
>>   The <iris:seeAlso> element contains <iris:entity> elements specifying
>>   entities that are indirectly associated with the name server.
> 
> 
> ARIN stores name servers as attributes of the network, not as a separate
> entity. The IP address and name server contacts are not necessary for
> in-addr.arpa zone generation, and therefore we do not collect or store this
> information.

Ok.  I think this was just some assumption on my part.  So attributes 
they can be.

>>3.2.2 <ipv4Network> Result
>>
>>[...]
>>   o  One of <directAllocation>, <directAssignment>, or <reassigned>
>>      signifying the assignment and allocation status of the network.
> 
> 
> Currently, ARIN has additional network types. Perhaps it should be 
> reworded to not be limited:
>     o The assignment or allocation status of the network such as
>       <directAllocation>, <directAssignment> or <reassigned>.

Listing out all the possibilities helps the client do localization.  It 
doesn't have to be limited to these three though.  Is there a list of 
all the types?

> Also, the terminology PA and PI are used in conjunction with the network 
> type at some of the RIRs. You may want to consider their use as well.

Is there a pointer to their meaning for those of us less educated?

>>   o  <parent> contains an <iris:entity> reference to the parent network
>>      of this network.  The referent MUST be an <ipv4Network> (Section
>>      3.2.2) result.
>>
> 
> 
> In the ARIN database some records, particularly those Allocated to RIR, do 
> not have a parent network, that is <parent> is NULL.

The cardinality of the <parent> element is 0 to 1, so if the network 
doesn't have a parent, then one does not have to be given.  Am I missing 
something?  Are you looking for an explicit signal of NULL vs. not 
giving a <parent> element?  If so, that's easily done.

>>3.2.4 <autonomousSystem> Result
>>
>>   o  <number> contains the globally unique autonomous system number.
> 
> 
> We have records that represent more than one AS number. Although we may 
> break up the customer AS blocks in the future, we would not do this for 
> the RIR allocations or the remaining IANA blocks in reserve.

Ok.  So it should be <numbers>, right?

>>3.2.6 <organization> Result
>>
>>[...] 
>>   o  <country> contains the country code where this organization is
>>      located.
> 
> 
> Since there is a standard, ISO-3166, did you want to mention that the 
> country code should comply?

Yeah, I should do this.  And for dreg as well.

>>   o  <adminContacts> contains <iris:entity> element references to the
>>      administrative contacts for this organization.  The referents MUST
>>      be <contact> (Section 3.2.5) results.
>>
>>   o  <techContacts> contains <iris:entity> element references to the
>>      technical contacts for this organization.  The referents MUST be
>>      <contact> (Section 3.2.5) results.
>>
>>   o  <abuseContacts> contains <iris:entity> element references to the
>>      abuse contacts for this organization.  The referents MUST be
>>      <contact> (Section 3.2.5) results.
>>
>>   o  <nocContacts> contains <iris:entity> element references to the NOC
>>      contacts for this organization.  The referents MUST be <contact>
>>      (Section 3.2.5) results.
>>
> 
> 
> If this is to be for all the RIRs, the list of contact types should be 
> more generic. It also doesn't indicate if these are optional or mandatory. 
> Perhaps making an <orgContacts> element would be the better approach.

Each one is optional.  And the reason I enumerated the types is that it 
helps clients with localization.  However, if the distinction isn't 
important, than an <orgContacts> works for me.

-andy