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

[Ballot discuss]
Updated DISCUSS text based on -21-

I think this document is useful, but the inaccurate use of RFC2119 language and the mixing of normative and non-normative text is problematic. Once that is corrected, I will support this being published as a Proposed Standard. For the sake of getting this pubished, I greatly reduced my DISCUSS, even though many of the problems were not fixed.

In section 11 there are some MUSTs here that tell IANA how to do their job, including "MUST be rejected by IANA" and "Expert review SHOULD NOT be initiated". I don't think working groups are empowered to require IANA to do their review and registration duties in specific ways. That is a job for the IAB (and for some things IESG or RSE). So I object to the normative language about IANA process.

[Ballot comment]
Some parts of sections 6 and 7 actually look normative to me, as they are not fully covered by RFC 5226. So I think use of RFC 2119 would be appropriate in some cases.

However in order to make your life easier, I am downgrading this to a Comment.

[Ballot comment]
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!

[Ballot discuss]
Updated DISCUSS text:

I think this document is useful, but the inaccurate use of RFC2119 language and the mixing of normative and non-normative text is problematic. Once that is corrected, I will support this being published as a Proposed Standard.

This document says it obsoletes section 3 of RFC3761. I have been made aware recently of id-nits requirements for documents that obsolete or update anther RFC. am a little unclear about the id-nits rules about partially obsoleting a prior RFC, but this is not reflected in the front matter or the abstract, and should be. It is mentioned in the INtroduction. I recommend Appendix B be renamed to "Changes from RFC3761". However, RFC3761 appears to be obsoleted by the 3761bis draft, so we make have some sorting out to do for the RFC Editor database.

OK. I went through enumservices-20 with Bernie's proposal to make certain sections normative and non-normative.
I have a different proposal that I think does a better job of separating non-normative from normative.

section 6 non-normatively describes the process flow. There are some RFC2119 keywords tossed around, but not many. Then we get to section 6.6 and 6.7 that has RECOMMENDs and MUSTs in what should be a non-normative section. I suggest that section 6 be made part of section 1 - the non-normative introduction. It provides flow charts of the overall process which would probably be more useful at the beginning of the document. The text should have no RFC2119 keywords.

The flow charts and description in section 6 discuss the whole process flow, breaking it into two parts: it starts with what a registration requester must do to submit a request, and then discusses the process after the requester submits a request. Currently, the document describes he detailed XML format, then discusses the process, which seems backwards.

Bernie suggested section 4 be non-normative; but it is full of MUSTs and SHOULDs and MAYs, and sections 3 and 5 point to section 4 requirements. It appears to me that sections 3,4,5 are the really normative pieces here, since they define the format for registering an enumservice, what fields are required, and the acceptable values. If you move section 6 to the introduction, then sections 3,4,5 can follow and discuss the detailed XML forms that must be filled in as part of the pre-submission process.

Sections 7 talks about Expert review, and has lots of "The experts MUST" do this and that. We have experts because they are experts. We should not tell them how to do their job. We can provide guidance, but I want to be sure they are not constrained in how they do their reviews, or how they make their expert decisions.

Sections 8 and 9 then diverge into a discussion of whether the normative forms should be used for revisions and extensions. Since this would also be part of the pre-submission flow, I think this belongs with the section 3,4,5 discussions of what the forms must contain. (These could be combined into one new section 6).

Section 10 mixes the security considerations for this document with the security considerations section of a registration request. I recommend section 10.2, which deals with the requirements of the security considerations in a registration request, be moved to section 5.5, which deals too lightly with how to fill out the  field (which is the security considerations section of the registration request).

Section 10 should contain the security considerations for **this** document. I think the current section 10.1 does this just fine.

section 11 mixes the IANA considerations for this document with the description of the IANA process, including how IANA uses expert reviews. It talks about how IANA actually performs their responsibilities about getting expert review and performing the registration. Normative and non-normative text are mixed together here. There are some MUSTs here that tell IANA how to do their job, including "MUST be rejected by IANA" and "Expert review SHOULD NOT be initiated". I don't think working groups are empowered to require IANA to do their review and registration duties in specific ways. That is a job for the IAB (and for some things IESG or RSE). So I object to the normative language about IANA process. I recommend the non-normative portions of text that describe the IANA registration process be moved to section 6 (then moved to section 1) and scrubbed of RFC2119 keywords.

