Domain Name Registration Data (DNRD) Objects Mapping
draft-ietf-regext-dnrd-objects-mapping-11

Note: This ballot was opened for revision 08 and is now closed.

Barry Leiba Yes

Deborah Brungard No Objection

Roman Danyliw No Objection

Comment (2020-10-08 for -10)
No email
send info
Thank you for this document and the various XLS/CSV examples related to particular elements of the data model.

Thanks for addressing my comments.

Benjamin Kaduk (was Discuss) No Objection

Comment (2020-12-09 for -10)
Thank you for addressing my Discuss (and Comment) points, as well as explaining
to me the ones that are not actually issues.

I think it would be good to make one last pass through the document to confirm that
the "parent" attribute is listed where needed.

Erik Kline No Objection

Comment (2020-08-25 for -09)
[ section 4.5 ]

* For text representations you want RFC 5952 rather than 4291.

[ section 5.1.2.1.5, 5.2.2.1.3 ]

* It's not clear that ",v4" or ",v6" are adding anything. The IP address
  family should be unambiguous without the hint.

  No change necessary, it just seems like this isn't really needed.  (For
  example, if there's even a remote possibility someone might try to list
  IPv4-mapped IPv6 addresses -- or even worse, compat addresses -- then
  there are going some other, much bigger problems ahead.)


[ section 5.4.1.1 ]

* Is it recommended at all that rdeRegistrar:url be https whenever possible?

* In addition to whois name/url should there RDAP information?  Or is the
  http/https whois URL expected to handle RDAP?

Murray Kucherawy No Objection

Comment (2020-08-26 for -09)
[To the IESG: In the IANA Considerations section, the contact for all registrations is "IESG <regext@ietf.org>".  That's not the IESG's address though.  (I remember us discussing this in previous telechats, but it's late and I'm blanking on whether this is the outcome we wanted.)]

My colleagues have made a lot of good suggestions already, so I don't have much to add other than these:

In Section 8, there's this bullet:

   o  If a Differential Deposit is to be tested, the dataset is created
      by using the Differential Deposit plus all the required deposits
      leading to the last previous Full Deposit.

It seems obvious, but should this make clear the order in which the differential deposits are applied?

Totally a nit (which I now see Eric V also mentioned): In a couple of places there's an ASCII expression like "ASCII value 0x002B".  Since ASCII is 7-bit, shouldn't that just be "ASCII value 0x2B"?

Warren Kumari No Objection

Comment (2020-08-25 for -09)
Thanks to Joe Clarke for his OpsDir comments, and thanks the authors for addressing them; this has improved the document noticeably (it's nice when the Directorate process works so well).

Some minor nits / comments:
1: 'Version compatibility: versions 03 - 08 are known to be implemented.' -- probably this should bump to -09
2: Wrapping the BEGIN <whole pile of XML> END in <CODE BEGINS> file "some_file_name.xml" <pile 'o xml> <CODE ENDS> as used by e.g. rfc6087 S3.1 (or use the v3 RFC tools) -- this will allow standard tools to extract the schemas more easily and with less errors.

Alvaro Retana No Objection

Martin Vigoureux No Objection

Éric Vyncke No Objection

Comment (2020-08-25 for -09)
Thank you for the work put into this document. Due to my heavy workload, I did not review in details the model itself.

Please find below a couple of non-blocking COMMENTs (a reply to  my COMMENTs will be welcome).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

A generic question about the point (5) of the document shepherd write-up:
"The AD is asking for further review from the Internationalization
Directorate, specifically on Section 10, which RECOMMENDS UTF-8 but allows
UTF-16.  The working group cites RFC 5730, Section 5, and aligns with that.
The AD would prefer to deprecate UTF-16, and notes that RFC 5730, is now
well over 10 years old.  Other opinions will be useful."

Did the WG receive any other opinions ? It is not clear from the write-up.

-- Section 4.3 --
Just curious here, why are the ASCII code expressed as a 16-bit unit while ASCII codes are 7-bit long ? E.g., '("+", ASCII value 0x002B)'

-- Section 4.4 --
Are you sure that CRC32 and SHA-256 belongs to a section named 'checksum' ? Those 2 techniques are different than checksums and much stronger for integrity checks. Suggest to renamed this section.

In addition, should the algorithm be identified ?

-- Section 4.5 --
RFC 4291 is about the addressing structure of IPv6 (i.e., semantic), please replace this reference to RFC 5952 that is about how to write an IPv6 address (i.e., syntax).

-- Section 4.6.1 --
Just curious again... why not using plain SQL data definition language 'create table()' statements rather than using XML to describe relational tables? Of course, the XML file contains other information than the SQL data definition language but it is lacking some information from SQL.

Also, it seems that using XML rather than SQL forces the primary key and foreign key to have the same name (e.g., <csvSample:fName/>)

-- Section 5.3.2.1.3 --
Should the postal ZIP code be included ?

== NITS ==

-- Section 5.1.1.1 --
Really cosmetic, but, having an expiration date in 2015 in the example in a document published in 2020 ;-)