Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 3 Feb 2004 08:09:52 -0800

My $0.02, I'm a fan of Ted's original suggestion for the table:

Option                    DHCPOFFER    DHCPACK            DHCPNAK
------                    ---------    -------            -------
Client identifier         MUST*        MUST*              MUST*

* - Only if the Client identifier was present in the client's packet

Although some wording should probably be added to the effect that this also
applies to RECONFIGURE messages (RFC 3203).

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Tuesday, February 03, 2004 8:03 AM
> To: Robert Elz
> Cc: [email-masked]
> Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-client-id-00.txt 
> 
> 
> > How about extending the words that can be used in the columns beyond
> > the standard MAY/SHOULD/MUST (and inverses) set, and include things
> > like DISCOVER & REQUEST which would be defined like
> 
> What we want is that whenever the client sends a client-identifier 
> option in a packet, the response from the server contains that client 
> identifier.   This is a very simple concept - there's no need for 
> anything fancy.   I like Bernie's table entries because they are a 
> little clearer for the reader, but from the perspective of 
> verbiage, as 
> opposed to tables, this really only needs to be a single 
> sentence, and 
> I don't think additional complexity in the table is going to help 
> clarify things for the reader - it will either not make a difference, 
> or it will confuse the reader.