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

Vivek Kashyap <[email protected]> Wed, 26 Jan 2005 15:54:00 -0800 (PST)
Newsgroups gmane.ietf.ipoib,gmane.ietf.dhc
Message-ID <Pine.LNX.4.44.0501261431490.25030-100000@dyn319548.beaverton.ibm.com>
On Wed, 26 Jan 2005, Ted Lemon wrote:

> On Jan 25, 2005, at 10:50 PM, Vivek Kashyap wrote:
> > I've kept the reference to RFC1542 because RFC 2131 itself points to 
> > RFC1542
> > when discussing the ramifications of using the BROADCAST flag.
> 
> I understand now why you want to refer to RFC1542.   I would suggest 
> this text instead:
> 
> Although [RFC1542] discourages the use of broadcast, in the case of 
> IPoIB, broadcast is necessary, since there is no way to respond with a 
> unicast.   Readers should be aware that RFC1542 has been superseded by 
> RFC2132, and should refer to RFC2132 rather than RFC1542 for guidance.
> 
> The point of this change is simply that I don't want a new draft to do 
> anything to encourage the reader to think that they need to read 
> RFC1542.   RFC1542 contains quite a few errors, which is why it was 
> replaced by RFC2132.   We have had problems in the past with people 
> reading RFC1541/1542 instead of RFC2131/2132, and the entire reason for 
> my objection to your reference to RFC1542 was to avoid encouraging 
> this.

I understand your reservation. Is it not contradictory to state supercession 
of the RFC when it is not obsolete and is actively referred by the RFC sought 
to be promoted? 

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.

> 
> 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? 

> 
> Pretty much the only way I would be comfortable with any text like this 
> is if you first referred the implementor to the 3315id draft and then 
> suggested these formats as what to do if for some reason the 
> implementor didn't follow the 3315id draft.   Again, my reason for 
> saying this is that I don't want it to be the case that someone reading 
> this draft would get the impression that it somehow superseded the 
> 3315id draft.
> 
> I would also suggest adding some text saying that these client id 
> formats are suggestions, and that DHCP servers MUST NOT consider it an 
> error if the client id differs from the suggested format.

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.

Vivek


> 
> 
> _______________________________________________
> IPoverIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
>