Subject: [regext] REGEXT Interim Meeting 2018OCT16

From: Roger D Carney <[email-masked]>
Date: Mon, 26 Nov 2018 18:57:47 +0000

Meeting started at 11:03 (UTC-5)

Attendees: Roger Carney, Jody Kolker, James Gould, James Galvin, Gurshabad Grover, Rick Wilhelm

Agenda

  1.  Validate draft (comments, concerns, implementations) - New version to be posted this week.
  2.  Registry Mapping
     *   Continue the lively discussion that were started in London and continued in Montreal
     *   Policy Extension Review: how a server implements an extension, the SHOULD(s), MAY(s), etc.

We first started talking about the changes to the Validate Draft:

*         Roger gave an update on the current version

*         Still need to make change to reference for RFC 7451 from normative to informative

*         Gould talked about a few items he had posted to the list:

     *   Section 2.2 "Validate Id"
        *   I recommend creating 2 numbered paragraphs for the two different scenarios and end the first sentence with a colon ":".  You could then change the "First if the <validate:id> is passed" with "1. If the <validate:id> element is passed" and "Second scenario would be if the request includes additional elements" with "2. If the <validate:id> element includes additional elements".
           *   [Interim] Will look at this
        *   Nit - Change ">validate:postalIinfo>" to "<validate:postalInfo>"
           *   [Interim] Will update
     *   Section 2.3 "Validate PostalInfo, Voice, Fax, Email, AuthInfo"
        *   I would directly refer to the validate elements by element name that mirror the associated elements in RFC 5733.  My recommendation is to be as explicit as possible here.  You reference section 2.3 for the elements in section 3.1.1 "EPP <check> Command", but you really don't describe the elements section 2.3.
           *   [Interim] Will look at this
     *   Section 3.1.1 "EPP <check> Command"
        *   I recommend putting the attribute in double quotes as in '...two required attributes: contactType, which describes...' to '...two required attributes: "contactType", which describes...' and '...tld, which provides...' to '"tld", which provides...'.
           *   [Interim] Will update
        *   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".  It would be best to enable the use of the EPP extensions to be passed directly to the validate mapping without the need for transforming them to key, value pairs.   The client and server would need to negotiate, most likely out-of-band, on the acceptable set of key, value pairs, or a new IANA registry would need to be defined to globally define the set of acceptable validate keys.
           *   [Interim] Gould was suggesting the draft to support the <create> so that it can use the extesions of the contact create so that they map more specifically instead of mapping these to KV pairs. I made mention that it is not a required element, a server may choose not to support. Maybe add text like "KV is server dependent and these keys would be communicated out of band"

We moved onto the Registry Mapping discussion

*         Gould talked about the GitHub project and all the issues that have been raised on list have been recorded into the project. Gould closed six items as corner cases. Currently 14 items remaining.

     *   Define Exceeding Maximum Expiration Date Policy<https://github.com/james-f-gould/EPP-Registry-Mapping/issues/11>
        *   Discussion
        *   Schema Change
        *   Maybe we can add the registry:exceedMaxExDate element under the registry:domain element after the registry:period element, with the description:
           *   The OPTIONAL action taken by the server when the domain:exDate exceeds the maximum expiration date by a fractional period on a renewal command like domain:renew or domain:transfer. The possible values for the registry:exceedMaxExDate element include:
           *   "fail": The server will fail the renewal command when the expiration date exceeds the maximum expiration date by a fraction of a period. An example is if the maximum expiration date is 10 years, and a client renews a domain name to 10.5 years, the server will fail the renew.
           *   "clip": The server will clip the fractional period when the expiration date exceeds the maximum expiration date by a fraction of a period. An example is if the maximum expiration date is 10 years, and the client renews a domain to 10.5 years, the server will clip the .5 fractional year so that the domain name will expire exactly in 10 years.

?  [Interim] This may need to specific for transfers and renew. Gould will update language here on the "fail".

     *   Definition of Regular Expressions for String Format Policies<https://github.com/james-f-gould/EPP-Registry-Mapping/issues/6>
        *   Discussion
        *   I addressed this in the Login Security Policy Extension (draft-gould-regext-login-security-policy) by choosing Perl-compatible Regular Expression (PCRE) syntax. I can add the appropriate informational reference to PCRE within the Registry Mapping draft and directly refer to PCRE for each of the regular expression elements.

?  [Interim] Rick mentioned something PCRE2. Gould will confirm. We agreed to move forward with PCRE.

     *   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. The crontab format was initially chosen since it's used by many tools today and it is used to define schedules in a condensed way. It is certainly not a standard, but I'm unaware of a relevant standard that can be used to declaratively define the batch schedules. The batches can and do execute in local time, so inclusion of the "tz" attribute is important for the clients to know exactly when the batches will run. I'll will do some research into alternatives for defining schedules that could be used in the draft.

?  [Interim] leave open, to look at more options beyond crontab

     *   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, the following are applicable:
           *   registry:host object policies would not apply, so the registry:host element must be made optional with <element name="host" type="registry:hostType" minOccurs="0"/> in the XML schema and described as OPTIONAL in the draft. If the parent registry:host element is not included, then that would address registry:maxCheckHost as well.
           *   We need an element under the registry:domain to identify whether domain:hostObj or domain:hostAttr is supported. How about adding an OPTIONAL registry:hostSupported element with two possible values of "hostObj" and "hostAttr", with the default set to "hostObj".
           *   Since, domain:hostAttr is an element in RFC 5731, then the policies associated with support for the "hostAttr" needs to reside under the registry:domain element. We could borrow elements that reside under the registry:host element to define the registry:hostAttr policy. Specifically, the registry:nameRegex for the host name syntax, the registry:internal element that supports registry:minIP and registry:maxIP, and the registry:external element that supports the registry:minIP and registry:maxIP elements.

?  [Interim] Gould will provide some examples

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 26 Nov 2018 23:02:18 -0500

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.

>     * 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?

>     * 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.

HTH,

-- 
  Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Tue, 27 Nov 2018 16:28:19 +0000

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

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" <[email-masked] on behalf of [email-masked]> wrote:

I agree that the key, value pair approach is an anti-pattern that has been tried before without success.  

    
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.  

    No. It is not "instead".

    

    

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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext