ENUM Implementation Issues and Experiences
RFC 5483

Note: This ballot was opened for revision 11 and is now closed.

(Jon Peterson) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) (was Discuss, No Objection) No Objection

Comment (2008-04-09 for -)
No email
send info
Support Peter Koch's comments from the DNS-DIR review that appear in Dan's DISCUSS.

(Ross Callon) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2008-04-08)
No email
send info
(And if it isn't going for Informational, I have a different review ready, because I read it thinking it was going for BCP.)

(Pasi Eronen) (was Discuss) No Objection

(Russ Housley) No Objection

(Chris Newman) No Objection

Comment (2008-04-10 for -)
No email
send info
Suggest adding one sentence to section 2.1:

This document does not itself revise DDDS or ENUM, but is intended to
provide technical input to future revisions of those documents.

(Tim Polk) (was No Record, Discuss) No Objection

Comment (2008-04-09)
No email
send info
(1) The backreference pattern is discussed in sections 8, 9, and 10.
These are "Collected Implications for ENUM Provisioning", 
"Collected Implications for ENUM Clients", and "Security Considerations"
respectively.  

The backrefernce pattern is never mentioned in sections 3 through 7,
which I considered the body of the document.   I found it confusing to
encounter "implications" without any supporting text in the body. My
confusion was resolved after reading the security considerations
section.  Perhaps a forward reference to section 10 from the
implications addressing backreference would be in order?

(2) In section 9.1, paragraph 3 I believe the final sentence should
state that, if present, a non-empty Regexp field MUST be ignored by
clients.

(Dan Romascanu) (was Discuss) No Objection

Comment (2008-04-10)
No email
send info
I jave cleared ny DISCUSS relying on Pasis's. 

I believe accepting the text suggested by Chris in his comment would be a good way to clarify the purpose of the document. 

DDDS appears in the Abstract, but is expanded only later at the third occurence. NAPTR is broadly used but never expanded in the document.

(David Ward) No Objection

Comment (2008-04-10 for -)
No email
send info
At some point we need to straighten out the category of Info, BCP for docs/specs that change the format, functionality and behavior of PS protocols.

Magnus Westerlund No Objection