[dns-dir] FW: Last Call: draft-ietf-enum-enumservices-guide (IANA Registrationof Enumservices: Guide, Template and IANA Considerations) to ProposedStandard

["Romascanu, Dan (Dan)" <[e-mail]>]

 Some DNS Consideration comments here from Pekka. 

Dan


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Pekka Savola
Sent: Wednesday, June 03, 2009 12:33 PM
To: [e-mail]
Cc: [e-mail];
[e-mail]
Subject: Re: Last Call: draft-ietf-enum-enumservices-guide (IANA
Registrationof Enumservices: Guide, Template and IANA Considerations) to
ProposedStandard 

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
_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf