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

From: <[email-masked]>
Date: Fri, 1 Mar 2013 11:24:03 +0100

Hi Bernie, all,

I updated the text as follows:

OLD:

   o  If the request is successfully handled by the server, the server
      MUST include a Status Code Option indicating "Success".

   o  If the request includes several Client Identifier options but the
      server will issue reconfigure requests only for a subset of them,
      the server MUST include a Status Code Option indicating "Success"
      but in the meantime it MUST copy back the list of Client
      Identifier Options pointing to clients for which the server won't
      issue a Reconfigure message.

   o  If the server failed to process the request for all clients, the
      server MUST set the Status Code Option to the appropriate status
      code (e.g., UnspecFail, NotAllowed, etc.).

NEW:

   o  If the request is successfully handled by the server, the server
      MUST include a Status Code Option indicating "Success".

   o  If the request includes several Client Identifier options but the
      server won't issue reconfigure requests to all of them, the server
      MUST include in Reconfigure-Ack a Status Code Option
      indicating "Success" but in the meantime it MUST copy back the
      list of Client Identifier Options pointing to clients for which
      the server won't issue a Reconfigure message.

   o  If the server fails to process the request for all clients, the
      server MUST set the Status Code Option to the appropriate status
      code (e.g., UnspecFail, NotAllowed, etc.).  In particular,

      *  UnspecFail MUST be returned if Reconfigure-Request message is
         malformed.

      *  NotAllowed MUST be returned if the server is not configured to
         allow Reconfigure-Request.

      *  NotConfigured MUST be returned if the server has no record of
         the link. 

Please check if the new wording is better.
If there are no other comments, this text will be incorporated in the next iteration of the draft.

Cheers,
Med