Section 11 should contain the **requests** for IANA to perform specific actions needed for **this** document. As far as I can tell, there are no IANA actions required by this document.

The IANA actions discussed are apparently triggered by draft-ietf-enum-enumservices-transition, which rebuilds the existing registry using the XML template, and by forthcoming expert-approved registration requests.
--
My previous DISCUSS text:
This is a discuss-discuss, and does not require authors to make changes to their document (although a few points could be addressed fairly easily).

1) I think it would be a bad idea to publish this document as a standard.
Much of what is in this document regarding the process to be followed is already stated elsewhere, in IETF process documents. This is a guidelines document, and as such I would find it much more suitable to be published as an Informational document.

Parts of this document standardize a template. If the template portion was published in a standards document separate from the description of IANA process and expert review process and document publication process, then it would make sense to me to publish part of this as standard and part of it as informational guidelines.

2) in 11.5,
OLD:
It is up to the experts to resolve possible clashes.
NEW:
The experts are authorized to resolves clashes as they see fit.
The requesters may need to update their registration request before getting expert approval.

OLD:
"Once the experts have approved ..."
NEW:
"Once the experts have conditionally approved ..."

3) 11.5 sounds like we are creating new process, or committing to a "casting in stone" of our existing processes.

4) in 11.6, there are RFC2119 keywords describing the process, and constraining the possile actions taken by IANA and the experts.

5) in 11.7, "Updates of EnumService Specifications MUST comply with the guidelines described in this document." What happens if the IETF modifies its processes regarding IANA action (e.g., RFC5226) or modifies its process for document publication or its ability to allow IESG override of RFC5226 rules, and so on. Is the IETF still bound by THIS DOCUMENT, rather than by our own updated processes?

6) 7.1 discusses expert review, extending the IETF process to REQUIRE experts to perform additional review" "The experts MUST evaluate the criterion as set out in [RFC5226], as well as consider the following:
(and then there is a list of additional steps reviewers MUST perform.
While it is good to have criteria defined, the wording REQUIRES the reviewer to perform each of these detailed steps. This feels at odds with RFC5226, "The review may be
  wide or narrow, depending on the situation and the judgment of the
  designated expert."
I would not want to see appeals filed because somebody felt the expert reviewer didn't follow these rules to the letter.

[Ballot comment]
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
  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?

[Ballot discuss]
I have a small list of issues which I would like to discuss before recommending approval of this document:

1)
4.2.2.1.  Protocol-Based Enumservice "Type" Strings

  A protocol-based Enumservice SHOULD use the lowercase name

(Comment) Why use of lowercase is only a SHOULD? What are the reasons to violate it?

  of the protocol as its Type string.

This is missing a reference to the registry that describes valid
entries. There are multiple IANA registries related to service (protocol) names, so the exact reference is needed here.

2)
4.2.3.1.  Application-Based Enumservice "Type" Strings

  It is RECOMMENDED that Application-class Enumservices use the
  lowercase well known name of the abstract application as Type string.

Without a proper reference it is not possible to satisfy this requirement.
This doesn't seem to have a registry. So at minimum RECOMENDED should be replaced with "recommended".

3)
4.2.4.  Data Type-Based Enumservice Class

  "Data Type" Enumservices typically refer to a specific data type or
  format, which may be addressed using one or more URI Schemes and
  protocols.  It is RECOMMENDED to use a well known name of the data
  type or format as the Enumservice Type string.

Is there a registry that defines recommended names? If there is none,
there is no way to satisfy this requirement.

This doesn't seem to have a registry. So at minimum RECOMENDED should be replaced with "recommended".

  Examples of such
  Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969].


