On 26.11.2014 15:59, Bernie Volz (volz) wrote:
> The draft is available here:
> http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-stateful-issues-09
> 
> *Please send your comments by December 12th, 2014. If you do not feel
> this document should advance, please state your reasons why.*
I reviewed version -09 of this draft and I strongly support it moving
forward. I do have several comments, but they minor and should not hold
this document.

Abstract (also repeated in Section 1):
"since shoe-horned a new option" =>
"since shoe-horned new options" (there are two: 25 and 26)

Section 1:
"modify the DHCP protocol" => "modify the DHCPv6 protocol". You're not
trying to put IA_PD in DHCPv4, are you? ;)

Section 1:
"The changes described in this document are intended to be
incorporated in a new revision of the DHCPv6 protocol specification
([I-D.dhcwg-dhc-rfc3315bis]).". You should add something along the lines
of "Until 3315bis is published, this document should stand on its own."
Otherwise IESG may think that they are not expected to send this draft
to RFC editor on its own.

Section 4, the last paragraph. This looks like a left-over and it states
the same as the previous one. If you want to keep it, I think it would
be good to remove "proposed" out of it. Once it is published as RFC,
this will no longer be a proposal.

Section 4.1 has a list of 3 choices the client must be able to handle.
I'd reorder them. The number two is the proposed way forward, so it
should be listed first. The other two (current #1 and #3) should be
marked as "This is backward compatibility with servers that hasn't been
updated to this change.".

Section 4.1 (paragraph starting with "Servers MUST return the Status
Code option...") also mentions where the server should put the status
codes when something fails. There are implementations that put status
code = Success in their responses. They should also be bound by the
rules you define here.

Section 4.2, the last proposed replacement proposes to replace the text
with "...such as the available options advertised in IAs.". Maybe it
would be better to say "...such as the available resources advertised in
IAs.". The "resources" naming convention is something we decided to use
in 3315bis. Maybe it's a good time to start using it? You could add it
to the terminology and explain that an allocatable resource is an
address, a prefix or any other resource governed by the server that is
assignable on a per client basis. (It's just an idea. I don't insist on
it. If you don't like it, it will wait till 3315bis is released.)

Section 4.3: "client MUST select a T1 and T2 time from all IA options
which will guarantee that the client will send Renew/Rebind messages not
later than at the T1/T2 times associated with any of the client's
bindings.". In simpler language, "use the smallest T1/T2 values.". Is
that what you want to say?

I don't like the idea of using 0s in the example in Section 4.3. There
was a discussion in 3315bis whether we should forbid 0 as that was
confusing to implementors and packet storms were observed. This brings
the topic of T1 set to 0. Since you mentioned 0 times, have you
considered adding a clarification that "at client's discretion"
explicitly excludes "immediately".

Section 4.4.3. The part that explains what T1=T2=0 means, after " should
add after "...at the client's discretion.": Client MUST NOT initiate the
transmission immediately. (In my opinion it is ok to point it out in
several places. It should be obvious, yet several implementors missed
that point.)

Section 4.4.5 says "If the client finds no usable addresses in any of
the IAs, it may either try another server (by restarting the DHCP server
discovery process) or use the Information-request message to obtain
other configuration information only.". That's not the only option. It's
possible that the client received additional Advertises from other
servers, just the server it picked didn't return anything useful. This
is somewhat obscure, but valid scenario. See Section 17.1.3 of RFC3315,
the paragraph starting with "If the client needs to select an alternate
server...".

Section 4.4.5 also says "The client uses addresses and other information
from any IAs that do not contain a Status Code option with the
NoAddrsAvail code.". I think it would be better to say non-success
status code. That blank statement would cover valid cases like
NoPrefixAvail in IA_PD, UnspecFail or NoBinding in IA_NA, but also
server bugs like when a server sets other error code that is not allowed
here.

Section 4.4.7 says "If the server finds the addresses in the IA for the
client and the server determines that the addresses in the IA are
appropriate for the link to which the client's interface is attached
according to the server's explicit configuration information, the server
SHOULD send back the IA to the client with new lifetimes and, if
applicable, T1/T2 times." What do you mean by "the server finds the
addresses in the IA"? That there are IA address options in the client's
message or that the server found those addresses in its lease database?

Editorial comment: links in section 4.4.8 should say Section 12.1 of RFC
3633. Right now the html version attempts to link to section 12.1 of
stateful-issues.

Section 4.7 may bring to the reader's attention a somewhat obscure
feature mentioned in RFC3315, section 17.1.3. It say says that the
client picks one *or more* Advertise messages. Obviously, how to use
that capability is outside of scope here.

Ok, that's it. Thanks a lot for doing this work. I find those
corrections very useful.

Tomek