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 is passed” with “1. If the element is passed” and “Second scenario would be if the request includes additional elements” with “2. If the element includes additional elements”.  • [Interim] Will look at this • Nit – Change “>validate:postalIinfo>” to “” • [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 Command”, but you really don’t describe the elements section 2.3.  • [Interim] Will look at this o Section 3.1.1 “EPP 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 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 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 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 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