Source Address Validation Improvement (SAVI) Solution for DHCP
draft-ietf-savi-dhcp-34

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)
No email
send info
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 7.4.1.2:
     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)
No email
send info
I support Russ's DISCUSS and the GENART review. With one more pass, this document could be much improved.