Review: draft-ietf-enum-3761bis-06.txt

Hi,

please, find below my comments on the 3761bis draft. As soon as these
comments are addressed, I will get the IESG as a whole to review the draft.

Cheers,

Gonzalo



Review: draft-ietf-enum-3761bis-06.txt

The titles of all subsections under Section 3.3 contain "Non-Terminal
NAPTRs". Given that the title of Section 3.3 already mentions that, you
may want to consider removing it from the rest of the titles.

Regarding the document structure, separating the sections that provide
normative behavior for clients and for entities provisioning ENUM
services is a very good idea. However, there are a few places in the
document where that distinction is not made (or is not clear enough). As
an example, the following paragraph at the end of Section 3.3.2.3.3
seems to contain rules for both, clients and provisioning entities:

   This field MUST be
   interpreted as holding the FQDN that forms the next key output from
   this non-terminal rule. Conversely, the Regexp field MUST be empty in
   a non-terminal NAPTR encountered in ENUM processing, and ENUM clients
   MUST ignore its content.

Another example seem to mix client rules with provisioning rules is
Section 3.3.2.3.2. The fact that some of the rules are described in
passive voice makes the distinction between both types of rules even
less clear.

Is the intention with Section 3.5 to summarize all the normative
behavior for clients or just to provide additional normative behavior in
addition to the normative statements already present in previous
subsections under Section 3?

The same question about Section 5. Section 9 states that those sections
contain "implied protocol requirements". Expanding what that means at
the beginning of each of the two sections would be useful.

The audience of some normative statements is not clear enough. For
example, in Section 1.2: ... and such private use MUST NOT be called
"ENUM"... Who must not call such a use ENUM? Implementers?

In Section 2, the normative MAY should not be normative: This
   implies that applications MAY send DNS queries when, for example, a
   user mistypes a number in a user interface.

Section 3.2.1 talks about the possibility of major problems but then
only says that it is reasonable to have a common ORDER value to avoid
that. Do we want to say RECOMMENDED instead up front instead of waiting
until the end of that subsection?

That section also says:
   Thus, one
   should expect to have a set of NAPTRs in a zone with identical ORDER
   field values and different PREFERENCE/PRIORITY field values; not the
   other way around.

What happens if it is "the other way around"?

Section 3.3.2.1 provides a definition for non-terminal NAPTR. You may
want to consider providing that definition before the current Section 3.3.1.

In Section 3.3.2.2, is loop detection mandatory, recommended, or just
optional?

Section 3.4.1:
OLD:
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404]
   and by this document.

NEW:
[RFC2915] and [RFC2916] have been obsoleted by [RFC3401] - [RFC3404]
   and by this document, respectively.