Re: DNS NSAP/NET RRs

[[e-mail]]

Rob,

> Several people have explained to me the historical background of including
> the zero sel in the NSAP representation of a NET, and using the NSAP
> representation. (The clearest explanation in Perlman, around where Radia
> uses the "trouble right here in River City" quote from Knibbe.)
> 
> Understand I'm not concerned about the extra 0 byte in the internal
> representation, or the ability of the implementors to get it right, or
> even aesthetic concerns, but rather the poor administrator who has to
> consistantly, every single time, add a .00 that isn't used for no
> explicable reason.
> 
> _then_, if the zero sel isn't there, it ought to be _called_ NET.
> 
> Even if the _internal_ representation includes the 0 in the DNS RR, the
> zone file (IMHO) should not have the .00

I believe we should aim for consistency.  Since the NET is defined to
include the zero Sel, it's representation in the zone file should include
it also.

Having said that, I'll note that the local format of a zone file is
an implementation issue.  The implementation of bind 4.9 that supports
name->nsap mapping includes the zero sel value because the implementors
thought it was "the right thing to do".


> ---
> 
> The "NSAP-PTR" RR definition isn't needed. The PTR RR itself has both the
> correct syntax and semantics; it can be used as is.


I like this.  PTR records are not, in fact, specific to IPaddr->name
lookups, so can also be used for NSAPaddr->name lookup.  Server code
won't need to be changed to support it, and user interfaces can be used
as is (although *good* user interfaces will need some changes).

Anyone see any overlooked subtlety here?


> Perhaps the inverse zone should use hex octet breaks for consistancy?
> 
> name	NET	C0.0000.81.2F.06.37
> 
> and
> 
> 37.06.2F.81.00.00.C0.#	PTR	name
> 
> Note that we have to mandate that "6" be represented as either .6. or
> .06. (I prefer the latter) to make this work.
> 
> I think we can assume octet breaks; from experience running networks it
> is much easier than arbitrary masks -- we only moved from A/B/C to bitmask
> subnetting because of a space crunch. Before the crunch, B's were happily
> subnetted on the "C mask", and A's on both byte-aligned masks.


First let me note that the greatest granularity for:

	- ESIS is octet alignment
	- ISIS is nibble alignment
	- IDRP is bit alignment

Since this is an issue of distributed allocation and control, it most
likely happens above the sysid, so ESIS isn't really relevant.

In RFC 1237.bis (draft-ietf-osinsap-allocation-00.txt), there are NSAP
formats which have fields defined on nibble boundaries (see Section
6.2.2).  Although it's not necessarily the case that *allocations* will
take place on nibble boundaries, I can already see the tendency to use
this.  My inclination is to err on the side of flexibility and use
nibbles rather than bytes.  I talked to Rob Austein (DNS WG chair) in
Amsterdam.  After some discussion we concluded that this was a workable
solution from the point of view of DNS name length (i.e., would fit
into DNS packets) and that there wasn't anything else obviously broken.

(I thought some about allowing the most general solution based on bit
boundaries.  After looking at the CIDR work in this area I decided against
it.)



I talked to Jon Postel in Houston about using .# as the root of the
NSAP->name tree because I'd seen it in CATNIP and liked it.  Jon didn't
think it sounded like such a great idea.  Since then I've officially
asked Jon for a root name for the NSAP->name tree.  I asked for .nsap,
but don't much care what it turns out to be.

--Richard