Subject: [dhcwg] SOL_MAX_RT

From: Wuyts Carl <[email-masked]>
Date: Thu, 20 Jun 2013 15:36:40 +0200

Hi,

I think I've popped up the question already some months ago, but I don't think there's any progress on this.
The SOL_MAX_RT document is still draft-only, and the assigned option is still '"TBD".

The RFC6204-12 says:
WAA-8:   The CE router must support the SOL_MAX_RT option
            [I-D.droms-dhc-dhcpv6-solmaxrt-update] and request the
            SOL_MAX_RT option in an ORO.

This is kind of "tricky" as lots of times you can see that implementations must be compliant with RFC6204-versionXX, but one cannot be compliant as the option number is still not assigned, so in fact, no single router can be compliant with RFc6204 today.
So, today, only possibility is to include support in a proprietary option or something?

Thx for the feedback.

Regs
Carl

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 20 Jun 2013 16:23:33 +0200

On 20.06.2013 15:36, Wuyts Carl wrote:
> Hi,
> 
> I think I’ve popped up the question already some months ago, but I don’t
> think there’s any progress on this.
> 
> The SOL_MAX_RT document is still draft-only, and the assigned option is
> still ‘”TBD”.
> 
> The RFC6204-12 says:
There's no such thing as RFC6204-12. RFCs do not have revision numbers.
What I think you are referring to is draft-ietf-v6ops-6204bis-12, right?
Thats an internet draft, not a published RFC.

> This is kind of “tricky” as lots of times you can see that
> implementations must be compliant with RFC6204-versionXX, but one cannot
This statement is incorrect. There is only one version of RFC6204. What
you are likely talking about is rfc6204bis - a nickname that was given
for an internet draft that will eventually be published as updated
version of RFC6204. It is currently a draft revision 12. It is not yet
published as RFC and it not a standard.

There are couple issues here. Let me explain them one by one:

1. draft-ietf-v6ops-6204bis-12 has normative reference to
droms-dhc-dhcpv6-solmaxrt-update. That draft was replaced by
draft-ietf-dhc-dhcpv6-solmaxrt-update. Note the difference in name - it
is a working group item now. draft-ietf-v6ops-6204bis-13 (if published)
should have that reference updated.

2. RFC editor will not publish draft-ietf-v6ops-6204bis-XY as RFC until
all its normative references are published or ready for publication.
That is the case with draft-ietf-dhc-dhcpv6-solmaxrt-update here. This
process is called clustering. See
http://www.rfc-editor.org/cluster_def.html.

3. Ralph plans to present draft-ietf-dhc-dhcpv6-solmaxrt-update in
Berlin (July/August 2013) during DHC meeting. It is likely that the WGLC
will follow shortly afterwards. If you want to speed up the process, I
encourage you to actively participate in
draft-ietf-dhc-dhcpv6-solmaxrt-update review. Please review it and post
your comments. Make sure you show your support (or objections) during WGLC.

4. IANA typically does not assign option numbers for drafts that are not
ready for publication. There's very good practical reason for it. Up
until publication, the draft could change or even be abandoned
completely in some cases. If IANA had assigned option codes too early,
people would end up with implementations based on different versions of
the same option spec. In extreme cases, that would be true even if IETF
decided to not standardize a given option after all.

> So, today, only possibility is to include support in a proprietary
This is done strictly with my chair hat off. I'm saying this as a long
time developer of DHCP server and client implementation. This worked for
me well, but may not work for you. In a general case you should not
release a code or product that implements draft version of a standard.
If you choose to release that, put a big fat disclaimer that the option
implementation is a work in progress, may not work or the behavior may
change, so it may not interoperate with other implementations that
happen to use later revision of the spec. For lab and interop sessions,
it is ok to come up with artificial high number (e.g. 300) and use it
for testing. Once the option is standardized and assuming there were no
other changes in the spec, you need to only update one constant in your
code and it is ready to go.

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Jun 2013 14:30:43 +0000

Do we need a SOL_MAX_RT presentation in Berlin?   Why not just last-call it now?

---

From: "Brzozowski, John" <[email-masked]>
Date: Thu, 20 Jun 2013 14:57:54 +0000

Ted I support a WGLC now.  This work is very much needed still and can be
advanced before Berlin.  In particular the back off timers are of
particular importance.  I believe this work is tied into 6204bis which
also needs to advance.

