Subject: [regext] Éric Vyncke's No Objection on draft-ietf-regext-dnrd-objects-mapping-09: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Tue, 25 Aug 2020 11:50:59 -0700

Éric Vyncke has entered the following ballot position for
draft-ietf-regext-dnrd-objects-mapping-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-dnrd-objects-mapping/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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 ;-)

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 25 Aug 2020 19:05:37 +0000

> -----Original Message-----
> From: Éric Vyncke via Datatracker <[email-masked]>
> Sent: Tuesday, August 25, 2020 2:51 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; regext-
> [email-masked]; [email-masked]; Hollenbeck, Scott
> <[email-masked]>; Hollenbeck, Scott
> <[email-masked]>
> Subject: [EXTERNAL] Éric Vyncke's No Objection on draft-ietf-regext-dnrd-
> objects-mapping-09: (with COMMENT)
>
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
>
>
> Please refer to https://secure-
> web.cisco.com/1W4L5pJ3TyJndjeWWepPJ0FYUtskoZH25tdV9KSXxHJKAETOV
> VLYUrU9UwS7IpMbffNuBMRr1FoqkK_AYGSpMMbXvLodTA9tzoICBUI-
> 2Nrnx6Mf9mkb0ye4qkvDMQvgWbHEXwz247RE03vC3Gfp85STTZtv9c_qSjk1p
> 3Ey6vKdCH_yMR3NY23wgcbc2_2Tn73FHz645-DCJd9ESo517r3St_DvzzdIU9-
> Hq-
> 84c6j6PQg_36CgAhz6SnQuEWo6_/https%3A%2F%2Fwww.ietf.org%2Fiesg%2
> Fstatement%2Fdiscuss-criteria.html
> https://secure-web.cisco.com/1LRZMVfz2P0-
> h9j7TBvAwsFXMfUmCjMvn9KguyOcseMpn2W7tiUjymb5xH2qfaIpi5XewFNIu
> 4VCP3iOduGLdFWkFmDFdUt8Z0rgLZSOxVYuRO_HmgQNvVBNAmhVBsQiT2s
> XlX3LQqqvpb0YZD9uxKfwyxuXhcfyIZeK4rG89aUTrsRj-W4foUixOz0Ht-
> uMZUgluC7kTtKsJOxNLotmtrvEKcQb89w8fz2m6c3xCsPa8JK0j4Lfzw_EAOcRpj
> axWJd6divcDTEFjbWpZpS82jg/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc
> %2Fdraft-ietf-regext-dnrd-objects-mapping%2F
>
>
>
> 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 didn't see any opinions expressed, or anything being requested of the i18n directorate..

Scott (the document shepherd)