4.2.4.1.  Data Type-Based Enumservice "Type" Strings

  It is RECOMMENDED to use the lowercase well known name of the data
  type or format as the Type string.

As above.

4)
11.1.  Registry Update

  IANA will update the Registry "Enumservice Registrations" as defined
  in (this) Section 11, which will replace the old mechanism as defined
  in RFC 3761 [RFC3761].

  It is noted that the process described herein applies only to
  ordinary Enumservice registrations (i.e. the registration process of
  "X-" Enumservices is beyond the scope of this document).

What about "P-"?

5)
  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

I think this reference is Normative. E.g. it is used normatively in Section 5.2.4.

[Ballot comment]
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
  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?

[Ballot discuss]
I have a small list of issues which I would like to discuss before recommending approval of this document:

1)
4.2.2.1.  Protocol-Based Enumservice "Type" Strings

  A protocol-based Enumservice SHOULD use the lowercase name

(Comment) Why use of lowercase is only a SHOULD? What are the reasons to violate it?

  of the protocol as its Type string.

This is missing a reference to the registry that describes valid
entries. There are multiple IANA registries related to service (protocol) names, so the exact reference is needed here.

2)
4.2.3.1.  Application-Based Enumservice "Type" Strings

  It is RECOMMENDED that Application-class Enumservices use the
  lowercase well known name of the abstract application as Type string.

Without a proper reference it is not possible to satisfy this requirement.
This doesn't seem to have a registry. So at minimum RECOMENDED should be replaced with "recommended".

3)
4.2.4.  Data Type-Based Enumservice Class

  "Data Type" Enumservices typically refer to a specific data type or
  format, which may be addressed using one or more URI Schemes and
  protocols.  It is RECOMMENDED to use a well known name of the data
  type or format as the Enumservice Type string.

Is there a registry that defines recommended names? If there is none,
there is no way to satisfy this requirement.

This doesn't seem to have a registry. So at minimum RECOMENDED should be replaced with "recommended".

  Examples of such
  Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969].


4.2.4.1.  Data Type-Based Enumservice "Type" Strings

  It is RECOMMENDED to use the lowercase well known name of the data
  type or format as the Type string.

As above.

4)
11.1.  Registry Update

  IANA will update the Registry "Enumservice Registrations" as defined
  in (this) Section 11, which will replace the old mechanism as defined
  in RFC 3761 [RFC3761].

  It is noted that the process described herein applies only to
  ordinary Enumservice registrations (i.e. the registration process of
  "X-" Enumservices is beyond the scope of this document).

What about "P-"?

5)
  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

I think this reference is Normative. E.g. it is used normatively in Section 5.2.4.

6) DISCUSS DISCUSS:

draft-ietf-enum-enumservices-transition-05.txt requires review by the Designated Expert. Who is the Designated Expert for this document?

[Ballot comment]
Section 5.2.4: s/more that/more than/

Review by Ari Keränen raised one question:

5.2.3. Enumservice Subtype ()

    Should the Enumservice not require a Subtype, then the
    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.

[Ballot comment]
Review by Ari Keränen raised one question:

5.2.3. Enumservice Subtype ()

    Should the Enumservice not require a Subtype, then the
    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.

[Ballot discuss]
Based on the explanation provided by one of the authors (Bernie Hoeneisen), I'm escalating this from a COMMENT to a DISCUSS.

Section 11.6.1 states:

  IANA MUST ensure that any further changes the Enumservice
  Specification might undergo before final RFC publication are approved
  by the experts.

Bernie Hoeneisen explained that this text is attempting to address perceived shortcomings of RFC 5226. However, if there are problems with RFC 5226 then we need to fix that spec, not update it only for ENUM service registrations via this I-D. Furthermore, this proposal appears to be involving the IANA in processes that are currently under the purview of the RFC Editor. Therefore I am blocking this document pending input from the IANA and the RFC Editor.

[Ballot discuss]
Based on the explanation provided by one of the authors (Bernie Hoeneisen), I'm escalating this from COMMENT to a DISCUSS.

