These are personal comments. I am also the shepherding AD for this draft.
> 2. Issues To Consider
...
> For example, if the space
> consists of text strings, it may be desirable to prevent
> organizations from obtaining large sets of strings that correspond to
> the "best" names (e.g., existing company names). Experience has also
> shown that some level of minimal review is useful to prevent
> assignments in cases where the request is malformed or not actually
> needed (this may not always be immediately obvious to a non-subject-
> matter expert).
It might be worth mentioning internationalization considerations for
text string name spaces.
> 2.1. The Motivation For Designated Experts
...
> Designated experts are appointed by the relevant Area Director of the
> IESG. They are typically named at the time a document that creates a
> new numbering space is published as an RFC, but as experts originally
> appointed may later become unavailable, the relevant Area Director
> will appoint replacements if necessary.
>
> Any decisions made by the designated expert can be appealed using the
> normal IETF appeals process as discussed in Section 5.2. below.
>
> Since the designated experts are appointed by the IESG, they may be
> removed by the IESG.
The first and third paragraphs are slightly inconsistent. If it's the
AD that appoints the expert, presumably it's the AD that removes
him/her. Also, is the 'of' in the first line supposed to be 'or'?
> 3.1. Well-Known IANA Policy Definitions
...
> Hierarchical allocation - Delegated managers can assign values
> provided they have been given control over that part of the
> name space. IANA controls the higher levels of the
> namespace according to one of the other policies.
>
> Examples: DNS names, Object Identifiers
I would add IP Address Space as another example
...
> IETF Review - (Formerly called "IETF Consensus" in [IANA-
> CONSIDERATIONS]) New values are assigned only through RFCs
> that have been shepherded through the IESG as AD-Sponsored
> IETF Documents [RFC3932,RFC3978]. The intention is that the
> document and proposed assignment will be reviewed by the
> IESG and appropriate IETF WGs (or experts, if suitable
> working groups no longer exist) to ensure that the proposed
> assignment will not negatively impact interoperability or
> otherwise extend IETF protocols in an inappropriate or
> damaging manner.
>
> To ensure adequate community review, such documents should
> be Last Called.
You need to specify who issues the last call and who judges the result.
Presumably it's the IESG via a shepherding AD, but it needs to be said.
> 3.3. Updating Guidelines In Existing Registries
>
> Updating the registration process for an existing name space is
> similar to that used when creating an new namespace. That is, a
> document is produced that makes reference to the existing namespace
> and then provides detailed management guidelines for each registry.
> Such documents are normally processed as BCPs [RFC1818].
I understand why you cite 1818, but the full definition of BCPs is in 2026.
(Why 2026 isn't listed as replacing 1818 beats me.)
> 4.3. Overriding Registration Procedures
>
> [XXX: following is new text w.r.t. 2434. Is this something that is
> appropriate to include??]
Personal opinion: yes, but...
> ...The
> intention is not to overrule documented procedures,
I think "properly documented procedures" would make more sense;
if they are badly documented, we might need to overrule them.
...
> ...In general, the IETF would like to see deficient IANA
> registration procedures for a namespace revised through the IETF
> standards process.
Suggest adding:
but not at the cost of unreasonable delay for needed assignments.
(Brian breathes in)
>5.1. When There Are No IANA Actions
>
> Before an Internet-Draft can be published as an RFC, IANA needs to
> know what actions (if any) it needs to perform. Experience has shown
> that it is not always immediately obvious whether a document has no
> IANA actions, without reviewing a document in some detail. In order
> to make it clear to IANA that it has no actions to perform (and that
> the author has consciously made such a determination!), such
> documents should include an IANA Considerations section that states:
>
> This document has no IANA Actions.
Suggest adding:
This statement, or an equivalent form of words, must only be inserted
after the WG or individual submitter has carefully verified it to be true.
In some cases, the absence of IANA-assigned values may be considered
valuable information for future readers; in other cases it may be
considered of no value once the document has been approved, and may be
removed before archival publication. This choice should be made clear
in the draft, for example by including a sentence such as
[RFC Editor: please remove this section prior to publication.]
or
[RFC Editor: please do not remove this section.]
> 5.2. Appeals
...
> ... By virtue
> of the IAB‚ÇÖs role as overseer of IANA administration [RFC 1602], the
> IAB‚ÇÖs decision is final.
Should cite 2026.
Nit:
Many non-ASCII characters (all intended to be ' I think)
Brian
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf