Re: [regext] REGEXT Interim Meeting 2018OCT16

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

Patrick,

Please review the latest version of draft-gould-carney-regext-registry, since I believe it has changes that are applicable to your feedback (e.g., batch schedule, host attribute support).  I provide my responses to your feedback below.  
  
—
 
JG



James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

On 11/26/18, 8:02 PM, "regext on behalf of Patrick Mevzek" <[e-mail] on behalf of [e-mail]> wrote:

    On Mon, Nov 26, 2018, at 13:58, Roger D Carney wrote:
    >  * I still don’t like the use of the <validate:kv> elements as a 
    > “flexible mechanism to share data between the client and the server”. 
    
    There are many registries going this route, and it is very sad, even
    if easy to understand why.
    It voids any usefulness of the schema attached to the (XML) documents,
    and basically will only need to interoperability problem because this content
    will not be described in an automated content, and relying on human
    documentation is not enough.

I agree that the key, value pair approach is an anti-pattern that has been tried before without success.  
    
    >     * The schedule format to use with the <registry:batchJob> 
    > <registry:schedule> element 
    > <https://github.com/james-f-gould/EPP-Registry-Mapping/issues/5>    * 
    > *Discussion*
    >  * This particular topic is not straight forward, since we need a 
    > condensed mechanism to define the batch schedules. 
    
    I do not see why "condensed". We are in XML land already, which is not
    known for its small size anyway so why would there be a need here to
    condense things?
    
The key is not the word "condensed", but "effective".  Please review the latest update to the approach taken for the schedule in draft-gould-carney-regext-registry-04.  

    >     * 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
    
    You will see that both options can cohabit.
    
    Now, I already know that some people will say: this is not allowed per EPP specifications.
    
    But besides that it is important to be clear on the purpose of this extension:
    being as "pure" and perfect as possible, with the hope that non-conforming current
    cases will then suddenly decide to fix their thing in order to be able to use it, or
    being as inclusive as possible so that as many registries as possible are using it
    as is.
    
    I think this extension can be very useful if many registries implement it.
    If it is only a few, it will not give registrars a lot of useful data, and hence
    they will not profit from it.
    
    And I do not think that "not conforming" cases will feel the need to change just
    to be able to implement this extension.
    
    This is a generic point I may try to raise again later in the past threads about
    this extension. It is an important question, that is itself tied to the amount
    of energy devoted to each extension, which extension becomes working group documents
    and which extensions really solve problem of more than one registry and hence
    may have the chance to be implemented by a sizeable chunk of current players.

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.  
    
    HTH,
    
    -- 
      Patrick Mevzek
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext