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