Éric Vyncke has entered the following ballot position for draft-ietf-regext-rfc7484bis-05: 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/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7484bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my blocking DISCUSS (ok it was trivial to fix ;-) ) and replying to all my comments below. I have kept it below for archiving only, ignore it. Thank you for the work put into this document. Special congratulations for having THREE implementations including one by the author. Please find below one archived DISCUSS point (trivial to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I am also sympathetic to Ben Kaduk's DISCUSS point. Special thanks to Jasdip Singh for the shepherd's write-up including the section about the WG consensus. I hope that this helps to improve the document, Regards, -éric == Archived DISCUSS for history — to ignored == -- Section 5.2 -- The end of this section uses "https://example.net/rdaprir2/ip/2001:0db8:1000::/48"; (not RFC 5952 compatible with the leading zero in front of "db8") as an example but this example seems to contradict section 3.1.1 of RFC 9082. == COMMENTS == -- Section 1 -- No need to reply, but I really appreciate the author's use of the past tense in "Per this document, IANA has created new registries" as opposed to similar documents using the future tense. This document will age well ;-) -- Section 3 -- "be retrieved via HTTP from locations specified by IANA" should this document include the IANA location ? Should a "real" date be used rather than "YYYY-MM-DDTHH:MM:SSZ" ? I.e., the syntax is specified later anyway so let's use a real example ? Later examples in section 5 use "real" dates but not those in section 4 ;-) -- Section 5.2 -- Should RFC 5952 also be specified as IPv6 representation in addition to RFC 4291 ? -- Section 5.3 -- The IANA allocation for documentation ASN is rather short (6 ASNs !), so, I do not mind too much that the example in this section uses private ASN space but suggest anyway to limit the example to the documentation ASNs. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
