Thank you for the great input. Comments inline.
On Fri, Apr 4, 2025 at 1:49 PM Elwyn Davies via Datatracker <noreply@xxxxxxxx> 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.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
