Subject: [Enum] Another send: IESG review of rfc2916bis

From: Allison Mankin <[email-masked]>
Date: Sat, 28 Jun 2003 20:51:36 -0700

First send of this was from an unsubscribed address.

To:      [email-masked], [email-masked], [email-masked]
cc:      [email-masked], [email-masked], [email-masked],
	 [email-masked]

The IESG reviewed rfc2916bis on Thursday.  The review is not complete.
There will be further discussion on July 10, so there may be more comments
to come.  

There are Discuss comments about language and about the IANA
Considerations from Ted Hardie.  I suggest addressing all but one, that on
section 2.5, where I know the language is finely tuned.  

If July 10 does not produce more complex comments than these, the draft 
will not need a rev'd i-d, but can be fixed with RFC Editor notes, which
are diffs submitted with the approval.

Allison

---------

Ted Hardie's Discuss comments:

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

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

--------

P.S.  Here is what Ted said about Section 2.5 but I believe we should leave
it as is:

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."

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum