Subject: [savi] draft version of savi-dhcp-02

From: "Jun Bi" <[email-masked]>
Date: Sat, 3 Apr 2010 22:51:10 +0800

Dear WG members,

Based on the discussion during IETF77 meeting and on the mailing-list,
we gathered the inputs and make draft version of savi-dhcp-02.
Please provide your valuable comment before we submit it to IETF.

Best Regards,
Jun Bi

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 03 Apr 2010 12:34:33 -0400

Apologies for the length of these comments.  I suspect that some of
these are probably older questions that I should have raised sooner.

1) The description of "Optional Attributes" (section 9.4) needs some
clarification.  It is not clear if these are intended to be optional to
implement, optional to use, or some other combination.  Also, the
current wording seems to say that the usage of these attributes (the
optional ones) is suboptimal.  This would seem to decrease the reason
for having them.  I believe this is largely a linguistic issue.

2) The SAVI-LocalGroup Attribute appears to define something that is
purely an implementation technique.  As such, it does not belong in this
spec.

3) I am not sure the Prefix configuration is actually a good idea.  The
spec already includes the notion of what port a DHCP reply message is
allowed from.  presumably, there at least can be configuration to
restrict which ports DHCP replies are accepted from.  In the absence of
such messages, prefix control is not a major improvement.  I am
concerned that requiring every sqitch to have this configuration
significnatly increases complexity.

4) I believe that the intent is to describe the DHCP Snooping process as
a finite state machine.  However, I found myself confused by teh
initialization section.  it is perfectly reasonable that there are
several different events that all cause initialization.  But
initialization can not actually be skipped.
As a minor point, I find it helpful particularly for initialization if
the trigger description includes the note that there is no table entry
for the anchor.
(Note, I do appreciate that an effort has been made to recognize and
take advantage of the knowledge provided by other mechanisms.)
4') There is a similar issue that the reply processing has a minor note
to create an entry.  This seems "interesting" in that as described the
original request will not have been sent upstream, so there won't be a
reply.

5) There is a note saying that "duplicate bindings of the same address
are allowed" under certain circumstances.  I would like to see this
expanded, as it appears counter-intuitive as written.  Is this allowing
multiple anchors to bind to the same IP address?

6) Section 11.2, although it is named a State Machine, is not a state
machine.  It shows different next-states from the same starting state
with the same event occurring.  It may be that trying for a concise
representation of the many choices available is not practical.  or it
may be that we need to reduce the number of choices.

7) I am concerned about the wording in section 20 on State Restoration.
 In IETF documents, when trying to say that an implementation must take
care of a certain problem, but may use one of several mechanisms, we do
not normally describe the first mechanism as MUST.  There are two common
writing techniques for this.
7a) If there is one specific solution that is expected to be the common
case, one can write that devices SHOULD implementat that, unless they
implement specified alternatives.
7b) If there are several equal alternatives, one can write that devices
MUST implement a mechanism to address the issue, and that the known
mechanisms are, followed by listing the mechanisms.  Whether the wording
says that one of the known tools MUST be sued depends upon the specific
protocol.

8) As currently written, there is no way to record a negative conclusion
about filtering.  This means that if a host is using an improper
address, every data packet will trigger validation.  Even with rate
limiting, this seems unfortunate, given that we have determined that the
answer is no.  (This is not a protection against a malicious host, but
merely more effective handling of a host with a problem.)

9) Why does the data triggered refer to DHCP and ND messages as data
packets?  Even if we are allowing datat triggered behavior, presumably
the control triggered behavior is still desired, and those are control
packets.  I think I am missing something in the beginning of section 21
in this regard.

Yours,
Joel M. Halpern

Jun Bi wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> savi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/savi

---

From: "Jun Bi" <[email-masked]>
Date: Mon, 5 Apr 2010 02:14:40 +0800

Hi Joel,

Thank you very much for your comments.

Since the length of comments is long, so please give us some time to 
investigate and feed you back.

Best Regards,
Jun Bi

--------------------------------------------------
From: "Joel M. Halpern" <[email-masked]>
Sent: Sunday, April 04, 2010 12:34 AM
To: "SAVI Mailing List" <[email-masked]>
Subject: Re: [savi] draft version of savi-dhcp-02