The latest attached version resolves my editorial comments. However, it does not resolve my one substantive comment.
> On May 9, 2017, at 11:09 AM, Dhananjay Patki (dhpatki) <[email protected]> > wrote: > > ---------------------------------------------------------------------- > Ben Campbell > ---------------------------------------------------------------------- > > Substantive: > > Security Considerations: Seems like more is needed here. Do you mean to > say that none of these parameters add any security considerations that > were not there for existing headers? If that's the case, please say so, > and why people believe that to be the case. The attached version modifies the text to say that the new parameters here inherit the guidelines from RFC5213. My point was to say that this draft creates a way to send new kinds of options. Is the content of these new parameters similar enough to those from RFC 5213 that those guidelines still apply? Does the ability to change the re-registration and heartbeat frequencies fall sufficiently into those existing guidelines that nothing else needs to be said? If so, then it would be helpful to say that. But if those new capabilities are materially different than previous ones, then some text that describes how they are different, ways they could be abused, and any mechanisms that can mitigate that abuse. For the record, I am not saying that I believe that these new capabilities create new vulnerabilities. But the security considerations should help the reader understand whether that is true or not. Thanks! Ben. _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
