On 9/30/24 18:25, Jen Linkova wrote:
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.
OK
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.
OK (but that's more subtle than I expected).
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?
Yes, that would be helpful. (I want reduce the risk that some
implementer assumes that A isn't needed once they add support for this
specification.)
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.
OK. Will that be for both of the above?
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.
Great.
Erik
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
