Subject: [regext] AD review of draft-ietf-regext-dnrd-objects-mapping-05

From: Barry Leiba <[email-masked]>
Date: Fri, 14 Feb 2020 23:43:43 -0500

Again, I’m sorry I didn’t get to this sooner.  Here’s my review.  I
have some items that I want to resolve (some of which might need some
discussion) before this goes to last call, and I’m putting those
first.

— Section 5.1.1.1 —

      If the domain name is an IDN, the ASCII
      Compatible Encoding (ACE) MUST be used.

You need a reference here.  I suggest saying “A-Label”, rather than
ACE, and adding a reference to RFC 5891, Section 4.4 (see my comment
on Section 5.9.1, below).  I also suggest using the term “A-Label”
everywhere you now say “ACE” or “ASCII Compatible Encoding (ACE)”.
Also in 5.6.1.1, 5.6.1.2, and some 5.6.2 subsections.

And I think that 5891 needs to be normative, not informative, because
one MUST understand how to do A-Labels.

   o  An OPTIONAL <originalName> element is used to indicate that the
      domain name is an IDN variant.  This element contains the domain
      name used to generate the IDN variant.

An example would help here.  Are we talking, for example, about having
the uName be in traditional Chinese, and then originalName would be
the domain name in simplified Chinese?  This, or an alternative
example would make the usage of this field clearer, especially to
people who don’t understand I18N issues that well.  The corresponding
item in 5.6.1.1 can then refer back to this section for the example.

— Section 5.9.1 —

      *  An OPTIONAL "rcdn" attribute indicates the REGISTRY-CLASS
         DOMAIN NAME (RCDN) of the objects included in the <count>
         element.  For IDNs the A-Label is used [RFC5891].

Ah, here’s your usage of “A-Label” and the 5891 reference.  Please
make the reference “(see [RFC5891], Section 4.4)”, so as to make it
easier to find.

— Section 9 —
A note that I did not review the schemas, as I am not a schema expert.
I am concerned that I have not seen evidence yet that a schema expert
has given this a good look.

— Section 10 —
What is the reason for allowing other encodings than UTF-8?  Would it
not be best to say “MUST use UTF-8”, rather than making it
SHOULD/RECOMMENDED?

— Section 11 —
We would generally prefer that the contact for IANA registrations in a
working group document be the working group — formally specified as
“IETF” with IANA holding the wg mailing list as the contact
information.  In this case, I’m of two minds, as it makes sense for
ICANN to be a contact here.  What does not make sense if for the
contact to be Gustavo as an individual (what happens when Gustavo no
longer works for ICANN, nor participates in the IETF any more?).
Shall we chat about this to decide what’s best?

      See the "Formal Syntax" section of this document.

I would strongly prefer that each schema’s registration actually
include the specific section number for that schema.  (You also might
make this whole section more compact by eliminating the extra empty
lines within each registration.)  So, for example:

NEW
   Registration request for the RDE CSV XML schema:
      URI: urn:ietf:params:xml:schema:rdeCsv-1.0
      Registrant Contact: IETF <[email-masked]>
      See Section 9.1 of this document.
END

— Section 13 —
Given the importance of all this, why are these SHOULD, rather than
MUST?  You know that the Sec ADs will be asking this; there needs to
be a compelling answer.

++++++++++++++

Other, non-blocking comments:

— Section 3 —

   Registry (either directly or through and affiliate company) provides

Typo: “an affiliate”

  dissemination of RCDN zone files; operation of the Registry DNS
   servers; and responding to queries for contact and other information
   concerning DNS registrations in the RCDN.    Any other products or
   services that only a Registry is capable of providing, by reason of
   its designation as the Registry.

Nit: That’s not a sentence at the end; it’s a list item.  You should
add it to the list:

NEW
  dissemination of RCDN zone files; operation of the Registry DNS
   servers; responding to queries for contact and other information
   concerning DNS registrations in the RCDN; and any other products
   or services that only a Registry is capable of providing, by reason of
   its designation as a Registry.
END

   Typical examples of Registry
   Services are: DNS resolution for the RCDN, WHOIS and EPP.

The colon should come out (gee, I sound like a surgeon...), as it
doesn’t belong there.

   "to allocate") may represents the first step

Nit: “may represent”

— Section 4.4 —

   Checksum of the CSV data escrow files MUST use CRC32, that is the
   algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 of
   ITU-T recommendation V.42.

