Minutes interim-2018-regext-04: Tue 12:00
minutes-interim-2018-regext-04-201810161200-00

Meeting Minutes Registration Protocols Extensions (regext) WG
Title Minutes interim-2018-regext-04: Tue 12:00
State Active
Other versions plain text
Last updated 2018-11-30

Meeting Minutes
minutes-interim-2018-regext-04-201810161200

   þÿ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 a. Continue the lively discussion that
were started in London and continued in Montreal b. 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:
o 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
o 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
o 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.
o Define Exceeding Maximum Expiration Date Policy
 " 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 ?.
o Definition of Regular Expressions for String Format Policies
 " 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.
o The schedule format to use with the <registry:batchJob>
<registry:schedule> element
 " 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
o Ensure that the hostAddr model of RFC 5731 is supported
 " 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