Reviewer: Susan Hares Review result: Ready with Issues 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-pio-pflag-?? Reviewer: Susan Hares Review Date: 2024-09-16 IETF LC End Date: 2024-09-09 IESG Telechat date: 2024-10-03 Summary: Nice addition to fix a gap in operational choices for prefix address assignment. Most sections provide strong descriptions of the mechanisms. Major issues: none Minor issues: section 6.2, clarity in paragraphs 2-3. Section 6.2 (Using Delegated Prefix(es)) could have a minor technical or editorial issue. The key point is that loops must be prevented by: a) using the prefix for directly connected devices as if the prefix was assigned by Neighbor Discovery and Duplicate Address Detection. b) If it receives a prefix, don't forward on the link unless b-1) already assigned to downstream interface. b-2) places a high metric discard route for prefix (often to loop back). The issue is how to define a downstream interface. This section does not clearly define it. Nits/editorial comments: 1.) Introduction, paragraph 2, sentence 1 Text:/ This model provides devices with large amounts of address space that they can use to individually number VMs or containers or extend the network to downstream devices./ Problem: It is unclear what specification "This model" applies to. If it is [draft-ietf-v6ops-pd-per-device] then, please put it with the first paragraph. If it is something else, specify what "this model" means. 2. Introduction, paragraph 2, sentence 2, Problem: grammar and sentence clarity old text:/ It also provides scalability benefits on large networks because network infrastructure devices do not need to maintain state per address: IPv6 neighbor cache, SAVI mappings ([RFC7039]), VXLAN routes, etc. / New text:/It also provides scalability benefits on large networks because network infrastructure devices do not need to maintain state per address. Some devices that do not need to maintain state are: IPv6 neighbor cache, SAVI mappings ([RFC7039]), and VXLAN routes. 3. Section 6.1, paragraph 2, sub-bullet, consider better wording text:/When a prefix's Preferred Lifetime becomes zero, either due to expiration or due to the receipt of a PIO with a Preferred Lifetime of zero, the prefix MUST be removed from the list./ The text is correct and it abides by rules of grammar. However, the sentence is difficult to read. If the authors can think of another way to state this sub-bullet, it would be helpful. 4. Section 6.1, paragraph 2, sub-bullet 4, text:/If the host has already received delegated prefix(es) from one or more servers, then any time a prefix is added to or removed from the list, the host MUST consider this to be a change in configuration information as described in Section 18.2.12 of [RFC8415], and it MUST perform a REBIND, unless it is going to stop the DHCPv6 client because the list became empty/ problem is with the portion the text:/" REBIND, unless it is going to stop the DHCPv6 client because the list became empty/ I think if you change /REBIND,/ to /REBIND/ it will make it clearer. Otherwise, perhaps a rewrite of the text is necessary. 5. Section 6.1, 2nd paragraph, last bullet, grammar + clarity issue old-Text:/Issuing a REBIND allows the host to obtain new prefixes if necessary, e.g., when the network is being renumbered. New-text: /Issuing a REBIND allows the host to obtain new prefixes if necessary (such as when the network is being renumbered)./ The "e.g." is unclear. 6. Section 6.1, 3rd paragraph, Editorial error in text version Text: /Similarly, if all PIOs processed by the host have the P bit set, the host SHOULD NOT request individual IPv6 addresses from DHCPv6, i.e., it SHOULD NOT include any IA_NA options in SOLICIT messages./ If you are referencing IA-NA in SOLICIT message, it would be good to provide the reference section in [RFC4861] or other RFCs or Drafts. 7. Section 6.2, paragraph 2, sub-bullet-3 Old text:/ * The host MAY use the prefix to allow devices directly connected to it to obtain IPv6 addresses, e.g., by routing traffic for that prefix to the interface and sending a Router Advertisement containing the prefix on the interface. / The inclusion of the "e.g.," makes the text unclear. 8. Section 6.4. Please define "on-link" and "off-link" or refer to appropriate RFC or draft. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
