Subject: [Enum] review of draft-ietf-enum-experiences-03.txt

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 31 Oct 2005 16:59:55 +0100

All,

having reviewed the ENUM experiences draft, i'd appreciate your comments on
the following issues [sorry, comments are a bit out of order]:

- The term "ENUM" should be expanded somewhere in the document, most
probably in the "Introduction" section where it is mentioned first (if not
considering the abstract). Same for "NAPTR".

- Section 6 is closely related to the EDNS0 draft - so imho there should be
at least a reference to it. However, one of the authors of the EDNS0 draft
has already indicated that recent progress there might trigger an update of
this section anyways. Other issue: I'm unsure if we want to introduce a
dependency here..

- [small nit] The document asks developers to raise "other issues" in the
ENUM WG - However, the ID-Checklist recommends to avoid reference to a
specific WG for future actions (just in case the WG does not exist anymore). 
  Anyway, i think we're fine here since there is a second contact option (the
authors) listed as well.

- Section 3, character sets:

"SED-like" should be changed to "sed-like" (at least that's how it appears
in RFC3402.

The RegExp seperator falls a bit short in this section: Unless i've
overlooked something, any octec except digits 1-9 and 'i' can be used as
seperator according to RFC3402 (section 3.2) - I think that using 0xff (or
even 0x00 ?) as seperator would definitely confuse most current clients...
The "Client" recommendation should at least mention this.

Generally, clients should be prepared for "bad" octets even in the fields 
where such octects would be illegal. They should be able to drop such 
records without affecting other records still to be processes. I'm missing a 
sentence about this somewhere.

I could not find out what the acronym "UCS" means in the document - please
expand.

- Examples: Please change those domain names to RFC2606 compatible names
(example.com/net/org).

- around Section 4.2 (including the two paragraphs before this section)

Please enlighten my where NAPTRs with the same ORDER and PREFERENCE collide 
with the specs (as long as they bear different services). I read [again] 
thorugh the relevant sections in RFC3761 and RFC3403, without any luck - am 
i the guy with the "buggy provisioning system"? ;)

that's all for now --

cheers

Alex Mayrhofer

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