(resend with different mail from) Rick, Jim,
Sorry to take long to respond. Thanks for the input and I will discuss with Jim Galvin as my co-author about splitting the draft. I will also review and address the comments you provided. I am occupied this week on work matters and I will be away next week. I will start as soon as I can from the week of July 4 on this draft. Best, Joseph On Wed, Jun 22, 2022 at 6:06 PM Rick Wilhelm <rwilh...@pir.org> wrote: > Joseph, > > > > Thanks for the ongoing updates to the draft. > > > > Some comments to the -07 draft below. > > > > Before getting into a more detailed, I want to express support for the > high-level suggestions that Jim Gould made in a June 15 message. Pasting > them here: > > > > 1. Split the draft into two separate drafts, with the first being a > standards track draft that covers the framework elements (format, IANA > registries, and a base set of report elements), and the second being an > informational track draft that includes reports that use the framework. > The framework should be flexible enough to support the definition of many > report elements and many reports. > 2. To support an extensible set of report element values, such as > transactions and objects, the Data Element Definition registry can be > expanded to support typed elements, with the initial set including (fields, > transactions, and objects). This is like the RDAP JSON Values registry > that supports multiple types of values. This way new types of transactions > and objects can be registered that are unique and are described. > > > > The first item is consistent with in-session comments that I’ve made at > prior meetings, but I don’t think that I’ve sent it to the list before. My > detailed review of the doc has further convinced me that separating into > two documents is a better idea than combining one. > > > > > > The second is something that has emerged upon further review. > > > > > > Now to detail > > > > > > Section 2: > > > > Regarding: > > > > Data element names in the > > IANA registry MUST be unique and MUST be processed as case > > insensitive. > > > > I’m certainly supportive of case-insensitive processing. But as the Draft > has data element names with a smattering of upper-case letters, I’m very > concerned that we are dooming our predecessors to a frustrating set of > defects when libraries fail to process these in a case-insensitive manner. > I’ve been through any number of difficult debugging sessions involving JSON > handling where things go awry. Since we are using the underbar as a word > separator, we don’t need the upper-case to denote word boundaries. That > is: “date_time” is just as readable as “Date_Time”. > > > > Therefore: I would like to suggest that the upper-case letters in all the > data elements be lower-cased. This would be covering 2.1 – 2.4. > > > > > > > > 2.1.4. Transaction_Type > > 2.1.5 Object_Type > > > > I found the specificity of these sections to be lacking. Based on this > language, incompatible implementations could emerge. For example: the use > of all lower case (“domain”), mixed case (“Domain”), all upper (“DOMAIN”). > Or even abbreviations: “dom”, “con”, “hos”. Same with the transaction > types. > > > > This comment is also linked to the (pasted) second suggestion from Jim > Gould’s comment. If, for some reason, Gould’s suggestion of an extensible > set of report element values is _*not*_ taken, then the lack of > specificity should still be address via some other mechanism. > > > > 2.1.5 Object_Type > > > > The current text: > > > > The object type involved in the report. > > > > Implies that a report can only involve a single object. I don’t have any > examples handy, but I don’t understand the restriction. Maybe the latter > part of the sentence can be improved? > > > > 2.3.1 Available_Date > > 2.3.2 Deleted_Date > > 2.3.3 Redemption_End_Date > > 2.3.4 Pending_Delete_Date > > 2.3.5 Updated_Date > > 2.3.6 Created_Date > > 2.3.7 Expiration_Date > > > > The date and time format follows the "type=dateTime" specification as > defined in RFC 5731 [RFC5731]. > > > > At the risk of stepping into Hollenbeck/Gould territory, the dateTime > linkage to EPP is established in RFC 5730 and I _*think*_ that there it > is part of base XML, not defined in the RFC. > > > > 2.4. > > > > Overall, in this section the descriptions of the element names would be > clearer if there was more use of the indefinite article “a” (or “an”) and > less use of the definite article “the”. This is because the data elements > apply broadly, rather than to a particular instance. As an example, the > first sentence of the section: > > > > As is: “The identifier assigned to the registrar.“ > > Proposed: “The identifier assigned to a registrar.” > > > > In the edits, this will look like a series of nits, but it would be > helpful to the reader > > > > 2.4.1. Registrar_ID > > > > The current text: > > > > The identifier assigned to the registrar. If the registrar is > > accredited under ICANN, it MUST be the registrar's IANA ID > > [IANA_Registrar_IDs]. Otherwise it is a value known between the > > producer and the consumer, set via an out-of-band mechanism and > > unique within all reports of the producer. > > > > Suggested: > > > > The identifier assigned to a registrar. If a registrar is > > accredited under ICANN and the producer report involves an > ICANN-accredited TLD, it MUST be the registrar's IANA ID > > [IANA_Registrar_IDs]. Otherwise it is a value known between the > > producer and the consumer, set via an out-of-band mechanism. > > . > > I think that the current text places too many restrictions of ccTLD > operators, who may have ICANN-accredited registrars and non-ICANN > accredited registrars. A ccTLD does not have any requirement to use IANA > IDs for those registrars that happen to be ICANN-accredited and this > document would have any sway regarding uniqueness requirements on registrar > identifiers for a producer. > > > > > > 2.4.3. DNSSEC > > > > Regarding: > > > > The value MUST be either 'YES' or 'NO' to indicate whether the domain > > is DNSSEC signed. > > > > In this context, the element seems like it might be better named > HAS_DNSSSEC to indicate that it is a boolean concept. > > > > Separately (or perhaps related), I think that “true” and “false” would be > better values than “YES” or “NO”, as these are used in JSON ( > https://datatracker.ietf.org/doc/html/rfc8259#section-3) > > > > 2.4.6. Contact_Name > > > > Regarding: > > The name of the contact object. Usually it is the name of an > > individual or an organization as described in RFC 5733 [RFC5733] > > Section 2.3. > > > > While RFC 5733 Section 2.3 describes the representation of individual and > organizational names associated with a contact, Section 3.2.1 has a clear > distinction between the individual and the (optional) organization. It is > unclear how the current doc handles a situation where both would be > communicated in the report. > > > > Also, this field is not actually the “name of the contact object”, it (per > RFC 5733) “contains the name of the individual or role represented by the > contact” > > > > 2.4.7. Linked > > > > See above comment related to YES/NO vs true/false for 2.4.3 DNSSEC > > > > 2.4.9. Host_IP > > > > Regarding: > > > > The IP address of the host object. The syntax of the IPv4 address > > MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address > > MUST conform to RFC 4291 [RFC4291]. If it contains mutliple IP > > addresses, each must be separated by symbol comma with the whole > > string under double quotes as specified in RFC 4180 [RFC4180] > > > > Various issues with clarity. Suggested text: > > > > The IP address(es) of a host object. The syntax of an IPv4 address > > MUST conform to RFC 791 [RFC0791]. The syntax of an IPv6 address > > MUST conform to RFC 4291 [RFC4291]. If the element contains multiple IP > > addresses, each must be separated by a comma; with the > > element enclosed with double quotes as specified in RFC 4180 [RFC4180] > > > > > > Section 3: > > > > I think that these comments are valid even if the doc gets split into two > (as described above) > > > > Regarding: > > > > A consumer MUST be able to receive data elements that are not > > recognized and MAY skip them accordingly, both in the header row and > > in the record rows. > > > > I think that the “MAY” here should be removed, because if the consumer > does not “skip them accordingly”, then the consumer really is not really > “able to receive data elements that are not recognized” (which is a MUST). > Suggested edit is to remove the “MAY”, as in: > > > > A consumer MUST be able to receive data elements that are not > > recognized and skip them accordingly, both in the header row and > > in the record rows. > > > > > > Regarding: > > > > A report is specified in the report registry with two pieces of > > information. First is the name of the report. This can be whatever > > is appropriate as defined by the producer of the report. The name of > > the report MUST be unique and this characteristic MUST be enforced by > > registry. > > > > It seems odd that there is so much work going into designing this and the > naming convention for reports is being left entirely unspecified. While I > haven’t given it much thought of what it _*should*_ be, the idea that > it’s a “free for all” seems odd. I don’t think that we should be requiring > everyone to have the same name for every report. But by this spec, whoever > is first to create “domain-report”, “contact-report”, etc and the name > doesn’t indicate any source. > > > > > > Section 3.1-3.7: > > > > Pls note that I did not do a detailed review the structure/contents of the > sample reports in 3.1-3.7, I think that they are interesting examples, but > by no means definitive. As described in the initial comments, I think that > these should be in an informational document because they provide a point > of view on what reports might look like, but it is just a point of view. > From personal experience, these reports vary widely (wildly?) and can be > impacted by all sorts of context. Having these examples in a standards > track document gives them inordinate weight. > > > > > > Nits: > > > > Section 1: > > > > Regarding: > > > > Among the distinctions that vary by > > producer is the syntax of the data provided, > > > > Suggest to add: “report” to improve clarity; to be: > > > > Among the report distinctions that vary by > > producer is the syntax of the data provided, > > > > > > Section 2: > > > > Regarding: > > > > The name of the data element MUST be unique and this characteristic > > MUST be enforced by the registry. > > > > I _*think*_ that in this context “registry” refers to “IANA data element > registry” (and not the report producer). Would be good to clarify regardless > > > > > > Regarding: > > > > The data elements adopt the same naming convention, where all the > > leading character of each word use upper-case and the rest in lower- > > case, > > > > Suggest to removed “all” and swap “the rest” for “the remaining > characters” to improve clarity; to be: > > > > The data elements adopt the same naming convention, where the > > leading character of each word uses upper-case and the remaining > characters use lower- > > case, > > > > Typo: “symbol” > > > > Section 3: > > > > Regarding: > > > > The name of the report MUST be unique and this characteristic MUST be > enforced by > > registry. > > > > Similar to the previous comment. I _*think*_ that in this context > “registry” refers to “IANA report registry” (and not the report producer). > Would be good to clarify regardless. > > > > > > This turned out longer than I expected. There are probably things that I > missed. Hope it’s helpful. > > > > Thanks, > > Rick > > > > > > *From: *regext <regext-boun...@ietf.org> on behalf of > internet-dra...@ietf.org <internet-dra...@ietf.org> > *Date: *Wednesday, June 8, 2022 at 5:22 PM > *To: *i-d-annou...@ietf.org <i-d-annou...@ietf.org> > *Cc: *regext@ietf.org <regext@ietf.org> > *Subject: *[EXTERNAL] [regext] I-D Action: > draft-ietf-regext-simple-registration-reporting-07.txt > > CAUTION: This email came from outside your organization. Don’t trust > emails, links, or attachments from senders that seem suspicious or you are > not expecting. > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Registration Protocols Extensions WG of > the IETF. > > Title : Simple Registration Reporting > Authors : Joseph Yee > James Galvin > Filename : draft-ietf-regext-simple-registration-reporting-07.txt > Pages : 35 > Date : 2022-06-08 > > Abstract: > Domain name registries (the producer) and registrars (the consumer) > report to each other by sharing bulk information through files. This > document creates two IANA registries to establish a standard > reporting mechanism between domain name registries and registrars. > The first IANA registry lists standard data elements and their syntax > for inclusion in the files. The second IANA registry lists standard > reports based on the standard data elements. Each report is a file > formatted as a CSV file. The advantage of this reporting mechanism > is that a report, each file, can be imported by recipients without > any prior knowledge of their contents, although reporting is enhanced > with a minimum of knowledge about the files. The mechanism for the > distribution of and access of the files is a matter of local policy. > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-regext-simple-registration-reporting/ > <https://protect-us.mimecast.com/s/PBFoCjRNX8inNRVU1YbO9?domain=datatracker.ietf.org> > > There is also an HTML version available at: > > https://www.ietf.org/archive/id/draft-ietf-regext-simple-registration-reporting-07.html > <https://protect-us.mimecast.com/s/6NS9CkRNY7iOG5Ph8I2X8?domain=ietf.org> > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-simple-registration-reporting-07 > <https://protect-us.mimecast.com/s/cYz1ClYNZ7C24XjFVSw62?domain=ietf.org> > > > Internet-Drafts are also available by rsync at rsync.ietf.org: > :internet-drafts > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > <https://protect-us.mimecast.com/s/gRR5CmZg1yCj4W9C3ox2a?domain=ietf.org> >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
