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

[ginny at arin.net]

> 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?

> 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.

> 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>.

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.

>    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.

> 3.2.3 <ipv6Network> Result

Same comments as in <ipv4Network>

> 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.


> 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?


>    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.