Re: Comments Re: C=US; A=IMX: draft-ietf-x400ops-admd-03.txt

[Allan Cargille <[e-mail]>]

Sorry - left out the contents last time I tried to mail this!  8-(
======================================================================

Hello ops folk,

I'd like to thank Stef for sending his message below and add my
complete agreement to the sections about the relationship between
C=US; ADMD=IMX and the international Internet community.

I'm afraid I disagree slightly with Stef (sorry, Stef! ;-) about the
IMX+ constructor syntax.  Stef wrote, "It should be entirely apparent
that only the owner of nma.com will be allowed to register
IMX+nma.com...".  I don't think that registration rules should be based
on assumptions, so I think it would be worth fleshing out the document
to clarify any necessary rules for IMX+... PRMD registrations.

As I said in my separate message, I believe that *recommendations*
about "good" PRMD names is quite a separate issue and should not be
included in this document.

Cheers,

allan

} Talking on the phone with Allan Cargille a bit ago, we agreed that the
} following comments should be distributed via X400ops, for whatever
} they are worth for the IETF discussion next week.  I will be brief.
} 
} Our concern is with possible misunderstandings of the context of the
} A=IMX actions, and why we are asking the full international X400ops WG
} to bless the document.
} 
} Here is the context of our request for blessings:
} 
} Under X.400, each sovereign nation is expected to unilaterally assign
} or register ADMD names in its own nation, and thus control name
} assignments in the X.400 ORAddress name space in each nation.
} 
} A=IMX is fulfilling this expectation for C=US, in the context of the
} "local" C=US national situation.  (ANSI and US-NMTS included).
} 
} But, we also recognize that what we are doing has Internet-wide
} implications which we may or may not correctly understand and address,
} thus we want to subject our A=IMX document to IETF X400ops WG review
} and approval, in terms of its international and internetworking
} implications.
} 
} We do not see that it is of any concern to the IETF X400ops WG as to
} how we chose the name "IMX" or whether and how we might register it in
} inside C=US.
} 
} What we are concerned about is how this might adversely affect
} Internet X.400 services in other (non-C=US) parts of the Internet.
} 
} Please bear in mind that we do not yet know how to deal with all the
} ramifications of interconnection with ADMD services providers, either
} in or out of C=US, but we assert that resolving these issues is
} independent of our choice of ADMD name, and independent of our choice
} for provision of A=IMX PRMD name registration services.
} 
} We do find it important for our C=US A=IMX PRMD registry to be
} publicly accessible from any point in the Global Internet, so this is
} called out for IANA action in the A=IMX draft.
} 
} And one more minor note: In C=US, ANSI procedures allow the registrant
} of any ANSI MHSMD registered ADMD Name to use it with the "famous"
} +constructor syntax to form PRMD names (e.g., P=IMX+nma.com) which
} will be guaranteed unique within the A=<space> virtual ADMD in C=US.
} 
} And, by our A=IMX rules, these same names will automatically also be
} unique without A=IMX if some PRMD operator wishes to use it, but it
} will of course need to be registered in the A=IMX PRMD register to be
} provided by the IANA.  It should be entirely apparent that only the
} owner of nma.com (in this example) will be allowed to register
} IMX+nma.com under A=IMX, or under A=<space>, in C=US.
} 
} Thus, without any further text included in the A=IMX draft, we expect
} to be able to use this ANSI "feature" wherever it makes sense in the
} operation of A=IMX or A=<space>.  If at some future time, we discover
} a need for additional text to deal with some aspects of this, we will
} then generate a new RFC to detail how things must be done.
} 
} For now, we want to regard +constructors as a non-issue with regard to
} adoption of our A=IMX draft.