Hi Erik, Thanks a lot for your review and comments! See inline. On Tue, Oct 1, 2024 at 12:50 AM Erik Nordmark via Datatracker <noreply@xxxxxxxx> wrote: > Nit: In the abstract it refers to draft-ietf-v6ops-dhcp-pd-per-device which > raises two things: 1. I think the rfc-editor doesn't like references in the > abstract, so maybe using english words to instead of the draft name makes > sense. Or defer to rfc-editor to fix this? I believe we can’t use references (like “xref”) but use the RCF number is OK. draft-ietf-v6ops-dhcp-pd-per-device already has an RFC number (it’s in AUTH48) so the next version of this draft will be referring to RFC9663 instead. 2. Should the "model" text in the > abstract refer to RFC8273 instead of the dhcp mechanism draft? The model is > described in RFC8273. I don’t think so. The model described in RFC8273 is slightly different from draft-ietf-v6ops-dhcp-pd-per-device. The former requires the network to ensure that every client gets its own dedicated RA with a dedicated (unique) PIO, so the clients can use that PIO for SLAAC. Draft-ietf-v6ops-dhcp-pd-per-device expects clients to ignore PIOs and use DHCPv6 PD to obtain the prefix. Yes, both are talking about ‘prefix per client’ but they are fundamentally different in how those prefixes (and their per-client uniqueness) are obtained. > > Suggested clarification in section 6: Would it make sense to explicitly state > that a router might need to continue to set the A flag if there might be some > hosts which do not implement this specification on the link? IMHO this draft shouldn’t change anything about setting an A flag in PIOs. Whatever the default behaviour for setting the A flag has been, it should continue. (I couldn’t find any RFC mandating that A must/should be 1 by default - though all implementations I’ve come across do exactly that). I guess we can make it more explicit by saying smth like “ “The P flag MUST be set independently from the A flag. In particular, enabling or disabling the P flag MUST not trigger automatic changes in the A flag value” What do you think? > Clarification in last paragraph in section 7.2: Instead of the last sentence > starting with "Similarly, the host" it would be more clear to start the > paragraph with "The host MUST NOT forward or originate packets" since the > implications and implementation suggestion are identical for the forward and > send/originate cases. > Nit: Section 8 refers to "DHCPv6 relay" but this can be either a DHCPv6 server > or relay as far as I can tell. I don't know if the DHCPv6 specification has a > term which covers both of them. Makes sense, I'll craft a PR. > Question: Has there been any discussion about adding operational considerations > to the document? What I had in mind is the fact that the operator can not > explicitly tell which hosts/routers implement this specification, hence if this > is important the operator needs tools to tell how many PD vs. how many IA_NA > plus SLAAC or DAD probed addresses it sees on the network. If this has not come > up in the WG, or is already covered in some other document, then don't bother. Operational considerations, including the pool size, are discussed in the draft-ietf-v6ops-dhcp-pd-per-device (section 7 in particular), which is focused on the network deployment. This draft focuses on signaling to the *host* that the network supports that model. -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
