Thank you for the great input. Comments inline. On Fri, Apr 4, 2025 at 1:49 PM Elwyn Davies via Datatracker < nore...@ietf.org> wrote:
> 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! ;-)] > Adjusted abbrv: to "Prioritizing known-local ULA in RFC 6724" > > 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. > > All "RFC XXXX" adjusted to "RFCXXX" for consistency. > 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), > Changed. > > END > > In s1: > > s/[RFC6724]/Default Address Selection for Internet Protocol Version 6 > (IPv6) > [RFC6724]/ > Changed. > > Abstract: The abbreviations ULA and GUA need to be expanded on first use > (Unique Local Address. Global Unicast Address) . > Addressed. > > 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 > Changed. > > s1, para 3: s/from externally/from locations external/ How does "from external locations" sound? > > s1, para 4: s/differs to/differs from/ > Changed. > > s1, para 5: s/in RFC 6724/in Section 5 of [RFC6724]/ > Changed to "This document also reinforces the text in Section 5 of RFC6724 to require support for Rule 5.5." > > 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. > Changed to: GUA: Global Unicast Addresses as defined in [RFC3587] ULA: Unique Local Addresses as defined in [RFC4193] We also adjusted the use of addressing for "addresses" in all locations where it made sense for readability. > > s3, para 2: getaddrinfo() needs a reference to [RFC3493] > > Adjusted to "Where getaddrinfo() as referenced in [RFC3493], or a comparable API is used, the sorting behavior should take into account both..." > s3, para 3: s/allow sites/in allowing sites/ > Adjusted. > > 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. > How does this sound: "It should be noted the order of rows in the policy table rows in the policy table is of no consequence and only the precedence value is relevant." 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. > Added. > > 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. > Correct, it is assumed as /64 as part of the RA. Would simply removing the /64 simplify the understanding? "PIOs received within fd00::/8 that are not already in the nodes known-local ULA list MUST be added to the list with an assumed prefix length of /48, regardless of how the PIO flags are set." > > 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/ > Fixed. I also clarified the paragraph above to be a bit more clear, referring to insertion into the current policy table. > > 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. > Fixed. > > 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. > That is the intention. > > 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] > Agreed. Section 13 and these reference implementations should probably be removed. > 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. > it does seem more logical to reference the I-D/RFC to SNACBIT. I will adjust that.
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