Section 11.6.1 states:

  IANA MUST ensure that any further changes the Enumservice
  Specification might undergo before final RFC publication are approved
  by the experts.

Bernie Hoeneisen explained that this text is attempting to address perceived shortcomings of RFC 5226. However, if there are problems with RFC 5226 then we need to fix that spec, not update it only for ENUM service registrations via this I-D. Furthermore, this proposal appears to be involving the IANA in processes that are currently under the purview of the RFC Editor. Therefore I am blocking this document pending input from the IANA and the RFC Editor.

[Ballot discuss]
This is a discuss-discuss, and does not require quthors to make changes to their document (although a few points could be addressed fairly easily).

1) I think it would be a bad idea to publish this document as a standard.
Much of what is in this document regarding the process to be followed is already stated elsewhere, in IETF process documents. This is a guidelines document, and as such I would find it much more suitable to be published as an Informational document.

Parts of this document standardize a template. If the template portion was published in a standards document separate from the description of IANA process and expert review process and document publication process, then it would make sense to me to publish part of this as standard and part of it as informational guidelines.

2) in 11.5,
OLD:
It is up to the experts to resolve possible clashes.
NEW:
The experts are authorized to resolves clashes as they see fit.
The requesters may need to update their registration request before getting expert approval.

OLD:
"Once the experts have approved ..."
NEW:
"Once the experts have conditionally approved ..."

3) 11.5 sounds like we are creating new process, or committing to a "casting in stone" of our existing processes.

4) in 11.6, there are RFC2119 keywords describing the process, and constraining the possile actions taken by IANA and the experts.

5) in 11.7, "Updates of EnumService Specifications MUST comply with the guidelines described in this document." What happens if the IETF modifies its processes regarding IANA action (e.g., RFC5226) or modifies its process for document publication or its ability to allow IESG override of RFC5226 rules, and so on. Is the IETF still bound by THIS DOCUMENT, rather than by our own updated processes?

6) 7.1 discusses expert review, extending the IETF process to REQUIRE experts to perform additional review" "The experts MUST evaluate the criterion as set out in [RFC5226], as well as consider the following:
(and then there is a list of additional steps reviewers MUST perform.
While it is good to have criteria defined, the wording REQUIRES the reviewer to perform each of these detailed steps. This feels at odds with RFC5226, "The review may be
  wide or narrow, depending on the situation and the judgment of the
  designated expert."
I would not want to see appeals filed because somebody felt the expert reviewer didn't follow these rules to the letter.

[Ballot discuss]
1) I think it would be a bad idea to publish this document as a standard.
Much of what is in this document regarding the process to be followed is already stated elsewhere, in IETF process documents. This is a guidelines document, and as such I would find it much more suitable to be published as an Informational document.

Parts of this document standardize a template. If the template portion was published in a standards document separate from the description of IANA process and expert review process and document publication process, then it would make sense to me to publish part of this as standard and part of it as informational guidelines.

2) in 11.5,
OLD:
It is up to the experts to resolve possible clashes.
NEW:
The experts are authorized to resolves clashes as they see fit.
The requesters may need to update their registration request before getting expert approval.

OLD:
"Once the experts have approved ..."
NEW:
"Once the experts have conditionally approved ..."

3) 11.5 sounds like we are creating new process, or committing to a "castijng in stone" of our existing processes.

4) in 11.6, there are RFC2119 keywords describing the process, and constraining the possile actions taken by IANA and the experts.

5) in 11.7, "Updates of EnumService Specifications MUST comply with the guidelines described in this document." What happens if the IETF modifies its processes regarding IANA action (e.g., RFC5226) or modifies its process for document publication or its ability to allow IESG override of RFC5226 rules, and so on. Is the IETF still bound by THIS DOCUMENT, rather than by our own updated processes?

[Ballot comment]
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.

[Ballot comment]
See , 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?

[Ballot comment]
Section 11.6.1 states:

  IANA MUST ensure that any further changes the Enumservice
  Specification might undergo before final RFC publication are approved
  by the experts.

This might unnecessarily involve the IANA in tasks that are currently under the control of the RFC Editor (e.g., AUTH48).

