IANA Registration of Enumservices: Guide, Template, and IANA Considerations
draft-ietf-enum-enumservices-guide-22

6.5.  Step 5: Expert Review

   IANA will conduct an "Expert Review" according to [RFC5226].

IANA doesn't "conduct" Expert Reviews (or hardly ever), it initiates them.

11.7.  Change Control

   Enumservice registrations MUST NOT be deleted.  An Enumservice that
   is believed no longer appropriate for use can be declared obsolete by
   publication of a new Enumservice Specification changing its <usage>
   element (Intended Usage) to "OBSOLETE"; such Enumservices will be
   clearly marked in the lists published by IANA.  As obsoletions are
   updates, they are also handled the same way as initial Enumservice
   Registrations.

I am wondering if this is too heavy weight. Have you thought about allowing "IESG action" as an alternative here?

in 3.2, 
s/specified in small letters/specified in lowercase letters/

in 11.6, I don't understand "foresees" here.

Update: These are additional comments of things I spotted while re-reviewing the document for the discuss. Up to the authors whether to fix or not.

in 3.2 "An Enumservice must be unique" - Is it the service itself, or the naming of the service that must be unique?

in section 3.3, some assertions are made about what must be in security considerations. It might be better to point to a BCP published by the security area that discusses these issues. BCP 72?

"as accurate and extensive as feasible" is too ambiguous to be useful in a standard.

"The security considerations section ... is subject to continuing evaluation and modification ..." Is this true once the spec is published as an RFC? An RFC is not subject to modification.

s/may/might/g

in 3.4, is there a requirement that a specification be freely available? This also comes up in the discussion of escrow later in the document; can IANA make the escrow version publicly available? This might be discussed in RFC 5226 or elsewhere; I don't know the correct answer.

in 4.1, "Delegation ... is currently not supported" - should this be tightened to a MUST NOT for the standard? The discussion seems to shwo the beenfits of having delegation and then says its not supported. What does that mean in terms of compliance? It feels like an invitation for implementers to go ahead and use it in a non-specified manner.

in 4.2.1, the first paragraph starts with a MUST NOT about using a string **unrelated** to the service protocol, but then gives an example of using a **conflicting** name string; these are slightly different issues, which seems to leave it to interpretation whether it is ok to use an unrelated name as long as it doesn't conflict with anything already defined (or mislead). If you really want to avoid conflicting or misleading names, use a registry. Then it doesn't matter if the name is unrelated, as long as it doesn't conflict.

in 4.2.1, the discussion of whether it is legal or not recommended to have only one subType waffles so much I cannot tell what the text really wants to say. Given the waffling, you might as well remove the second paragraph of 4.2.1

in section 5, the term (MANDATORY) is thrown about. That is not an RFC2119 keyword. use REQUIRED.

 a real nit: "Should the Enumservice not require a Subtype" - you could rephrase this not using RFC2119 keywords.

in 5.2.5, is the external document required to be freely and publicly available? If not, that won't help a reader understand the terminology defined in the external document.

in 5.2.6, a reference to the security considerations section of a specification is called for. is the external document required to be freely and publicly available? If not, that won't help a reader understand the security considerations defined in the external document. 

in 5.2.7, OBSOLETE - "Applications should however expect to encounter legacy instances ..." Did you consider deprecated?

in 5.2.8, the example shows parentheses outside the XML angle brackets; I suspect that's not legal XML.If you want to carry that information, maybe you should define an obsoletedby= attribute for the xref.

in 5.2.9, is one of the requesters the designated contact person for the specification? 

in 5.2.10, no discussion or example of artwork is shown, also not in appendix A examples, but it is in the 11.2 schema.

in 5.4, "If at all possible" could be rewritten "well, if you feel like it ..." I recommend removing this phrase and simply saying "Recommendations ... SHOULD ..."

in 5.5, "threats that are unique". Hmmm, so if I know  there is one other case of the threat being applicable, it must not be unique, therefore I shouldn't discuss it here? You might reword this as "If a threat is especially applicable to this Enumservice then discuss it here." or something similar.

in 5.6, I find the text confusing when it talks about "this document, RFCXXXX"; it is unclear whether you mean "this registration request and RFCXXXX and 3761bis" or you mean "this document (also known as RFCXXXX) and 3761bis". I recommend you change "this document" to "this registration request".

in 6.1, "this document" might be better as "Sections 3,4,5 of this document"
in 6.1 "makes suggestions on content", as in MUST contain? try "describes requirements and suggestions for content"