Two nits here: make it “The checksum” and “which is”.

— Section 4.5 —

   IP addresses syntax MUST conform

Nit: either “IP address syntax” or “The syntax of IP addresses”.

— Section 4.6.1 —

   starting from the parent record in differential and incremental
   deposits.

The regext-data-escrow draft capitalizes the terms, so, “Differential
and Incremental Deposits.”  Please check for consistency on this
throughout the document.  Please also cite regext-data-escrow here as
a reference for the definitions of these terms, as it’s the first time
they’re used.

— Section 4.6.2.1 —

      There is one or more child elements that substitute

This is a tricky nit: “one or more <things>” is a structure that’s
treated as a plural noun, so “There are one or more...”

   The <rdeCsv:csv> elements requires a "name" attribute

Nit: “element”

— Section 4.6.3 —

   Some elements MAY be provided in either internationalized form
   ("int") or provided in localized form ("loc").

The “provided in” part is factored out of the “either” and isn’t needed twice:

NEW
   Some elements MAY be provided in either internationalized form
   ("int") or localized form ("loc").
END

— Section 5.1.1.1 —

   o  An OPTIONAL <uName> element that contains the fully qualified name
      of the domain name in Unicode character set.

Nit: “the fully qualified domain name”

  o  Zero or more OPTIONAL <rgpStatus> element to represent

Nit: “elements”

   o  An OPTIONAL <registrant> element that contain the identifier

Nit: “contains”

      *  An <acRr> element that contains the identifier of the registrar
         that SHOULD act upon a PENDING transfer request.

This should not be a BCP 14 “SHOULD”, but just a plain English
“should”.  Same comment in 5.3.1.1.

— Section 5.1.2.1.1 —
You use “xn—abc123.example” in the examples in this and other
sections.  But “xn—abc123” is not valid punycode.  It would be better
to pick something that is valid punycode.

— Section 5.3.2.1.3 —

   <csvContact:fStreet>  Contains the contact's contact's street address

Typo: duplicate “contact’s”

— Section 5.4 —

   The registrar object represents the sponsoring client for other
   objects, for operational purposes MAY be the registry operator.

I can’t parse this sentence and dont know what you mean it to say;
please fix it.

— Section 5.4.1.1 —

   o  Zero or two OPTIONAL <postalInfo> elements

Shouldn’t this be “One or two”?

