Source Address Validation Improvement (SAVI) Solution for DHCP
Note: This ballot was opened for revision 12 and is now closed.
(Ralph Droms) Discuss
Discuss (2012-04-06 for -12)
I'm taking the unusual position of posting a Discuss on a document I am responsible for. I've taken over this document from Jari. Eric Levy-Abegnoli raised some issues in e-mail to ietf.org: http://www.ietf.org/mail-archive/web/savi/current/msg01778.html The authors posted revisions to respond to Eric's e-mail: http://www.ietf.org/mail-archive/web/savi/current/msg01779.html I will hold the Discuss until rev -13 is published.
(Russ Housley) Discuss
Discuss (2012-04-09 for -12)
This document needs significant rewrite to be clear enough to produce interoperable implementations. This view is supported by the Gen-ART Review by Elwyn Davies supports this view, and it can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg07297.html
(Jari Arkko) Yes
(Ted Lemon) Yes
(Brian Haberman) (was Discuss) No Objection
Barry Leiba No Objection
Comment (2012-04-09 for -12)
This document looks generally good. I have a few, small, non-blocking comments: Section 5.1, a very, very minor thing: I found myself laughing at this sentence: "The state field is used to identify state." Maybe change it to something like, "The state field changes over time to identify the current state of the binding." That fits in well with what you say two sentences later, about a state change. --- Section 6.1: you say, "To filter bogus DHCP server message by default," using the vague term "bogus DHCP server message" for the first time. The introduction tells me that you're using these bindings "to filter or identify packets with forged source IP address." Is that what you mean by "bogus messages" here? If so, maybe say "forged" instead of "bogus". If there are other ways that a message can be bogus, other than having a forged address in it, maybe you could make that clearer, either here or in the introduction. --- The third paragraph of section 6.4 is a good example of explaining something well, and heading off what might otherwise be a confusing point. Thanks. --- Section 184.108.40.206: The states of the corresponding entries are set to be BOUND. The lifetime of the entries MUST be set to be the lease time. There's really no reason to have that "MUST" there. You're specifying what goes into the table, and the second sentence should read just like the first -- it's normative, without the need for the "MUST" (use "are" instead of "MUST be"). --- Section 13.1: If one of the following conditions is satisfied, the security can be ensured. I suggest wording that differently to state actively what it is that you're doing: Protection from this attack can be ensured by making sure that one of the following conditions is satisfied: --- Section 13.4: This mechanism is designed in consideration that a node may move on the local ink, and a node may have multiple binding anchors. It seems that "ink" is a typo for "link", but I find the sentence unclear in general. Can you try to re-word it?
(Martin Stiemerling) No Objection
(Ron Bonica) (was No Objection) No Record
Comment (2012-04-09 for -12)
I support Russ's DISCUSS and the GENART review. With one more pass, this document could be much improved.