On 20.06.2013 18:23, Tomek Mrugalski wrote:
> 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.
Very useful draft. I strongly support this work moving forward. I do
have some comments, though.

1. Clarifying question regarding text:

   As a result of receiving this
   option, the DHCPv6 client MUST NOT send any Solicit messages more
   frequently than allowed by the retransmission mechanism defined in
   sections 17.1.2 and 14 of RFC 3315

The (updated) section 17.1.2 says that SOLMAXRT is now 3600 (seconds).
Any value received in the option that is smaller than 3600 will mean
that the SOLICIT messages would be sent more frequently, thus must be
ignored. Does it mean that allowed range of values is 3600 - 2^32-2 ?

I'm somewhat ok with that, but I would prefer that there would be an
ability to revert to current behaviour, i.e. configure value of SOLMAXRT
option to 120, so old and new clients would behave the same way.

In any case, I think the allowed values should be explicitly specified
for both options. I would also consider the upper end of possible ranges
here. 2^32 seconds is around 136 years, so perhaps limiting the upper
value is a good idea as well? Speaking of big numbers, section 5.6 of
3315 says that 0xffffffff means infinity (I agree that it is somewhat
debatable if that applies to timers, but it's a matter of
interpretation). Is it allowed value here? That would mean that this
draft allows tweaking backoff mechanism to essentially have no upper
threshold. I prefer to not have a solution that can be told to count to
infinity.

2. Section 8 must be updated to cover also INF_MAX_RT value.

3. RFC3315 mentions client restarting configuration process in various
events (NotOnLink status received, received REPLY for INF-Request failed
validation, link change etc.) and there are operational events that also
trigger it: service restart, sleep/resume, device reboot etc. It is not
clear whether client should attempt to store the INF_MAX_RT and
SOL_MAX_RT values across those events? If not, at what situation should
it revert back to default (3600) values? I think it would be good to
clarify that.

4. It is not very well specified what should the client do if it
receives several ADVERTISEs, each with different SOLMAXRT (or INFMAXRT)?
I'm tempted to assume that according to the current text, it must
process them in the order in which they appear. That may not be the best
thing to do. Perhaps clarifying text about using exactly one value from
the received advertises could be helpful? I agree that having two
servers on the same link advertising different values is a bit uncommon
(configuration error or a rogue server), but clients should be able to
behave consistently in such case.

5. The text does not include Client and Server behaviour sections, as
recommended by option-guidelines-12, Section 21. I agree that this draft
is very simple, but it would be good to follow those recommendations if
possible.

6. Is RFC3633 reference really normative here? I think it should be
informative.

7. Ralph already mentioned his plan to have the name updated to reflect
the addition of INF_MAX_RT.

8. The discussion in Security considerations is not precise. According
to last paragraph of section 4 ("If a DHCPv6 client receives a message
containing a SOL_MAX_RT option, the client MUST set its internal
SOL_MAX_RT parameter to the value contained in the SOL_MAX_RT option.").
Note that this sentence applies to all received messages, including
non-selected Advertises. So whether the value sent by legitimate or
rogue server will be used by the server, depends on the order of
received messages. Also see my comment #4.

Hope that helps,
Tomek