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

[Gustavo Lozano <[e-mail]>]

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" <[e-mail]> wrote:

    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.

Fixed
    

    — 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.
    
Fixed

    — 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.

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

    — 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 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 —
    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 <[e-mail]>
          See Section 9.1 of this document.
    END
    
Fixed

    — 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.
    


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.


    ++++++++++++++
    
    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”
    

Fixed

    — 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”.

Fixed

    
    — Section 4.5 —
    
       IP addresses syntax MUST conform
    
    Nit: either “IP address syntax” or “The syntax of IP addresses”.


Fixed
    

    — 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.

Fixed
    
    — 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”

Fixed
    
    — 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
    
Fixed

    — 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.

Fixed
    

    — 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.

Fixed
    

    — Section 5.3.2.1.3 —
    
       <csvContact:fStreet>  Contains the contact's contact's street address
    
    Typo: duplicate “contact’s”

Fixed
    

    — 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.
    
Fixed

    — Section 5.4.1.1 —
    
       o  Zero or two OPTIONAL <postalInfo> elements
    
    Shouldn’t this be “One or two”?

Fixed

    
    — 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”.
    

Fixed


    — 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”.


Fixed
    
    — 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.”?
    

Fixed

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


Fixed
    
    — 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.

Fixed
    

    -- 
    Barry