Re: [regext] REGEXT Interim Meeting 2018OCT16

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

Patrick,



I like how you have broken down the problem into discrete registry implementation cases that can be applied to any EPP extension.  To make the core object-extension (draft-gould-carney-regext-registry) workable, we need to target case 1 (fully RFC-compliant registry implementers) and case 3b (implement base and standard policy extensions along with a server-specific policy extension for unique policies), since the goal is to define policies associated with the SHOULDs, MAYs, and options included in RFCs.  Case 3b could also be a sub-option for case 1 (1a), since a fully compliant registry implementer may have unique RFC-compliant policies that they need to define.  Targeting case 2 does not make any sense, since those not implementing draft-gould-carney-regext-registry will most likely not speak up.  Targeting case 3a is highly unlikely to be successful, since why would an implementer change their policy to support defining their policy externally?  Also, case 3a is equivalent to case 1 from a draft-gould-carney-regext-registry  perspective.  I also have a 3c case, where the implementer creates a Registry Mapping-like implementation by not following the normative language or/and customizing the XML schema.  In the end, the best that we can do is to define a solid base draft that covers the SHOULDs, MAYs, and options of the EPP RFCs, with the ability to define system-level and zone-level policy extensions that cover the policies of specific EPP extensions or a server-specific policy.  I would imagine that if there is a need for a server-specific policy extension, that the implementer would define just one.  For clarity, I include the revised draft-gould-carney-regext-registry implementation cases below:



  1.  Fully RFC-compliant Registry Implementers - Implementation driven by policy/business/marketing case.
     *   Optionally create Server Policy Extension for server-specific policies
  2.  Registry Non-Implementers - Registries not implementing for a variety of reasons.
  3.  Non RFC-compliant Registry Implementers
     *   Change policies to be compliant with RFCs
     *   Define Server Policy Extension for server-specific policies (e.g., RFC overrides)
     *   Create Registry Mapping-like implementation (e.g., not following normative language and/or XML schema in draft-gould-carney-regext-registry)



—

JG







James Gould

Distinguished Engineer

[e-mail]



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 12/11/18, 1:53 AM, "regext on behalf of Patrick Mevzek" <[e-mail] on behalf of [e-mail]> wrote:



    On Tue, Nov 27, 2018, at 11:28, Gould, James wrote:

    >     >     * Ensure that the hostAddr model of RFC 5731 is supported

    >     > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/1>    *

    >     > *Discussion*

    >     >  * In the case of a zone that supports domain:hostAddr instead of

    >     > domain:hostObj,

    >

    >     No. It is not "instead".

    >     Have a look at the example on page 19 of some registry documentation

    >     at

    > https://www.viestintavirasto.fi/attachments/fi-verkkotunnus/EPP_interface.pdf



    [..]



    > The purpose of draft-gould-carney-regext-registry and the policy

    > extensions is to define the policies around the SHOULDs, MAYs, and

    > options included in extension RFCs, I-Ds, custom extensions, and to

    > define the server-specific policies.  If a registry chooses not to

    > follow the MUSTs in the extensions, that is their choice.  They can

    > define their custom, non-compliant policies in a server-specific policy

    > extension of draft-gould-carney-regext-registry.  Custom policy

    > extensions can be created that define system-level and zone-level

    > policies that don't need to go through the IETF.  There is no need to

    > attempt to address non-compliant policies in the standards track I-Ds.



    I think you are missing the point I try to raise here.

    It is of course very easy to dismiss this specific case (but there are tons of others)

    because the RFC says "MUST", and the case does not follow it, so it is deemed invalid

    per RFC specifications and can then be ignored.

    Technically, yes.

    But this has consequences for the future.



    First, let me reiterate how important I think this extension is, and I wished we

    had it many years ago already. With it, life of registrars would be tremendously easier. Which would then also make registries life easier.



    **IF** (and this is the big if and the core of my point) it gets implemented, and this is where I fear problems, even more so because there is basically no discussion

    on this list from other registries about it.



    For me the future can morph into the following cases:



    1) a registry is fully conformant with all RFCs and hence could implement this

    extension as is without difficulties. It is just a policy/business/marketing case

    to decide to implement it or not, the specification is not a barrier



    2) registries that decided not to implement it anyway, for whatever reasons and case they are in



    3) registries that DO NOT respect all RFCs to the letter and/or are in cases not handled by this new extension and that are thinking about implementing it or not.

    If they want to implement it they have the choice:

    a) either to change their policies and business rules that either contradicts core

    EPP documents or are incompatible with the extension as written right now

    b) or to create **another** EPP extension just to code for the differences between the kind of policies that can be encoded in your extension and the registry policies that do not fit in



    The above are facts, the below are my assumptions.



    - case 1 will be mostly gTLDs or said differenly I doubt many ccTLDs will fall in this case

    - case 2 is irrelevant for this discussion as nothing we discuss can change that

    - case 3 is the interesting point, and my assumption is that this will group basically all ccTLDs, and my further assumptions are that of course registries will not change their policies just because this extension is not tailored to them (so 3a will mostly be empty) and I doubt many will go the length of writing a new extension just to codify their policies (so 3b will be negligible)

    [BTW 3b introduces again the exact same problem we had with EPP extensions since the beginning: fragmentation. Multiple registries have a "trade" operation for example. To encode that as policy, there is a risk each one drafting an extension for it, and then you come back to the case of multiple non-interoperable extensions that do the same things which is a nightmare]



    So I fear that at the end we will have something beautiful that caters for all the

    generic/simple cases, but that left out all complicated cases, and hence the implementation will not be widespread.



    The fact that no registry claimed to be willing to implement it or to write an extension for their own policy is very troublesome for me. But maybe it happened in private or will be announced in the future.





    --

      Patrick Mevzek



    _______________________________________________

    regext mailing list

    [e-mail]

    https://www.ietf.org/mailman/listinfo/regext