>-----Message d'origine-----
>De : Bernie Volz (volz) [mailto:[email-masked]] 
>Envoyé : vendredi 1 mars 2013 06:21
>À : Tomek Mrugalski; BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : RE: [dhcwg] Reminder - WGLC: 
>draft-ietf-dhc-triggered-reconfigure-03
>
>(WG hat off)
>
>The issue regarding section 4.4 and error-codes should be 
>addressed and clarified.
>
>Personally, I don't see a need for the server to return 
>specific status (error) information for each client, as the 
>likely reasons it would not be able to send a Reconfigure is 
>because the client didn't negotiate for reconfigure support or 
>the client doesn't exist in the server. There are other 
>reasons (lack of resources) ...
>
>We have to ask what benefit (other than potentially logging) 
>would the Relay gain by having more specific information? I 
>don't really believe there is.
>
>Perhaps the three possible returns are:
>- Full Success (first bullet in existing section).
>- Partial Success (second bullet) - includes list of clients 
>NOT processed (for whatever reason) which might be ALL clients.
>- Full failure (third bullet) where clients were not even 
>attempted - this handles the case where:
>A) the packet is malformed (for example has no 
>client-identifier option) - UnspecFail
>B) the server has been configured not to allow this request - 
>NotAllowed
>C) the server has no record of the link - NotConfigured
>
>- Bernie
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Tomek Mrugalski
>Sent: Tuesday, February 26, 2013 5:57 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [dhcwg] Reminder - WGLC: 
>draft-ietf-dhc-triggered-reconfigure-03
>
>On 26.02.2013 10:34, [email-masked] wrote:
>>> Figure 1 mentions NAS, without explaining what it means. I presume 
>>> that it is Network Access Server, but it is not a common 
>term in DHCP 
>>> world, so it would be good to explain it.
>> 
>> Med: I added this sentence: 
>> "Figure 1 shows a broadband network scenario in which the 
>Network Access Server (NAS) embeds a DHCPv6 relay agent."
>> Do you think the document needs to say more?
>No. That addition is sufficient.
>
>
>>> Section 2: "Reconfigure message is then sent to the DHCPv6 relay, 
>>> which in turn will forward the message to the appropriate DHCPv6 
>>> client." This reconfigure message will be sent encapsulated in 
>>> Relay-Reply, so it will look like every other message 
>received from a 
>>> server and to be processed by the relay, right? There's no 
>text that 
>>> clarifies that.
>> 
>> Med: I added this sentence just after the one you quoted: 
>> 
>> "Note, the server encapsulates the Reconfigure message in a 
>Relay-reply message."
>> Better?
>Yes.
>
>>> Last paragraph is section 2 talks about retransmissions, but do not 
>>> explain how to conduct them if there is no server response. 
>It should 
>>> point out that the details are explained in section 4.3.
>> Med: The text is now updated to call out Section 4.3. 
>Thanks.
>
>>> Section 4.2.1: "Clients MUST silently discard any received 
>>> RECONFIGURE-REQUEST messages.". I would add that logging such an 
>>> event is allowed, though.
>> Med: Is there any value to log such events in the client side?
>Sometimes yes. Some clients (e.g. dibbler) will print out a 
>warning message, when receiving unknown message (basically 
>anything besides advertise or reply). Reception of such a 
>message by a client may mean that your network is seriously 
>broken or there is an attack in progress.
>This is really a grey area that nobody cares about. Many 
>clients and servers log various things when configured with 
>sufficient log levels.
>If we want to be strict, this is a violation of RFC3315, but I 
>have serious doubts anyone care about that. So I'm ok if you 
>don't want to do anything here.
>
>>> "The server MUST be configurable to accept or reject RECONFIGURE- 
>>> REQUEST messages." This should probably be moved to "Server 
>behavior"
>>> section. 
>> Med: Ok for me. Done.
>Thanks.
>
>> Also, you should specify what is the server default if not
>>> explicitly configured. It should be reject in my opinion.
>> 
>> Med: I added this sentence: 
>> "If no indication is explicitly configured to the server, 
>the default behaviour is to reject RECONFIGURE-REQUEST messages."
>Ok, great.
>
>>> "The relay agent MUST be configurable to accept or reject 
>>> RECONFIGURE- REQUEST messages received from other relay agents.".
>>> Reconfigure-Request
>>> is not addressed at relay and it merely helps deliver it to server, 
>>> so instead of "accept or reject" I would use "forward or drop" here.
>> 
>> Med: I do think both wording would work. "accept" is more 
>generic as forwarding the message will be the result of other 
>steps than just accept handling the message. I will maintain 
>the initial wording. 
>Ok.
>
>>> There should be a separate "Relay behavior" section and second to 
>>> last paragraph in 4.2.1 should be moved to it.
>> 
>> Med: I added a new section called "Intermediate Relay Agents 
>Behaviour" and moved that text to the new section.
>Thanks.
>
>>  There are very good reasons
>>> for having separate behavior sections for server, relays and client 
>>> There should be one for client as well, even if it contains 
>only one 
>>> sentence about dropping those messages. It makes life of 
>implementors 
>>> much easier and increases chances of wider adoption of that 
>proposal.
>>>
>>> The last paragraph in 4.2.1 belongs more in the Server behavior 
>>> section.
>> 
>> Med: Agree.
>Ok, thanks.
>
>
>>> Section 4.3 "The relay may receive (Relay-Reply) 
>Reconfigure before..."
>>> is awkward. It should be "The relay may receive Reconfigure 
>>> encapsulated in Relay-Reply before..."
>> 
>> Med: Fixed. Thanks.
>Thanks.
>
>>> "The relay agent MUST include a Client Identifier 
>Option..." => "The 
>>> relay agent MUST include one or more Client Identifier Options..."
>> Med: Fixed. 
>Thanks a lot. This was confusing without this clarification.
>
>>> Section 4.4 "Upon receipt of a valid Reconfigure-Request 
>message from 
>>> a
>>> DHCPv6 relay agent (see Section 4.2), the server determines the
>>> client(s) for which a Reconfigure message is to be sent.".
>>>
>>> Section 4.4, bullet 2 and 3 contradict each other. When relay 
>>> requested reconfigure for 2 clients and one succeeds and the other 
>>> fails, what should be the return status: success or failure code?
>> 
>> Med: bullet 2 is about partial failure (i.e., there is at least a 
>> success for one client); bullet 3 is when there is failure for all 
>> clients. In
>the
>> partial failure case, the list of failed cio are returned 
>also in the 
>> Reconfigure-Ack.
>> 
>>  What if the
>>> failure reasons are different for each client? It seems that the 
>>> status code returning is not very useful for more than one client.
>>>
>>> Section 4.4, bullet 2 says that server must keep list of client-ids 
>>> that it couldn't configure, but does not explain what to do 
>with that 
>>> list.
>>> Did you mean "include in reconfigure-ack"? If that is so, please 
>>> rephrase that sentence. If you meant something else, please clarify 
>>> as well.
>> 
>> Med: The text is about Reconfigure-Ack. I fixed the text.
>Thanks.
>
>>> Section 7. You should change the text to say that servers MUST 
>>> discard configure-request unless explicitly configured to 
>accept them 
>>> (or perhaps this should go into server behavior section). 
>It's better 
>>> to be safe than sorry.
>> 
>> Med: discarding RECONFIGURE-REQUEST messages + configuration options 
>> are already covered in the server behaviour. I prefer
>Good point. THere's no need to repeat them here. One place is enough.
>
>>> Although DUIDs are typically 14 bytes long, the maximum allowed 
>>> length is 128, so we can hit fragementation limit with only 10 
>>> clients. There should be a short clarification that relay 
>should send 
>>> separate reconfigure-requests if there are more clients (or some 
>>> other suggestion what to do if the MTU limit is hit).
>> 
>> Med: Isn't this covered in the text of Section 4.3: 
>> 
>>  If including Client
>>    Identifier Options of all impacted clients exceeds the maximum
>>    message size (see Section 5), the relay MUST generate several
>>    RECONFIGURE-REQUEST messages required to carry all Client 
>Identifier
>>    Options.  Rate-limit considerations are discussed in Section 5.
>Oh, I missed that. Sorry. Yes, the existing text is clear then.
>
>>> Reconfigure mechanism is optional. What should the server do if 
>>> client does not support Reconfigure?  There's currently no way for 
>>> server to signal that to back to relay. UnspecFail doesn't look 
>>> right. Perhaps NotConfigured would be the right code for it?
>> 
>> Med: If we need to specific, a new error code need to be defined for 
>> this case. If you think there is a value in specifying that 
>behaviour, 
>> I suggest we define a new error code for it.
>I don't know. Does the relay can use the information why the 
>reconfigure failed? I suppose there could be some value in 
>making different permanent failures (e.g. the client do not 
>support reconfigure) with some temporary failure that may 
>disappear when repeated reconfigure request is made. But I do 
>not have any strong opinion on that. Can someone else comment 
>on this as well?
>
>>> Excuse my poor understanding of how NAS works, but does it 
>keep DUIDs 
>>> of all clients connected through it? So from the pure DHCP 
>>> perspective, this is a stateful relay, right? If that is so, it 
>>> should be pointed somewhere that the way relay keeps the 
>information 
>>> about clients is outside of scope for this document.
>> 
>> Med: Section 2 says: 
>> 
>>    This setup assumes the relay has a record of the client, 
>so that it
>>    has enough information to send the Reconfigure-Request 
>message to the
>>    server.  Means to recover state in failure events must be 
>supported,
>>    but are not discussed in this document.
>> 
>> I propose to change it to
>> 
>>    This setup assumes the relay has a record of the client, 
>so that it
>>    has enough information to send the Reconfigure-Request 
>message to the
>>    server. How the state is recorded in the relay is out of 
>scope. Furthermore, means to recover state in failure events 
>must be supported,
>>    but are not discussed in this document.
>Ok.
>
>Ok, great. That deals with all my comments. Let's see if 
>anyone else has additional comments on the status code. I'm ok 
>with leaving it as it is, reusing some of the codes from 
>leasequery or defining a new one.
>
>After that I think the draft is good to move forward.
>
>Cheers,
>Tomek
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Mar 2013 13:34:56 +0000

