[dhcwg] Comments on draft-ietf-dhc-rfc3315bis-05

[Shawn Routhier <[e-mail]>]

I was reminded that today is the last day for comments,
so here are mine.  I apologize if some of them have already
been discussed on the email list but haven’t had the chance
to check for duplications.

Most of my comments are editorial or otherwise not-major,
and I support this work.  The editorial ones are the first
section while the more substantive issues are the second
section.

regards,
Shawn

RFC3315 Bis 05 review comments

Minor typos:

Section 1, para 6
"summarizes relation to" => "summarizes the relation to"

Section 1.1, para 1
"follow up extensions published" => "follow up extensions were published"

"Understanding a protocol which definition" => "Understanding a protocol whose definition"
or "Understanding a protocol where the definition"

"between large number" => "between a large number"

"Furthermore, a significant" => "Furthermore, signficiant"

"definition of the DHCPv6 that" => "definition of DHCPv6"

Section 4.2, item lease
This is the only item that starts with "It is".  It would
be more consistent to simply have "An address assigned ..."

Section 12.3, para 8
"provides such posibility" => "provides for such a possibility"

Section 13.1, Para 1
"This loops" => "These loops" or "This loop"

Section 13.2, para 2
"Client MUST" => "The client MUST"

Section 16.2, para 1
"and mentioned" => "as mentioned"

Section 17, Para 3
"The client does it by" => "The client does this by"
"message and selects a server" => "message and selecting a server"

Section 17.2 Para 2
"A server sends Advertise message" => "A server sends Advertise messages"

Section 17.2 Para 7
"message as indicated by the as indicated by the" => "message as indciated by the"

Section 17.2.1 Para 6
"back to the client may useful using" => "back to the client may be useful during"

Section 17.2.9, para 3
"by the client during server selection process" => "by the client during the server selection process"

Section 17.2.9, para 6
"(IA_NA or IA_IA)" => "(IA_NA or IA_TA)"

Section 18.1.1, para 1
"If not addresses of" => "If no addresses"

Section 20.7, para 3
"or the will not be sent" => "or they will not be sent"
"MUST NOT by in the" => "MUST NOT be in the"

Section 20.17, para 7
"Severs only" => "Servers only"

** Issues: **

Section 3, para 1 and para 5
This section mentions 2136 should it also include some of
4701, 4703, 4704?

Section 6.6
Should that be unsigned 32 bit integers?

Section 11.1
This section is titled as "Identity Assocaitions for Address Assignemnt"
which implies it handles both IA_NAs and IA_TAs but it describes an IA
as including T1 and T2 and references 20.4 which is only for IA_NAs.

Section 11.2
In Section 11.1 para 3 mentions that each address in an IA
has a preferred and valid lifetime.  Why isn't there a similar
paragraph for prefixes?

Section 17.1.2
Should the client be restricted to send basically the same
options in a request as it did in the original solicit?

Section 17.1.3
Bullet item 1 - If the client is rebooting it doesn't really matter
if it has stable sorage or not.

Section 17.1.4,last para
The description of what to do on timeout in a reconfigure situation
is unclear.  It reads as if a reconfigure should trigger renew messages
until such time as rebinds should be sent.  But the text also says
reconfigure is handled differently.

Section 17.2.4 para 3
"This paragraph has "If the server chooses to include the IA address
or IA prefix option for such an address or delegated prefix, the server
SHOULD set T1 and T2 to the valid lifetime for the IA option ..."
This appears to say that T1 & T2 should be equal to the valid lifetime.
Is that really what was desired?  or should it be something like 
"set T1 and T2 based on the value of the valid lifetime"?

Section 17.2.10
This seems an odd place for this text.  It would seem that it would
be better before 17.2.9 as before that are the sections that generate
replies then 17.2.9 generates advertise messages.

Section 18.1.1, para 1
Section 18.1.2, para 3
I thought site-scoped addresses were killed some time ago.
Is this being left in for historical reasons?

Section 20.6, para 5 (client discards any addresses)
Given that the server is ignoring the lifetimes and T1 and T2 already
I'm not sure that ignoring them in special circumstances is useful
but I suppose it's not harmful.

Section 20.21
IAID - In the descriptions of IAID for IA_NA and IA_TA the text
specifies that they are from differnet name spaces.  I assume that
IA_PD is from a third namespace.  It might be useful to mention that.

Section 20.21, para 6
The text states that the delegating router MUST use the values in T1 and T2.
Should that be the requesting router?  Or is this trying to say that the
delegating router must use them to control the requesting router, in which
case the text is confusing.

Section 20.21, para 8
As with section 20.6 I find this paragraph somewhat redundant but mostly
harmless.

Section 20.22, para 5
same as secton 20.6, para 5 - the delegating router is already ignoring
lifetimes and T1 and T2