RE: draft-gould-rfc4310bis-06.txt Submitted for Review
"Hollenbeck, Scott" <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <046F43A8D79C794FA4733814869CDF07031D0592@dul1wnexmb01.vcorp.ad.vrsn.com> |
The informative reference to 4310 is perfectly appropriate, but yes, any mention of "updates" should be changed. I'll let Jim take care of your other comments since he's holding the editing pen. Scott ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Friday, February 26, 2010 5:15 AM To: Gould, James Cc: EPP Provreg Subject: Re: [ietf-provreg] draft-gould-rfc4310bis-06.txt Submitted for Review > I submitted http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt <http://www.ietf.org/id/draft-gould-rfc4310bis-06.txt> > which includes the feedback that I received so far and will be the > basis for the IESG review. Please let me know if you have any > feedback to the latest draft. Not being an EPP guru, what's the rationale for requiring a 2102 error if the server doesn't support <secDNS:update urgent="1"> or <secDNS:maxSigLife> ? I would have thought that Postel's law should apply, otherwise a registrar has to have advance knowledge of which registries support those elements and which don't, and alter their submitted XML accordingly. I can't immediately see how any harm would come from simply ignoring those elements. Also, I note that §4 says that a server MUST support either <secDNS:dsData> or <secDNS:keyData>, but not both (unless in transition from one to the other). However I can find no guidance on what should happen if the client sends the wrong one. The schema is clear that it's a choice, but that only affects individual messages, and doesn't reflect the server's capabilities. BTW, §10 (Acknowledgements) says that this doc _updates_ 4310 and refers readers to that document's acknowledgements section, whereas elsewhere it's clear that it obsoletes it. There's also an informative reference to 4310. I don't believe it's permitted to both obsolete a document and refer to it at the same time. kind regards, Ray -- Ray Bellis, MA(Oxon) MIET Senior Researcher in Advanced Projects, Nominet e: [email protected], t: +44 1865 332211