I still think this means if there is 1 client in request but it cannot be Reconfigured as client didn't negotiate for that support, the third case would apply but I don't think that is what you want as what status code would you use?

In my mind third case means that request itself is invalid - not that clients are.

Use of "won't" is also not recommended.

Perhaps reorder the items:
1. Server is unable to process request. Missing data, not allowed, unknown link.
2. Server processes request but one or more clients cannot be sent a reconfigure (might be all clients).
3. Full success. This is same as #2, just no clients included.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Mar 2013 13:50:27 +0000

>      the server won't issue a Reconfigure message.

I'm uncomfortable with the number of conditionals in this that seem unnecessary.   How about this:

If the server is able to issue one or more Reconfigure messages to the clients identified in the Reconfigure-Request, the server MUST return a Status Code option indicating "success."   In addition, the server MUST include a list of all the Client-Identifier options of the clients to which Reconfigure messages were successfully sent.

This points out two issues that I think you should consider:

1. What result code does the server return if zero of the listed clients could receive a Reconfigure?
2. Is this really even a good idea?   Now the DHCP server is holding off on sending the acknowledgement until all the reconfigures have been sent; is that in fact what you want?   It's fine if it is, but I thought I'd ask the question.   You probably already answered it elsewhere in the draft, but I haven't read it in a while. :(

---

From: <[email-masked]>
Date: Fri, 1 Mar 2013 14:52:11 +0100

Re-,

Please see inline.

Cheers,
Med

