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

þÿ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