[Ballot discuss]
#1) This is a DISCUSS-DISCUSS.  To be clear there is nothing for the authors to do at this time.

How can this document and draft-ietf-enum-enumservices-guide both obsolete RFC 3761?

#2) Header says it obsoletes 3761, but in the text it only says it obsoletes section 3.  Is section 4 not being obsoleted?  If it's not then "Updates: 3761 (once approved)" in the header might be more appropriate.  You'd also need some words to say that Section 4 should be renumbered.

[Ballot comment]
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.

7.3.  Appeals

  Appeals of Expert Review decisions follow the process described in
  section 7 of [RFC5226] and section 6.5 of [RFC2026].

What is the first line of appeal? Is it IESG or RAI ADs?


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
  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?

[Ballot discuss]
I have a small list of issues which I would like to discuss before recommending approval of this document:

1)
4.2.2.1.  Protocol-Based Enumservice "Type" Strings

  A protocol-based Enumservice SHOULD use the lowercase name

(Comment) Why use of lowercase is only a SHOULD? What are the reasons to violate it?

  of the protocol as its Type string.

This is missing a reference to the registry that describes valid
entries. There are multiple IANA registries related to service (protocol) names, so the exact reference is needed here.

2)
4.2.3.1.  Application-Based Enumservice "Type" Strings

  It is RECOMMENDED that Application-class Enumservices use the
  lowercase well known name of the abstract application as Type string.

Which registry (or document) defines recommended names? Without a proper reference it is not possible to satisfy this requirement.

3)
4.2.4.  Data Type-Based Enumservice Class

  "Data Type" Enumservices typically refer to a specific data type or
  format, which may be addressed using one or more URI Schemes and
  protocols.  It is RECOMMENDED to use a well known name of the data
  type or format as the Enumservice Type string.

Is there a registry that defines recommended names? If there is none,
there is no way to satisfy this requirement.

  Examples of such
  Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969].


4.2.4.1.  Data Type-Based Enumservice "Type" Strings

  It is RECOMMENDED to use the lowercase well known name of the data
  type or format as the Type string.

As above.

4)
11.1.  Registry Update

  IANA will update the Registry "Enumservice Registrations" as defined
  in (this) Section 11, which will replace the old mechanism as defined
  in RFC 3761 [RFC3761].

  It is noted that the process described herein applies only to
  ordinary Enumservice registrations (i.e. the registration process of
  "X-" Enumservices is beyond the scope of this document).

What about "P-"?

5)
  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

I think this reference is Normative. E.g. it is used normatively in Section 5.2.4.

6) DISCUSS DISCUSS:

draft-ietf-enum-enumservices-transition-05.txt requires review by the Designated Expert. Who is the Designated Expert for this document?

[Ballot comment]
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.

7.3.  Appeals

  Appeals of Expert Review decisions follow the process described in
  section 7 of [RFC5226] and section 6.5 of [RFC2026].

What is the first line of appeal? Is it IESG or RAI ADs?


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
  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?

[Ballot discuss]
I have a small list of issues which I would like to discuss before recommending approval of this document:

1)
4.2.2.1.  Protocol-Based Enumservice "Type" Strings

  A protocol-based Enumservice SHOULD use the lowercase name

(Comment) Why use of lowercase is only a SHOULD? What are the reasons to violate it?

  of the protocol as its Type string.

This is missing a reference to the registry that describes valid
entries. There are multiple IANA registries related to service (protocol) names, so the exact reference is needed here.

2)
4.2.3.1.  Application-Based Enumservice "Type" Strings

  It is RECOMMENDED that Application-class Enumservices use the
  lowercase well known name of the abstract application as Type string.

Which registry (or document) defines recommended names? Without a proper reference it is not possible to satisfy this requirement.

3)
4.2.4.  Data Type-Based Enumservice Class

  "Data Type" Enumservices typically refer to a specific data type or
  format, which may be addressed using one or more URI Schemes and
  protocols.  It is RECOMMENDED to use a well known name of the data
  type or format as the Enumservice Type string.

