Subject: [dhcwg] Review of draft-ietf-dhc-relay-agent-flags-02.txt

From: Thomas Narten <[email-masked]>
Date: Wed, 07 Mar 2007 09:23:57 -0500

Here is my review of this document. I have not been following the
discussion on this document, so this is a "fresh eyes" review.

2007-03-06 review of -02 (in AD evaluation state)

Overall, I suspect this option is useful and a reasonable thing to
do. However, I think the document itself could make a better case for
why the option is needed. Some small text changes are probably all
that is needed to acheive this.

E.g.,

>    In general, DHCP servers may also make subtle (and sometimes not so
>    subtle) changes in their processing algorithms depending on whether
>    or not the DHCP server received the message as a unicast packet from
>    the DHCP client directly, a broadcast packet from the DHCP client on
>    a locally connected network, or a unicast packet from a DHCP Relay
>    Agent which has forwarded on a packet broadcast from a DHCP client
>    connected to a network local to the DHCP Relay Agent.

The document makes the general assertion above several times, but I
would find it helpful for the document to provide at least one
specific example. What would the server do differently and why/how
does this option solve the problem?

Later, the document says:

>    This option provides additional information to the DHCP server.  The
>    DHCP server MAY use this information to make processing decisions
>    regarding the DHCP Client's packet which it is processing.  For
>    instance, knowledge of the broadcast or unicast reception of a packet
>    by a DHCP relay agent is important when making the processing
>    decisions required to implement Load Balancing [RFC3074].

A single sentence here explaining how this information could actually
be used would be helpful. (Why leave this to the reader to figure
out?)

> 4.  DHCP Relay Agent Behavior
> 
>    A DHCP relay agent MUST include this suboption in every Relay Agent
>    Information Option [RFC3046] it adds to a forwarded DHCP request.  In

It seems to me like this MUST is too strong and unenforceable. Relay
Agent options are already defined, and this is a new one, so this
requirement is unenforceable. Moreover, why is this so important?  In
the absence of a compelling justification, SHOULD seems more
appropriate.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Mark Stapp <[email-masked]>
Date: Mon, 12 Mar 2007 14:10:00 -0700

Thomas,
Thanks for the comments.

Some questions inline...

> be used would be helpful. (Why leave this to the reader to figure

Since the wg last-call is over, I'm not sure quite what the right thing 
to do is. Do you feel that the iesg will not be able to evaluate this 
draft without another revision, containing one extra sentence?

> the absence of a compelling justification, SHOULD seems more

the intention here wasn't to introduce some sort of ... unfunded 
mandate. it was just to make it clear what support for the standard 
would mean. if an implementation doesn't support the (eventual) 
standard, then of course it's not going to be including this suboption. 
an implementation that claims compliance needs to obey section 4. an 
implementation that isn't compliant ... probably won't. Is there 
something here that's different from any of the other suboptions (or 
options) that have been developed individually?

-- Mark

---

From: Thomas Narten <[email-masked]>
Date: Tue, 13 Mar 2007 06:44:24 -0600

> draft without another revision, containing one extra sentence?

I think they (and the IETF as a whole, as I don't think the IETF LC
has happened) will probably be able to evaluate it better with the
extra sentence (btw, what will it be?). But is it critical? No. Also,
since it only takes 2 minutes to submit a revised ID (once you have
the text), I think its often less work to just do so than have a
discussion about whether to. :-)

> options) that have been developed individually?

Well, for one thing, the above text makes its sound like a protocol
violation to implement the spec, but choose not to send the option
(e.g., even if configured to do so for some reason). That seems a bit
strong to me.

Thomas

---

From: Stig Venaas <[email-masked]>
Date: Wed, 14 Mar 2007 18:51:10 -0400

> discussion about whether to. :-)

Yes, submitting a new ID is pretty easy, while people in general
seems to somehow resist this.

Anyway, I suggest that the authors can state what to change/add.
We can see if people are happy with it, and I can also check with
Jari whether we should update now or later.

Not having that extra sentence might possibly delay the IESG
evaluation...

Stig