Document: draft-ietf-6man-rfc6724-update Title: Prioritizing known-local IPv6 ULAs through address selection policy Reviewer: Elwyn Davies Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-6man-rfc6724-update-18 Reviewer: Elwyn Davies Review Date: 2025-04-04 IETF LC End Date: 2025-04-02 IESG Telechat date: Not scheduled for a telechat Summary: Ready but with a number of nits. It all seemed clear and well explained except for Rule 4 in Section 5.3 which I think needs a little rework and possibly Major issues: None Minor issues: Nits/editorial comments: Minor: Nits: RFC header format: The short name of the RFC that appears in page headers is one character too long and misses off the 4 from RFC 6724. [There's a new issue I haven't seen before! ;-)] Format of references to RFCs: The document uses an unconventional approach to second and (most) subsequent appearances of RFC references by using the [RFC1234] format for the first and 'RFC 1234' for subsequent references. Personally I would prefer to use the [RFC1234] format for all references. Also I am not sure if idnits checks references in the 'RFC 1234' form. Abstract and first sentence of s1: I think it would be worth putting in the title of RFC 6724. This might stop idnits complaining that you don't say the document updates RFC 6724: In Abstract OLD: This document draws on several years of operational experience to update RFC 6724, NEW: This document draws on several years of operational experience to update the recommended process of Default Address Selection for Internet Protocol Version 6 (IPv6) (RFC 6724), END In s1: s/[RFC6724]/Default Address Selection for Internet Protocol Version 6 (IPv6) [RFC6724]/ Abstract: The abbreviations ULA and GUA need to be expanded on first use (Unique Local Address. Global Unicast Address) . Abstract: The location of the definition of Rule 5.5 needs to be specified as Rule 5.5 defined in Section 5 of RFC 6724 s1, para 3: s/from externally/from locations external/ s1, para 4: s/differs to/differs from/ s1, para 5: s/in RFC 6724/in Section 5 of [RFC6724]/ s2: RFC 3587 and RFC 4193 define Address(es) not Addressing. Also the abbreviations as used in this document appear to refer to addresses rather than addressing. s3, para 2: getaddrinfo() needs a reference to [RFC3493] s3, para 3: s/allow sites/in allowing sites/ s5.1: It might seem obvious, but should it be explicitly stated that the order of rows in the policy table is of no consequence and only the precedence value is important - in RFC 6724 the row order and the precedence value order matched but this is no longer so. s5.3: I would suggest putting RA, PIO and RIO into the terminology (s2). Also SLAAC need to be added to the terminology. MTU is well-known and not required. s5.3, Rule 4: This rule refers explicitly to length 64 prefixes but the PIO option can specify essentially any length. Should the rule apply to any prefix length from 40 to 64 or maybe from 48 to 64 to cope with the assumed prefix length of 48? I assume the idea is that if there are multiple PIOs with the same high order 48 bits, only one of these is stored - I think the wording of 'that are not already in the node's known-local ULA list' is meant to imply this but I think this needs clarifying. I am not clear how this interacts with Rule 6. s5.3, para 16 (2nd one after bullet 8): I think this is intended to refer to the 'current policy table' - this is what is interesting to see! s/default policy/current policy/ s5.3, last para: In the discussion of ULA prefix lengths the phrase 'up to /40' appears. ULA prefixes are supposed to be /48 but this rule appears to 'forgive' lengths from 40 to 47, so: OLD: allows the use of ULA prefixes of up to /40 in length. NEW: allows the use of ULA prefixes from /40 to /48 in length. END I take it that the Policy Table records the actual prefix length in these cases unlike the Rule 4 case where the prefix length is forced to /48 even if the prefix is actually longer. s16: I think it would be useful to retain this section as an appendix in the published document. s17.1: I note that the three references [SNACBIT], [ANDROID] and [RAIO-ULA-PY] may not be adequately stable as references in a published RFC. SNACBIT is derived from a document that is still an I-D. The other two may not be long term stable and are probably more illustrative than normative. In fact pace s13, these two references should be removed on publication as they are only relevant to that section and it will be removed on publication. Possibly the SNACBIT reference should be via its defining I-D/RFC rather than to the IANA page. This would avoid a problem with a downref. _______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
