Hi Ben, Thank you for the review! Comments inline. >Security Issues: >The security section is, if anything, too detailed, as it describes attacks that are not meaningful to the security of the system. I would shorten this section. Would you be able to elaborate on this? Currently the section describes: - the first paragraph: an attack vector which leads to service degradation or complete DoS for the endpoint; - second paragraph: an attack vector leading to DoS for the server infrastructure. Anything in particular you consider not very relevant for the security of the system? >The privacy considerations are important and are described appropriately. It >might be worth adding a note that privacy-conscious clients should consider not >implementing this specification. As the privacy section of both this draft and ietf-v6ops-dhcp-pd-per-device mentions, the privacy properties of the proposed solution are similar but better than ones of DHCPV6 IA_NA. So privacy-conscious clients should either consider implementing this specification instead of DHCPv6 IA_NA (or choose not to implement DHCPv6 at all, but such statement would be clearly out of scope of this particular draft..) >Other topics: >I was not able to see why prefix requests "MUST" be short enough for SLAAC. >Why would a host perform SLAAC within its own exclusively allocated prefix? If >the host is acting as a router for a network containing SLAAC clients, it can >request a larger prefix, but why is this mandatory for all hosts? This was discussed by the WG extensively. The reason is explained in the pd-per-device draft, so we added a reference to clarify that (we've just submitted -10). -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
