Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 19 June 2014 11:16 UTC

Return-Path: <shollenbeck@verisign.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 1D53F1A036D for <eppext@ietfa.amsl.com>; Thu, 19 Jun 2014 04:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 PnaAhHfT3wO4 for <eppext@ietfa.amsl.com>; Thu, 19 Jun 2014 04:16:12 -0700 (PDT)
Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BBC1A014F for <eppext@ietf.org>; Thu, 19 Jun 2014 04:16:09 -0700 (PDT)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKU6LGeREa1zZk0G8q3L4OChesltsWy5GU@postini.com; Thu, 19 Jun 2014 04:16:12 PDT
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s5JBG82a032423 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 07:16:08 -0400
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0174.001; Thu, 19 Jun 2014 07:16:08 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: Marc Groeneweg <Marc.Groeneweg@sidn.nl>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
Thread-Index: AQHPPS0YgCxNWBlNXk+aQfXNlhT+aJrcBN6AgAKwP4CAAInngIBDOB+AgAR9xwCAAEctgIBRZEmAgABD9WA=
Date: Thu, 19 Jun 2014 11:16:07 +0000
Message-ID: <831693C2CDA2E849A7D7A712B24E257F494246E5@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
References: <535E2642.3010104@sidn.nl> <CF83D24B.5DC99%jgould@verisign.com> <CFC857BE.157C2%marc.groeneweg@sidn.nl>
In-Reply-To: <CFC857BE.157C2%marc.groeneweg@sidn.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.173.152.4]
Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F494246E5BRN1WNEXMBX01vc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/eppext/AKJkPG8inBSkjwgxD4_dFE2G2rM
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback
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: <http://www.ietf.org/mail-archive/web/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: Thu, 19 Jun 2014 11:16:15 -0000

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Marc Groeneweg
Sent: Thursday, June 19, 2014 3:09 AM
To: eppext@ietf.org
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

All,

Thank you all for the given feedback. The authors have considered your
feedback, and they make sense EPP protocol wise.

When we started the EPPEXT WG, we promised we would document what is
currently implemented, and that is the draft as is. The changes are
significant to the current implementation at SIDN, our registrars and
what's implemented in EPP clients already, so changing the draft would
mean there would be no implementation. So we would like to stick to the
Draft, and register this version as a SIDN version of the Key Relay.

How about registering EPP-keyrelay as is for now with the draft as
documentation, as it is an implemented extension, and progress with a
new version of the draft aimed to be accepted as EPP RFC for a
generic relay command? All your feedback is being considered as input for
this new version, which we are discussing internally at this moment.

[SAH] I see value in this. Documents that describe existing implementations are often published as Informational RFCs, and the approach we're taking  should be able to accommodate the registration of non-standard extensions. I'm OK with the idea of using this document to explore that kind of registration use case.

Scott