Re: [IPv6] Working Group Last Call for <draft-ietf-6man-pio-pflag>

[Tim Chown <[e-mail]>]

Hi Jen,

> On 8 Apr 2024, at 14:07, Jen Linkova <[e-mail]> wrote:
> 
> Hi Tim,
> 
> Thank you for the feedback!
> 
> On Mon, Apr 8, 2024 at 7:44 PM Tim Chown
> <Tim.Chown=[e-mail]> wrote:
>> Section 1:
>> "This solves the scaling issues
>>   because the amount of state that has to be maintained by the network
>>   does not depend on how many addresses are in use.”
>> 
>> I think it always depends on the number of addresses, perhaps you mean “devices” as devices can have one prefix for their needs rather than multiple addresses?
> 
> What we are trying to say is that now the network needs to scale to
> the number of devices, not to the number of addresses (which can be
> 10-20 times more).
> 
> Would this read better:
> 
> "This solves the scaling issues because the amount of state that has
> to be maintained by the network depends on the number of devices and
> does not depend anymore on how many addresses those devices are
> using."
> 
> ?

Yes :)

>> (The justification for the PD draft probably doesn’t need to be repeated in this document.)
> 
> Yes, there is a significant overlap in the justification/problem
> statement. The goal is for this draft to be comprehensible w/o reading
> the PD document first.
> 
>> Section 3:
>> “This is suboptimal” - change to “Using SLAAC would be suboptimal”
>> Else I read it as putting the info in the RA as being suboptimal.
> 
> Fixed, thank you!
> 
>> Section 4:
>> Typo “opearator"
>> 
>> Section 5.1:
>> Typo “DHPCv6”
> 
> Both fixed.
> 
>> Section 7.1:
>> The changes to RFC 4861 section 4.6.2 are a little confusing as presented.
>> The reserved field was originally 6 bits, then became 5 bits with the R bit of RFC 6275, and will now be 4 bits with the new P bit.
>> But the text seems to be written as a change from A and 6 bits?
> 
> Yes, you are right, I'm not sure how to handle this. RFC6275 does not
> formally update RFC4861, so there is no text which can be easily
> updated.
> 
> Maybe we can do this:
> 
> * do not use "old text"/"new text" format.
> * say smth like "this document makes the following changes to the
> Prefix Information Option (Section 4.6.2 of RFC4861, updated by
> RFC6275):
> Reduces the Reserved field from 5 bits to 4 bits and introduces a P
> which is 1-bit DHCPv6-PD flag. When set, indicates that this prefix
> SHOULD NOT be used for stateless address configuration. Instead the
> host SHOULD request a dedicated prefix via DHCPv6-PD and use that
> prefix for stateless address configuration."
> * provide an illustration of the new PIO format.
> 
> Would it be less confusing?

Your new solution trumps this.

>> As an aside I was also surprised that RFC 4861 doesn’t say “Updated by RFC 6275” in its header.
> 
> Good catch. [chair hat on] I guess we need to do smth about that - I
> also missed the fact the Reserved field is 5, not 6 bits, as RFC 6275
> is not linked.
> 
>> Section 7.2:
>> Typo “collink” should now be “ietf”
>> And “as if the A”, adding “the”.
>> Section 8:
>> Typo “might sent” -> “might send” and “ignore A flag” -> “ignore the A flag”
> 
> Fixed.

Cheers,
Tim

> 
> -- 
> Cheers, Jen Linkova