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

Barry Leiba <barryleiba@computer.org> Sat, 15 February 2020 04:44 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6934E120046; Fri, 14 Feb 2020 20:44:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS2LZvr2Uu1l; Fri, 14 Feb 2020 20:43:59 -0800 (PST)
Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F37120018; Fri, 14 Feb 2020 20:43:56 -0800 (PST)
Received: by mail-io1-f54.google.com with SMTP id m25so12830047ioo.8; Fri, 14 Feb 2020 20:43:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=D4MERvUptHxDLbXatVoVcMeL3TpAyDrg7PGCVtEdUNQ=; b=ZPVEHZQ3DlEyNLaM8dWeCzEX7A+0nHBhluIYSnzVvsaTWuqXgV/l7RPqeaeU2YgTN/ kQW4uj0Y+m36YMig6545cVJKrlqCx9zqIl0Ylw2pPChcvFJ0lJG+Va53LqJK/jYnBjdf Ru8MxF7/HAv6LdnGAtJD9AsaAZvPdIVqOtzvoWll2knqkErJ0P+Sn//H5qpM80/IqqEG NlGtAsL6ch7tV4uQHAD7fW3TELyAZCTNe7Qhio1sjtt4pGV448d4rs78FMIPQWXMNkoq E/k6lPpTMZaMyQCf3S/T5/dEgQ8VSTHkcnGD61Y7XuTLf4CPFjtMiUXkWf5TF5FEXRi+ nSkw==
X-Gm-Message-State: APjAAAU/MCrD8Ff8k6Iw46wmOPZryIgdeEorFEzhwQTOe/JnAhTPhdCJ lrMakHQYPcEXOGMtWYMB5bF2YusLloQdbO8nd78GxmLY
X-Google-Smtp-Source: APXvYqyMXN1N3fCpJryBdWFGnAEsk+G/4veiaObCsKDwYskexRKKXSacJ+a2E9edKU+ZdEzLfBCIeCLiJ/wcolwTnVw=
X-Received: by 2002:a6b:7310:: with SMTP id e16mr4977744ioh.107.1581741835115; Fri, 14 Feb 2020 20:43:55 -0800 (PST)
MIME-Version: 1.0
From: Barry Leiba <barryleiba@computer.org>
Date: Fri, 14 Feb 2020 23:43:43 -0500
Message-ID: <CALaySJJKGLxCanozQiJYeAj-Ek3E8bgABo2qVmDcMTm6-DMbNQ@mail.gmail.com>
To: draft-ietf-regext-dnrd-objects-mapping.all@ietf.org
Cc: regext <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/nA8eTYIrXJ44_6ullQlRLW6T74s>
Subject: [regext] AD review of draft-ietf-regext-dnrd-objects-mapping-05
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Feb 2020 04:44:01 -0000

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 <regext@ietf.org>
      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