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

From: Vivek Kashyap <[email-masked]>
Date: Tue, 25 Jan 2005 21:50:55 -0800 (PST)

Picking up the thread again with the Ted's comments/Bill's questions:

On Mon, 20 Dec 2004, Bill Strahm wrote:

> Vivek,
> 
> One question is hard, one is easy...
> 
> On Wed, 2004-12-15 at 20:55 -0700, Ted Lemon wrote:
> > This draft uses a SHOULD to specify what data should be in the client 
> > identifier. This is in conflict with another draft that's in the 
> > process of working its way through to last call - 
> > draft-ietf-dhc-3315id-for-v4-??.txt. This is a bad thing - someone 
> > reading this spec will wonder which of the two specifications 
> > supersedes the other. I don't see any reason to specify the format of 
> > the client identifier in this draft - instead, refer the reader to 
> > draft-ietf-dhc-3315id-for-v4-??.txt and to RFC2132 for advice on how to 
> > format the client-identifier option.
> > 
> This is the hard question... What should we do about this... I think we
> should take this  request - and say our client ID SHOULD follow RFC2132
> (if I understand the problem correctly)... Is there any non-capped
> advise that we can give ?

I looked at the ID Ted has pointed to and that helped me understand Ted's 
comment a lot better. I've modified the draft such that it no longer 
states SHOULD for any particular format but instead gives the listed 
formats as examples of possible uses.  Ted's draft is not mandatory either.
A user therefore has the option of using any of the formats described.

The above change is included in the next version (-08.txt) of the draft.

> 
> Can you propose a change for this Vivek ?
> 
> > Also, you have a reference to RFC1542. This is superseded by RFC2132, 
> > so you should refer to RFC2132 instead - it is a huge mistake for 
> > someone to read RFC1542 as advice on how to implement a DHCP client, 
> > and so this draft shouldn't imply that the reader ought to look at 
> > RFC1542 - he or she oughtn't.
> > 
> OK - this is the easy one.  Can you change the reference to RFC2132.
> 
> Any objections to this for closing this issue ?

I've kept the reference to RFC1542 because RFC 2131 itself points to RFC1542
when discussing the ramifications of using the BROADCAST flag.

Vivek

> 
> Bill
> > Ralph, what's going on with draft-ietf-dhc-3315id-for-v4-??.txt? This 
> > is getting a little bit embarrassing... :'}
> > 
> I think this is DHC work - nothing for us to see here - IPoIB is moving
> on
> 
> Bill
> 
> 
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
> 
> 

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jan 2005 13:12:58 -0700

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

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.

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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jan 2005 17:04:28 -0700

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.

> 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.   :'}

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jan 2005 17:36:12 -0700

On Jan 26, 2005, at 5:25 PM, Vivek Kashyap wrote:
> No it does not obsolete it..the RFC header states that it obsoletes 
> 1533.
> there is no mention of 1542.

D'oh!   I knew those numbers looked funny.   I'm sorry about that - I 
didn't bother to go make sure I was using the right RFC number, so I 
thought you were talking about 1533 when you were talking about 1542.   
:'(   So yeah, that text is just fine as is.

> I'll add some text that should hopefully close this.

Great, thanks!

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 26 Jan 2005 15:54:00 -0800 (PST)

> my objection to your reference to RFC1542 was to avoid encouraging 

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.

Did you look at -08.txt? 

> 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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 26 Jan 2005 16:25:22 -0800 (PST)

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

Vivek

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jan 2005 10:00:27 -0500

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

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

>Vivek

- Ralph

---

From: Bill Strahm <[email-masked]>
Date: Wed, 26 Jan 2005 16:48:04 -0800

Ted Lemon wrote:

> thought you were talking about 1533 when you were talking about 
> 1542.   :'(   So yeah, that text is just fine as is.
>
Ok - WG Chair summary of these two issues

1) First issue - mistaken RFC - no problem
2) Second issue - clarify text to say these are possible values, 
proposed text change will be published to both WG and closed - new ID 
will be issued to close issue

Bill
co-chair IPoIB WG

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jan 2005 13:32:14 -0700

My personal preference on the second issue is the same as Ralph's: you 
should just take out all the text about how to format the client 
identifier and reference the draft-ietf-dhc-3315id-for-v4-03.txt draft. 
   If you want to have your text in there as well, I'm not going to 
fight it really hard, but the right thing to do is definitely to 
reference the 3315id-for-v4 draft.   I presume the motivation for not 
referencing it is to avoid a dependency on that draft for finalizing 
the infiniband draft?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jan 2005 14:21:14 -0700

On Jan 27, 2005, at 2:01 PM, Bill Strahm wrote:
> I would hate to have a dependency on it and have to wait a year or so
> for the dependency to clear.  However, if this is in last call (or very
> close to it now) we can adjust accordingly.
The draft is in last call, with a couple of significant comments which 
will require some changes, but the changes aren't severe - basically, 
there was some uncaught bad wording in the draft that a new reader 
noticed.

> So for this issue our choices seem to be
> 1) Leave it like it is - sub optimal, but not horrible
>
Can't live with this.

> 2) Reference 3315* and help push the draft out sooner
>
This would be great, and I don't _think_ it would create any 
significant delay.

> 3) Remove text referring how to format the  client identifier
>
This works for me, but I do prefer 2.

> Lets figure out what the correct thing to do is and try to close this 
> so
> final draft can make it in by the Draft cutoff deadline and we can 
> close
> this in Mn.

Agreed.

---

From: Vivek Kashyap <[email-masked]>
Date: Thu, 27 Jan 2005 09:47:39 -0800 (PST)

> doesn't refer to the test about broadcast in RFC 1542.

Yes, it forwards the reader to 1542. 

> 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

---

From: Bill Strahm <[email-masked]>
Date: Thu, 27 Jan 2005 13:01:13 -0800

> referencing it is to avoid a dependency on that draft for finalizing 
[trimming some of the cc's so we will only get one copy each]

What is the timing on 3315id-for-v4 ?

<WG Hat Off>
Wondering if the easiest thing to do is 3 ??? 

Comments Vivek ?
<WG Hat back On>

Lets figure out what the correct thing to do is and try to close this so
final draft can make it in by the Draft cutoff deadline and we can close
this in Mn.

Bill
co-chair IPoIB WG