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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