— Section 5.6 —

   A NNDN (NNDN's not domain name) can be used to store registry

How do you pronounce “NNDN” such that “a” works with it?  I think it’s
pronounced “en-en-dee-en”, so it’s “an NNDN”.  Can you change that
throughout?

   Domain Name Registries may maintain domain names without them being
   persisted as domain objects in the registry system

Total obscure-English-geekiness nit: it’s customary to use possessives
with gerunds, so, “without their being persisted”.

— Section 6 —

   Depending on the Registration Policy of the Registry; for a domain
   name there may be multiple variant names.

I had to read this three times before I realized the problem: replace
the semicolon with a comma.

   behavior during restoration of a SRS

“an SRS”, assuming it’s “ess-ar-ess”.

— Section 7 —

   Different business models of registries exist, therefore the registry
   is responsible to define a profile that matches its particular

This sounds a bit odd, at least in American English.  We would say,
“responsible for defining a profile”.

       usually REQUIRED but it is specified as OPTIONAL in this
       specification to support existing business models.

Should this be “some existing business models” (not all)?

   o  A domain name exists as a domain name or NNDN, but not both.

Maybe “Each domain name”?  Or perhaps, “No domain name exists as both
a domain name and an NNDN.”?

— Section 9 —
Just a note that I did not review the schemas, as I am not a schema expert.

— Section 13 —

   Depending on local policies, some elements or most likely, the whole
   deposit will be considered confidential.  As such the Registry
   transmitting the data to the Escrow Agent SHOULD take all the
   necessary precautions like encrypting the data itself and/or the
   transport channel to avoid inadvertent disclosure of private data.

Nit: This needs a comma after “or” and one after “such”.

   It is also of the utmost importance the authentication of the parties
   passing data escrow deposit files.

NEW
   Authentication of the parties passing data escrow deposit files is of the
   utmost importance.
END

   from the Registry, but also the contents are also "meaningful".

Remove one of the “also”s.

-- 
Barry

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 18 Feb 2020 13:33:48 +0000

> -----Original Message-----
> From: Barry Leiba <[email-masked]>
> Sent: Friday, February 14, 2020 11:44 PM
> To: [email-masked]
> Cc: regext <[email-masked]>
> Subject: [EXTERNAL] AD review of draft-ietf-regext-dnrd-objects-mapping-
> 05
>
> Again, I’m sorry I didn’t get to this sooner.  Here’s my review.  I have some
> items that I want to resolve (some of which might need some
> discussion) before this goes to last call, and I’m putting those first.

[snip]

> I am concerned that I have not seen evidence yet that a schema expert has
> given this a good look.

Barry, I noted the schema review situation in the shepherd write-up. I checked it, and I worked with the author to run it and the examples through a series of automated checks using the xerces XML parser. It's syntactically correct and valid as far as I can determine.

Scott

---

From: Barry Leiba <[email-masked]>
Date: Tue, 18 Feb 2020 06:39:05 -0800

Ok, thanks, Scott.  I did read the writeup, but interpreted it to mean that
we still needed a full schema review.  Sorry for the misinterpretation.

Barry

On Tue, Feb 18, 2020 at 5:34 AM Hollenbeck, Scott <[email-masked]>
wrote:

> Barry, I noted the schema review situation in the shepherd write-up. I
> checked it, and I worked with the author to run it and the examples through
> a series of automated checks using the xerces XML parser. It's
> syntactically correct and valid as far as I can determine.
>
> Scott
>

---

From: Gustavo Lozano <[email-masked]>
Date: Sat, 22 Feb 2020 02:24:45 +0000

Thank you, Barry.

Version 06 (https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-06.txt) was published based on your feedback.

Differences here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-regext-dnrd-objects-mapping-06.txt

Comments inline.

Regards,
Gustavo

On 2/14/20, 20:44, "Barry Leiba" <[email-masked]> wrote:

    — Section 5.1.1.1 —

    

Fixed

    — Section 5.9.1 —

    
Fixed

    — Section 9 —

See, https://mailarchive.ietf.org/arch/msg/regext/q6VmGPW-h_DexGyT6LguS3cs6tE

    — Section 10 —

Section 10 is modeled after section 5 of RFC 5730 that draft-ietf-regext-dnrd-objects-mapping uses extensively.  The recommendation is to not make draft-ietf-regext-dnrd-objects-mapping more restrictive than EPP or not cause incompatibilities with existing implementations by keeping the language as is.    

    — Section 11 —

    
    NEW
    
Fixed

    — Section 13 —

The escrow drafts define a format, and the relationship between escrow agents and clients is determined based on contracts between the parties were security properties should be established.

    ++++++++++++++

    — Section 3 —

    Typo: “an affiliate”

    
    NEW

    
    
    Nit: “may represent”

Fixed

    — Section 4.4 —

Fixed

    — Section 4.5 —

Fixed

    — Section 4.6.1 —

Fixed
    
    — Section 4.6.2.1 —

    
    
    Nit: “element”

Fixed
    
    — Section 4.6.3 —

    
    NEW
    
Fixed

    — Section 5.1.1.1 —

    
    
    Nit: “elements”

    Nit: “contains”

Fixed

    — Section 5.1.2.1.1 —

Fixed

    — Section 5.3.2.1.3 —

Fixed

    — Section 5.4 —

    
Fixed

    — Section 5.4.1.1 —

Fixed

    — Section 5.6 —

    

Fixed

    — Section 6 —

    

Fixed
    
    — Section 7 —

    

    

Fixed

    — Section 9 —

Fixed
    
    — Section 13 —

    
    
    NEW

Fixed

    -- 
    Barry

---

From: Barry Leiba <[email-masked]>
Date: Sun, 23 Feb 2020 12:28:35 -0800

Hi, Gustavo, and thanks for addressing my comments.

On just one point:

> Section 10 is modeled after section 5 of RFC 5730 that draft-ietf-regext-dnrd-objects-mapping
> uses extensively.  The recommendation is to not make draft-ietf-regext-dnrd-objects-mapping
> more restrictive than EPP or not cause incompatibilities with existing implementations by keeping
> the language as is.

OK, I'm going to go ahead and send this out for last call, but I'm
also going to ask the I18N Directorate to have a closer look at this
and see what they think.  I do think it's time we make it clear that
we are deprecating the use of encodings other than UTF-8 to represent
Unicode in our protocols.  5370 is well over 10 years old now, and I
don't really buy that we have to remain aligned with it today.

Barry