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

["Hollenbeck, Scott" <[e-mail]>]

WG chairs: can we do this? Our charter doesn't specifically identify the intended status of the in-charter extensions.

Scott

From: Gould, James
Sent: Monday, July 07, 2014 4:08 PM
To: Hollenbeck, Scott; Marc Groeneweg; [e-mail]
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

I concur.  I believe that we're going to see many custom extensions that will be registered as is, but that will be of general interest for collaborative rework as Standards Track drafts.  The Key Relay draft would be a good representative use case.
--

JG

[cid:image001.png@01CF9B42.A50F3DA0]

James Gould
Principal Software Engineer
[e-mail]<mailto:[e-mail]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: <Hollenbeck>, Scott <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 19, 2014 at 7:16 AM
To: Marc Groeneweg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [eppext] draft-ietf-eppext-keyrelay-00 Feedback

From: EppExt [mailto:[e-mail]] On Behalf Of Marc Groeneweg
Sent: Thursday, June 19, 2014 3:09 AM
To: [e-mail]<mailto:[e-mail]>
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