Skip to main content

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

Discuss


Yes

(Jari Arkko)
(Ted Lemon)

No Objection

(Brian Haberman)
(Martin Stiemerling)

No Record


Note: This ballot was opened for revision 12 and is now closed.

Ralph Droms Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-04-06 for -12) Unknown
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 Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2012-04-09 for -12) Unknown
  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 Former IESG member
Yes
Yes (for -12) Unknown

                            
Ted Lemon Former IESG member
Yes
Yes (for -29) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2012-04-09 for -12) Unknown
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?
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (for -15) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Ron Bonica Former IESG member
(was No Objection) No Record
No Record (2012-04-09 for -12) Unknown
I support Russ's DISCUSS and the GENART review. With one more pass, this document could be much improved.