Re: DNS under o=Internet

Einar Stefferud <Stef@nma.com> Fri, 07 February 1992 12:35 UTC

Received: from nri.reston.va.us by NRI.NRI.Reston.VA.US id aa06400; 7 Feb 92 7:35 EST
Received: from bells.cs.ucl.ac.uk by NRI.NRI.Reston.VA.US id aa06396; 7 Feb 92 7:35 EST
Received: from ics.uci.edu by bells.cs.ucl.ac.uk with Internet SMTP id <g.08976-0@bells.cs.ucl.ac.uk>; Fri, 7 Feb 1992 11:26:57 +0000
Received: from nma.com by q2.ics.uci.edu id aa02070; 7 Feb 92 1:20 PST
Received: from odin.nma.com by nma.com id aa10681; 6 Feb 92 22:55 PST
To: A.Waugh@mel.dit.csiro.au
cc: osi-ds@cs.ucl.ac.uk
Subject: Re: DNS under o=Internet
In-reply-to: Your message of Fri, 07 Feb 92 13:00:17 +1100. <199202070200.AA10223@shark.mel.dit.csiro.au>
Reply-to: osi-ds@cs.ucl.ac.uk
From: Einar Stefferud <Stef@nma.com>
Date: Thu, 06 Feb 1992 22:50:44 -0800
Message-ID: <8660.697445444@nma.com>
Sender: stef@nma.com

Thanks Andrew for supporting our (NADF) position on listing vs
registration, and for pointing out where I went wrong in my discussion
of NSAPs and OIDs.  Your following point is totally relevant --

> The allocation of OIDs and NSAPs in any country is likely to be
> handled under different plans. In Australia, for example, the next
> portion of the OID for a company is the Australian Company Number.
> (Note; the SAA, in this case, is acting as a listing authority, not a
> registration authority.) With NSAPs the SAA are simply keeping a
> register of companies who have received authority for a portion of the
> NSAP space, so the SAA are acting as an registration authority.

Just to clarify -- Do I have this right?  In AU you simply graft the
AU Company Number Register under your AU DCC (Data Country Code) for
"automatic" OID use, but require the registered company to also
register the fact that it intends to use this value in forming NSAP
addresses, so you are then registering the intended use, rather than
just the value.  (This is a very subtle distinction!)

In c=US, ANSI does not record anything about intended use, but tells
the registered owner that their NumberForm Value may be used in
certain ways for OID or NSAP formation.

In what I said earlier, I was forgetting that each country is free to
decide how to do NSAPs, within the constraints of the ISO/CCITT
standards.  There is no need within any given AFI+IDI "domain" for
NSAP values to be drawn from any particular portion of any
international name|number space, as long as within the AFI+IDI all
values are unique to their "assigned owners"

What I should have said was that --

In the US, ANSI administers the

		{ joint-iso-ccitt(2) country(16) US(840) }

arc of the international standards naming tree, and has decided that
NumberForm Values registered under this arc may be used by their
registered owners in forming NSAPS in the ISO DCC IDI format defined
by ISO 8348, Addendum 2 (CCITT X.213).  IDI=840 is assigned to c=US.
AFI 38 and 39 are assigned for use in the ISO DCC IDI format.

This means that in c=US:

	Initial Domain Part	|	Domain Specific Part
------------------------------------------------------------------
	AFI	|	IDI	| Registered  	|Org Determined |
		|		| NumberForm	|    Part	|
------------------------------------------------------------------
  38 or 39	|	840	|	n	|	?	|
------------------------------------------------------------------

This scheme has since been refined to match with the US GOSIP NSAP
scheme in the Domain Specific Part, but you should be able to get the
idea from what I have shown here.

I should note however that in c=US the Registered NumberForm "n" is
also usable in forming OID values under the Registered Organizations
(sub)authority.  (e.g., OID = { 2 16 840 n m } where "m" is assigned
by the owner of "n".

With the information on what AU is doing, it should be clear that NSAP
assignment is indeed different in different countries, so no sweeping
global generalizations can or should be made.

The point is that ISO/CCITT has assigned the NSAP address space with
AFI=38|39 and IDI=840 to their memberbodies in c=US.  ANSI is the US
memberbody in ISO, and the US Dept of State is the US memberbody in
CCITT.  ANSI and the US Dept of State are jointly responsible for
administration of { 2 16 840 }.

I hope that this is as much as we need to delve into the NSAP business
in this forum, because all this NSAP stuff has nothing to do with the
registration and X.500 use of AlplhaForm Names in RDN Attribute Value
Assertions.

On this last point, I will only remind that Alphaform Name use, as
described in the revised ISO 9834, which established { 2 16 }, places
all the ISO 3166 country names under the X.500 "root", and does not
(as far as I know) place any other RDN values under the X.500 root.

I think it is proper for someone in this list to dig into ISO 9834 (as
revised) and dig into the X.500 standards, to help us understand
exactly who can and does decide what X.500 RDN AVAs can be placed
under the root.

We keep talking about placing o=INTERNET under the root, as though we
really have the unilateral right to do this.  Are we just trying to
finess things by doing it now in our pilots and then claiming some
kind of grandfather rights when we are challenged when we emerge as
part of the global public directory system?

The latter sounds like a poor tactic, when what we need is a good
strategy.

Best...\Stef