Skip to main content

Last Call Review of draft-ietf-6man-pio-pflag-09
review-ietf-6man-pio-pflag-09-genart-lc-hares-2024-09-16-00

Request Review of draft-ietf-6man-pio-pflag
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-09-09
Requested 2024-08-26
Authors Lorenzo Colitti , Jen Linkova , Xiao Ma , David Lamparter
I-D last updated 2024-09-16
Completed reviews Secdir Last Call review of -09 by Benjamin M. Schwartz (diff)
Genart Last Call review of -09 by Susan Hares (diff)
Iotdir Telechat review of -10 by Erik Nordmark
Intdir Telechat review of -09 by Dirk Von Hugo (diff)
Assignment Reviewer Susan Hares
State Completed
Request Last Call review on draft-ietf-6man-pio-pflag by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/7553jBvlN8HBLO5tjf0D8zhkuKo
Reviewed revision 09 (document currently at 10)
Result Ready w/issues
Completed 2024-09-16
review-ietf-6man-pio-pflag-09-genart-lc-hares-2024-09-16-00
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.