Last Call Review of draft-ietf-eppext-keyrelay-10
review-ietf-eppext-keyrelay-10-genart-lc-sparks-2015-11-25-00
Request | Review of | draft-ietf-eppext-keyrelay |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2015-12-04 | |
Requested | 2015-11-20 | |
Authors | Rik Ribbers , M. Groeneweg , R. (Miek) Gieben , Antoin Verschuren | |
I-D last updated | 2015-11-25 | |
Completed reviews |
Genart Last Call review of -10
by Robert Sparks
(diff)
Genart Telechat review of -11 by Robert Sparks (diff) Opsdir Last Call review of -10 by Tina Tsou (Ting ZOU) (diff) |
|
Assignment | Reviewer | Robert Sparks |
State | Completed | |
Request | Last Call review on draft-ietf-eppext-keyrelay by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 10 (document currently at 12) | |
Result | Ready | |
Completed | 2015-11-25 |
review-ietf-eppext-keyrelay-10-genart-lc-sparks-2015-11-25-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-eppext-keyrelay-11 Reviewer: Robert Sparks Review Date: 14Dec2015 IETF LC End Date: 4Dec2015 IESG Telechat date: 17Dec2015 Summary: (Still) ready for publication as Proposed Standard Thanks for addressing most of my nits. I think it's a problem (not for this document, but for the overall work) that draft-koch-dnsop-operator-change isn't moving forward. I think the group should spend energy on how to capture what it was saying. I also still think you would have a stronger document if it discussed the SHOULD NOT in the security section as I suggest below. I think you read that to be me suggesting you change it to MUST NOT. That was not the intent. I was asking you to add to the document _why_ it wasn't MUST NOT. On 11/25/15 3:45 PM, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-eppext-keyrelay-10 > Reviewer: Robert Sparks > Review Date: 25Nov2015 > IETF LC End Date: 4Dec2015 > IESG Telechat date: (not yet scheduled) > > Summary: Ready for publication as Proposed Standard with nits > > This is a small nit, but please consider changing the document to > address it. The motivation for this extension leans on improving the > security of transferring information between registrars. It should be > recast as providing better automation and reliability instead. In > practice (and I think in specification), it hinges on passing a > password from the registrar of record to the gaining registrar through > some unspecified means (though typically through the registrant). That > password is required to be placed in the create by the gaining > registrar as specified in this document in order for that create to > succeed at the registry. While it would be impractical and > error-prone, the same channel that was used to hand this password > around _could_ be used to pass the keying material this extension > addresses. > > Reading draft-koch-dnsop-operator-change (an informational reference > currently) helped greatly with understanding this document. That draft > expired in 2014. Please be sure it advances, and consider making it a > normative reference. > If it is not going to move forward, consider pulling some of the > transfer mechanic recommendations and the definitions of > losing/gaining entities into this draft, unless they've already made > it into the RFC series somewhere else? > > The security considerations document says a server SHOULD NOT perform > any transformation on data under server management when processing a > <keyrelay:create> command. Can this point to more detailed discussion > somewhere? Why is this not a MUST NOT? (What are the conditions where > violating the SHOULD NOT is the right thing to do? What are the risks > a server takes if it performs such a transformation?) > > Micro-nit : In section 2.1 where you say "The <expiry> element MUST > contain one of the following", consider saying "The <expiry> element > MUST contain exactly one of the following". > > RjS > >