[Ietf-not43] comments on FIRS
Edward Lewis
edlewis at arin.net
Tue Jun 10 00:46:37 EDT 2003
Here are some comments based on one reading of the FIRS documents
(all fit in this: draft-ietf-crisp-firs-*-01.txt).
The context I'm coming from looking at IP network registrations,
which don't fall neatly into domain names.
Umbrella thoughts -
1) Internet resources are keyed by domain name. The name space is
composed of sets (a misnomer as order is important) of
domainComponents ("dc="'s) "which cumulatively identify a specific
portion of the global directory tree."
This is a problem. Network blocks are registered as ranges of
network addresses and DNS entries only map to class-full boundaries.
Even if you get into CIDR-ized DNS (RFC 2137), the problem isn't
solved, e.g.,
% whois -h whois.arin.net NET-631-823-120-0-1
NetRange:631.823.120.0 - 631.823.127.0
CIDR: 631.823.120.0/22, 631.823.124.0/23, 631.823.126.0/24, 631.823.127.0/32
(Obviously, the numbers have been changed to protect the innocent.)
Basically, address ranges can't be cleanly identified by a domain name.
DNS also can't show the hierarchy of the address assignments - you
can only delegate from the /16 to the /24 once, but the 255 addresses
can be suballocated from ISP 1 to ISP 2 to ISP 3...
It appears that the issue for ASN's isn't so dire, but the proposed
solution places a requirement on IANA to run a ldap server answering
for a domain that has been handed to the IAB (arpa).
2) In this proposal, DNS appears front and center as the glue of the
ldap servers and as the representation of all things registered.
This is contrary to the way in which the numbers registries work
where DNS is a "tail of the dog." Being allocated number space
without a DNS presence is of value as the space only needs to appear
in the routing tables. This is unlike the name registries, where
presence in the DNS is akin to presence in the routing tables.
Pretty much that is the most substantive stuff I hit. Below is a
recounting of dog eared pages, mostly coming from the above thoughts.
Document by document -
-firs-arch
I agree with the needs - global data-typing and formatting, need to
infer knowledge of other servers, potentially account for security
and for privacy. I'm dubious that there is a need to fit into any
database schema - just to look like it came from one is the goal.
section 4 namespace - issues already in umbrella section
" distributed partitions. Furthermore, the SRV resource records
associated with those DNS domains also provide a useful mechanism
for locating the authoritative LDAP servers associated with any
particular resource in the global FIRS directory database.
"
Not so true in the reverse map - e.g., a /17 yields 128@/24
delegations. I guess that we could live with 127 SRV's in that
instance.
section 4.5
" elements SHOULD provide multiple URLs, each of which identify
"
Already submitted a comment that implementations check all IP's of
host parts of URLs - suggested to avoid a mistake in DNS resolver
code.
section 7.2
" occurred for a particular resource. For example, RIPE and some of
its member ccTLDs provide WHOIS output which includes a series of
"
ccTLD's aren't (per se) members of RIPE - at least not in an
operational sense although they maybe sponsorships in there. Maybe
this is just a terminology issue.
-firs-core
Section 3.2 - name problem, DNS is a poor representative of network ranges.
Section 3.4 -
" * The protocol identifier of a URL MUST specify the LDAP
service type. Although general-purpose LDAP referrals are
allowed to specify any kind of protocol, FIRS referrals are
intended to be used for automated queries, and the use of
other protocols is forbidden in the default case.
"
Not sold that this restriction makes enough sense. As in, perhaps, but I
don't see the rationale.
Section 4.1.2
" inetResources
( 1.3.6.1.4.1.7161.1.0.0 NAME 'inetResources' DESC 'The
inetResources container for the FIRS service' SUP top
STRUCTURAL MUST cn MAY ( o $ ou $ description $
inetResourceComments $ businessCategory $ telephoneNumber $
facsimileTelephoneNumber $ labeledURI $
preferredDeliveryMethod $ physicalDeliveryOfficeName $
postOfficeBox $ postalAddress $ postalCode $ street $ l $
st $ c $ inetAbuseContacts $ inetGeneralContacts $
inetSecurityContacts $ inetTechContacts $
inetGeneralDisclaimer ) )
"
I think more flexibility is needed in the names of the contacts -
maybe have a structure called contact and inside have a "kind" -
Admin, Tech, Abuse, Notify, etc. Also, we tag contacts as persons or
roles.
We also have a "Public comments" field in the ARIN database, probably
close to "General Disclaimer"
Section 4.2.3 (Example)
I'd like to see this for a true net range, not just a class-full CIDR notation.
Section 5 - reference to a "Section 0" (Nit.)
Section 5.2.1 - "query fails" - returns no data? Failure modes will
need better treatment, failure cases are traditionally poorly defined
and become the Achilles heal of specs.
Section 5.2.2.
" The top-down model is primarily suited for locating Internet
resources which are centrally managed and delegated, and where
information about the delegation is desired. In particular, this
includes resources such as DNS domain names, IP address blocks,
and AS numbers.
"
Okay for following database but not in DNS. Addresses can be sub-allocated.
Step a.1 - what if the IP address isn't on a class-full boundary?
-firs-asn
inetAsnRegistrar - not applicable
inetAsnRoutingContacts - number registries may not have access to any
routing policy, in any shape or form.
" inetAsnContacts
( 1.3.6.1.4.1.7161.1.4.2 NAME 'inetAsnContacts' DESC
'Contacts for general administrative issues concerning
this ASN.' EQUALITY caseIgnoreMatch SYNTAX
inetContactSyntax )
"
Need more flexibility to identify the contacts for the ASN, and
whether the ASN is role/individual.
" 0 Reserved delegation (permanently inactive)
1 Assigned and active (normal state)
2 Assigned but not yet active (new delegation)
3 Assigned but on hold (disputed)
4 Assignment revoked (database purge pending)
"
Not sure if these apply, maybe they do... (ASN's aren't delegated.)
" cn=65535,cn=inetResources,dc=arin,dc=net
...
+-attribute: inetAssociatedIpv4Networks
| value: "192.0.2.0/24"
"
ARIN doesn't associate ASN's with prefixes - that's an operational
decision. (We register ASNs and prefixes to organizations, not each
other.)
Section 5.1
This sounds like it's creating a ASN swamp - ARIN doesn't give out
all AS's, each registry would have to run it's own ldap server for
it's component. I.e., IANA is the root of this.
-firs-ipv4
" An augmented BNF for this syntax is as follows:
inetIpv4NetworkSyntax = inetIpv4Octet "." inetIpv4Octet "."
inetIpv4Octet "." inetIpv4Octet "/" inetIpv4Prefix
"
Doesn't capture ranges accurately enough.
inetIpv4Registrar, Routing contacts - same as for Asn above, and same
for Ipv6 in the -firs-ipv6 document.
Section 5.1
" Finally, a
classless IPv4 address block of "192.0.2.0/20" would be mapped to
the reverse-lookup DNS domain name of "0/14.2.0.192.in-addr.arpa"
which would in turn be mapped to the fully-qualified distinguished
name of "dc=0/14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa".
"
I don't follow that.
-firs-ipv6
Nothing new (comment wise) that wasn't in -ipv4.
-firs-dns and -firs-dnsrr didn't seem to be of interest to my
context, I can't figure out the latter anyway.
-firs-contacts
Problems in here have already been mentioned...
We have a generic contact with "subtypes" and the role/individual
thing. Issues here aren't hard to hammer out....
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
Digital cameras are to film cameras as Etch-A-Sketches are to canvases.
More information about the Ietf-not43
mailing list