I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-enum-experiences-08.txt
Reviewer: Brian Carpenter
Review Date: 2008-01-21 
IETF LC End Date: 2008-01-29
IESG Telechat date: (if known)

Summary: Clarification needed on advisory status vs normative keywords.

Comments: 

The Abstract says:

   This document captures experience in implementing systems based on
   the ENUM protocol, and experience of ENUM data that have been created
   by others.  As such, it is advisory, and produced as a help to others
   in reporting what is "out there" and the potential pitfalls in
   interpreting the set of documents that specify the protocol.

And in the Inroduction:
   ...This document mentions potential choices that
   can be made, in an attempt to help to foster interworking between
   components that use this protocol.  The reader is reminded that
   others may make different choices.

If it's advisory, how can it be a BCP? In fact, it uses the RFC 2119
terms in the "advice" and that makes it normative. I think the Abstract
and the first paragraph of the Introduction are out of line with the
rest of the document. The formal use of the RFC 2119 terms means that
this is more than advice.

6.2.2.  Non-Terminal NAPTRs - loop detection and response

   Where a chain of non-terminal NAPTRs refers back to a domain already
   traversed in the current query, this implies a "non-terminal loop".
   In ENUM processing, a chain of more than 5 domains traversed during a
   single ENUM query MAY be considered excessive, and an indication that
   a such a referential loop may have been entered.

Is this really a normative MAY? If so, it's very hard to parse. How about:

  An implementation MAY treat a chain of more than 5 domains traversed
  during a single ENUM query as an indication that a referential loop
  has been entered.

If that isn't what you mean, it isn't a normative statement.
(But section 9.1 suggests that this is the intended meaning.)

   There are many techniques that can be used to detect such a loop, but
   the simple approach of counting the number of domains queried in the
   current query MAY suffice.

That is definitely not a normative MAY. Lower case please!

10.  Security Considerations

   This document does not specify any standard.  It does however make
   some recommendations, and so the implications of following those
   suggestions have to be considered.

This sounds apologetic. I would just delete it.

11.  IANA Considerations

   This document is advisory, but does include one IANA consideration.
   This is the suggestion (in Section 7.1) that no-one should be allowed
   to register an Enumservice with any of its identifying tags set to
   "E2U".  IANA SHOULD reject such a request.

As noted, it can't be both advisory and a BCP using normative keywords.
And I don't see how IANA can be asked to decide whether to adopt a
"suggestion" or to interpret a SHOULD in such a complex technology.
I think this one needs to be unambiguous:

  IANA must not register an Enumservice with any of its identifying tags
  set to "E2U" (see Section 7.1).  

Typos:

5.3.1.  Compound NAPTRs and implicit ORDER/REFERENCE Values
...
   To avoid indeterminate client behaviour, it is recommended that ENUM
   clients SHULD process the Enumservices within a compound NAPTR in a
   left to right sequence.

s/SHULD/SHOULD/

5.4.  Processing Order value across Domains
...
   Two main questions remain from the specifications of DDDS and RFC
   3671:

s/3671/3761/