[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
- [regext] AD review of draft-ietf-regext-dnrd-obje… Barry Leiba
- Re: [regext] AD review of draft-ietf-regext-dnrd-… Hollenbeck, Scott
- Re: [regext] AD review of draft-ietf-regext-dnrd-… Barry Leiba
- Re: [regext] [Ext] AD review of draft-ietf-regext… Gustavo Lozano
- Re: [regext] [Ext] AD review of draft-ietf-regext… Barry Leiba