Subject: [regext] I-D Action: draft-ietf-regext-validate-04.txt

From: [email-masked]
Date: Thu, 11 Oct 2018 13:47:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Validate Mapping for the Extensible Provisioning Protocol (EPP)
        Authors         : Roger Carney
                          Joseph Snitker
	Filename        : draft-ietf-regext-validate-04.txt
	Pages           : 16
	Date            : 2018-10-11

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for the validation of contact and eligibility data.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-validate/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-validate-04
https://datatracker.ietf.org/doc/html/draft-ietf-regext-validate-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-validate-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Gould, James" <[email-masked]>
Date: Mon, 15 Oct 2018 16:08:27 +0000

Roger,

In implementing draft-ietf-regext-validate-04, below is my feedback:

  1.  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”.
     *   Nit – Change “>validate:postalIinfo>” to “<validate:postalInfo>”
  2.  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.
  3.  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…’.
     *   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.

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 10/11/18, 4:47 PM, "regext on behalf of [email-masked]" <[email-masked] on behalf of [email-masked]> wrote:

            Authors         : Roger Carney

                              Joseph Snitker

                Pages           : 16

                Date            : 2018-10-11

    Abstract:

    _______________________________________________

    regext mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/regext