Is there a registry that defines recommended names? If there is none,
there is no way to satisfy this requirement.

  Examples of such
  Enumservices include "vpim" [RFC4238] and "vcard" [RFC4969].


4.2.4.1.  Data Type-Based Enumservice "Type" Strings

  It is RECOMMENDED to use the lowercase well known name of the data
  type or format as the Type string.

As above.

4)
11.1.  Registry Update

  IANA will update the Registry "Enumservice Registrations" as defined
  in (this) Section 11, which will replace the old mechanism as defined
  in RFC 3761 [RFC3761].

  It is noted that the process described herein applies only to
  ordinary Enumservice registrations (i.e. the registration process of
  "X-" Enumservices is beyond the scope of this document).

What about "P-"?

5)
  [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

I think this reference is Normative. E.g. it is used normatively in Section 5.2.4.

[Note]: 'Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> is shepherd fro this. Proto write up entered as IESG note on 2010-0225.  Should cluster with
- draft-ietf-enum-3761bis
- draft-ietf-enum-enumservices-guide
- draft-ietf-enum-enumservices-transition' added by Gonzalo Camarillo

[Note]: 'Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> is shepherd fro this. Proto write up entered as IESG note on 2010-0225.  Should cluster with
- draft-ietf-enum-3761bis
- draft-ietf-enum-enumservices-guide
- draft-ietf-enum-enumservices-transition' added by Amy Vezza

[Note]: 'Bernie Hoeneisen <bernie@ietf.hoeneisen.ch> is shepherd fro this. Proto write up entered as IESG note on 2010-0225.  Should cluster with
- draft-ietf-enum-3761bis
- draft-ietf-enum-enumservices-guide
- draft-ietf-enum-enumservices-transition' added by Cullen Jennings

THE PROTO WRITE UP IS

                                                      Thu, 25 Feb 2010

  (1.a) Who is the Document Shepherd for this document?

        Bernie Hoeneisen

        Note: Bernie is at the same time lead author of this
              document. Should anyone on IESG have an issue concerning
              "checks and balance in the system", Bernie would step
              back as Document Shepherd immediately.  (The reason for
              this unusual situation is known the the Shepherding AD.)


        Has the Document Shepherd personally reviewed this version of
        the document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        Yes


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?
       
        Yes


        Does the Document Shepherd have any concerns about the depth
        or breadth of the reviews that have been performed?

        No concerns       


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        No concerns


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

        No concerns


        For example, perhaps he or she is uncomfortable with certain
        parts of the document, or has concerns whether there really is
        a need for it. In any event, if the WG has discussed those
        issues and has indicated that it still wishes to advance the
        document, detail those concerns here.

        All issues have been resolved


        Has an IPR disclosure related to this document been filed? If
        so, please include a reference to the disclosure and summarize
        the WG discussion and conclusion on this issue.

        Yes
        https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-enum-enumservices-guide


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

        Strong consensus, no outstanding objections; any objections
        raised have been resolved
       

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        The ENUM WG secretary has performed a nit review on this document;
        no open issues.


  (1.h) Has the document split its references into normative and
        informative?

        Yes       


        Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state?  If such
        normative references exist, what is the strategy for their
        completion?

        (Cross-)references require the following documents to be
        published as cluster:

        - draft-ietf-enum-3761bis     
        - draft-ietf-enum-enumservices-guide
        - draft-ietf-enum-enumservices-transition

       
        Are there normative references that are downward references,
        as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call
        procedure for them [RFC3967].

        No downrefs


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226].

        IANA reviewed the document several times; any issues raised by
        IANA have been resolved


        If the document describes an Expert Review process has
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during the IESG
        Evaluation?

        This document specifies Expert Review; experts to be appointed
        by the IESG


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        N/A (IANA is responsible for the XML chunk)


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

          This document specifies a revision of the IANA Registration
          Guidelines for Enumservices, describes corresponding
          registration procedures, and provides a guideline for
          creating Enumservice Specifications.


    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

          Non-contentious document


    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

          This is a pure process document, which updates the process
          for registering Enumservices; IANA as most affected party
          has review this document.

                                                      Thu, 25 Feb 2010

  (1.a) Who is the Document Shepherd for this document?

        Bernie Hoeneisen

        Note: Bernie is at the same time lead author of this
              document. Should anyone on IESG have an issue concerning
              "checks and balance in the system", Bernie would step
              back as Document Shepherd immediately.  (The reason for
              this unusual situation is known the the Shepherding AD.)


        Has the Document Shepherd personally reviewed this version of
        the document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

        Yes


  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members?
       
        Yes


        Does the Document Shepherd have any concerns about the depth
        or breadth of the reviews that have been performed?

        No concerns       


  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

        No concerns


  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?

        No concerns


        For example, perhaps he or she is uncomfortable with certain
        parts of the document, or has concerns whether there really is
        a need for it. In any event, if the WG has discussed those
        issues and has indicated that it still wishes to advance the
        document, detail those concerns here.

        All issues have been resolved


        Has an IPR disclosure related to this document been filed? If
        so, please include a reference to the disclosure and summarize
        the WG discussion and conclusion on this issue.

        Yes
        https://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-enum-enumservices-guide


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

        Strong consensus, no outstanding objections; any objections
        raised have been resolved
       

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

        No


  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

        The ENUM WG secretary has performed a nit review on this document;
        no open issues.


  (1.h) Has the document split its references into normative and
        informative?

        Yes       


        Are there normative references to documents that are not ready
        for advancement or are otherwise in an unclear state?  If such
        normative references exist, what is the strategy for their
        completion?

        (Cross-)references require the following documents to be
        published as cluster:

        - draft-ietf-enum-3761bis     
        - draft-ietf-enum-enumservices-guide
        - draft-ietf-enum-enumservices-transition

       
        Are there normative references that are downward references,
        as described in [RFC3967]? If so, list these downward
        references to support the Area Director in the Last Call
        procedure for them [RFC3967].

        No downrefs


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226].

        IANA reviewed the document several times; any issues raised by
        IANA have been resolved


        If the document describes an Expert Review process has
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during the IESG
        Evaluation?

        This document specifies Expert Review; experts to be appointed
        by the IESG


  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

        N/A (IANA is responsible for the XML chunk)


  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

          This document specifies a revision of the IANA Registration
          Guidelines for Enumservices, describes corresponding
          registration procedures, and provides a guideline for
          creating Enumservice Specifications.


    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

          Non-contentious document


    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

          This is a pure process document, which updates the process
          for registering Enumservices; IANA as most affected party
          has review this document.

