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

Rik Ribbers <> Tue, 15 December 2015 19:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A626E1AC432; Tue, 15 Dec 2015 11:20:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.084
X-Spam-Status: No, score=0.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YytTHg3YZbFZ; Tue, 15 Dec 2015 11:20:28 -0800 (PST)
Received: from ( [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 251161AC429; Tue, 15 Dec 2015 11:20:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt;; s=sidn-nl; c=relaxed/relaxed; h=from:to:cc:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-mailer:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:mime-version; bh=oQjxuSVV31Yj6u2T0/6YszKLEzk278e/E7QPcOrMZ4E=; b=osJCNPsSgmKUNMCSmdmWLwFu8P1IR+wq7XmeW3rmzShhlmSqQ6RtAEWKwmxNdtpK18Ahq0nx5kiKNkZ42h8LosuiUJ2ZPSCQs7x4C/J6RgnH7o67wvnhwJKbAcI4D9sGgx3zFiC9ue0dwcaq5ghHJ4gcr8xAlJlXGeqspTywuO4qkcD7ACRLcGHhvMdG4S/6HkD4DsQYRFj0Ru8ES/GNFfN46ootbCE7hJ5eccnikADbE2xIs9Bejbr7ujmcWyL0feUQYpKM1RVjrskAbZh6jdfOZtUA7w0A09ccsNRXwv6oe70STb1T2gQbBJ6SERc8G+RpvBbkSB8bBV30+420Yw==
Received: from ka-mbx03.SIDN.local ([]) by with ESMTP id tBFJKP6B032311-tBFJKP6D032311 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 15 Dec 2015 20:20:25 +0100
Received: from ka-mbx02.SIDN.local ( by ka-mbx03.SIDN.local ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 15 Dec 2015 20:20:29 +0100
Received: from ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549]) by ka-mbx02.SIDN.local ([fe80::9855:369a:1ca4:6549%13]) with mapi id 15.00.1130.005; Tue, 15 Dec 2015 20:20:29 +0100
From: Rik Ribbers <>
To: Robert Sparks <>
Thread-Topic: Genart Telechat review draft-ietf-eppext-keyrelay-11
Thread-Index: AQHRNqbpgs5JTL/8Q0Sj9dFJjMVwgJ7MXTuA
Date: Tue, 15 Dec 2015 19:20:29 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-mailer: Apple Mail (2.3112)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_7DEAB4FB-C67B-4069-A0F8-D89E4841B791"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, General Area Review Team <>, "" <>, Marc Groeneweg <>, eppext <>
Subject: Re: [eppext] Genart Telechat review draft-ietf-eppext-keyrelay-11
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Dec 2015 19:20:30 -0000


> 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 ;-))