IETF Logo Mail Archive

Re: [Gen-art] Genart Telechat review draft-ietf-eppext-keyrelay-11

Jari Arkko <jari.arkko@piuha.net> Thu, 17 December 2015 12:51 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852381A1EEE; Thu, 17 Dec 2015 04:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 rK86P-sQI-Ry; Thu, 17 Dec 2015 04:51:04 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6001A1C02; Thu, 17 Dec 2015 04:51:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EC4C22CCBF; Thu, 17 Dec 2015 14:51:02 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDGPiyi9w8rq; Thu, 17 Dec 2015 14:51:02 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 700AB2CCAE; Thu, 17 Dec 2015 14:51:02 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_9E2D85D6-AFBE-4436-BD35-972F48C90431"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <0716DBF5-5FF7-45BB-AD0E-5985B5626EE6@sidn.nl>
Date: Thu, 17 Dec 2015 14:51:02 +0200
Message-Id: <45B9D1EB-17FF-4403-917C-1680FFA5CD7E@piuha.net>
References: <56562C04.2060308@nostrum.com> <566F1A78.6010006@nostrum.com> <0716DBF5-5FF7-45BB-AD0E-5985B5626EE6@sidn.nl>
To: Rik Ribbers <rik.ribbers@sidn.nl>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/tQDFePl-Ny6qokv_InUvUQaJAOk>
Cc: "ietf@ietf.org" <ietf@ietf.org>, General Area Review Team <gen-art@ietf.org>, "draft-ietf-eppext-keyrelay@ietf.org" <draft-ietf-eppext-keyrelay@ietf.org>, eppext <eppext@ietf.org>, Marc Groeneweg <Marc.Groeneweg@sidn.nl>
Subject: Re: [Gen-art] Genart Telechat review draft-ietf-eppext-keyrelay-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 12:51:05 -0000

Robert, thank you for your review(s), and Rik, thanks for the edits.
Your proposed wording below works for me.

Jari

On 15 Dec 2015, at 21:20, Rik Ribbers <rik.ribbers@sidn.nl> wrote:

> Robert,
> 
>> 
>> 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.
> 
> I’ll take that into consideration, as I have explained it in the response the wording isn’t that difficult anymore. There are some more IESG review comment on this section so I assume there will another version to before publication.
> 
> Current wording:
> 
> A server SHOULD NOT perform any transformation on data under server management when processing a \<keyrelay:create\> command.
> 
> Proposed wording:
> 
> A server SHOULD NOT perform any transformation on data under server management when processing a \<keyrelay:create\> command. The intent of this command is to put DNSSEC key material on the poll queue of another client. To make sure that this EPP extension is interoperable with the different server policies that already have implemented EPP this extension it is not classified as must not.
> 
> Please let me know what you think of this proposal (or send in text ;-))
> 
> Gr,
> Rik

v2.23.0 | Report a Bug | By Email