John
=========================================
John Jason Brzozowski
Comcast Cable
m) 484-962-0060
o) 609-377-6594
w) www.comcast6.net
e) [email-masked]
=========================================

-----Original Message-----
From: Ted Lemon <[email-masked]>
Date: Thursday, June 20, 2013 10:30 AM
To: Tomasz Mrugalski <[email-masked]>
Cc: dhc WG <[email-masked]>
Subject: Re: [dhcwg] SOL_MAX_RT

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Jun 2013 11:11:18 -0400

> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just last-call it now?

OK with me.  I suggested the presentation in Berlin to prompt a discussion of two issues that were raised during the previous WG last call: sending >1 Solicit or Information-Request after the back-off timer expires and clarifying whether a host has to remain actively listening for a response while waiting for the back-off timer to expire.

I didn't see any declaration of consensus around either of those topics and did not address them in -01.

Personally, I would prefer to see the document proceed in its current form and consider the other two issues in a separate document.  In my opinion, the document is ready for WG last call in its current state.

At some point, I see the title should be updated to "Modification to Default Value of SOL_MAX_RT and INF_MAX_RT".  That change probably doesn't need a presentation in Berlin.

- Ralph

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 20 Jun 2013 18:23:15 +0200

On 20.06.2013 17:11, Ralph Droms wrote:
> On Jun 20, 2013, at 10:30 AM 6/20/13, Ted Lemon wrote:
> OK with me.
My understanding is that under normal circumstances chairs cannot just
announce WGLC on their own. They can do so if authors or editors state
the the draft is ready and chairs concur with that opinion. Anyway, here
it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and
indicate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that
control SOLICIT and INFORMATION-REQUEST message retransmissions and
define a mechanism for server to override client's default values. There
is a document in v6ops about basic requirements for IPv6 CE routers that
depends on this work.

At the time of this writing, there is no IPR reported against this draft.

Bernie and I will evaluate consensus after 2013-07-04.

Thanks,
Bernie & Tomek

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 20 Jun 2013 16:46:43 +0000

+1 for what Ralph suggests.
I've seen some strong demand for a published 6204bis. And, as has been pointed out, that won't happen till the dependencies are published. So we need the dependencies published.
Barbara

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ralph Droms
> Sent: Thursday, June 20, 2013 11:11 AM
> To: Ted Lemon
> Cc: [email-masked] WG
> OK with me.  I suggested the presentation in Berlin to prompt a discussion of
> two issues that were raised during the previous WG last call: sending >1
> Solicit or Information-Request after the back-off timer expires and clarifying
> whether a host has to remain actively listening for a response while waiting
> for the back-off timer to expire.
> 
> Personally, I would prefer to see the document proceed in its current form
> and consider the other two issues in a separate document.  In my opinion,
> the document is ready for WG last call in its current state.
> 
> At some point, I see the title should be updated to "Modification to Default
> Value of SOL_MAX_RT and INF_MAX_RT".  That change probably doesn't
> need a presentation in Berlin.
> 
> - Ralph
> 
> >

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 20 Jun 2013 17:13:15 +0000

<WG co-chair hat OFF>

I don't yet support this document moving forward - I think the issues raised earlier need to be 'resolved'.

The ND cache timeout is a concern if there are relays (routers) or servers (kernel stacks) that do not save the packet needing ND resolution.

The DHCPv6 client will send 1 packet every hour to the relay or server. This is MULTICAST and there is no ND exchange since the mac address is known. When the relay or server then UNICASTs the response, it will need to do ND (of the link-local address) to determine the mac address. And, if the DHCP reply is not saved while this ND resolution takes place, nothing will end up being transmitted to the client when the ND resolution completes.

An hour later, the same thing could happen. Hence, the client never gets the ADVERTISE.

The old maximum retransmission timer was more likely within bounds of the expiration of the ND cache entry (except in cases where the cache grew large and some entries might be prematurely removed if not recently used).

I know this negates some of the benefits of the longer time if the client were to retransmit several times. And, if we simply want to point out this issue and recommend that ND implementations assure that they retain these (DHCPv6) packets when doing a resolution, that is fine by me.

I'm also not sure why stating the a client is only required to wait for a 'reasonable' time for a response wasn't addressed. This could be something like:

