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

Gustavo Lozano <gustavo.lozano@icann.org> Wed, 16 December 2020 23:09 UTC

Return-Path: <gustavo.lozano@icann.org>
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 8AD0A3A128E; Wed, 16 Dec 2020 15:09:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2wwqw3Nd0H6j; Wed, 16 Dec 2020 15:09:43 -0800 (PST)
Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4FD3A1289; Wed, 16 Dec 2020 15:09:43 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0BGN9gr7020947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Dec 2020 23:09:42 GMT
Received: from MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Wed, 16 Dec 2020 15:09:41 -0800
Received: from MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) by MBX112-W2-CO-2.pexch112.icann.org ([10.226.41.130]) with mapi id 15.02.0721.006; Wed, 16 Dec 2020 15:09:41 -0800
From: Gustavo Lozano <gustavo.lozano@icann.org>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-regext-dnrd-objects-mapping@ietf.org" <draft-ietf-regext-dnrd-objects-mapping@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>, "Scott Hollenbeck" <shollenbeck@verisign.com>
Thread-Topic: [Ext] Benjamin Kaduk's Discuss on draft-ietf-regext-dnrd-objects-mapping-09: (with DISCUSS and COMMENT)
Thread-Index: AQHWfDuKvLXjw9cyk0+yGyo9uY1PKKmOg6kAgGIuFACAClbbAA==
Date: Wed, 16 Dec 2020 23:09:41 +0000
Message-ID: <C23391BD-A518-43A2-8949-B1C31453368D@icann.org>
References: <159850980859.9278.16659516718065092581@ietfa.amsl.com> <E4A80472-B044-4992-9C0F-C51D85CAF69B@icann.org> <20201210011612.GC64351@kduck.mit.edu>
In-Reply-To: <20201210011612.GC64351@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: text/plain; charset="utf-8"
Content-ID: <F213B77B8FD4794FB7FE71E18185E2B4@pexch112.icann.org>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-16_10:2020-12-15, 2020-12-16 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/pL_rrQWEaJyOm_Umaz-J1CMILBM>
Subject: Re: [regext] [Ext] Benjamin Kaduk's Discuss on draft-ietf-regext-dnrd-objects-mapping-09: (with DISCUSS and COMMENT)
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: Wed, 16 Dec 2020 23:09:47 -0000

Thank you Ben,
 
