Ballot for draft-ietf-uuidrev-rfc4122bis
Note: This ballot was opened for revision 10 and is now closed.
# Internet AD comments for draft-ietf-uuidrev-rfc4122bis-10 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S6.2 * "which is sorts" -> "which is sorted"? ### S6.10 * "UUIDs formats" -> "UUID formats"
Thank you for the work on this document. Many thanks to Marco Tiloca for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/wXCmWw9yLijUDNSHcZxLainEUb8/, and to the authors for addressing Marco's comments. I agree with Paul and was surprised to see no IANA registry is created (at least for var and ver), but the document does explicitly mention that "the authors and working group have concluded that IANA is not required to track UUIDs used for identifying items such as versions, variants, namespaces, or hashspaces.", so that makes me believe a discussion has happened around it and a conclusion reached. Without knowing much of the background behind it, I'll leave it to the responsible AD to make sure that has been the case.
Thanks for the document update. I've updated my ballot to No Objection.
Thanks for addressing my comments. Discuss cleared.
Section 6.6 High Impact: A duplicate key causes an airplane to receive the wrong course which puts people's lives at risk. In this scenario there is no margin for error. Collisions MUST be avoided and failure is unacceptable. Applications dealing with this type of scenario MUST employ as much collision resistance as possible within the given application context. Not to trivialize the seriousness of the described scenario, but normative language around airplane design and operation doesn’t seem appropriate or in scope for the WG. Furthermore “as much collision resistance as possible” isn’t particularly precise. Recommend s/MUST/must/ ** Section 6.9 A generic approach, however, is to accumulate as many sources as possible into a buffer, use a message digest such as MD5 [RFC1321] or SHA-1 [FIPS180-4], take an arbitrary 6 bytes from the hash value, and set the multicast bit as described above. RFC4112 referenced MD5 and SHA-1, but didn’t tie the implementation to them, why can’t a modern hash algorithm (SHA-256) be recommended here instead? ** Section 6.11 UUIDs SHOULD be treated as opaque values and implementations SHOULD NOT examine the bits in a UUID. However, inspectors MAY refer to Section 4.1 and Section 4.2 when required to determine UUID version and variant. As general guidance, we recommend not parsing UUID values unnecessarily, and instead treating them as opaquely as possible. Although application-specific concerns could of course require some degree of introspection (e.g., to examine the variant, version or perhaps the timestamp of a UUID), the advice here is to avoid this or other parsing unless absolutely necessary. Why are both of these paragraphs needed? The first seems to say the same thing as the second except with normative language. ** Section 8 Implementations SHOULD NOT assume that UUIDs are hard to guess. For example, they MUST NOT be used as security capabilities (identifiers whose mere possession grants access). -- Why isn’t this a “MUST NOT assume”? ** Section 8 MAC addresses pose inherent security risks and SHOULD NOT be used within a UUID. Is there any advisory language that can be provided that could explain when a MAC address should be used?
Firstly, I'd like to sincerely thank Geoff Huston and the authors for working so closely to address the comments in Geoff's excellent DnsDir review - https://datatracker.ietf.org/doc/review-ietf-uuidrev-rfc4122bis-10-dnsdir-telechat-huston-2023-08-26/ I believe that this has noticeably improved the document. Other than my thanks for the above, and for a well written document, I'd like to support Eric's DISCUSS on the length of MAC addresses.
Thanks for working on this specification. This specification does not raise transport related issues in my evaluation. However, for clarity in description I think Eric's discuss need to be resolved. Supporting his discuss.
Thanks again for this document and for addressing my previous blocking DISCUSS point (see https://mailarchive.ietf.org/arch/msg/iesg/1ZxBR8Ohbz7lL2mipYTNxTtBdqU/) -éric # COMMENTS ## Section 1 Two sentences appear to contradict each others: - `A UUID is 128 bits long and requires no central registration process` - `In addition, a global registration function is being provided by the Telecommunications Standardization Bureau of ITU-T` ## Section 2 Should there be an informative reference to `IEEE 802 node identifiers` ? ## Section 2.1 What is the impact of randomised MAC address (cfr MADINAS WG and IEEE work) on bullet 4. Should this randomised MAC address be mentioned in the text ? ## Section 5.1 Why only IEEE 802.3 LAN what about 802.11 or 802.15.4 ? Should the text be relaxed ? ## Section 8 Should privacy be added in `MAC addresses pose inherent security risks ` ? # NITS ## Section 3.3 The usual wording is more like `Note to RFC Editor: This section needs to be removed before publication as RFC`. ## Sections C.1 & C.5 Please use a documentation MAC address per section 2.1.2 of RFC 7042. *IF* the node is assumed to be a MAC address.