Re: [regext] [Ext] Benjamin Kaduk's Discuss on draft-ietf-regext-dnrd-objects-mapping-09: (with DISCUSS and COMMENT)

["Gould, James" <[e-mail]>]

Benjamin,

Did the response from Gustavo address your feedback or is there more that needs to be discussed?

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

On 10/8/20, 5:58 PM, "Gustavo Lozano" <[e-mail]> wrote:

    Thank you Benjamin,

    Comments below are prefixed with Authors-.

    A new version of the I-D has been published here: https://secure-web.cisco.com/1bMXqrg8QldLTsptiSXBdrA-nBZlvGFSyysYzL7g7VfZqazF6K4MQiKoPMBKLBXHZApEkqk54ppUhKIWSSTtRvJD9ZlzQ4zdbCIitKUImHdg0kPY9lyjjK258NhuxOnEjkSG3M42PS3-uvQ1wOOoxAsE838M2NaEQYfWiaGXjGSah7O8Hd8-aZaUS0tJhRBNuScyng05Vf--Swxvk7SqVwJ4mdYDLRTRwu7loc9UCPjiAlvuEc1JTOc0JjoM1U6YqbgzW_ACteC_hJjx5KW1wv1qEjGR39IfOxFep-dr7eLo/https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-ietf-regext-dnrd-objects-mapping-10.txt

    Regards,
    Gustavo

    On 8/26/20, 23:30, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:

        Benjamin Kaduk has entered the following ballot position for
        draft-ietf-regext-dnrd-objects-mapping-09: Discuss

        When responding, please keep the subject line intact and reply to all
        email addresses included in the To and CC lines. (Feel free to cut this
        introductory paragraph, however.)


        Please refer to https://secure-web.cisco.com/1EZs5AU651pu9tOsVNiIn9521olvcvGuwNnR1VNyA842YC0U-wsMW6ejBz5eorHyq_4wTk2SC18UENXhDjoLxoeoLglOPaLep9Mm0qmLbmI0sIyVr3M8sEzf_z31W1HY4Lum4iT24IuCZInaEtaYV-7U5wGivkv07XrIxP9DiW5C8yrsQstkGov2tRs3GMU4cxd59AT4-qqWwuYmY_FKaA84eJxr3FRJtT5LNt-p2cIiF9QopJRfADJg-eKkxTHeD8kq6_8SXLCXUu8u4dbDjIA/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html__%3B%21%21PtGJab4%21s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e6IR8BTA%24 
        for more information about IESG DISCUSS and COMMENT positions.


        The document, along with other ballot positions, can be found here:
        https://secure-web.cisco.com/1ILv_hP4PAw3aHFvv35dyqDkNxkjFXjf6eBKJNRxRfka4OAWEQX5cYP8jxe24k3nEm8h7pWCUDCdTLB7JlkdLxkdCpBlId8qW5bJ8oxjM0xfomCLf12uPFem5AbL94zSoRp1NilsYK5rrqVZSHWwU0or3FNxo11-jD2UWTm9B8pBm8isp0DuL-euyB4V69gK5RVBElFNvpJ9M7DOt051LpxQF70pmuh2EmnXmWw6xMMrUxMd9J-KTuePsKThvMu_rQarE508dBtFyiHG24uTBuA/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-dnrd-objects-mapping%2F__%3B%21%21PtGJab4%21s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e5ypcsy4%24 



        ----------------------------------------------------------------------
        DISCUSS:
        ----------------------------------------------------------------------

        It's possible that I just misunderstand what is required to go where,
        but for several (possibly only CSV?) elements, the body text claims that
        "[t]he attribute "isRequired" MUST equal "true"." but the corresponding
        examples do not consistently list the "isRequired" attribute.
        (Sometimes they do, but not always.)  Shouldn't the examples be
        consistent with the protocol requirements?  I note some examples in my
        COMMENT section but this should not be treated as an exhaustive list.

    Authors- The "isRequired" attribute is set by default based on the type referenced by the field in the XML schema.  Inclusion of the "isRequired" attribute explicitly in the examples is used to override the default of the referenced type.  Below is the relevant text for the "isRequired" attribute of the <rdeCsv:field> elements, in section 4.6.2.1 "<rdeCsv:csv> element":

    The <rdeCsv:field> elements
    support the "isRequired" attribute, with a default value of
    "false", when set to "true" indicates that the field must be non-
    empty in the CSV files and when set to "false" indicates that the
    field MAY be empty in the CSV files.  The "isRequired" attribute
    MAY be specifically set for the field elements within the XML
    schema and MAY be overridden when specifying the fields under the
    <rdeCsv:fields> element.

        A similar property (again, if I understand correctly) holds for the
        "parent" attribute of various elements (which is definitely only a thing
        for the CSV objects)..

    Authors- The “parent” attribute is explicitly set in the <rdeCsv:field> elements to provide a hint that it represents a foreign key.  Below is the relevant text for describing the “parent” attribute of the <rdeCsv:field> elements in section 4.6.2.1 "<rdeCsv:csv> element":

    The <rdeCsv:field> element supports an
    OPTIONAL "parent" attribute that identifies the field as a
    reference to a parent object, as defined in CSV Parent Child
    Relationship (Section 4.6.1 [tools.ietf.org]).  For example, the <rdeCsv:csv
    name="domainStatuses"> <csvDomain:fName> field SHOULD set the
    "parent" attribute to "true" to identify it as the parent domain
    name of the domain status.

        The claim in the IANA Considerations regarding "URI assignments have
        been registered by the IANA", accompanied by specific URN
        namespace/schema values, is codepoint squatting, in the absence of a
        disclaimer about being "requested values".  The registration policy is
        only Specification Required, so there is no formal guarantee that we can
        actually get these values.

    Authors- text updated in the next version of the I-D.

        At least one of the examples shows RSA/MD5 DNSSEC key records.  RSA/MD5
        usage is specifically disallowed (see RFC 6944 and RFC 8624);
        please replace with a more modern algorithm.  (One location noted in the
        COMMENT, along with some SHA-1 usage that should probably go as well.)

    Authors- Examples fixed in the next version of the I-D.

        ----------------------------------------------------------------------
        COMMENT:
        ----------------------------------------------------------------------

        We have at least one example that shows a gurid of 123, which is an
        actual value allocated to a real registrar by ICANN (details in the
        section-by-section comments).  Please consider using a different value
        for the example.

    Authors- fixed in the next version of the I-D.

        Section 1

           Registry Data Escrow is the process by which a registry periodically

        nit: maybe include "(RDE)", since we use the acronym later on before the
        definitions section.

    Authors- text updated in the next version of the I-D.

           This document defines the following pseudo-objects:
           [...]
           o  EPP parameters: Definition of the specific EPP parameters
              supported by the Registry Operator.

        nit: is the pseudo-object containing the "definition of" the specific
        parameters or something related, like the values of those parameters?

    Authors- text updated in the next version of the I-D.

        Section 4.1

           Numerous fields indicate "dates", such as the creation and expiry
           dates for domain names.  These fields SHALL contain timestamps
           indicating the date and time in UTC as specified in [RFC3339], with
           no offset from the zero meridian.

        Should we mention anything about leap seconds?

    Authors- There is nothing mentioned about leap seconds in the related provisioning EPP RFCs.  https://secure-web.cisco.com/1NtF3e3iKI2eA0ZE_QfXwyHM4mVtSPO3aOc4HCoIITh4KquFz-j3ypfOENrSCVaodd1MGH-93YbomXslNQYhWqu14M9h-zsE7c0WkO9FUN97_aDaZDAtTD5jCnfBreKukzyJt2cLEIx5oLij9WE8wENBpQ2Rk8is17uTe6P2kMu0cMhAsTvM3JOPO-ibeiXuZKVlkQO6YCD16yS3DYzXzVplPOENcXe2ILzb0SpLaghYIcbHguldoN8F1naSBpxo8c-7wxtJwIocxNGUTZnCccg/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5731%23section-2.4 [tools.ietf.org] is an example of the provisioning dates and times definition, which needs to be supported in draft-ietf-regext-dnrd-objects-mapping for escrow.

        Section 4.4

        If I understand correctly from the examples, the actual checksum value
        of the CSV file is encoded as an attribute of the corresponding
        <rdeCsv:file> element in the XML description/schema/thing that
        accompanies the CSV files.  Is my understanding correct?

        Why is CRC32 the default?  In my opinion SHA-256 is better as a default,
        based on the "fail safe" principle.

    Authors- Yes, that is correct, the XML in the CSV Model defines the format, the CSV file reference, and the checksum of the referenced CSV file reference.  CRC32 was the checksum algorithm used exclusively prior to the last version based on the feedback https://secure-web.cisco.com/1ayQW8mBLtShARlyAwtfu4ZvoyWRxyW615V4zCw5uXmgmhKZtShHn8iLv8gxgpsrtHsZsozR1TY-3e6kRkQ85_wMtB-lHIWjbLSd6GN2pHCg6HQhfBSnc4xyyEEzT1IoJ6DuJmPVYU8H5YJo96mNz0XVoqTco5XhyRU6dHdR8cLQuo3YNUfp760x6D-RkM-3_hSIUuYL-MURuPfi8JUVT19z98flGlMVJljEV_kD4B9OPonXpI4Yd8367HbbdpKFsfWfJrpzzrUka4nkcI15aJnm1WqYu4AStJurysRGE3Q0/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fregext%2FEmKW32exlPgLbBUIbS8OjdYUJWc%2F [mailarchive.ietf.org].  To support algorithms other than CRC32, the “cksumAlg” attribute was added, and the default was set to CRC32 so not to impact the existing implementations.

        Section 4.5

           The syntax of IP addresses MUST conform to the text representation of
           either Internet Protocol Version 4 [RFC0791] or Internet Protocol
           Version 6 [RFC4291].

        Where exactly in RFC 791 is the text representation discussed?  "text"
        only appears three times, none of which are relevant, and
        "representation" not at all.  I do note that traditional/historic APIs
        involving IPv4 addresses have been quite lenient, allowing even such
        things as 18.1179790 (18/8 is a class A network), and I expect the
        intent is to limit to "dotted quad" decimal values.

    Authors – This is borrowed for the related EPP Host RFC 5732 (https://secure-web.cisco.com/1pJh9_7lvanePcdXfPeXZ8FxZsdfgAQ6gEYriCF76Lzpl0Ao6lDL83P_1_yC5gYA6WhFrXxKFeIYiXqW_AkWiO1Mm9ZmsGTujHvHVDapBTaJQhe54vtrSwaDgL74wWx0i_KcSo-UN8l7yfIT6Pu0ZjwZxvpSi3kqEdJXc5SnDKbek1MynMGfTPeBuUfw6ne-X_SjOZ_sJ7_ixqpeRURw6BCpV-ntjIQugauw0aX28BkZovmizfHL71SXoRbl1AC5eBIlBPgH94FErBBwQ0oxY8w/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5732%23section-2.5 [tools.ietf.org]).  The data escrow format for IP addresses needs to be in line with the RFC 5732 format, because EPP is the provisioning protocol.

        Section 4.6.1

        nit: we jump pretty quickly into the example without much introduction
        for the concepts and abbreviations it uses; a note about where it will
        be explained further might be helpful.

    Authors- text updated in the next version of the I-D.

        Section 4.6.2

        (editorial) I feel like these CSV elements would be more understandable
        if they appeared after the XML model (which presents descriptions for
        the XML elements that are used in the example CSV elements), though I
        don't have a specific proposal for section reorderings that would make
        that happen.

    Authors- Unfortunately, there is really no good option to move the section 4.6.2 “CSV elements”, and subsequently the section 4.6 “Conventions applicable to the CSV Model” after the XML Model sections that are embedded for each of the objects in section 5 “Object Description”.

        Section 4.6.2.1

           The following is example of the "domain-YYYYMMDD.csv" file with one
           record matching the <rdeCsv:fields> definition.

           domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,
           clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
           2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z

        Is that last 2015-04-03T22:00:00.0Z the expiration date (now five years
        in the past)?  It may be worth making a pass through the examples and
        thinking about which dates might be updated to more-current values.

    Authors- Examples fixed in the next version of the I-D.

        Section 4.6.2.2

           <rdeCsv:fRegistrant>  Registrant contact identifier with
              type="eppcom:clIDType".

        So the client ID type is used for both clients (registrars, per below)
        and registrants (users, as used here)?

           <rdeCsv:fCrRr>  Identifier of the registrar, defined in Section 5.4,
              of the client that created the object with type="eppcom:clIDType".

           <rdeCsv:fCrID>  Identifier of the client that created the object with
              type="eppcom:clIDType".

        Or am I wrong to equate clients and registrars?

    Authors – Correct, the eppcom:clIDType data type definition from the EPP RFCs is reused.

           <rdeCsv:fTrStatus>  State of the most recent transfer request with
              type="eppcom:trStatusType" and isRequired="true".

        We assume that there has always been a most recent transfer request?  I
        note that <trnData> (and the <trStatus> it contains) "MUST NOT be
        present if a transfer request for the domain name has never been
        created".

    Authors- The <rdeCsv:fTrStatus> field would be defined in a transfer CSV file, such as the section 5.1.2.1.7 “domainTransfer” CSV File Definition.  If there is no most recent transfer request, a record for that object would not exist.  If a transfer request does exist, then there <rdeCsv:fTrStatus> field is required and must have a non-empty value.  The XML Model is an object model, where the absence of the XML element means it doesn’t exist, while the CSV Model is a relationship model, where the absence of a record means it doesn’t exist.

        Section 4.6.3

                 <csvRegistrar:fGurid/>

        It looks like we don't actually expand this to "globally unique
        registrar identifier" anywhere; we just say it's the ID assigned by
        ICANN" (in §5.1.2.1.1)?

    Authors- fixed in the next version of the I-D.

        Section 5.1.1.1

           o  An OPTIONAL <uName> element that contains the fully-qualified
              domain name in Unicode character set.  It MUST be provided if
              available.

        Who is tasked with verifying that the <uName> is consistent with the
        <name>?  (Similarly for other uName elements, later.)

    Authors- the receiving party (e.g. escrow agent, ICANN-EBERO program, etc.)

        Section 5.1.2

           include a <csvDomain:fName parent="true"> field.  All the child CSV
           file definition data for the domain name objects in the parent
           "domain" CSV File Definition (Section 5.1.2.1.1) MUST first be
           deleted and then set using the data in the child CSV files.  The
           deleted domain name object data under the <csvDomain:deletes> element
           is a cascade delete starting from the "domain" Deletes CSV File
           Definition (Section 5.1.2.2.1).

        I feel like I want to check my understanding here.  When we say "All the
        child CSV file definition data [...] MUST first be deleted and then set
        [...]", this is not talking about the <csvDomain:deletes> stuff, right?
        It's just "anything that's listed in <cvsDomain:contents> is wiped
        clean, so the contents of the <cvsDomain:contents> reflect the full and
        exact state after the updates"?

    Authors- Correct, there are two use cases to cover.  One use case is updating an object, like updating a domain name (example.com) by adding a name server (ns1.example.com) and removing a name server (ns2.example.com), adding a status (clientUpdateProhihibited), and replacing the registrant.  Since the CSV Model is a relational model, inclusion of a domain record in the “domain” CSV file means that it’s a new domain or an updated domain.  If the updated domain case, all of the existing child records for the domain name need to be removed and then replaced with the contents of the child CSV files.  The “domain” CSV file would contain the “example.com” record with a reference to the new registrant (registrantid2 instead of registrantid), the “domainNameServers” CSV file would contain the current set of name servers with the new n21.example.com and without the deleted ns2.example.com, and the “domainStatuses” CSV file would contain the current set of statuses that would include the set of statuses with the new clientUpdateProhibited status.  For the second use case, a deleted domain name would be only included in the <csvDomain:deletes> “domain” CSV file that will do a cascade delete of the domain parent record and all of the child records.  I hope this helps.

        Section 5.1.2.1.1

           <rdeCsv:fUpRr>  Identifier of the registrar, defined in Section 5.4,
              of the client that updated the object.

           <rdeCsv:fUpID>  Identifier of the client that last updated the domain
              name object.

        nit: we could probably normalize around "object" vs "domain name object"
        and "updated" vs "last updated".  (This seems to occur multiple times in
        the document, at least with respect to "updated"/"last updated".)

    Authors- normalized on domain name object and last updated.

           <rdeCsv:fUName>  UTF8 encoded domain name for the <csvDomain:fName>
              field element.

        [same question as for CSV about who does the consistency check]

    Authors- the receiving party (e.g. escrow agent, ICANN-EBERO program, etc.)

           <rdeCsv:fUpDate>  Date and time of the last update to the domain name
              object.

        Should we say anything about the case where the domain object has never
        been modified?

    Authors- text updated in the next version of the I-D.

           <rdeCsv:fTrDate>  Date and time of the last transfer for the domain
              name object.

        [likewise.  I will probably not mention this for subsequent
        transfer/update-related elements, though they would presumably be
        similarly affected]

    Authors- text updated in the next version of the I-D.

        Section 5.1.2.1.5

           The "domainNameServersAddresses" CSV File Definition defines the
           fields and CSV file references used for supporting the host as domain
           attributes model.

        Is there a typo in here?  Google didn't find much for "host as domain
        attributes model".

    Authors- text updated in the next version of the I-D. The difference between host objects and host attributes is described in section 1.1 of RFC 5731.  

        Section 5.1.2.1.6

           Example of the corresponding dnssec-ds-YYYYMMDD.csv file.  The file
           contains two DS records for domain1.example.

           domain1.example,604800,12345,3,1,49FD46E6C4B45C55D4AC
           domain1.example,604800,12346,3,1,38EC35D5B3A34B44C39B

    Authors- Examples fixed in the next version of the I-D.

        It would be nice to use SHA-256 rather than SHA-1 for the examples,
        given SHA-1's weaknesses.

           Example of the corresponding dnssec-key-YYYYMMDD.csv file.  The file
           contains two key records for domain1.example.

           domain1.example,604800,257,3,1,AQPJ////4Q==
           domain1.example,604800,257,3,1,AQPJ////4QQQ

        RSA/MD5, on the other hand, is specifically disallowed (see
        RFC 6944 and RFC 8624).
        Please replace with a more modern algorithm.

    Authors- Examples fixed in the next version of the I-D.

        Section 5.2.2.1.1

           Example of the corresponding host-YYYYMMDD.csv file.  The file
           contains six host records with four being internal hosts and two
           being external hosts.

        What is an internal (or external) host?

    Authors- The internal and external hosts are described in section 1.1 “Relationship of Domain Objects and Host Objects” in RFC 5731.  In summary, for the .example registry, an internal host is a .example host (e.g., ns1.domain1.example), and an external host is a non-.example host (e.g., ns1.example.net).

        Section 5.2.2.1.2

           The following "rdeCsv" fields, defined in section CSV common field
           elements (Section 4.6.2.2), MAY be used in the "hostStatuses"
           <rdeCsv:csv> <rdeCsv:fields> element:

           <rdeCsv:fStatusDescription>  Host object status description which is
              free form text describing the rationale for the status.  The
              attribute "isRequired" MUST equal "true".

        I feel like the "MAY" and "MUST" must be targetted at different parties,
        but am not entirely sure I understand the distinction.

        And if "isRequired" must be true, why is it not listed as such in the
        example that follows or present in the corresponding example csv file?

    Authors- Good catch!, text updated in the next version of the I-D.

        Section 5.2.2.1.3

           <csvHost:fAddr>  IP addresses associated with the host object with
              type="host:addrStringType".  The attribute "isRequired" MUST equal
              "true".

           <csvHost:fAddrVersion>  IP addresses version associated with the host
              object with type="host:ipType".  "host:ipType" has the enumerated
              values of "v4" or "v6".  The attribute "isRequired" MUST equal
              "true".

        Is anyone supposed to do consistency checks that the string
        representation of the address matches the claimed address type?

    Authors- the receiving party (e.g. escrow agent, ICANN-EBERO program, etc.)

           <rdeCsv:fRoid>  Host object Registry Object IDentifier (ROID)
              assigned to the host object with isRequired="true".

        (I don't see the "isRequired" in the example that follows, though it is
        present for fAddr and fAddrVersion.)

    Authors – The <rdeCsv:fRoid> element is already defined as isRequired=”true” in section 4.6.2.2.  The example only need to define the “isRequired” if the value is being overridden, which in this example it is not.

        Section 5.3.2.1.2

           <csvContact:fId>  Server-unique contact identifier of status with
              isRequired="true".

        It needs to have parent="true", too, right?

    Authors- fixed in the next version of the I-D.

        Section 5.3.2.1.3

           <csvContact:fStreet>  Contains the contact's street address line with
              type="contact:fPostalLineType".  An index attribute is required to
              indicate which street address line the field represents with index
              "0" for the first line and index "2" for the last line.  An
              OPTIONAL "isLoc" attribute to used to indicate the localized or
              internationalized form as defined in section Section 4.6.3.

        nit(?): pedantically, this would seem to say that if I only have two
        lines, I use indices 0 and 2 (not 0 and 1), and leave me in an awkward
        situation if there is only one line.  But I don't think anyone will
        actually get confused...

    Authors- text updated in the next version of the I-D.

           <csvContact:fCc>  Contains the contact's country code with
              type="contact:ccType" and isRequired="true".  An OPTIONAL "isLoc"
              attribute to used to indicate the localized or internationalized
              form as defined in section Section 4.6.3.

        Is there really localization available for ISO-3166-1 country codes?
        (I didn't follow the reference.)

    Authors- text updated in the next version of the I-D.

           <csvContact:fId>  Server-unique contact identifier for the contact
              object with isRequired="true".

        "parent", too, right?  I will stop reporting additional cases where
        "parent" seems to be needed.

    Authors- fixed in the next version of the I-D.

        Section 5.3.2.1.5

           <csvContact:fDiscloseNameLoc>  Exceptional disclosure preference flag
              for the localized form of the contact name with type="boolean".

           <csvContact:fDiscloseNameInt>  Exceptional disclosure preference flag
              for the internationalized form of the contact name with
              type="boolean".

        What happens if both 'Loc' and 'Int' are set?
        (Similarly for the other fields.)

    Authors- That is fine.  EPP RFC 5733 supports one or both forms, where a contact can have one postal information instance supplied with “type” = “int” and another instance supplied with “type” = “loc”.  The data escrow needs to be able to support providing one or both forms of postal information that also applies to the disclose fields.

        Section 5.4.1.1

           o  An OPTIONAL <upDate> element that contains the date and time of
              the most recent RDE registrar-object modification.  This element

        Is the "RDE" part here correct?  It feels weird for me for the escrow
        data format contents to include information that is more properly
        metadata about the escrow data; we do not seem to mention "RDE" when
        talking about other modification times.

    Authors- text updated in the next version of the I-D.

           Example of <registrar> object:

           ...
             <rdeRegistrar:gurid>123</rdeRegistrar:gurid>

        "123" seems to be a real registrar ID, listed at
        https://secure-web.cisco.com/1TgaXMf2Uug368L7Bp-i_JDdaoX_YnuJnxNlJFYxeIg6b0oFSc46d_COfCVTXv4gee1ETL2b01z4RGmfVuewO09acJhOZXjTO6VTDxuRbx3-8EmSb4E9QClGHi6gfOZ--DK04zl-yclRgB-eBnONnPd5M1gD8X2hyen8sTekXyG4Ottb1hvjJPgC_E9yElKN80qu8upWMaRw0AnXK8IzjYzuaJuA0mnZ-qaBQZRTMMBAowGqSrwO-9I0knbaa1bF7pxmXgyJk1T390kGhPJY7GA/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fregistrar-ids%2Fregistrar-ids.xhtml as
        corresponding to "The Registry at Info Avenue, LLC d/b/a Spirit
        Communications".  Perhaps a reserved value (e.g., 1) could be used
        instead?

    Authors- fixed in the next version of the I-D.

        Section 5.4.2

           Definition (Section 5.4.2.1.1).  The child CSV file definitions
           include a <csvRegistrar:fId parent="true"> field.  All the child CSV

        (this is probably applicable to previous models as well, but) we seem to
        allow either fId or fGurid, so this text is inconsistent with the actual
        practice.

        Section 5.4.2.1.1

        We list <csvRegistrar:fGurid> in both the "MUST" (as part of the choice)
        and "MAY" sections.  My reading of the "choice" part was that you had to
        pick one or the other, so it's not entirely clear to me how internally
        consistent this treatment is.

    Authors- The deposit can use either the registrar internal identifier (<csvRegistrar:fId>) or can use the IANA identifier (<csvRegistrar:fGurid>) for the unique identifier and for the foreign keys to cover cases where there are registrars that are not ICANN-accredited.  Specially ccTLDs can have registrars that are not ICANN-accredited and therefore will not have a valid registrar IANA identifier.

        Section 5.4.2.2.1

              <csvRegistrar:fId>  Contains the server-unique registrar
                 identifier with type="eppcom:clIDType" and isRequired="true".

              <csvRegistrar:fGurid>  Contains the ID assigned by ICANN with
                 type="positiveInteger".  The attribute "isRequired" MUST equal
                 "true".

        nit: we could use the same sentence structure for these two elements'
        descriptions.

    Authors- fixed in the next version of the I-D.

        Section 5.5.2.1.1

           <rdeCsv:fUrl>  URL that defines the character code points that can be
              used for the language defined by the <rdeCsv:fLang> field element.

        A pointer to which <rdeCsv:fLang> element(s) this is might be helpful,
        since it's not local to this section.

    Authors- fixed in the next version of the I-D.

        Section 5.6

           A domain name can only exist as a domain name object or an NNDN
           object, but not both.

        What entities are charged with enforcing this invariant?

    Authors- the receiving party (e.g. escrow agent, ICANN-EBERO program, etc.)

        Section 5.6.1.1

              *  If an NNDN is considered a mirrored IDN variant of a domain
                 object, then the NNDN will be tagged as "mirrored".  A

        Where is "NS mirroring" defined?  This seems particularly poingant since
        it defaults to "true".

    Authors- text updated in the next version of the I-D.

        Section 5.7

           registry supports EPP.  Only one EPP Parameters Object MUST exist at
           a certain point in time (watermark).

        nit: Is "only one" a maximum or a synonym for "exactly one"?

    Authors- It is a maximum of one. Fixed in the next version of the I-D.

        Section 5.9.1

           o  A <count> element that contains the number of objects in the SRS
              at a specific point in time (watermark) regardless of the type of
              deposit: Differential, Full or Incremental.  The <count> element
              supports the following attributes:

        If the count is supposed to be for objects in the SRS, why do we have
        the "uri" that distinguishes between the XML and CSV models?  What model
        is used for escrow seems independent of what the state of the SRS is.

    Authors- Correct, but the object type is important for cross-check against the deposits.

        Section 5.10

        I feel like I'm left without a proper understanding of what the DNRD
        Common Objects Collection actually does.

    Authors- The XML objects defined in the specific objects (e.d. domain, hosts, etc.) schemas are defined within the object schema and only used there. The collections are XML objects that are used in one or more objects schema.

        Section 8

        I had asked in a few previously places what entity is tasked with
        verifying some property (usually that an A-name and U-name are actually
        equivalent); would that be something that could/should be done by a data
        escrow agent during this sort of validation process?

    Authors- the receiving party (e.g. escrow agent, ICANN-EBERO program, etc.) performs the validations, and it's out of the scope of this document define the reaction to inconsistencies. For example, in the case of the ICANN-EBERO program, there are business rules when inconsistencies are found with the objetive of trying to restore objects within an agreed degree of certainty.

        Section 9

        (I am only spot-checking that min/maxOccurs in the schema matches with
        the prose descriptions, etc., not doing an in-depth review.)

        Section 9.1

        Some of the indentation seems inconsistent, e.g., around:

            </complexType>
             <complexType name="fRequiredDateTimeType">
             <complexContent>

    Authors- XSDs were beautified.

        Section 9.2

                     <element name="status"
                       type="domain:statusType" maxOccurs="11"/>

        11 is an interesting number (§5.1.1.1 has in prose just "one or more
        <status> elements"); is there a story behind it?

    Authors – Yes, 11 is an interesting number, but it represents the maximum number of statuses defined in RFC 5731 that can be included in the data escrow deposit.  The 11 maximum statuses would be:
    clientDeleteProhibited, clientHold, clientRenewProhibited, clientTransferProhibited, clientUpdateProhibited, inactive, serverDeleteProhibited, serverHold, serverRenewProhibited, serverTransferProhibited, serverUpdateProhibited
    The pending statuses can’t be combined with the matching prohibited statuses and the ok status is set when the other statuses are not set.  The net maximum number of statuses comes to 11 statuses. 

        Section 9.3

            <!-- Variant group / tag field -->
            <element name="fVariantGroup"
              type="rdeCsv:fTokenType"
              substitutionGroup="rdeCsv:field"/>

        Where is the "variant group" usage specified?

    Authors – Impressive catch of a legacy field definition! The csvDomain:fVariantGroup and the csvNNDN:fVariantGroup fields were removed from the Domain (Section 9.3) and the NNDN (Section 9.13) CSV XML schemas.

        Section 9.4

                     <element name="status"
                       type="host:statusType" maxOccurs="7"/>

        And here we have maxOccurs of 7; interesting.

    Authors – This is the number of statuses defined in RFC 5732.

        Section 9.7

            <!-- Disclosure of localized name
                 based on fDiscloseFlag? -->

        nit: why do all these comments have a question mark?

    Authors- Because they are boolean flags indicating exception disclosure to the fDiscloseFlag field value.

        Section 9.8

             <simpleType name="postalLineType">
               <restriction base="normalizedString">
                 <minLength value="1" />
                 <maxLength value="255" />

        Where does the line-length limit of 255 come from?

    Authors- The 255 comes from the use of contact:postalLineType in RFC 7433 for the name element of a contact and from the use of org:postalLineType in RFC 8543 for the name of an organization.

        Section 9.10

        Some whitespace niggles here as well, e.g.:

                   </sequence>
                     <attribute name="id" type="rdeIDN:idType" use="required"/>
                 </extension>

    Authors- XSDs were beautified.

        Section 9.14

            <!-- ASCII Compatible Encoding (ACE) name field -->
            <element name="fAName" type="rdeCsv:fNameRequiredType"
             substitutionGroup="rdeCsv:field"/>

        How common is the ACE abbreviation/term?  It does not seem to be used
        elsewhere in this document (and it is a little distracting to me, as the
        name of a security-area WG).

    Authors- text updated in the next version of the I-D.

            <!-- Variant group / tag field -->
            <element name="fVariantGroup"
              type="rdeCsv:fTokenType"
              substitutionGroup="rdeCsv:field"/>

        Where is the "variant group" usage specified?

    Authors – Impressive catch of a legacy field definition! The csvDomain:fVariantGroup and the csvNNDN:fVariantGroup fields were removed from the Domain (Section 9.3) and the NNDN (Section 9.13) CSV XML schemas.

        Section 11

           This document uses URNs to describe XML namespaces and XML schemas
           conforming to a registry mechanism described in [RFC3688].  Fourteen
           URI assignments have been registered by the IANA.

        "Fourteen" does not seem accurate any more.

        (Also, it is maybe a bit overzealous to use the generic "csv" prefix
        for the RDE CSV usage, though I do not specifically object to doing so.)

    Authors- fixed in the next version of the I-D.

        Section 13

        Thanks for what's here already; it covers a lot of good stuff.

        We should also say something about the level of trust placed in the
        escrow agent.  One might imagine a scenario where the data placed in
        escrow is signed by the registry in a way that can be verified
        post-facto by not only the escrow agent but other entities as well; in
        this case the escrow agent is trusted only to preserve an accurate copy
        and provide "new enough" data.  That does not seem to be the trust model
        used by this scheme, since we also must trust the escrow agent to
        provide a faithful copy of what the registry gave it, in the case when a
        recovery is needed.  Whether or not this presents significant risk is a
        policy and perhaps contractual matter, so it's not problematic from the
        specification point of view, but we should document that we make this
        strong assumption of trust of the escrow agent.  (This is particularly
        true due to the number of things that are negotiated out of band between
        registry and escrow agent, which would of course not be covered by any
        in-protocol indication of source authenticity.)

    Authors- text updated in the next version of the I-D.

        In a similar vein, we might mention that there's no protocol mechanism
        to detect a registry providing bogus data to an escrow agent.  (I'm sure
        there are legal/contractual mechanisms in place to do so, though!)

    Authors- We don’t believe the bogus data use case is worth mentioning in the draft. Like any other service, a legal/contractual requirement is needed as a companion.

        It's also important to discuss the vagaries of quoting/escaping in the
        CSV format, especially so since we allow for the separator to be
        specified manually.  The parser needs to ensure that only the intended
        separators are treated as separators and ignore that character when it
        is quoted or escaped (as appropriate) for appearance in the body of a
        given field.

    Authors- text added to section 4.6.2.1.

        I would suggest some mention that the various datastructures include a
        few places that have some internal redundancy, and that if the values
        become inconsistent there can be harmful consequences (e.g., if
        different entities use different fields as their reference).

    Authors- text updated in the next version of the I-D.

           Note: if Transport Layer Security (TLS) is used when providing an
           escrow services, the recommendations in [RFC7525] MUST be
           implemented.

        Please cite this as BCP 195.

    Authors- fixed in the next version of the I-D.

        Section 19

        Perhaps the YYYYMMDD could be replaced with non-placeholder values to
        make the example more realistic?

        Should there also be examples for the CSV contents of the indicated
        files?  (This would also give the opportunity to show that the checksum
        of the content matches the value indicated in the example XML.)

    Authors- The use of YYYYMMDD is preferred because it doesn’t get into the draft age issue.  The use of a real date is not required, but the use of a pseudo date is useful.  There are plenty of examples of the CSV files in the draft, so section 19 should solely focus on the example XML.

        Section 21.1

        If it is not needed for the textual representation of an IPv4 address,
        RFC 791 seems to otherwise not be referenced.

    Authors– Textual representation of IPv4 addresses is needed, so RFC 791 needs to be referenced.

        Section 21.2

        Since SHA-256 is a "MAY", that might qualify RFC 6234 as a normative
        reference (per
        https://secure-web.cisco.com/1uwIuac4euQPGBID88dBOLdFEvDZRPl2rDYlp8T6xU6AVgvJBBPJcY7LWhsbLZrnWUMcYc5KcGOGFa0PaMLyCeaRDYBmNkFWFH1z8llobzhbmVx7ZNWmZNKIbxDO7Mmlg1D8L9IQEPaUR_avwwDIJ9yQ2oOttQynOdxeVrw9u7PHByf8aSAPt1BlAM5VWBsvOU2VASXy_MtwKc_QUK2j_80Hr93Tgp2URXBUwfe8PsT-AhryvlceXuwf4ALFvJnNjc2siOkV7bpeim4QofiSbvQ/https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fnormative-informative-references%2F__%3B%21%21PtGJab4%21s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1eT6sl1gU%24 )

        Likewise for RFC 7525, which is a MUST when TLS is used.

    Authors- fixed in the next version of the I-D.