[Ietf-not43] comments on FIRS

[Eric A. Hall]

[general comments here, and some detailed comments below]

Thanks for the input. I've made the changes and corrections I could, based
on errors and comments below. We need to discuss some of the general
concerns you raised in more detail to see where there are real issues or
just poor wording on my part.

Before we get into that, let me make a disclaimer, which is that the IP
addressing and ASN specifications were really intended to serve as
placeholders until somebody from that area expressed sufficient interest
in working on the subject (tag, you're it). Also, the WG charter doesn't
cover those areas, although my understanding of the situation is that
we're probably going to flip back to include them at some point. For those
reasons, I specificallly labelled the IP specifications as "Experimental"
(and had meant to do the same with the ASN specification but forgot to
change the template apparently). The specifications in their current form
really only represent my best-guess at the subject, and I want/need your
help to make them useful.

You're correct in your observation that ASN entries are served from a
swamp namespace. That's because ASNs do not have any hierarchy, and are
not mapped to the DNS hierarchical namespace. Since there's no hierarchy
or namespace, a "default" authoritative partition has to be used to
initiate the query-resolution process. However, my expectation is that the
entries in the default partition will *only* exist as referral sources,
with queries for each entry being immediately referred to canonical
entries at RIR-specific partitions. For example, a query for ASN 65535
would be mapped to the default partition and get sent to the swamp server,
which would immediately return a referral to the RIR-specific partition.
If you have any ideas on how we could impose ASN-to-partition mapping at a
higher layer using some kind of DNS mapping, it would lighten the overall
burden on the servers somewhat (moving it to the clients), but that's
really our only other alternative to using a swamp referral system.
Alternatively, I can put the above text into the ASN specification and
tell folks what's actually going on.

IP addresses do have hierarchy, and can be mapped to DNS domains in order
to construct the authoritative partition element of a fully-qualified
distinguished name for a particular resource. However, the default query
process does not use the authoritative partition, but instead uses dc=arpa
as the default partition. As with ASN entries, queries are sent to the
swamp server by default, and referrals take over from there. The reason
for specifying how to build the fully-qualified distinguished name is so
that the other bootstrapping models *can* be used if necessary or
desirable. But by default, it is not used. Whereas ASNs can *only* use the
top-down model (since there is no delegation hierarchy to map against),
address blocks can use any of them, but by default use the top-down model.

Judging from your comments, you are saying that there some of the
centrally delegated address blocks don't align with mappings in the
IN-ADDR.ARPA hierarchy. I'd like to talk to you off-list about these to
see what we can do to make the full syntax predictable, or if the errors
in my text are the actual problem (the example you cited was malformed and
has been corrected, and there is a missing recursion for parent octets).
Let's talk about this off-list.

Specific responses below.

on 6/9/2003 10:46 PM Edward Lewis wrote:

> -firs-arch

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

reworded as "RIPE and some ccTLDS"

> -firs-core

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

FIRS is an application service which is specifically intended to provide
automated retrieval. The application service is expected to be integrated
into a variety of user applications, such as ~"click on a traceroute entry
and fetch information about the network resource". In order for this work
as expected, the referrals have to be constrained to predictable and
defined mechanisms, and allowing unstructured and/or undefined services
breaks the usage models. For example, a traceroute client that calls of
FIRS should be able to expect that the data will always be provided as
LDAP attributes; if the answer data is a generic web page or a gopher menu
or some other unstructured and/or undefined URL/service, the application
wouldn't be able to use the information. I reworded the text to try and
clarify that the restriction is due to the application limitations.

> Section 4.1.2

> 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 should probably talk more about the kinds of contact types/roles you
need to support. I'm not going to be excited about putting them into a
structured ASN.1 attribute (if that's your suggestion) since that makes
searching by value much harder (eg, ~find all resources with this contact
address). I've no problems with moving the generic contact attributes into
an auxiliary object class, and almost did that on the last edit. We should
talk about the types/roles that need to be supported and then we can
figure out the best way to go from here.

> Section 4.2.3 (Example)
> 
> I'd like to see this for a true net range

That's just an example of the associated resources. I don't want to
introduce complications, since that would unnecessarily obfuscate the
canonical purpose of the example (associated resources).

> Section 5 - reference to a "Section 0" (Nit.)

Fixed, thanks

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

I tried to clarify that there is no recovery in this model (directed
queries), and that the search has to exit if the "known" server or "known"
resource do not exist at the expected locations.

> -firs-asn
> 
> inetAsnRegistrar - not applicable
> inetAsnRoutingContacts - number registries may not have access to any 
> routing policy, in any shape or form.

> Need more flexibility to identify the contacts for the ASN, and 
> whether the ASN is role/individual.

> Not sure if these apply, maybe they do...  (ASN's aren't delegated.)

That's all stuff we should talk about.

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

The "associated" entries are mostly for operator use, not for use by the
registrars or delegation bodies. There are some instances where it would
be useful for a delegation body to provide some of this data, but it is
mostly provided as a way for people to say "this domain is associated with
this netblock" for internal linkage purposes. You can ignore it.

> -firs-ipv4

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

There was an error in the example, sorry. It's been fixed. New text is:

  For example, a host-specific IPv4 address block of "192.0.2.14/32"
  would be mapped to the reverse-lookup DNS domain name of
  "14.2.0.192.in-addr.arpa." which would in turn be mapped to
  "dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Meanwhile, the "Class
  C" block of "192.0.2.0/24" would be mapped to the reverse-lookup
  DNS domain name of "2.0.192.in-addr.arpa." which would in turn be
  mapped to "dc=2,dc=0,dc=192,dc=in-addr,dc=arpa". Finally, a
  classless IPv4 address block of "192.0.2.0/20" would be mapped to
  the reverse-lookup domain name of "0/20.14.2.0.192.in-addr.arpa"
  which would in turn be mapped to the fully-qualified distinguished
  name of "dc=0/20,dc=14,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa".

See the intro text at the top of this message. The purpose is to provide a
fully-qualified DN which *can* be used for non-default queries.

> -firs-dns and -firs-dnsrr didn't seem to be of interest to my 
> context, I can't figure out the latter anyway.

-firs-dnsrr is intended to provide a way to store raw DNS resource records
with a specific entry. This is primarily intended to provide structured
nameserver data (host:address pairs) with domain name entries and for
storing address data associated with a known nameserver entry (I need to
better explain this). It is generalized to allow both of these uses and to
also allow any kind of raw RRs to be associated with any domain name
entry, for any other purpose. For example, some DNS servers allow
LDAP-storage of zone data, and this accomodates that usage in an
interoperable way. Those other uses aren't the stated goal because they
aren't part of the charter but they are well-served by a generalized RR
storage schema which is needed anyway.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/