[Note]: 'Given up on getting proto write up. Will move ahead without one.

cluster with
- draft-ietf-enum-3761bis
- draft-ietf-enum-enumservices-guide
- draft-ietf-enum-enumservices-transition' added by Cullen Jennings

IANA questions/comments:

ACTION 1:

Upon approval of this document, the IANA will make the following
changes in the "Enumservice Registrations" registry at
http://www.iana.org/assignments/enum-services

OLD:

Reference: [RFC3761]

NEW:

Reference: [RFC-enum-enumservices-guide-16]

ACTION 2:

The registration procedure will be listed as Expert Review. We have
questions, however:

- Does Step 5 apply to documents that are submitted for
publication as RFCs? That is, is IANA responsible for sending
documents to the experts during the Last Call process?

- For registrations that are requested by generic specs: does
the specification require a second review after publication? If
so, rather than place the registration "on hold" after the initial
approval, we would prefer that the authors simply re-submit their
requests for a second expert review upon publication.

Posted related IPR disclosure: Comcast IP Holdings I, LLC's Statement about IPR related to RFC 3953, RFC 4415, RFC 4759, RFC 4769, RFC 4002, RFC 4355, RFC 4414, RFC 4725, RFC 4969, RFC 4979, RFC 5028, RFC 5278, RFC 5346, RFC 5067, RFC 5076, RFC 5105, RFC 2168, RFC 3401, RFC 3402, RF...