>Envoyé : vendredi 1 mars 2013 14:35
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Tomek Mrugalski; [email-masked]
>Objet : Re: [dhcwg] Reminder - WGLC:
>I still think this means if there is 1 client in request but
>it cannot be Reconfigured as client didn't negotiate for that
>support, the third case would apply but I don't think that is
>what you want as what status code would you use?

Med: For me this is covered in the second bullet:

Should the text be tweaked further?

>In my mind third case means that request itself is invalid -

Med: The third bullet covers the case where the server fails to process the request itself or can't process it for administrative reasons.

>Use of "won't" is also not recommended.

Med: s/won't/is unable to?

>2. Server processes request but one or more clients cannot be
>sent a reconfigure (might be all clients).
>> If there are no other comments, this text will be
>incorporated in the next iteration of the draft.
>>
>> Cheers,
>> Med
>>

---

From: <[email-masked]>
Date: Fri, 1 Mar 2013 15:08:48 +0100

Hi Ted,

Please see inline.

Cheers,
Med 

>De : Ted Lemon [mailto:[email-masked]] 
>Envoyé : vendredi 1 mars 2013 14:50
>Cc : Bernie Volz (volz); Tomek Mrugalski; [email-masked]
>If the server is able to issue one or more Reconfigure 
>messages to the clients identified in the Reconfigure-Request, 
>the server MUST return a Status Code option indicating 
>"success."   In addition, the server MUST include a list of 
>all the Client-Identifier options of the clients to which 
>Reconfigure messages were successfully sent.

Med: Only clients for which reconfigure won't be sent are returned in the response and also I would change "Reconfigure messages were successfully sent" to "Reconfigure messages will be sent". Apart from that, I'm fine with the proposed wording.

>1. What result code does the server return if zero of the 
>listed clients could receive a Reconfigure?

Med: If there is no error to handle the request (e.g., malformed request) or there is no administrative policy which disallow reconfigure-request, then a "success" is returned with the list of ALL clients. Else, an error code is sent back. The order proposed by Bernie will make this more clear IMHO.

>2. Is this really even a good idea?   Now the DHCP server is 
>holding off on sending the acknowledgement until all the 
>reconfigures have been sent; is that in fact what you want?

Med: No, the server should not hold reconfigure-ack. The reconfigure-ack is sent back once the server validates the requests and concludes it can generate a reconfigure or not. For rate-limit considerations, the actual sending of the corresponding reconfigure messages will be delayed, but not the reconfigure-ack.
   
>It's fine if it is, but I thought I'd ask the question.   You 
>probably already answered it elsewhere in the draft, but I 
>haven't read it in a while. :(

Med: This text is in the draft to explain the rationale: 

   The support of Reconfigure-Ack simplifies the retransmission
   procedure of the relay as it provides an explicit indication from the
   server.  An alternative approach is the relay monitors Reconfigure
   messages received from the server to conclude whether Reconfigure-
   Request was successfully handled or not.  Nevertheless, this implicit
   approach may fail to achieve its goals in some cases: e.g., the
   server accepts the request but it delays to generate the
   corresponding Reconfigure messages due to its rate-limiting policies,
   the request was partially failed for some clients, etc.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Mar 2013 14:13:26 +0000

I would prefer the failed clients be listed.

Sent from my iPad

---

From: <[email-masked]>
Date: Fri, 1 Mar 2013 15:17:33 +0100

One correction inline.

Cheers,
Med

>De : BOUCADAIR Mohamed OLNC/OLN 
>Envoyé : vendredi 1 mars 2013 15:09
>À : 'Ted Lemon'
>Med: Only clients for which reconfigure won't be sent are 
>returned in the response and also I would change "Reconfigure 
>messages were successfully sent" to "Reconfigure messages will 
>be sent". Apart from that, I'm fine with the proposed wording.
>

Med: I wanted to say: "Reconfigure messages were successfully sent" to be changed to "Reconfigure messages won't be sent"

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Mar 2013 14:20:00 +0000

> Med: Only clients for which reconfigure won't be sent are returned in the response and also I would change "Reconfigure messages were successfully sent" to "Reconfigure messages will be sent". Apar…

Okay, so the language ought to look like this?

If the reconfigure request is successfully validated, the server MUST return a Status Code option indicating "success."   In addition, the server MUST include a list of 
all the Client-Identifier options of the clients to which 
Reconfigure messages will not be sent.   Note that this means that "success" will be returned even if none of the clients are able to receive Reconfigure messages.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Mar 2013 14:38:52 +0000

Yes that looks good with one minor edit:

