Note: This ballot was opened for revision 08 and is now closed.
Thank you for this document and the various XLS/CSV examples related to particular elements of the data model. Thanks for addressing my comments.
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.
[ section 4.5 ] * For text representations you want RFC 5952 rather than 4291. [ section 184.108.40.206.5, 220.127.116.11.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 18.104.22.168 ] * 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?
[To the IESG: In the IANA Considerations section, the contact for all registrations is "IESG <email@example.com>". 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"?
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.
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 22.214.171.124.3 -- Should the postal ZIP code be included ? == NITS == -- Section 126.96.36.199 -- Really cosmetic, but, having an expiration date in 2015 in the example in a document published in 2020 ;-)