Re: [dhcwg] Layer 2 Relay Agent Information draft

Bharat,

Few comments/suggestions. Search for [Ramesh].

Section 4.1.1
-------------
3 ... The DHCP server responds with a DHCPOFFER message after applying
its local policies.
[Ramesh] Will it be good to mention ".. after applying its local policies for
address allocation". This is just to make clear of what policy, DHCP
is all concerned
about and readers do not relate this to any system policies.

Section 4.1.1
-------------
3 ...A Layer 2 Relay Agent may be configured to intercept unicast DHCP messages.
[ramesh] I think all L2 Relay Agents SHOULD intercept _all_ the DHCP
messages from server
_if_ it has inserted option-82. This is because for a client,
option-82 do not make any sense.

section 4.1.1
-------------
6. ...

DHCPNACK  - RFC 2131 refer to DHCPNAK and not DHCPNACK. Is this ok?

section 4.2.2
-------------
1 .... Layer 2 relay agents SHOULD select the longest lease time of
two conflicting
but similar replies, by discarding replies that shorten the lease time.
[Ramesh] I thought, to keep the state of a client, L2 Relay Agent will learn
from the REQUEST+ACK message exchange which involves only one server. So there
is no question of keeping a client state more than its life time. Am I missing
something here?

In any case, Maintaining a state ( and hence filter) even after a
client is dead,
mean anomalies.

section 4.3.2
-------------
3 ...Because of this, it could be difficult for the DHCP server to differentiate
between a RENEWING and REBINDING state.
[Ramesh] Did you mean "difficult to differentiate between RENEW and
REBIND messages
here? State is term used in the server context, right?
If you are talking about server state - then its server who leased out
an IP and
hence it would know the state of the client based on T1 & T2.

-- 
cheers
ramesh

On Wed, Apr 22, 2009 at 6:43 AM, Bharat Joshi <bharat_joshi@infosys.com>wrote:

> Hi All,
>
>       We have published version 04 of Layer 2 Relay Agent Information
> draft. This version addresses several editorial comments provided by Alfred.
>
>       Draft is available at
> http://www.ietf.org/internet-drafts/draft-ietf-dhc-l2ra-04.txt
>
> Thanks,
> Bharat
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended
> solely
> for the use of the addressee(s). If you are not the intended recipient,
> please
> notify the sender by e-mail and delete the original message. Further, you
> are not
> to copy, disclose, or distribute this e-mail or its contents to any other
> person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has
> taken
> every reasonable precaution to minimize this risk, but is not liable for
> any damage
> you may sustain as a result of any virus in this e-mail. You should carry
> out your
> own virus checks before opening the e-mail or attachment. Infosys reserves
> the
> right to monitor and review the content of all messages sent to or from
> this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>