Skip to main content

Telechat Review of draft-ietf-6man-rfc6724-update-23
review-ietf-6man-rfc6724-update-23-intdir-telechat-winters-2025-07-23-00

Request Review of draft-ietf-6man-rfc6724-update
Requested revision No specific revision (document currently at 25)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2025-06-19
Requested 2025-05-19
Requested by Éric Vyncke
Authors Nick Buraglio , Tim Chown , Jeremy Duncan
I-D last updated 2026-05-20 (Latest revision 2025-08-11)
Completed reviews Tsvart IETF Last Call review of -18 by Michael Tüxen (diff)
Dnsdir IETF Last Call review of -18 by Vladimír Čunát (diff)
Opsdir IETF Last Call review of -19 by Niclas Comstedt (diff)
Genart IETF Last Call review of -18 by Elwyn B. Davies (diff)
Secdir IETF Last Call review of -18 by Ned Smith (diff)
Dnsdir Telechat review of -20 by Jim Reid (diff)
Intdir Telechat review of -23 by Timothy Winters (diff)
Dnsdir Telechat review of -21 by Jim Reid (diff)
Dnsdir Telechat review of -22 by Jim Reid (diff)
Assignment Reviewer Timothy Winters
State Completed
Request Telechat review on draft-ietf-6man-rfc6724-update by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/RuEIszTVCg9WiCVvEdxz84Qqg0I
Reviewed revision 23 (document currently at 25)
Result Ready w/issues
Completed 2025-07-23
review-ietf-6man-rfc6724-update-23-intdir-telechat-winters-2025-07-23-00
I am the assigned int-dir reviewer for this draft. These comments were written
with the intent of improving the Internet area aspects of the IETF drafts.
Please wait for direction from your document shepherd or AD before posting a
new version of the draft. For background on int-dir, please see the
[FAQ](https://wiki.ietf.org/en/group/intdir).

I think this document is ready, there are three minor technical issues that
need to be addressed before publication.

Technical:

Section 3.1

$known_local/48 - Later in the document, in Section 3.3 the range is documented
as /40 to /48.  I would recommend putting the range in this table /48 to /40?
---
Section 3.3
These known-local ULA prefixes are inferred from ULA addresses assigned to
interfaces or learned from Prefix Information Options (PIOs) in Router
Advertisements (RAs) [RFC4861] received on any interface regardless of how the
PIO flags are set.

This reads to me that an implementation will need to merge all the ULA prefixes
they receive on any interface.  I don't think that is the intention, I would
suggest clarifying.
---
Section 3.3
7. Entries MUST be removed from the known-local ULA list and the Policy Table
when the announced RIOs or PIOs are deprecated, or an interface address is
removed, and there is no covering RIO or PIO.

RIO can't be deprecated, they only have a valid lifetime this should be
invalidated?
---

Nits:
---
OLD:
It further clarifies the unconditional requirement for implementing Rule 5.5 of
RFC 6724

NEW:
It introduces a requirement to implement Rule 5.5 of RFC 6724
---
OLD:
This document therefore introduces two changes to RFC6724 to support a node
implementing

NEW:
This document therefore introduces two requirements to RFC6724 to support a
node implementing
---
OLD:
Known-local ULA: A ULA prefix that an individual organization/site has
determined to be local to a given node/network/administrative domain

NEW:
Known-local ULA: A ULA prefix that an node has determined to be local to a
given network domain.
---
Section 3.3
Tools that display a node's current policy table MUST show all currently
inserted known-local ULA prefixes.

What defines a tool?
---