> none of the clients are able to [be sent] Reconfigure messages.

The server has no idea whether clients are able to receive them.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Mar 2013 14:46:48 +0000

> The server has no idea whether clients are able to receive them.

Not true—clients indicate if they are willing to be reconfigured.   That's what I meant with this bit; maybe the language could be clearer.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 1 Mar 2013 15:31:39 +0000

That is my point about sending. That is the clearer language. Note that yes that isn't 100% clear because a send can fail (destination unreachable, etc.) but the intent here was that the server has attempted to initiate the Reconfigure, not that the reconfigure was not possible - reconfigure not negotiated or the client no longer has any bindings.

----

We might have to look at clarifying one other issue ... if the server relays the Reconfigure, does it use the relay that sent the Reconfigure-Request or does it use what it has stored about the client (which could be a different relay - perhaps the relays have a high-availability (HA) feature and the relay that was last used by the client may not be the one sending the Reconfigure). Note that on a server that allows an administrator to request a Reconfigure or generates one automatically based on some configuration change, it would only have the stored information.

The text currently reads:

  Then, the server MUST follow the procedure defined in Section 19.1 of
   [RFC3315] to construct a Reconfigure message.  This Reconfigure
   message may be sent directly to the DHCPv6 client or to a relay agent
   [RFC3315].

Note that it says "a relay agent", which is ambiguous. Perhaps that was on purpose?

I suppose if the relays really have some HA feature, either would be OK and it would be up to the relays to deal with it?

---

And, I might as well ask now whether to rename RECONFIGURE-ACK to RECONFIGURE-REPLY. ACK is more DHCPv4 terminology :) It is just a name so no big deal either way, but just thought I'd mention it now just so it is thought about.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Friday, March 01, 2013 9:47 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] Reminder - WGLC: draft-ietf-dhc-triggered-reconfigure-03

> The server has no idea whether clients are able to receive them.

Not true-clients indicate if they are willing to be reconfigured.   That's what I meant with this bit; maybe the language could be clearer.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 1 Mar 2013 18:41:23 +0000

> That is my point about sending. That is the clearer language. Note that yes that isn't 100% clear because a send can fail (destination unreachable, etc.) but the intent here was that the server has…

Okay, that's a good distinction to make.  Thanks!

---

From: <[email-masked]>
Date: Mon, 4 Mar 2013 10:42:22 +0100

Hi Bernie,

* I'm OK to rename the message. 
* The excerpt you mentioned about the server behaviour is just an extract of the server's behaviour as defined in rfc3315; it is there to say the procedure defined in this document does not change that behaviour. Whether the reconfigure it is relayed or not is out of scope. 

Cheers,
Med 

>Envoyé : vendredi 1 mars 2013 16:32
>À : Ted Lemon
>Cc : BOUCADAIR Mohamed OLNC/OLN; Tomek Mrugalski; [email-masked]
>That is my point about sending. That is the clearer language. 
>Note that yes that isn't 100% clear because a send can fail 
>(destination unreachable, etc.) but the intent here was that 
>the server has attempted to initiate the Reconfigure, not that 
>the reconfigure was not possible - reconfigure not negotiated 
>or the client no longer has any bindings.
>
>----
>
>We might have to look at clarifying one other issue ... if the 
>server relays the Reconfigure, does it use the relay that sent 
>the Reconfigure-Request or does it use what it has stored 
>about the client (which could be a different relay - perhaps 
>the relays have a high-availability (HA) feature and the relay 
>that was last used by the client may not be the one sending 
>the Reconfigure). Note that on a server that allows an 
>administrator to request a Reconfigure or generates one 
>automatically based on some configuration change, it would 
>only have the stored information.
>
>I suppose if the relays really have some HA feature, either 
>would be OK and it would be up to the relays to deal with it?
>
>---
>
>And, I might as well ask now whether to rename RECONFIGURE-ACK 
>to RECONFIGURE-REPLY. ACK is more DHCPv4 terminology :) It is 
>just a name so no big deal either way, but just thought I'd 
>mention it now just so it is thought about.
>
>- Bernie
>
>Not true-clients indicate if they are willing to be 
>reconfigured.   That's what I meant with this bit; maybe the 
>language could be clearer.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 13:19:34 +0000

> * The excerpt you mentioned about the server behaviour is just an extract of the server's behaviour as defined in rfc3315; it is there to say the procedure defined in this document does not change…

There shouldn't ever be text in a draft that reiterates what has already been standardized.   If the text doesn't update RFC3315, you should take it out.