Re: [regext] I-D Action: draft-ietf-regext-simple-registration-reporting-07.txt

[Rick Wilhelm <[e-mail]>]

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 <[e-mail]> on behalf of [e-mail] <[e-mail]>
Date: Wednesday, June 8, 2022 at 5:22 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>
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
[e-mail]
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/gRR5CmZg1yCj4W9C3ox2a?domain=ietf.org>