Version 11 of the I-D (https://tools.ietf.org/html/draft-ietf-regext-dnrd-objects-mapping-11) has been published.

We think that this version addresses your feedback.
 
Comments inline.
 
Regards,
Gustavo

On 12/9/20, 17:16, "Benjamin Kaduk" <kaduk@mit.edu> wrote:

    Hi Gustavo,

    Thank you for the updates in the -10 and your many responses below.  I
    appreciate that you took the time to explain things to me that I clearly
    had not properly understood at first, and I am sorry that I took so long to
    reply.

    I will go update my ballot position in the datatracker shortly (to No
    Objection), but would appreciate if you could confirm or do another pass
    through the (CSV) element specifications to look for whether "parent" needs
    to be specified anywhere else -- I did not re-read enough of the document
    to remind myself exactly which tables would be present, but it seemed that
    perhaps the fId element would almost-always be expected to be a foreign
    key, among others.

Authors- The "parent" attribute represents a parent, child relationship or a 1-to-many relationship between a parent and child CSV files, where the attribute is set in the child CSV fields.  The parent, child relationship includes the use of a cascade replace or cascade delete of the existing child records in a differential or incremental deposit.  Not all foreign keys, such as when used in a many-to-many relationship (e.g., fId), make up a parent and child relationship, so therefore setting the parent="true" is not applicable.  The draft has been reviewed for the use of the "parent" attribute to define a parent, child relationship between the CSV files.
 
Upon the re-review, the following fields need to have the parent="true" attribute set:
 
1. <csvDomain:fName parent=”true”/> for the “dnssec” Key Data Interface example (section 5.1.2.1.6)
 
Upon the review, the following fields need to have the parent=”true” attribute removed:
 
1. <csvContact:fId/> for the “domainContacts” example (section 5.1.2.1.2) – This is really not a parent, child relationship with the contact.  The contact can only be deleted in the registry if all links to the contact from domains are removed.
2. <rdeCsv:fRoid/> for the “domainNameServers” example (section 5.1.2.1.4) – This is really not a parent, child relationship with the host.  The host can only be deleted in the registry if all links to the host from domains are removed.

    More inline...

Authors- Comments inline.

    On Thu, Oct 08, 2020 at 09:57:50PM +0000, Gustavo Lozano wrote:
    > Thank you Benjamin,
    > 
    > Comments below are prefixed with Authors-.
    > 
    > A new version of the I-D has been published here: https://urldefense.com/v3/__https://www.ietf.org/id/draft-ietf-regext-dnrd-objects-mapping-10.txt__;!!PtGJab4!uK3J4KInw1rca0UARWPu3DFXht_ZfgN5arMzbMi2NitoFK-82nDfBWsJtKnz3YkRoYLoKFSHJDs$ 
    > 
    > Regards,
    > Gustavo
    > 
    > On 8/26/20, 23:30, "Benjamin Kaduk via Datatracker" <noreply@ietf.org> 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!PtGJab4!s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e6IR8BTA$ 
    >     for more information about IESG DISCUSS and COMMENT positions.
    > 
    > 
    >     The document, along with other ballot positions, can be found here:
    >     https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/__;!!PtGJab4!s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1e5ypcsy4$ 
    > 
    > 
    > 
    >     ----------------------------------------------------------------------
    >     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":

    Between your explanation and looking at the draft again, I think I have a
    better handle on what is going on here, now -- thanks.  (I do see there was
    at least one spot where the -10 fixed things up, too -- thanks for going
    checking that.)

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

    Much appreciated.

    >     ----------------------------------------------------------------------
    >     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://urldefense.com/v3/__https://tools.ietf.org/html/rfc5731*section-2.4__;Iw!!PtGJab4!uK3J4KInw1rca0UARWPu3DFXht_ZfgN5arMzbMi2NitoFK-82nDfBWsJtKnz3YkRoYLo4B2APUk$  [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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/regext/EmKW32exlPgLbBUIbS8OjdYUJWc/__;!!PtGJab4!uK3J4KInw1rca0UARWPu3DFXht_ZfgN5arMzbMi2NitoFK-82nDfBWsJtKnz3YkRoYLoAY3bi74$  [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://urldefense.com/v3/__https://tools.ietf.org/html/rfc5732*section-2.5__;Iw!!PtGJab4!uK3J4KInw1rca0UARWPu3DFXht_ZfgN5arMzbMi2NitoFK-82nDfBWsJtKnz3YkRoYLo0YCnJEQ$  [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.

    I still think this is under-specified, but will drop the point since
    there's no reason to insist on this document doing things differently than
    5732.

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

    Understood; we'll just have to live with this.

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

    I like your solution :)

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

    Thanks.  (Best to leave further changes to the RFC Editor, who I expect to
    leave just the first expansion and remove the others.)
    >     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.

    I think it helps -- thanks.

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

    It looks like the instances of "parent" usage that I specifically noted
    were changed in the -10, but I didn't see any other changes.  I find it
    pretty unlikely that I just happened to stop calling them out exactly where
    they stopped being needed, so please confirm that the remaining fId
    elements do not in fact need to have "parent" set.  (And any others that
    might need it, though I'm not sure there are any.)

Authors- thank you, Ben. Please refer to the details of the re-review above.

    >     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://www.iana.org/assignments/registrar-ids/registrar-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.

    I see how there can be registrars that will not have a GURID.  My question
    is more about why we include the <fGurid> element appears in the list of
    "MAY be used" elements -- the presence in the form of "MUST use <fId> or
    <fGruid>" would seem to be enough to allow its presence, so I'm not sure if
    having it in the MAY list as well actually would allow it to be used in
    places that it would not otherwise be allowed.

Authors- For the “registrar” CSV file, the choice of the <csvRegistrar:fId> and <csvRegistrar:fGurid> fields are included under the field elements that MUST be used as the primary key.  The inclusion of the MAY <csvRegistrar:fGurid> enables the use of the <csvRegistrar:fId> as the primary key and to include the additional GURID as an attribute of the registrar.

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

    It looks like this (or maybe other) change allowed a few places to creep in
    where we write "isRequired"="true" (with quotes around "isRequired" that
    are not used in most of the document).

Authors- The use of the isRequired=”true” is used to match what’s included in the XML, while the “isRequired” is used when naming the attribute.  The <csvRegistrar:fGurid> definition in section 5.1.2.1.1 should be reflected as isRequired=”true” instead of “isRequired”=”true”.  That looks to be the only incorrect reference to “isRequired”=”true”.

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

    Thank you!

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

    Ah, thank you for explaining where this came from (and the 7 for the
    statuses as well).

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

    Okay.

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

    Thanks for all of these!

    >     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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/__;!!PtGJab4!s1nuWEaTWTlygiU9qZXsG1O9BWmgP0nR53eMCtazUTqp49hdVhbJM2IvF2YN_gjULj1eT6sl1gU$ )
    > 
    >     Likewise for RFC 7525, which is a MUST when TLS is used.
    > 
    > Authors- fixed in the next version of the I-D.

    Thanks again for all the updates.

    -Ben