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

From: ginny at arin.net ([email-masked])
Date: Tue Jun 24 14:20:47 2003

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

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Jun 24 17:19:57 2003

Ginny,

My responses are in-line:

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

> in-addr.arpa zone generation, and therefore we do not collect or store this

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

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

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

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

> the RIR allocations or the remaining IANA blocks in reserve.

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

> country code should comply?

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

> 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

---

From: ggm at apnic.net (George Michaelson)
Date: Tue Jun 24 20:02:59 2003

> Is there a pointer to their meaning for those of us less educated?
 
Andy, this is a very bad space to be defining 'ENUMERATED' type values for. The
status is a matter of policy, within each RIR region, and is dynamic: it changes
in the 3-5 year timeframe. It would be a mistake to lock into RFC status
specific values for this kind of field, its not really in IETF definitional
space.

If its not possible to take a DB schema approach, and define this as being a
keyword-value restricted element, where the value set is locally defined, in
some external process, then I would suggest it might be best left as a simple
string type, with no applied 'business logic' on it.

PI and PA are actually deprecated terms. We now refer to ALLOCATED PORTABLE and
ALLOCATED NON-PORTABLE and ASSIGNED PORTABL and ASSIGNED NON-PORTABLE but this
is a matrix of values, and there are emerging changes in both RIPE and APNIC
region.

cheers
	-George

---

From: timc at arin.net (Tim Christensen)
Date: Tue Jun 24 20:14:52 2003

> is a matrix of values, and there are emerging changes in both RIPE and APNIC

As there are changes from time to time in the ARIN region.  I agree,
attempting to enumerate a list is non-value-added and out of IETF scope.

To quote Ginny's previous mail and agree with George,

> Perhaps it should be
> reworded to not be limited.

BTW, ARIN does not use the PA and PI terms, either.
(Provider-assigned and Provider-independent, if memory serves, but since
we don't use them don't quote me as the authority ;) )

Tim Christensen

Database Administrator
American Registry for Internet Numbers

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Jun 24 22:53:43 2003

> string type, with no applied 'business logic' on it.

3-5 years doesn't leave much wiggle room, huh?

With XML namespaces, it is possible to define an extension mechanism to 
allow each RIR to define their own locally-defined, locally-managed 
list.  Given the frequency of the changes, that makes the most sense here.

-andy