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