Reviewer: Erik Nordmark Review result: Ready with Nits 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? 2. Should the "model" text in the abstract refer to RFC8273 instead of the dhcp mechanism draft? The model is described in RFC8273. 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? 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. 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
