Re: DNS under o=Internet

[Einar Stefferud <[e-mail]>]

I have just reviewed all the mail on this Subject, and have snipped
out some text from some messages to use as a foil for comment.  I
don't recall who said which, but I don't think it matters.

> My solution is to avoid the problem altogether by viewing the DIT as
> a listing hierarchy :-).

Clearly the DIT is a Listing Hierarchy, but it is possible to simply
graft the IANA and the DNS registration tree, or any other truly
independent name space tree under any arc of the DIT or the OID Tree
that you wish for the purposes of using it for a registry combined
with a facility to also use it as a listing directory.  There is no
harm with actually using the X.500 directory as a combined registry
and listing arrangement.  

What we cannot do is require that these two always be combined.

It is very important to understand that Registration Trees can behave
according to different rules than Listing Trees.  NOW, having said
this, let me see if I can explain it;-).

Look at the way NSAP values are assigned (registered) and how they are
used.  The values are assigned under various OID tree arcs, like the
ICD (which registers International Organizations).  Other NSAP values
come from registration of organizational OIDs under countries, as with
ANSI in c=US, under {joint-iso-ccitt(2) country (16) US(840) }.  When
used in a real NSAP, none of the two top level OID values appear,
because the NSAP "scheme" assigns specific prefixes to each of several
branches of the OID tree, and these prefixes are what shows up in the
"real NSAP which goes down the wire in a PDU".

So, maybe the IANA or the ISOC should get an ICD assignment for NSAPS
and become a subauthority for assigning NSAP values?  Seems perfectly
reasonable to me.  Unfortunately, this does not do anything for
alphanumeric X.500 names because the ICD arc is not commissioned for
this use.

There is only one arc that is jointly agreed upon for holding both
AplhaForm Names and NumberForm Names, and that is the recently
assigned {joint-iso-ccitt(2) country(16)} arc, under which each
country is assigned an arc with its 2-character ISO-3166 country code
registered as its AlphaForm Name and its ISO-3166 Numeric Code
registered as its NumberForm Name (OID). 

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

Now, you gasp "But we don't want our DN to include joint-iso-ccitt"
and of course you are right about this.  The ISO-CCITT rules are that
the "root" of the X.500 tree starts with c=<country-code>, and all
above this is an "assumed prefix" if you wish to be complete about
things.  But, operationally this can be ignored and we just pretend
that we don't know about that other part of the tree above c=.

The running code does not need to be concernd about it, as long as
the only top level domains under the root are the ISO-3166 2-character
country codes.

So, within each country the AlphaForm Name values registered under the
{ joint-iso-ccitt country } arc may be used for X.500 Organization
attribute values (o= ).  But as noted in RFC1255, this is not the only
source of names at this level, because ISO does not tell the US
Congress what to do.  ISO also does not tell the GB or FR or DE (etc)
governments what to name things either.

That is, the US Congress does not ask ANSI for permission to name a
new state, or a new "What's His Name National Laboratory" (WHNNL).  If
and when ANSI does attempt to assert authority in this name space, I
plan to get a good seat to watch the spectacle as the US Congress
tells ANSI what to do with their ISO authority.

> A second issue to consider is the set of second-level domains - a
> DNS tree in the X.500 directory that has O=Internet@domain=EDU will be
> quite useless if there are only 5 entries under it - do we wish to
> populate the tree with *all* domains, even if they are NOT
> participating in the current pilots?

First, the idea should be to simply graft the entire DNS tree under
what ever arc you chose to hang it under.  NO REREGISTRATIONS!  It si
done wholesale by simply registering the DNS tree under some arc.

But, I have a question about this issue: Where is o=internet
registered?  I have not seen anything other than the idea of adding it
under the root,as a peer of the ISO-3166 registered countries.

But, we all agree that there is no registration authority that we know
of that will grant permission to do this (ie. register o=Internet).

Then I found this idea from Al Grimstad:

> Anyway, what if (a) the NADF had the chuzpah to claim that
> it was going to use the addmdName attribute in this way, i.e.
> {AD=Speedy Delivery, C=US, O=US National Gizmos},
> a{AD=Speedy Delivery, C=FR, O=French National Gizmos}, ...

> and (b) it registered (offered to register) the internet as an
> "adminstrative" domain, so that the following was possible:
> {AD=Internet, C=US, O=National Lab for Gizmo Research},
> {AD=Internet, C=FR, O=Gizmo University}, ...

As I have mentioned, it does not matter where the DNS "register" is
placed in the name assignment tree, as long as all users (people and
programs) of the registered values understand the context of use
(e.g., "what is the assumed prefix that is not visibly shown?")

Of course, it is going to be very hard to explain to the French about
how it does not matter whether the whole tree is registered under
c=US, or c=GB, or c=DE, or c=NO, so since all the other countries will
understand that it does not matter at all where the DNS tree is hung,
lets hang it under c=FR!

Frankly, I cannot think of a better place to hang it.  Surely the
French will take very good care of it and no doubt treat it as a
National Treasure.  It really does not matter at all, because we will
not make it visible in any DNS registered name, or in the use of any
registered name.  This is because the INTERNET DNS name space is a
truly independent name space, unrelated to all other name spaces.  Of
course, its name values often look similiar to names in otehr spaces
because they are chosen to stand for companies and institutions who
want to be recognized, but I assure you that IBM registered under .com
in the DNS (bound to an IP address and to COM) is not the same thing
as IBM registered by ANSI (bound to an NSAP and to o= ) under 
{ joint-iso-ccitt country US }, even if both are owned by IBM.

Then, some one asked:

> In other words, does the IANA has any authority to allocate
> Directory Names and/or NSAPs? (I'm just asking, not arguing!).

For now, the answer is no, because IANA has not applied for (or
obtained) authority to issue NSAP useable Numberform values under any
suitable arc.  If desired, an application should be made by letter to
BSI in the UK which is the registration agent for the ICD arc, under
which NSAP values may be assigned.  This works because the ICD and the
values assigned under it are both visible in the NSAP, and thus we get
global unicity, when coupled with the associated prefix.

And then Wengyik observed:

> The fact of the matter is that the Internet exists, and has a
> registration authority.  This registration authority is more or less
> globally recognized in the Internet universe.

Yes, indeed, this was also pointed out above, that the DNS is a truly
independent name space, with its assigned (registered) name values all
honored by the inhabitants of the internet.  This is all that is
required.

Best...\Stef