DNS NSAP/NET RRs

Robert L Ullmann <ariel@world.std.com> Tue, 09 November 1993 04:53 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa02709; 8 Nov 93 23:53 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa02705; 8 Nov 93 23:53 EST
Received: from mailhost.lanl.gov by CNRI.Reston.VA.US id aa29239; 8 Nov 93 23:53 EST
Received: from noc-gw.lanl.gov by mailhost.lanl.gov (4.1/1.2) id AA08372; Mon, 8 Nov 93 21:42:43 MST
Received: by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19530; Mon, 8 Nov 93 21:41:50 MST
Return-Path: <ariel@world.std.com>
Received: from mailhost.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1) id AA19526; Mon, 8 Nov 93 21:41:49 MST
Received: from world.std.com by mailhost.lanl.gov (4.1/1.2) id AA08341; Mon, 8 Nov 93 21:41:18 MST
Received: by world.std.com (5.65c/Spike-2.0) id AA16873; Mon, 8 Nov 1993 23:41:46 -0500
Date: Mon, 8 Nov 1993 23:41:46 -0500
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert L Ullmann <ariel@world.std.com>
Message-Id: <199311090441.AA16873@world.std.com>
To: tpix@world.std.com, tuba@lanl.gov
Subject: DNS NSAP/NET RRs

Hi,

In reference to the DNS NSAP RR specification (draft-manning-dns-nsap-03.txt):

This is a suggestion; I don't want to create a confrontation; just find
the common ground.

The RR defined specifies that it is only for N-SEL=0, and the text suggests
that the SEL should be selected by the hosts by a procedure that avoids using
any IANA-assigned protocol for SELs assigned "dynamically" for OSI transport
protocols. The CATNIP requirements are almost identical, with a difference
(at this time) only in where the IANA assignments appear in the CLNP context.

I'd suggest leaving the SEL out of the RR data, so that the data is exactly
the network entity title without the (zero) SEL. I like the hex format with
.'s optional anywhere.

I think that the acronym should then be NET, which is accurate, and kind
of neat:

emu	NET	47.0005.80.005a00.0000.0001.e137.08002010726e
	A	129.6.55.32
(aka)
	NET	C0.0000.81.06.37.20

(assuming the same 192 (=C0 hex) AFI assignment assumed in the CATNIP draft
to make the examples clearer.)

----
This would get us 100% convergence between TUBA and CATNIP in the DNS records,
if we also assume the CATNIP proposal for the PTR .# zone. (This is also a 
point for comment; the .# PTR proposal assumes breaks on octet boundaries.)

Remember, this is a suggestion for discussion; I'm out for a cooperative
solution here ... <grin>

Best regards,
Robert