Minutes interim-2018-regext-03: Tue 16:00
minutes-interim-2018-regext-03-201806051600-00

Meeting started at 11:06 (UTC-5)

Attendees: Roger Carney, James Gould, Jody Kolker, Jim Galvin

Agenda
1.    Validate draft (comments, concerns, implementations)
2.    Registry Mapping
      a.    Continue the lively discussion that was started in London
      b.    Policy Extension Review: how a server implements an extension, the
      SHOULD(s),
            MAY(s), etc.

Jim Galvin mentioned that co-chairs have been discussing milestones and updated
charter with AD (Adam). Hopefully circulate new Charter to the group next week.
Planning two meetings for IETF-102.

James Gould said that he has started implementing the Validate draft in their
SDK. I mentioned that Nominet has already implemented.

We started out discussing the Validate draft, specifically the questions James
Gould posted to the list Monday June 4, 2018, copied below:

1. I don’t see the purpose of the <validate:cd> element in the check command..
   Initially, I thought the <validate:cd> may support a list within a list
   (e.g., <validate:contact>), but that is not the case.  There is also a
   little confusion with the use of <validate:cd> in both the check command and
   response.  My recommendation is to remove the <validate:cd> element from the
   check command and simply move all its sub-elements to sub-elements of the
   <validate:contact> element. [Interim] Interesting for removal, post to list.

2. Is the extension meant to validate the contact details of existing contacts
by contact
   id and also non-existent contacts based on the contact details, by contact
   type and by tld?  [Interim] Yes, both scenarios. For “new” contacts pass all
   data, don’t try to short cut it with only id, if only id is passed server
   will assume it is an existing contact. Change response validate:cd to
   include TLD and contact type attributes. Discussed the preferences of
   smaller payload versus complicated payload, went with simpler. Add a new
   section to 2.0 describing validate:id (Need to have response pass back
   contact type and tld). a. If both cases are true, then wouldn’t you have a
   choice of referencing the contact
      by identifier for an existing contact or defining the contact attributes
      for a non- existing contact?
   b. Also, what if you desire to use the same contact information for multiple
   contact
      types for a tld?
      i.  Do you need to replicate the same attributes for each contact type? 
      [Interim]
          Simple method would
      ii. It may be better to define a single contact (existing with contact
      identifier)
          or contact attributes for non-existing with the list of contact
          types.  I imagine that you always want to validate a contact within
          the scope of a tld. [Interim] Interesting, thoughts?

3. I view definition of only the check command and response with many contacts
and with
   extensibility via the kV elements as somewhat non-optimal.  Other options
   include: a. Instead of supporting multiple contacts in an individual
   command, why not support
      the check or info of an individual contact with attribute extensibility
      via command / response extensions.  Yes, you can validate only a single
      contact with multiple target types and a tld at a time, but you get to
      use existing contact command / response extensions to define the
      additional contact attributes without having to use key / value pairs. 
      [Interim] One goal is to pass in multiple contacts and validate as a whole
   b. Create a validate command / response extension of the contact mapping
   that extends
      the contact create to function as a no-op with the additional attributes
      used to validate usage of the contact (e.g., object - domain, contact
      types, tld), which would define a validate contact validate create
      command.  The contact info could have been extended by the validate
      extension to function as a validate usage command with the usage
      attributes consistent with the contact validate create command (e.g.,
      object – domain, contact types, tld).  In this case, the contact commands
      can be directly extended by the validate extension. [Interim] So does
      key/value make sense here. Can this validate extension be able to be
      extended with other extensions (e..g. registry has a VAT extension
      instead of this)?

4. Each element needs to be fully described..  I include some examples below:
   a. <validate:contact> element does not define the required “contactType” or
   “tld”
      attributes.  [Interim] Add more descriptions
   b. There is no description of any of the <validate:cd> sub-elements in the
   check
      command or response. [Interim] Add more descriptions

5. Wouldn’t be better to include a required “valid” attribute in the check
response
   <validate:cd> element with an optional reason and reason language similar to
   the domain check response?  I’m not sure if there is a real need to define a
   whole list of validity errors using the list of <validate:kv> elements.  It
   may be good enough to short circuit the validation by simply saying yes or
   no and if no a human readable reason. There would be no need for the
   <validate:response> element or the <validate:kv> elements. [Interim] Should
   the response look more like a check response (result, and free form text
   response if invalid)? I like the draft format better but I understand the
   consistency part

6. I don’t recommend directly referencing the
urn:ietf:params:xml:ns:contact-1.0 elements,
   since it adds a direct dependency to inclusion of the contact XML schema and
   namespace for a subset of the elements that are really specific to the
   validate mapping.  I would prefer for the validate XML schema to stand on
   its own by only referring to epp and eppcom, with no cross references to
   contact.  This would mean copying and pasting elements directly from the
   contact XML schema into the validate XML schema, which is an inconvenient,
   but makes it easier to implement.  [Interim] There has been discussion on
   list on this topic, continued discussion will be good.

We did not make it to the Registry Mapping discussions.