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

["Gould, James" <[e-mail]>]

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
Principal Software Engineer
[e-mail]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com




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

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>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: [phone]  M: [phone]
>Mailto: [e-mail]
>XMPP: [e-mail]
>HTTP://www.sidn.nl/
>-----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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/eppext