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

From: "Gould, James" <[email-masked]>
Date: Mon, 7 Jul 2014 20:08:29 +0000

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

James Gould
Principal Software Engineer
[email-masked]

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

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

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Jul 2014 10:54:29 +0000

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; [email-masked]
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

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

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

All,

[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

---

From: Antoin Verschuren <[email-masked]>
Date: Wed, 9 Jul 2014 15:14:14 +0200

op 09-07-14 12:54, Hollenbeck, Scott schreef:
> WG chairs: can we do this? Our charter doesn’t specifically
> identify the intended status of the in-charter extensions.

[hat on]
Our charter does not specify that documentation for an extension needs
to have a status, as that was left as the topic for discussion for the
process in the registry document.
The charter talks about registration of extensions, not standards.

The milestones seem to suggest that the 3 example extensions need to be
documented by the IETF though, be it that the status of the IETF
document is not defined in the milestones, they can also be
experimental. That seems to suggest that "documentation required" in the
registry document is not sufficient to meet our charter, and that "RFC
required" is the minimum for at least the 3 example extensions.

The charter also says that "the problem of non-standard extension
duplication by multiple operators" is the problem we're trying to solve
with the registry. I would say keep it simple. It's a standard, or it's
not, it's implemented, or it's not.

I would advise the WG to review the registry document in WGLC with these
specific requirements in mind.
There is a possibility to not register the extensions mentioned in our
charter due to a lack of standardization, but standardizing the
extensions or at least documenting them in the IETF is in our charter.
[/hat on]

[no hat]
The wish to harmonize extensions is a specific wish from the registrar
community, that I don't see well represented in the EPPEXT WG.

The specific wish to be able to register a proprietary extension came
from some in the registry community as an argument against "RFC required".

I may have a suggestion around this:
What if we allow proprietary extensions to be registered, but with the
specific notion that it is a proprietary extension and not a standard?

One way to do this is to say that when the "TLDs" field in the registry
identifies specific TLD's, "documentation required" is sufficient, but
when "ANY" or "Any" is used, it must be a standard and therefor "RFC
required". Perhaps the words "ANY" or "Any" should be replaced by
"STANDARD" or "Standard"?

This way we accommodate inclusion in the registry for proprietary
extensions, but we do meet our charter in trying to solve the
non-standard extension duplication. Many registries will only implement
the "standard" extensions, and will be aware that a proprietary
extension may not be supported by all registrars so they loose market
share.

Mind though that it is not compulsory to register a proprietary
extension. I personally feel registering a proprietary extension is a
failure to meet market demand.
[/no hat]

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: "Gould, James" <[email-masked]>
Date: Wed, 9 Jul 2014 14:23:21 +0000

Antoin,

There may be extensions that are proprietary (not standard) and not
specific to any one or a small set of TLD¹s.  Registries most likely have
built platforms that support a pluggable set of TLD¹s, where the
extensions are applicable to the platform (or set of platforms), and may
be used for most or all of the TLD¹s on the platform.  I believe most of
the extensions will be classified as ³Any² even if they are proprietary by
not going through the IETF process.  Actually, only a few have fully
followed the RFC process, some have been posted as IETF drafts, and many
more have been defined outside of the IETF.  EPP makes it easy to create
extensions to meet specific business needs that may not be applicable to a
large set of TLD¹s.  I don¹t view registering a proprietary extension as a
failure to meet market demand, but as a reality of meeting different
business models.  As a co-author of an EPP extension RFC, as a co-author
of an inflight EPP extension IETF draft, and as an author of many
proprietary EPP extensions, I understand the tradeoffs of meeting specific
business needs and collaborating with the community on a standard.  I
believe it is important for the proprietary extensions to get registered
into the extension registry, with an adequate amount of documentation, to
help identify overlap and open up the opportunity for consolidation.  The
Registry Operations Industry Alliance being discussed on the regops
mailing list may be a good place to help with the consolidation.

-- 
 
JG

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

On 7/9/14, 9:14 AM, "Antoin Verschuren" <[email-masked]> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>> WG chairs: can we do this? Our charter doesn¹t specifically
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.11 (GNU/Linux)
>
>iQEcBAEBAgAGBQJTvUAmAAoJEDqHrM883AgnzmUH/Aqe1DDfs5t0s0Zqk70DfG/M
>Sp9jhYQJkSz+ignqKXU/A+q3G4QZ39p34TV551eqBMBuqdVSq3nlMHTVrQj4xLdW
>rS2ZRiW0cRXQhf/Ei6DLj572yN4QusBIuPIdw//vuflC2xgKzslAyaBLrL577RHD
>Av7r/Lq9wtyvdYmBjJQ+x6y20TnnLuKDpGzYKXWaIWhReHQH6ODXmsSOu4Qjs+dL
>YdteEDj5DBtCrjZjsMPIi1nPEaXEwGhf/GnmH3Ye17HzHqqs7TAQ5dqw8r9+2bI8
>lRuzBKgUy8BLheCHetcUvxEOmwA+zx1lVDQheBjcN7hEc+qWYD6n6saQuz1CG2E=
>=V1ur
>-----END PGP SIGNATURE-----
>
>_______________________________________________
>EppExt mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/eppext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 10 Jul 2014 12:21:45 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Antoin
> Verschuren
> Sent: Wednesday, July 09, 2014 9:14 AM
> To: [email-masked]
> > WG chairs: can we do this? Our charter doesn't specifically

I'd say just the opposite. The fact that our charter doesn't explicitly define the intended status means that we have some flexibility. It may be that the three we're considering are intended to be RFCs because we started with documents that happened to be I-Ds, but I don't think that implies that every extension should have an RFC requirement - or that all RFCs need to be on the Standards Track.

Back to the document that's the subject of this message: We all need to take another look at it if the idea is to document it as an as-is, informational document that describes an existing implementation. It currently says "Intended status: Standards Track". This note from one of the authors:

http://www.ietf.org/mail-archive/web/eppext/current/msg00117.html

suggests that the intended status should be "Informational". We need to make a decision and proceed accordingly. I would be OK with an Informational document as long as appropriate changes are made to reflect that status and doing so would be consistent with our charter.

Scott