Re: Last Call: draft-ietf-enum-enumservices-guide (IANA Registration of Enumservices: Guide, Template and IANA Considerations) to Proposed Standard

[Pekka Savola <[e-mail]>]

On Tue, 26 May 2009, The IESG wrote:
> - 'IANA Registration of Enumservices: Guide, Template and IANA
>   Considerations '
>   <draft-ietf-enum-enumservices-guide-16.txt> as a Proposed Standard

This is an ops-dir review.  I'm only superficially familiar with ENUM, 
so take the comments with a grain of salt.  I did not see major issues 
with the document, but the document could be improved by a clarifying 
revision.

Wrt. operational considerations, given that the document deals with 
IANA registrations, I do not see much that should be a cause for 
concern. Registration documents must include a section on DNS 
considerations, which could possibly discuss some operational aspects 
as well (some of this below).  Personally identifiable information has 
already been highlighted in the document.  Management-side of O&M does 
not appear to be relevant in this case. The usability and control of 
enum from users' point of view is a possible issue but that goes 
beyond the scope of this document.

Some specific comments below:

substantial
-----------

5.7. DNS Considerations (MANDATORY)

.. I note that exampe DNS considerations mostly relate to DNS protocol.  I
wonder about DNS operations related considerations.  For example, is the
usage expected to incur a significant (quantifiable?) load on the name
server chain?  Are there recommendations/restrictions/assumptions wrt TTL of
the records (somewhat related to the previous)?

Further I assume that DNS records related to the enum services are "static"
in such a fashion that they can be protected if needed by DNSSEC signing. 
Is this a correct assumption?  There is no clear prohibition of defining
"synthetic" or synthethizing DNS records that would be generated on the fly.
(I'm not sure if this would even be interesting to someone...)


semi-editorial
--------------

    This document specifies a revision of the IANA Registry for
    Enumservices, which was originally described in [RFC3761].  This
    document obsoletes Section 3 of RFC 3761.

.. yet in the header it says Obsoletes: 3761.  What about the rest of 3761?
I'd say it's best that the whole 3761 gets obsoleted in some manner.

    The IETF's ENUM Working Group has encountered an unnecessary amount
    of variation in the format of Enumservice Specifications.  The ENUM
    Working Group's view of what particular information is required
    and/or recommended has also evolved, and capturing these best current
    practices is helpful in both the creation of new Enumservice
    Specifications, as well as the revision or refinement of existing
    Enumservice Specifications.

.. yet the revision of existing Enumservices Specification is only touched
upon in Section 8, which says doing the revision is a MAY.  Is this
sufficient?  (After reading the whole doc, it appears that there is an
effort in progress to revise these, but it is not clear if that process is
exhaustive.)

In Section 9, you describe extension of existing enumservices. 
If an enum service is extended, does the extended version need to comply
with this document (Section 8 could be read to imply that but this is not
100% clear)?

    Types and Subtypes MUST conform to the ABNF specified in
    [I-D.ietf-enum-3761bis].

    The ABNF specified in [I-D.ietf-enum-3761bis] allows the "-" (dash)
    character for Types and Subtypes .

.. when I search for "ABNF" in I-D.ietf-enum-3761bis, I come up with one
hit, and it seems to be in an irrelevant spot.  I'm not sure if ABNF is
defined clearly enough in I-D.ietf-enum-3761bis (and that document could be
improved); in addition, given this is not very clear, I'd suggest a more
specific reference in this document (e.g. pointing to specific sections of
3761bis one should conform to).

6.5.3. Outcome 3: Experts Reject the Registration Document

    The expert might reject the Registration, which means the Expert
    Review Process is discontinued.  For appeals, see Section 7.3.

.. I'm not sure in which case the result might be a rejection instead of
"changes needed", but should you also point to some other recourse other
than the appeals process?  For example, "Go back to step 1 and
reconsider whether a registration is needed". :-)

7.2. Review Guidelines

.. one of the things that could perhaps be explicitly listed here is
verifying that the type name does not conflict with any well-known other
name (e.g. the example given in the document where "imap" was proposed for
"internet mapping" service).

11.1.4.2. Published as generic Specification

.. in S 11.1.2 you require IANA to escrow the specification, so I guess it
should be stated in the required IANA steps in the last paragraph of this
section as well.

13.1. Normative References

    [RFC2223]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
               RFC 2223, October 1997.

.. this is a down-ref problem: BCP referring to an informational document.
Is this critical for understanding this document?  If not, it could be moved
to an informative reference.

editorial
---------

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.  Examples of such
    Enumservices include 'vpim' [RFC4238] and 'vCard' [RFC4969].

.. I would suggest replacing "vCard" with another example or removing it
because it does not seem to conform to the RECOMMENDED all-lowercase
representation.

In Section 5.2:
    o  Enumservice Subtype (<subtype>):

.. I understand that subtype can be empty.  Does this mean it's unspecified
and/or omitted?  You should probably describe what to do in this case; the
preamble in S 5.2 seems to indicate that all the following elements are
mandatory -- if that's not the case, the mandatory or optional ones should
be clearly marked.

6.4. Step 4: Submit Registration Document


    If the Registration Document is to be published as RFC, the normal
    IETF publication process applies (see [instructions2authors]), i.e.
    the Registration Document is submitted to the RFC Editor in the form
    of an Internet Draft.  For Independent Submission the guidelines in
    Independent Submissions to the RFC Editor [RFC4846] apply.

.. the second part in first sentence (after i.e.) is misleading.  While that
is the ultimate "submission", if IETF publication process is followed, the
document needs to go through a working group or via AD-sponsored paths, and
finally it will end up at the RFC-editor as an Internet-draft.  It is not
submitted to the RFC-editor directly.  This occurs only when when
independent submission to RFC-editor is used.  Rewording seems necessary.
(It seems both these choices are acceptable and the author can pick one.)

6.4. Step 4: Submit Registration Document

    For publications as RFC Steps 6 below does not apply.
...
    The Step 6 below does only apply in case the Registration Document is
    to be published in a specification other than RFC.

.. unnecessary duplication, remove one of these?

In 11.1.3:
    [I-D.hoeneisen-enum-enumservices-transition] updates the existing
    Enumservices into the new IANA Registration Template.

.. replaced by draft-ietf-enum-enumservices-transition-00