[psg.com #441] IESG - Architecture - atsign

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi Folks,

Let's revist the discussion of the "@".  The IESG notes were relevent to
the "IANA Considerations" Section in [ARCH].  However, Ticket 440 (my note
from yesterday) is a request from an IANA reviewer to plainly state what
parts of [ARCH] are to be used to form the initial IANA Registry.  I've
taken care of that by adding a note that the information in the "IANA
Considerations" section of [ARCH] is there only for reference and that the
_real_ IANA information is in [NUMBERS].  However, nothing about the use
of "@" is actually mentioned in [NUMBERS].  I'll get that in there but I
need some clarification.

The discussion in [ARCH] is about algorithm names.  In [NUMBERS] many of
the sections prevent the use of the "@" and "," symbols with no further
explanation.  Are the locally defined extensions applicable to:
 - Service Names
   - Authentication Methods
   - Connection Protocol Channel Names
   - Connection Protocol Global Request Names
   - Connection Protocol Channel Request Names
 - Key Exchange Method Names
 - Assigned Algorithm Names
   - Encryption Algorithm Names
   - MAC Algorithm Names
   - Public Key Algorithm Names
   - Compression Algorithm Names

If _ALL_ of these Names are locally extensible, then I can state quickly
state that.  Essentially, I'll add a section in [NUMBERS] that will state
that the IANA will not accept anything with "@", but that the use of "@"
in a method or name will indicate that it is outside the control of IANA.
(I'll incorporate the other notes about self-control of this namespace
from the prior discussion as well.)

If _NOT_ALL_ of these are locally extensible, then I need to know which
ones are/aren't and I'll edit appropriately.

Thanks,
Chris