Re: Evaluation: draft-ietf-enum-rfc2916bis - The E.164 to URIDDDS Application (ENUM) to Proposed Standard

[hardie@qualcomm.com]

Ted Hardie          [   ]     [   ]       [ x ]      [   ]

I went back forth as to whether these were serious nits
or a mild discuss.  The tired lady mentioned in the nit
related to section 2.1 was the deciding factor.  In other
words, I think these should be fixed, but pushback is
welcome.


In the introduction:

   "like delegation through NS records and NAPTR records, one can look up
   what services are available for a specific domain name"

Would it not make more sense to say, "what services are associated with a
specific E.164 number"?  This is not general to all domain names.


For Section 1.2, the language seems less than clear.  How about:

    This document describes the operation of these mechanisms in the context
    of numbers allocated according to the ITU-T recommendation E.164.  The
    same mechanisms might be used for private dialing plans.  If the
    mechanisms are re-used, the suffix used for the private dialing plan
    MUST NOT be e164.arpa, to avoid conflict with this specification.
    Parties to the private dialing plan will need to know the the suffix
    used by their private dialing plan for correct operation of these
    mechanisms.  Further, the application unique string used SHOULD be
    the full number as specified, but without the leading '+'

In Section 2.1,  the draft says:


   For example, the E.164 number could start out as "+1-770-923-9595".
   To ensure that no syntactic sugar is allowed into the AUS, all
   non-digits except for "+" are removed, yielding "+17709239595".

I'm not sure "syntactic sugar" is clear.  Is the AUS a gas tank? :)
Frankly, I'd suggest deleting the second paragraph, as I don't think it adds
anything, but if it's kept, I'd suggest updating it to "the E.164 number could
be represented to a user as".  I'd also suggest using a known-to-be invalid
number.  A tired lady answer this number when I called it,
and she didn't know anything about this draft.

In section 2.4.2.1, the draft says:

   The mapping, if any, have
   to be made explicit in the specification for the Enumservice itself.
   A registration of a specific Type also have to specify the Subtypes
   allowed.

I think the grammar is off there.  how about:  "the mapping, if any, 
must be made
explicit"?


I'm concerned that section 2.5  might cause as much confusion as it
prevents.  How about replacing the whole thing with "The ENUM algorithm
always returns a single rule.  Specific applications may have
application-specific knowledge or facilities that allow them to
present multiple results or speed selection, but these should
never change the operation of the algorithm."

For the IANA consideration, the work requested by the first two paragraphs
is done.  I think that it would be betterto change it to note that 
the obsoleted RFC
requested these, and to give a pointer to the current IAB/ITU-T agreement.