Re: Re: [dhcwg] WG Last Call for DHCP draft

On Thu, 27 Jan 2005, Ralph Droms wrote:

> At 04:25 PM 1/26/2005 -0800, Vivek Kashyap wrote:
> >On Wed, 26 Jan 2005, Ted Lemon wrote:
> >
> > > On Jan 26, 2005, at 4:54 PM, Vivek Kashyap wrote:
> > > > If it is strongly felt that we need to discourage 1542 then I could
> > > > refer to
> > > > both 2131 and 1542 rather than just 1542. Even better would be to
> > > > obsolete
> > > > 1542 by writing an updated draft.
> > > That's 2132.   2132 obsoleted 1542.
> >
> >No it does not obsolete it..the RFC header states that it obsoletes 1533.
> >there is no mention of 1542.
> 
> I think the text about broadcasts (and the included citations) are OK; just
> a reference to RFC 2131 might have been cleaner but RFC 2131, unfortunately,
> doesn't refer to the test about broadcast in RFC 1542.

Yes, it forwards the reader to 1542. 

> 
> > > >> Regarding the text about client identifiers, I am extremely
> > > >> uncomfortable with this.   Obviously it's not just my decision, but
> > > >> right now you haven't given me any reason to think this is a good
> > > >> idea,
> > > >> and I've given you some pretty definite reasons why I _don't_ want it.
> > > >
> > > > Did you look at -08.txt?
> > > Yes, you emailed it to me.
> > >
> > > > The draft is not mandating any particular use and mentions other
> > > > values. I'll
> > > > see if I can make it even clearer that other values are certainly
> > > > possible.
> > >
> > > The problem is that any time you suggest a way for someone to do
> > > something, it's likely to be taken as a mandate whether you say MUST or
> > > not.   So for safety, I prefer to make it extremely clear whenever
> > > possible that a certain suggested behavior is not mandated by stating
> > > what other behaviors are allowed, preferably by referring to the RFCs
> > > that define them, and also to state that the implementation must not
> > > treat the suggested behavior as mandatory in the sense of treating
> > > input that does not follow the suggested behavior as erroneous.
> > > Unfortunately I have seen implementors do precisely this; thus my
> > > paranoia about it.   :'}
> >
> >I'll add some text that should hopefully close this.
> 
> It seems to me that it would be to the advantage of a DHCP-for-Infiniband
> implementor to use the draft-ietf-dhc-3315id-for-v4-03.txt form of client
> identifier.  The GID can, I think, be used in the DUID-LLT form of the DUID
> so the draft-ietf-dhc-3315id-for-v4-03.txt form of client identifier would
> be no harder to construct than the other client identifiers suggested in the
> draft, and would guarantee uniqueness even if the GIDs are not unique.

I'm adding text that makes it clear to the reader that there are other 
desirable ways to constructing the client identifier, thereby explcit reference
to 3315id-for-v4 draft may not be needed. Thoughts?

Vivek

> 
> >Vivek
> 
> - Ralph
> 
> 
>