A client SHOULD wait TTL * 2 (which is like close to the 120 which was the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for less if, for example, power consumption is a key concern.

I had though Ralph proposed to discuss these issues at Berlin and resolve them -- then we'd do the WGLC. I'm fine with trying to resolve these issues on the list.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Thursday, June 20, 2013 12:23 PM
To: [email-masked] WG
Cc: Ralph Droms; Ted Lemon
Subject: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

>> Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
My understanding is that under normal circumstances chairs cannot just announce WGLC on their own. They can do so if authors or editors state the the draft is ready and chairs concur with that opinion. Anyway, here it goes:

Folks, the author of draft-ietf-dhc-dhcpv6-solmaxrt-update-01
(http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-solmaxrt-update-01)
feels it's ready for work group last call. Please review this draft and indicate whether or not you feel it is ready to be published.

This document redefines two timers (SOL_MAX_RT and INF_MAX_RT) that control SOLICIT and INFORMATION-REQUEST message retransmissions and define a mechanism for server to override client's default values. There is a document in v6ops about basic requirements for IPv6 CE routers that depends on this work.

Thanks,
Bernie & Tomek

---

From: Hans Liu <[email-masked]>
Date: Fri, 21 Jun 2013 20:56:00 +0800

+1 too!
>From a vendor point of view, we sincerely would like to see a publish of
6204bis, so we have something solid to follow up.

Best regards,
Hans

On Fri, Jun 21, 2013 at 12:46 AM, STARK, BARBARA H <[email-masked]> wrote:

> I've seen some strong demand for a published 6204bis. And, as has been
> pointed out, that won't happen till the dependencies are published. So we
> need the dependencies published.
> Barbara
>
> > > Do we need a SOL_MAX_RT presentation in Berlin?   Why not just
> last-call it
> > now?
> >
> > I didn't see any declaration of consensus around either of those topics
> and
> > did not address them in -01.
> >

-- 
Instead of following the fashion, we lead it through.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Jun 2013 10:29:04 -0400

> The ND cache timeout is a concern if there are relays (routers) or servers (kernel stacks) that do not save the packet needing ND resolution.

That behavior is not RFC-compliant; from section 7.2.2 of RFC 4861:

   While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  The queue MUST hold at least one
   packet, and MAY contain more.

> A client SHOULD wait TTL * 2 (which is like close to the 120 which was the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for less if, for example, power consumption is a key co…

I wasn't given any indication of consensus supporting that change, so I didn't include it.
> I had though Ralph proposed to discuss these issues at Berlin and resolve them -- then we'd do the WGLC. I'm fine with trying to resolve these issues on the list.

IMHO, we should first determine consensus for publishing draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these additional issues in a separate document or holding draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues are discussed.  While the question has not been posed explicitly on the list, there seems to be support for going ahead with draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form.

- Ralph

>>> last-call it now?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 21 Jun 2013 15:24:07 +0000

Hi Ralph:

OK, great that the ND issue isn't real. I had looked for something like that at one point but didn't find it. As that is the case, that is no longer an issue. Too bad this wasn't found earlier (or if it was mentioned, I missed it - sorry). So I withdraw that objection.

Regarding the issue about how long the receiver needs to wait for a packet, I think there was some discussion and support for that during some of the email exchange. I don't believe anyone was against adding something to NOT require waiting the full time (given the longer solmax) for a response from the DHCP server. That makes no sense to wait an hour or even many minutes.

It seems silly to have a completely separate draft mention that. We didn't have a need to mention this when RFC 3315 was written since the times were assumed to be reasonable for 'waiting'.

> A client SHOULD wait TTL * 2 (which is like close to the 120 which was the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait for less if, for example, power consumption is a key co…

A more formal clarification (actual text) might be:

Add to section 3 of the draft (end of existing text):

  Also, with this change, a new parameter is need to cap the time a client
  must wait for a response from the server as waiting for the new
  SOL_MAX_RT seems excessive. Hence, the following is added:

  NEW:
       MAX_RCV_TIME       120 secs    Max time to wait for a response

Add to section 6 of the draft (probably first):

   Add to section 14 of RFC 3315 (at end of existing text):

   RT specifies the retransmission interval and not necessarily the time a
   client listens for a response from the server. Clients SHOULD  wait for
   responses for at least the shorter of the RT and MAX_RCV_TIME. There
   MAY be situations where a shorter MAX_RCV_TIME is appropriate - such
   as when power consumption is a key concern.

Optional: Document the source of MAX_RCV_TIME which came from old SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph Droms
Sent: Friday, June 21, 2013 10:29 AM
To: Bernie Volz (volz)
Cc: [email-masked] WG; Lemon Ted
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

- Ralph

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 26 Jun 2013 01:50:51 +0000

Bernie,

Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the ND
cache considerations?  This seems out of context for a DHCWG ID.  I think
it is worth noting but certainly not something that delay advancing the
draft.  Alternatively are you think each retransmission should include
multiple attempts?  If yes I think we need to be careful not to recreate
the original problem that we are trying to resolve.

Regarding the client wait time for responses, are we trying to address a
security concern or simply trying to provide some guidance for client
implementers?  In general I am not opposed to the text, however, I wonder
if it is completely necessary.

John

-----Original Message-----
From: Bernie Volz <[email-masked]>
Date: Thursday, June 20, 2013 1:13 PM
To: Tomasz Mrugalski <[email-masked]>, dhc WG <[email-masked]>
Cc: Ralph Droms <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>The ND cache timeout is a concern if there are relays (routers) or
>servers (kernel stacks) that do not save the packet needing ND resolution.
>
>The DHCPv6 client will send 1 packet every hour to the relay or server.
>This is MULTICAST and there is no ND exchange since the mac address is
>known. When the relay or server then UNICASTs the response, it will need
>to do ND (of the link-local address) to determine the mac address. And,
>if the DHCP reply is not saved while this ND resolution takes place,
>nothing will end up being transmitted to the client when the ND
>resolution completes.
>
>The old maximum retransmission timer was more likely within bounds of the
>expiration of the ND cache entry (except in cases where the cache grew
>large and some entries might be prematurely removed if not recently used).
>
>I know this negates some of the benefits of the longer time if the client
>were to retransmit several times. And, if we simply want to point out
>this issue and recommend that ND implementations assure that they retain
>these (DHCPv6) packets when doing a resolution, that is fine by me.
>
>
>I'm also not sure why stating the a client is only required to wait for a
>'reasonable' time for a response wasn't addressed. This could be
>something like:
>
>A client SHOULD wait TTL * 2 (which is like close to the 120 which was
>the old SOL_MAX_RT so perhaps we should just use that) with a MAY wait
>for less if, for example, power consumption is a key concern.
>
>
>I had though Ralph proposed to discuss these issues at Berlin and resolve
>them -- then we'd do the WGLC. I'm fine with trying to resolve these
>issues on the list.
>
>- Bernie
>

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 26 Jun 2013 01:55:59 +0000

Regarding the below I for one have no objections.  However, I could just
as easily see the work advancing as-is.  Providing the below allows us to
move forward I support the edits.

John
-----Original Message-----
From: Bernie Volz <[email-masked]>
Date: Friday, June 21, 2013 11:24 AM
To: Ralph Droms <[email-masked]>
Cc: dhc WG <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] WGLC on
draft-ietf-dhc-dhcpv6-solmaxrt-update-01	-	respond by July 4

>Optional: Document the source of MAX_RCV_TIME which came from old
>SOL_MAX_RT and also is the TCP Maximum Segment Lifetime, RFC 792.
>
>- Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 26 Jun 2013 01:58:16 +0000

This issue was already addressed - Ralph found text in the ND document that 'requires' the node to retain packet(s) while doing ND to send them once the ND is successful. So, it is a non-issue and I removed my objection.

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Tuesday, June 25, 2013 9:51 PM
To: Bernie Volz (volz); Tomek Mrugalski; [email-masked] WG
Cc: Ralph Droms; Ted Lemon
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

Bernie,

Are you expecting the DHCPv6 SOL_MAX_RT draft to include text about the ND cache considerations?  This seems out of context for a DHCWG ID.  I think it is worth noting but certainly not something that delay advancing the draft.  Alternatively are you think each retransmission should include multiple attempts?  If yes I think we need to be careful not to recreate the original problem that we are trying to resolve.

Regarding the client wait time for responses, are we trying to address a security concern or simply trying to provide some guidance for client implementers?  In general I am not opposed to the text, however, I wonder if it is completely necessary.

John

-----Original Message-----
From: Bernie Volz <[email-masked]>
Date: Thursday, June 20, 2013 1:13 PM
To: Tomasz Mrugalski <[email-masked]>, dhc WG <[email-masked]>
Cc: Ralph Droms <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

>known. When the relay or server then UNICASTs the response, it will 
>need to do ND (of the link-local address) to determine the mac address. 
>And, if the DHCP reply is not saved while this ND resolution takes 
>place, nothing will end up being transmitted to the client when the ND 
>resolution completes.
>
>The old maximum retransmission timer was more likely within bounds of 
>the expiration of the ND cache entry (except in cases where the cache 
>grew large and some entries might be prematurely removed if not recently used).
>
>I know this negates some of the benefits of the longer time if the 
>client were to retransmit several times. And, if we simply want to 
>point out this issue and recommend that ND implementations assure that 
>they retain these (DHCPv6) packets when doing a resolution, that is fine by me.
>
>
>I'm also not sure why stating the a client is only required to wait for 
>a 'reasonable' time for a response wasn't addressed. This could be 
>something like:
>
>I had though Ralph proposed to discuss these issues at Berlin and 
>resolve them -- then we'd do the WGLC. I'm fine with trying to resolve 
>these issues on the list.
>
>- Bernie
>
>Of Tomek Mrugalski
>the the draft is ready and chairs concur with that opinion. Anyway, 
>here it goes:
>
>define a mechanism for server to override client's default values. 
>There is a document in v6ops about basic requirements for IPv6 CE 
>routers that depends on this work.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 05:02:40 +0000

On Jun 25, 2013, at 9:50 PM, "Brzozowski, John" <[email-masked]> wrote:
> cache considerations?  This seems out of context for a DHCWG ID.

It looks like a device that doesn't keep the DHCP response long enough to get an answer from neighbor discovery and correctly forward it is out of spec, so we don't need to worry about this.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Jun 2013 08:12:39 -0400

I haven't seen any additional discussion of Bernie's suggestion to add text to this draft clarifying client behavior regarding listening for responses.  We need some indication of consensus before changing the document.

Minor editorial comments in line...

- Ralph

>  must wait for a response from the server as waiting for the new

s/wait/listen/

>  SOL_MAX_RT seems excessive. Hence, the following is added:

s/seems/may, in some situations, be unnecessary and expensive.

s/following is added/the following change to RFC 3315 is  made/
>   client listens for a response from the server. Clients SHOULD  wait for

s/wait/listens/

>   MAY be situations where a shorter MAX_RCV_TIME is appropriate - such

s/MAY/may/

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Jun 2013 08:16:34 -0400

John...

On Jun 25, 2013, at 9:50 PM 6/25/13, "Brzozowski, John" <[email-masked]> wrote:

> implementers?

That text is intended to clarify that a client can stop listening for a response and, for example, go to sleep before sending the next retransmission of a specific message.  The immediate purpose is to allow resource conservation in constrained devices while remaining compliant with the DHCPv6 specification.

- Ralph

>  In general I am not opposed to the text, however, I wonder

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 26 Jun 2013 13:12:10 +0000

Understood, thanks.

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wednesday, June 26, 2013 8:16 AM
To: John Jason Brzozowski <[email-masked]>
Cc: Bernie Volz <[email-masked]>, Tomasz Mrugalski
<[email-masked]>, dhc WG <[email-masked]>, Ted Lemon
<[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 -
respond by July 4

>John...
>
>On Jun 25, 2013, at 9:50 PM 6/25/13, "Brzozowski, John"
><[email-masked]> wrote:
>
>> Bernie,
>> 
>> 
>That text is intended to clarify that a client can stop listening for a
>response and, for example, go to sleep before sending the next
>retransmission of a specific message.  The immediate purpose is to allow
>resource conservation in constrained devices while remaining compliant
>with the DHCPv6 specification.
>
>- Ralph
>
>>>need
>>> An hour later, the same thing could happen. Hence, the client never
>>>gets
>>> the ADVERTISE.
>>> 
>>>the
>>>client
>>>resolve
>>>Of
>>> Tomek Mrugalski
>>>here
>>>There

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 26 Jun 2013 13:13:16 +0000

I seem to recall some feedback from Barbara Stark early on, I do not
recall the context.  Also I assume the authors of 6204bis should have an
opinion here.

John

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wednesday, June 26, 2013 8:12 AM
To: dhc WG <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>I haven't seen any additional discussion of Bernie's suggestion to add
>text to this draft clarifying client behavior regarding listening for
>responses.  We need some indication of consensus before changing the
>document.
>
>> OK, great that the ND issue isn't real. I had looked for something like
>>that at one point but didn't find it. As that is the case, that is no
>>longer an issue. Too bad this wasn't found earlier (or if it was
>>mentioned, I missed it - sorry). So I withdraw that objection.
>> 
>> 
>> Regarding the issue about how long the receiver needs to wait for a
>>packet, I think there was some discussion and support for that during
>>some of the email exchange. I don't believe anyone was against adding
>>something to NOT require waiting the full time (given the longer solmax)
>>for a response from the DHCP server. That makes no sense to wait an hour
>>or even many minutes.
>> 
>> It seems silly to have a completely separate draft mention that. We
>>didn't have a need to mention this when RFC 3315 was written since the
>>times were assumed to be reasonable for 'waiting'.
>> 
>>> The DHCPv6 client will send 1 packet every hour to the relay or
>>>server. This is MULTICAST and there is no ND exchange since the mac
>>>address is known. When the relay or server then UNICASTs the response,
>>>it will need to do ND (of the link-local address) to determine the mac
>>>address. And, if the DHCP reply is not saved while this ND resolution
>>>takes place, nothing will end up being transmitted to the client when
>>>the ND resolution completes.
>>> 
>>>gets the ADVERTISE.
>>> I'm also not sure why stating the a client is only required to wait
>>>for a 'reasonable' time for a response wasn't addressed. This could be
>>>something like:
>>> 
>> IMHO, we should first determine consensus for publishing
>>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 as is and addressing these
>>additional issues in a separate document or holding
>>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 until these additional issues
>>are discussed.  While the question has not been posed explicitly on the
>>list, there seems to be support for going ahead with
>>draft-ietf-dhc-dhcpv6-solmaxrt-update-01 in its current form.
>> 
>>> 
>>> - Bernie
>> 
>> - Ralph
>> 
>>> 
>>> feels it's ready for work group last call. Please review this draft
>>>and indicate whether or not you feel it is ready to be published.
>>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 26 Jun 2013 13:32:07 +0000

Ralph:

>>  Also, with this change, a new parameter is need to cap the time a client

s/need/needed
or
s/need/added

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Wednesday, June 26, 2013 9:13 AM
To: Ralph Droms; [email-masked] WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

I seem to recall some feedback from Barbara Stark early on, I do not recall the context.  Also I assume the authors of 6204bis should have an opinion here.

John

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wednesday, June 26, 2013 8:12 AM
To: dhc WG <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>On Jun 21, 2013, at 11:24 AM 6/21/13, Bernie Volz (volz) 
><[email-masked]>
>wrote:
>
>> Hi Ralph:
>> 
>> OK, great that the ND issue isn't real. I had looked for something 
>>like that at one point but didn't find it. As that is the case, that 
>>is no longer an issue. Too bad this wasn't found earlier (or if it was 
>>something to NOT require waiting the full time (given the longer 
>>solmax) for a response from the DHCP server. That makes no sense to 
>>wait an hour or even many minutes.
>> 
>>> A client SHOULD wait TTL * 2 (which is like close to the 120 which 
>>>was the old SOL_MAX_RT so perhaps we should just use that) with a MAY 
>>>wait for less if, for example, power consumption is a key concern.
>> 
>>> I don't yet support this document moving forward - I think the 
>>>issues raised earlier need to be 'resolved'.
>>> 
>>>address is known. When the relay or server then UNICASTs the 
>>>response, it will need to do ND (of the link-local address) to 
>>>determine the mac address. And, if the DHCP reply is not saved while 
>>>this ND resolution takes place, nothing will end up being transmitted 
>>>to the client when the ND resolution completes.
>>> 
>>> The old maximum retransmission timer was more likely within bounds 
>>>of the expiration of the ND cache entry (except in cases where the 
>>>cache grew large and some entries might be prematurely removed if not 
>>>recently used).
>>> 
>>>point out this issue and recommend that ND implementations assure 
>>>that they retain these (DHCPv6) packets when doing a resolution, that 
>>>is fine by me.
>>> 
>>> 
>>>for a 'reasonable' time for a response wasn't addressed. This could 
>>>be something like:
>>> 
>>> A client SHOULD wait TTL * 2 (which is like close to the 120 which 
>>>was the old SOL_MAX_RT so perhaps we should just use that) with a MAY 
>>>wait for less if, for example, power consumption is a key concern.
>> 
>>>resolve them -- then we'd do the WGLC. I'm fine with trying to 
>>>resolve these issues on the list.
>> 
>>are discussed.  While the question has not been posed explicitly on 
>>the list, there seems to be support for going ahead with
>>> My understanding is that under normal circumstances chairs cannot 
>>>just announce WGLC on their own. They can do so if authors or editors 
>>>state the the draft is ready and chairs concur with that opinion. 
>>>Anyway, here it goes:
>>>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 13:44:43 +0000

<no hat>

I think it's relatively harmless to leave power saving behavior as unspecified.   I don't think we have data to support an assertion as to how long the client should leave the radio on, and in the absence of data, we'd be more likely to do harm than good.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 26 Jun 2013 14:43:05 +0000

> From: Ted Lemon
> <no hat>
> 
> I think it's relatively harmless to leave power saving behavior as unspecified.
> I don't think we have data to support an assertion as to how long the client
> should leave the radio on, and in the absence of data, we'd be more likely to
> do harm than good.

+1
I would prefer to leave power saving behavior unspecified. As long as it isn't precluded, it's my experience that the various radio interface specialists tend to figure out what works best for their environments. Also, given that doze intervals for Wi-Fi interfaces (and some other radio interfaces) are often in the range of ~200ms, I see no reason why such an interface couldn't doze while waiting.
Barbara

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Jun 2013 10:57:24 -0400

> I think it's relatively harmless to leave power saving behavior as unspecified.   I don't think we have data to support an assertion as to how long the client should leave the radio on, and in the…

Is there any chance some diligent specification compliance organization will interpret the current unspecified behavior as "the client MUST continue to listen actively"?

I don't think so; just making sure the question is asked explicitly.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 15:01:52 +0000

> Is there any chance some diligent specification compliance organization will interpret the current unspecified behavior as "the client MUST continue to listen actively"?

I don't think it's wrong to say that some clients may choose to turn off their radios after some interval.  Saying that would address this concern.   I just think we should leave the interval as an implementation-dependent value.   There is a concern here that an implementation will never actually test this scenario, in which case it may use a too-short interval.   But I just don't think we have enough information to be able to make a determination as to what the interval should be, so we have to accept that this failure mode is a possibility.

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Jun 2013 11:36:43 -0400

> I don't think it's wrong to say that some clients may choose to turn off their radios after some interval.  Saying that would address this concern.   I just think we should leave the interval as an…
Suggested text to be added at the end of section 3 of draft-ietf-dhc-dhcpv6-solmaxrt-update:

   To accommodate resource constrained devices such as battery-powered
   sensor nodes, the following text is added as the last sentence in
   section 14 of RFC 3315:

   NEW:

   Some client devices may choose to stop listening for responses from
   the server before RT expires.  For example, a battery-powered device
   may choose to turn off its radio after actively listening for a
   response for an appropriate period of time.

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 26 Jun 2013 18:37:45 +0000

Seems like reasonable text.

John

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wednesday, June 26, 2013 11:36 AM
To: dhc WG <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>>> Is there any chance some diligent specification compliance
>>>organization will interpret the current unspecified behavior as "the
>>>client MUST continue to listen actively"?
>> 
>> I don't think it's wrong to say that some clients may choose to turn
>>off their radios after some interval.  Saying that would address this
>>concern.   I just think we should leave the interval as an
>>implementation-dependent value.   There is a concern here that an
>>implementation will never actually test this scenario, in which case it
>>may use a too-short interval.   But I just don't think we have enough
>>information to be able to make a determination as to what the interval
>>should be, so we have to accept that this failure mode is a possibility.
>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 26 Jun 2013 18:51:18 +0000

Is the "may" in the proposed text normative? If not, could it be "might" to avoid confusion? If yes, could it look normative?
I'm ok either way and have no (other than this nit) problem with the proposed text.
Barbara

> Sent: Wednesday, June 26, 2013 11:37 AM
> To: [email-masked] WG
> >> Is there any chance some diligent specification compliance organization
> will interpret the current unspecified behavior as "the client MUST continue
> to listen actively"?
> >
> > I don't think it's wrong to say that some clients may choose to turn off their
> radios after some interval.  Saying that would address this concern.   I just
> think we should leave the interval as an implementation-dependent value.
> There is a concern here that an implementation will never actually test this
> scenario, in which case it may use a too-short interval.   But I just don't think
> we have enough information to be able to make a determination as to what
> the interval should be, so we have to accept that this failure mode is a
> possibility.
> >

---

From: Ralph Droms <[email-masked]>
Date: Wed, 26 Jun 2013 14:55:00 -0400

> I'm ok either way and have no (other than this nit) problem with the proposed text.

Author hat off, I would prefer to avoid normative text and would be ok with s/may/might/

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Jun 2013 19:19:56 +0000

> Author hat off, I would prefer to avoid normative text and would be ok with s/may/might/

You can also put in the RFC 2119 section that only capitalized keywords are normative, and then just use regular english.   The IESG has been seeing a lot of tortured english as a result of people assuming that lowercase versions of RFC2119 keywords have to be normative, and we think it damages the quality of the documents.

---

From: Chris Donley <[email-masked]>
Date: Thu, 27 Jun 2013 14:49:40 +0000

Works for me.

Chris
-- 
Chris Donley
CCIE, CISSP, SCiPM
Director - Network Technologies
CableLabs®
858 Coal Creek Circle
Louisville, CO 80027
303-661-3480 (v)

On 6/26/13 12:55 PM, "Ralph Droms" <[email-masked]> wrote:

>> Is the "may" in the proposed text normative? If not, could it be
>>"might" to avoid confusion? If yes, could it look normative?
>>>>>organization
>>>>off their
>>> Suggested text to be added at the end of section 3 of
>>>draft-ietf-dhc-dhcpv6-
>>> solmaxrt-update:
>>>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2013 10:57:56 -0400

> You can also put in the RFC 2119 section that only capitalized keywords are normative, and then just use regular english.   The IESG has been seeing a lot of tortured english as a result of people…

OK, but wouldn't that paint a big target on this draft with a caption "ADs, shoot here"? :-)

Seriously, I agree with you, and I'm willing to join the fight, but maybe not with this doc...

- Ralph

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 27 Jun 2013 17:37:00 +0000

I'm OK with it.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Wednesday, June 26, 2013 2:38 PM
To: Ralph Droms; [email-masked] WG
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01 - respond by July 4

John

-----Original Message-----
From: Ralph Droms <[email-masked]>
Date: Wednesday, June 26, 2013 11:36 AM
To: dhc WG <[email-masked]>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcpv6-solmaxrt-update-01
-	respond by July 4

>draft-ietf-dhc-dhcpv6-solmaxrt-update:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jun 2013 18:19:24 +0000

> OK, but wouldn't that paint a big target on this draft with a caption "ADs, shoot here"? :-)

No, I don't think so.   When we discussed this in the informal telechat, people seemed to think it was a good idea.   None of us like to read a document that says "the foo needs to bar" when it should say "the foo should bar" just because someone was afraid of getting shot by an AD.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2013 14:52:27 -0400

> No, I don't think so.   When we discussed this in the informal telechat, people seemed to think it was a good idea.   None of us like to read a document that says "the foo needs to bar" when it sho…

Looking hard for potential roadblocks to publication - will the use of an RFC 2119 statement in this document that is different from the one in RFC 3315 cause problems, considering that this document updates RFC 3315 with text that is to be considered part of RFC 3315?

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Jun 2013 19:36:00 +0000

> Looking hard for potential roadblocks to publication - will the use of an RFC 2119 statement in this document that is different from the one in RFC 3315 cause problems, considering that this docume…

If you are stating diffs to RFC3315, that could be an issue.   Otherwise not.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 27 Jun 2013 15:56:52 -0400

> If you are stating diffs to RFC3315, that could be an issue.   Otherwise not.

I interpret the current text in draft-ietf-dhc-dhcpv6-solmaxrt-update as publishing diffs to RFC 3315; e.g.:

6.  Updates for SOL_MAX_RT and INF_MAX_RT options to RFC 3315

   Update to RFC 3315 [RFC3315], section 17.1.3:

   OLD:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user.

   NEW:

   The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MUST process an included SOL_MAX_RT option and/or an
   included INF_MAX_RT option and MAY display the associated status
   message to the user.

and this new text as a diff, as well:

Suggested text to be added at the end of section 3 of draft-ietf-dhc-dhcpv6-
solmaxrt-update:

  NEW:

- Ralph