[eppext] Genart LC review draft-ietf-eppext-keyrelay-10

Robert Sparks <rjsparks@nostrum.com> Wed, 25 November 2015 21:45 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A00B1B30D4; Wed, 25 Nov 2015 13:45:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pe8AOtewD-uj; Wed, 25 Nov 2015 13:45:47 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6551A8A90; Wed, 25 Nov 2015 13:45:47 -0800 (PST)
Received: from unnumerable.local (pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAPLjj3t098755 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Wed, 25 Nov 2015 15:45:46 -0600 (CST) (envelope-from rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-210-37.dllstx.fios.verizon.net [173.57.210.37] claimed to be unnumerable.local
To: General Area Review Team <gen-art@ietf.org>, ietf@ietf.org, eppext@ietf.org, draft-ietf-eppext-keyrelay@ietf.org
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <56562C04.2060308@nostrum.com>
Date: Wed, 25 Nov 2015 15:45:40 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/R2WPqqq6xKWQlNrK54mHzqDH9gw>
X-Mailman-Approved-At: Fri, 27 Nov 2015 17:12:35 -0800
Subject: [eppext] Genart LC review draft-ietf-eppext-keyrelay-10
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Nov 2015 21:45:49 -0000

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