in 6.2, "regarded" by whom? by the writer of the spec? by the expert reviewer? by IANA? Why is that discussed here in section 6.2? I suggest you could make this clearer by changing from passive voice to active voice "The requester MUST write a specification, using the format specified in sections 4 and 5, and make it publicly available." (I think the expert review discussion does not belong in section 6.2, unless you are trying to provide guidance to the writer about what to write).

in 6.3, what is a "reasonable time"? if a reasonable time is two to four weeks, why not just say that instead of giving it as an example? Under what conditions would two to four weeks not be a reasonable time? under what circumstances would a reasonable time be less or longer than 2-4 weeks?

in 6.5.3, you discuss expert rejection as part of the process flow, but the possibility of appeal isn't mentioned as part of the possible flow. 

in 7.1, it says RFC5226 says experts are appointed by RAI directors. RFC5226 doesn't mention RAI at all. This should be reworded to say RFC5226 says the IESG selects the experts. It is possible that the RAI area could be renamed, eliminated, or enum could be reassigned to another area. It is probably safer to simply say IESG selects the experts without mentioning RAI.

in 7.2, I recommend removing moist RFC2119 keywords. In most sentences the text is somehting like "the expert MUST verify"; removing the keyword would leave "the expert verifies" - a non-normative description of what the expert does, rather than a normative requirement the expert MUST do. 

s/may/might/

in 8, the title says pre-existing, but the content says existing. I think existing is adequate.

in 8, the first paragraph says it MUST be done this way. The seocnd paragraph says follwoing the transition rules, it will NOT be compliant. Why define two ways, one of which is not compliant with the other? and if there are two ways, then the first way is really not a MUST, it's a SHOULD.

in 10.2, Enumservice SHOULD have a reference ... when is it acceptabel to NOT have the reference?

in 11.2, "should be used" - by whom? do you mean th erequester should use the template, or IANA should use the template?
(see my discuss)

in 11.3, please rephrase from "IANA MUST hold" to "the requester MUST provide so IANA can hold"

in 11.6.2 "generic" - is this "non-RFC"; If I publish it as an ITU-T recommendatino, is this "generic"?; I'm not sure ITU-T would agree ;-)

in 11.7, MUST comply with guidelines - MUST comply with requirements

whew!

Section 5.2.4: s/more that/more than/

Review by Ari Keränen raised one question:

5.2.3. Enumservice Subtype (<subtype>)

    Should the Enumservice not require a Subtype, then the <subtype>
    element MUST be omitted in the registration XML chunk.  If a given
    Enumservice Type has multiple Subtypes, then there MUST be a separate
    "IANA Registration" XML chunk for each Subtype.  Please find further
    instructions in Section 4.

"IANA Registration XML chunk" is a bit ambiguous; especially since 
Section 4 (where reader is referred to for more information) does not 
mention "XML" or "chunks". Perhaps using something like "separate record 
element for each Subtype" would be better, if that's what you mean, or 
you could add a reference to section 11.2 describing the chunk template.

Consider deleting Appendix A and pointing to enumservices-transition instead.

  The Gen-ART Review by Miguel Garcia on 16-Jun-2010 includes some
  comments that deserve consideration:

  - Section 6.5: The text reads:

      IANA will conduct an "Expert Review" ...

    I guess a designated expert will conduct the review. At most
    (specially for non-RFC Specifications), IANA will make sure that
    an Expert Review has been done by and IESG-approved expert.

  - Section 11.6.1 discusses the process of registering Enumservices
    through the publication of an RFC. I don't understand the purpose
    of the second paragraph, which changes the process to IANA. The
    text reads:

      IANA MUST only add Enumservices to the Registry, if the experts
      have approved the corresponding Enumservice Specification as to
      be published.  IANA SHOULD attempt to resolve possible conflicts
      arising from this together with the experts.  In case changes
      between the approved and the to be published version are
      substantial, IANA MAY reject the request after consulting the
      experts.

    My problem is related to the process. If a document has gone through
    the RFC publication process, I expect that experts have inspected
    the document and approved the Specification prior to publication as
    an RFC, as part of a regular RFC process. This process may differ
    between standard track RFCs and individual submissions, but in any
    case, experts are involved in the RFC publication process, and the
    RFC will not be published if experts speak against the document. Or
    when do the authors expect that an Internet-Draft could be published
    without expert review?  So, I think that for RFCs, IANA does not
    need to do anything different from what they are doing today.

See <xref type="rfc" data="rfc9999"/>, Section 7.

RFC9999 will become a live RFC. Should we not be using an example RFC number in templates such as this? Perhaps RFC2606 would be a suitable RFC?