Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-triggered-reconfigure-01

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Dec 2012 13:58:14 +0000

On Nov 22, 2012, at 7:53 AM, Ted Lemon <[email-masked]> wrote:
> The authors have requested a working group last call on the triggered-reconfigure draft.   This draft allows the relay agent to communicate to the DHCP server that configuration information provided by the relay agent has changed.   The DHCP server may then, if so configured, send a Reconfigure message to the client.

We had a working group last call on Med's triggered-reconfigure draft and got only one response.   Is it truly the case that nobody else is interested in this work?   Quite a few more people expressed interest in adopting the draft when the call for adoption went out.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Dec 2012 14:09:01 +0000

> We had a working group last call on Med's triggered-reconfigure draft and got only one response.   Is it truly the case that nobody else is interested in this work?   Quite a few more people expres…

No replies.   I guess nobody wants this—just me and Med in favor isn't enough to count as a consensus.   That's a shame—I think this is useful work.

Med, I think if you want this to advance you need to start doing a sales pitch to the working group to get people interested.   It's hard for me to believe that nobody wants this, but I can't call consensus in favor on a hunch.   :(

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 07:41:25 +0100

Hi Ted, 

I fully understand your concern. I was also expecting more reviews in addition to the ones acknowledged in the draft.   

The practices in some other WGs is to ask for 5 reviewers for documents to pass the WGLC. 

I know Christian and Roberta are OK with the changes I made to integrate their comment. I let them confirm/infirm they are OK with this version to move forward. Gurav has sent a message when the WGLC was initiated. 

I sincerely hope to see at least one or two more reviews; otherwise shouldn't we interpret "no answer" as consent ;-)?

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Ted Lemon
>Envoyé : mercredi 12 décembre 2012 15:09
>À : [email-masked] WG
>Objet : [dhcwg] draft-ietf-dhc-triggered-reconfigure did not pass WGLC
>
>> We had a working group last call on Med's 
>triggered-reconfigure draft and got only one response.   Is it 
>truly the case that nobody else is interested in this work?   
>Quite a few more people expressed interest in adopting the 
>draft when the call for adoption went out.
>
>No replies.   I guess nobody wants this-just me and Med in 
>favor isn't enough to count as a consensus.   That's a shame-I 
>think this is useful work.
>
>Med, I think if you want this to advance you need to start 
>doing a sales pitch to the working group to get people 
>interested.   It's hard for me to believe that nobody wants 
>this, but I can't call consensus in favor on a hunch.   :(
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 10:36:36 +0100

Dear all,

I indeed confirm that the -01 version of this draft reflects the comments I had. Let me also take the opportunity of this message to insist on the usefulness of this work, as it addresses the rather typical issue depicted in section 1.1 and experienced in some provider's environment, like ours.

Cheers,

Christian.  

-----Message d'origine-----
De : BOUCADAIR Mohamed OLNC/OLN 
Envoyé : jeudi 13 décembre 2012 07:41
À : Ted Lemon; [email-masked] WG
Cc : JACQUENET Christian OLNC/OLN; Maglione Roberta; Gaurav Halwasia (ghalwasi)
Objet : RE: draft-ietf-dhc-triggered-reconfigure did not pass WGLC
Importance : Haute

Hi Ted, 

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part 
>de Ted Lemon Envoyé : mercredi 12 décembre 2012 15:09 À : 
>[email-masked] WG Objet : [dhcwg] draft-ietf-dhc-triggered-reconfigure 
>did not pass WGLC
>
>Quite a few more people expressed interest in adopting the draft when 
>the call for adoption went out.
>
>Med, I think if you want this to advance you need to start doing a 
>sales pitch to the working group to get people
_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2012 13:49:53 +0000

I do NOT favor advancing this draft. It needs to include information similar to the link-address that would normally be included in relayed messages so that the server can more easily locate the client and is not required to reconfigure all instances of the client (such as a multi-homed client that may have obtained leases on different links, even from different relays).

I also am not sure if providing some additional relay information might be warranted (i.e., the things a relay would normally have added to a relay-forw).

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 14:33:20 +0000

> I do NOT favor advancing this draft. It needs to include information similar to the link-address that would normally be included in relayed messages so that the server can more easily locate the cl…

How likely is that in practice?   I don't think this is a terrible suggestion—it would be pretty easy to add the requirement for the link address option.   But I'm having trouble picturing a common real-world scenario where this would be necessary.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2012 14:37:11 +0000

Again, the main issue is for server to know what link this is. It has no such information and can't use the relay's source address as that isn't necessarily related to the client's "location". For all requests the server gets this information (either explicitly or implicitly, if client is on same link as server). So we need to be consistent.

I will not remove my objection until this is addressed. Sorry.

- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2012 14:51:20 +0000

No. This is DHCPv6 and we don't use the relay's source address at all (well, only for sending back a Relay-Reply). The link-address is what is used from the Relay-Forw to determine the client's "location".

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 9:43 AM
To: Bernie Volz (volz)
Subject: Re: [dhcwg] draft-ietf-dhc-triggered-reconfigure did not pass WGLC

> Again, the main issue is for server to know what link this is. It has no such information and can't use the relay's source address as that isn't necessarily related to the client's "location". For…

Right now doesn't the DHCP server figure out the client's "location" from the relay agent's source address?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 15:00:55 +0000

> No. This is DHCPv6 and we don't use the relay's source address at all (well, only for sending back a Relay-Reply). The link-address is what is used from the Relay-Forw to determine the client's "lo…

How does the link-address option indicate the client's location?

---

From: Andre Kostur <[email-masked]>
Date: Thu, 13 Dec 2012 07:33:31 -0800

The relay is supposed to put "A global or site-local address that will
be used by the server to identify the link on which the client is
located." into the link-address of the relay-forward.

-- 
Andre Kostur
Distinguished Software Architect & Engineer
P: 604-678-2864
E: [email-masked]
Toll-Free: 1-800-877-1856

F: 604-678-2864
VoIP: sip:[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 15:44:00 +0000

> located." into the link-address of the relay-forward.

Ah, thanks, sorry, I was confusing link-address and peer-address.

So Bernie, you would be satisfied if the triggered reconfigure message included a link-address field that contained the same address that was included in previous requests from the client?

Med, is that operationally possible in the use case you are trying to address?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2012 15:55:47 +0000

> So Bernie, you would be satisfied if the triggered reconfigure message included a link-address field that contained the same address that was included in previous requests from the client?

That is correct. Note that there is no "field" if this is a normal looking client packet and thus it would need to be an option (and I don't think we presently have such an option).

Perhaps that the document is silent about whether other relay options can or cannot be included is OK - that leaves it open for people to do what is necessary should they need additional relay information to be communicated (I've heard various rumblings where apparently other information is desired to be used to determine the client's location - such as the interface-id option -- RFC 3315 doesn't really forbid that.). 

- Bernie

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 16:57:31 +0100

Dear Bernie,

I have considered the alternative to design RECONFIGURE-REQUEST message using the same format as RELAY-FORW. I have even the text hidden as a comment in my xml version. The reason I abandoned that approach is: If we forgot about the reconfigure-request extension, RFC 3315 says:

   A server sends each Reconfigure message to a single DHCP client,
   using an IPv6 unicast address of sufficient scope belonging to the
   DHCP client.  If the server does not have an address to which it can
   send the Reconfigure message directly to the client, the server uses
   a Relay-reply message (as described in section 20.3) to send the
   Reconfigure message to a relay agent that will relay the message to
   the client.  The server may obtain the address of the client (and the
   appropriate relay agent, if required) through the information the
   server has about clients that have been in contact with the server,
   or through some external agent.

For this reason, RECONFIGURE-REQUEST does only need to indicate which client is concerned with a configuration change.

Could you please clarify why RECONFIGURE-REQUEST should include more information than what is described in the excerpt from rfc3315 cited above? 

Many thanks in advance. 

Cheers,
Med

>De : Bernie Volz (volz) [mailto:[email-masked]] 
>Envoyé : jeudi 13 décembre 2012 14:50
>À : JACQUENET Christian OLNC/OLN
>Cc : BOUCADAIR Mohamed OLNC/OLN; Ted Lemon; [email-masked] WG
>Objet : Re: [dhcwg] draft-ietf-dhc-triggered-reconfigure did 
>not pass WGLC
>
>I do NOT favor advancing this draft. It needs to include 
>information similar to the link-address that would normally be 
>included in relayed messages so that the server can more 
>easily locate the client and is not required to reconfigure 
>all instances of the client (such as a multi-homed client that 
>may have obtained leases on different links, even from 
>different relays).
>
>I also am not sure if providing some additional relay 
>information might be warranted (i.e., the things a relay would 
>normally have added to a relay-forw).
>
>- Bernie
>
>> I indeed confirm that the -01 version of this draft reflects 
>the comments I had. Let me also take the opportunity of this 
>message to insist on the usefulness of this work, as it 
>addresses the rather typical issue depicted in section 1.1 and 
>experienced in some provider's environment, like ours.
>> 
>> Cheers,
>> 
>> Christian.  
>> 
>> I fully understand your concern. I was also expecting more 
>reviews in addition to the ones acknowledged in the draft.   
>> 
>> I know Christian and Roberta are OK with the changes I made 
>to integrate their comment. I let them confirm/infirm they are 
>OK with this version to move forward. Gurav has sent a message 
>when the WGLC was initiated. 
>> 
>> I sincerely hope to see at least one or two more reviews; 
>otherwise shouldn't we interpret "no answer" as consent ;-)?
>> 
>> Cheers,
>> Med
>> 
>_______________________________________________________________
>__________________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des 
>informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si 
>vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. 
>Les messages electroniques etant susceptibles d'alteration,
>> France Telecom - Orange decline toute responsabilite si ce 
>message a ete altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or 
>privileged information that may be protected by law;
>> If you have received this email in error, please notify the 
>sender and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not 
>liable for messages that have been modified, changed or falsified.
>> Thank you.
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 13 Dec 2012 16:10:23 +0000

This "link-address" is not being used to send the Reconfigure request to the client -- other than to find the correct client to send the reconfigure to.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 13, 2012 10:58 AM
To: Bernie Volz (volz); JACQUENET Christian OLNC/OLN
Cc: Ted Lemon; [email-masked] WG
Subject: RE: [dhcwg] draft-ietf-dhc-triggered-reconfigure did not pass WGLC

Dear Bernie,

Many thanks in advance. 

Cheers,
Med

>De : Bernie Volz (volz) [mailto:[email-masked]] Envoyé : jeudi 13 
>décembre 2012 14:50 À : JACQUENET Christian OLNC/OLN Cc : BOUCADAIR 
>Mohamed OLNC/OLN; Ted Lemon; [email-masked] WG Objet : Re: [dhcwg] 
>draft-ietf-dhc-triggered-reconfigure did not pass WGLC
>
>I do NOT favor advancing this draft. It needs to include information 
>similar to the link-address that would normally be included in relayed 
>messages so that the server can more easily locate the client and is 
>not required to reconfigure all instances of the client (such as a 
>multi-homed client that may have obtained leases on different links, 
>even from different relays).
>
>I also am not sure if providing some additional relay information might 
>be warranted (i.e., the things a relay would normally have added to a 
>relay-forw).
>
>- Bernie
>
>the comments I had. Let me also take the opportunity of this message to 
>insist on the usefulness of this work, as it addresses the rather 
>typical issue depicted in section 1.1 and experienced in some 
>provider's environment, like ours.
>> 
>> Cheers,
>> 
>> Christian.  
>> 
>> Envoyé : jeudi 13 décembre 2012 07:41 À : Ted Lemon; [email-masked] 
>> WG Cc : JACQUENET Christian OLNC/OLN; Maglione Roberta; Gaurav
>Halwasia (ghalwasi)
>to integrate their comment. I let them confirm/infirm they are OK with 
>this version to move forward. Gurav has sent a message when the WGLC 
>was initiated.
>>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 17:59:09 +0000

So for the benefit of the working group, I should mention that Med has done an update to the draft that defines a new format for the triggered reconfigure message.   The format is just a message type followed by a link-address field followed by a variable-length option field.

This was my preference—back when we originally wrote 3315, we decided that fixed-length information that's mandatory should just go in the message header, and this is why we have a different message header for relay messages than for client<->server messages.

Bernie objected to defining a third format, because he feels that it will complicate message parsers.   So he'd prefer that we use the same format that is used for client<->server messages, and just define a new link-address option to carry the link address information.

So the question for the working group is, what do others think about this?   Is it better to continue the RFC3315 convention, or to break from that convention and just use an option?

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 13 Dec 2012 19:18:40 +0100

On 13.12.2012 18:59, Ted Lemon wrote:
> So for the benefit of the working group, I should mention that Med
> has done an update to the draft that defines a new format for the
> triggered reconfigure message.   The format is just a message type
> followed by a link-address field followed by a variable-length option
> field.
> 
> This was my preference—back when we originally wrote 3315, we decided
> that fixed-length information that's mandatory should just go in the
> message header, and this is why we have a different message header
> for relay messages than for client<->server messages.
I recently dug up old, old versions of dhc-dhcpv6 draft. Fascinating
stuff. Why did you guys drop the "Bad hair day" or "Insufficient funds"
status codes? :)

> Bernie objected to defining a third format, because he feels that it
> will complicate message parsers.   So he'd prefer that we use the
That is my preference as well. Every server and client implementation
already have routines for checking if mandatory options are present and
handling cases where they are missing.

> same format that is used for client<->server messages, and just
It is not only client-server, but also server-requestor in leasequery.

> define a new link-address option to carry the link address
> information.

> So the question for the working group is, what do others think about
> this?   Is it better to continue the RFC3315 convention, or to break
> from that convention and just use an option?
I prefer to continue RFC3315 convention. There are some options that are
mandatory, e.g. client-id, yet there is no such field in SOLICIT or
REQUEST. It is not exactly the same (DUIDs have variable length), but
it's close.

Just add a text that the option MUST be present and the server MUST drop
the message if it is missing. Simple, clear and easy to implement.

Tomek

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 13 Dec 2012 14:25:40 -0500

Ted,

"continue the RFC3315 convention" could be taken more than one way.  

 a) I believe that you mean it to be taken "define a new message
 header whenever there is fixed-length mandatory information"
 required for the processing.

 b) An alternative reading of "continue the RFC3315 convention" is
 to consider the existing fixed-length message headers defined
 in RFC3315 as the headers that you should use unless you
 *really* need another fixed length message header, and to use
 options in the *existing* 3315-defined message headers.

------------------------

Personally, I prefer minimizing the new message headers, and
using options where possible.  I think that it is easier to
modify servers and clients to handle (or require) a new option
than it is to handle a new message header, and that nothing bad
happens from using options.  I also think that servers and
clients will tend to handle options they don't understand better
than message headers they don't understand, though I can
certainly create straw-man proposals where that isn't true.

In any case, my preference for options over new message headers
is moderate, but it isn't a huge deal for me.

Regards -- Kim

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Dec 2012 19:45:31 +0000

On Dec 13, 2012, at 2:25 PM, Kim Kinnear <[email-masked]> wrote:
> using options where possible. 

It seems to me that we have three people saying they'd like to use an existing header format, one saying we should define a new format, and one, Med, probably not caring either way.

That being the case, Med, can you spin the draft one more time?

I think you can go back to the text you had, and just add the requirement for the link-address option.   You'll also have to define the link-address option and explain how it should be used.   Maybe you can talk Bernie into providing some text... :)

Once you've done that, let's re-spin the draft and do another last call, and see if we get any more responses.   I'm hoping that Kim, Bernie and Tomek will weigh in on the next last call, since they've helped to figure out how to proceed with the draft.

---

From: Bud Millwood <[email-masked]>
Date: Fri, 14 Dec 2012 16:23:00 +0100

> options in the *existing* 3315-defined message headers.

This sums it up for me. I'll happily add a new message format if
that's where it really belongs, but if seems to belong in the context
of an existing message in any way then it should be an option.

Anything that doesn't throw away messages it doesn't understand is an
accident waiting to happen.

- Bud

---

From: <[email-masked]>
Date: Thu, 13 Dec 2012 10:34:10 +0100

Dear all,

Cheers,

Christian. 

-----Message d'origine-----
De : BOUCADAIR Mohamed OLNC/OLN 
Envoyé : jeudi 13 décembre 2012 07:41
À : Ted Lemon; [email-masked] WG
Cc : JACQUENET Christian OLNC/OLN; Maglione Roberta; Gaurav Halwasia (ghalwasi)
Objet : RE: draft-ietf-dhc-triggered-reconfigure did not pass WGLC
Importance : Haute

Hi Ted, 

Cheers,
Med

---

From: <[email-masked]>
Date: Mon, 17 Dec 2012 08:26:33 +0100

Hi Ted, all,

I updated the draft with the suggested changes. Please check the diff: 

http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-triggered-reconfigure-02

Cheers,
Med 

>De : Ted Lemon [mailto:[email-masked]] 
>Envoyé : jeudi 13 décembre 2012 20:46
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked] WG
>Objet : Re: [dhcwg] Should triggered-reconfigure define a new 
>DHCP message header format?
>
>It seems to me that we have three people saying they'd like to 
>use an existing header format, one saying we should define a 
>new format, and one, Med, probably not caring either way.
>
>I think you can go back to the text you had, and just add the 
>requirement for the link-address option.   You'll also have to 
>define the link-address option and explain how it should be 
>used.   Maybe you can talk Bernie into providing some text... :)
>
>Once you've done that, let's re-spin the draft and do another 
>last call, and see if we get any more responses.   I'm hoping 
>that Kim, Bernie and Tomek will weigh in on the next last 
>call, since they've helped to figure out how to proceed with the draft.
>
>