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