Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

[神明達哉 <[e-mail]>]

On Tue, May 9, 2017 at 7:52 AM, Bernie Volz (volz) <[e-mail]> wrote:

> The co-authors believe that all of the issues reported for the last August
> WGLC on draft-ietf-dhc-rfc3315bis-05 have now been resolved. But, because of
> the large number of changes, the DHC WG co-chairs feel another “WGLC” is
> appropriate.
>
> Please review this document and provide your comments and whether you
> support the document moving forward by May 30th, 2017. The DHC WG co-chairs
> will again ask Ralph to evaluate the responses. We are doing a 3 week WGLC
> as the document is rather large and important to get right!

I'd still abstain about whether to advance the document as I stated
for the previous WGLC:
https://www.ietf.org/mail-archive/web/dhcwg/current/msg17577.html
but I've checked if the 08 version has addressed my LC comments.

I found some of them still open (perhaps they are intentionally left
open or unchanged, but it's not clear to me).  I'm listing them below,
with followup comments for some of them.

>> - I'm okay with deprecating the delayed authentication protocol,
>> but I'm not sure if it's okay to ship the spec with no built-in
>> authentication (the reconfigure key protocol is very limited and
>> too weak).

>> - I wonder whether we should still keep IA_TA.

>>   link-local address        An IPv6 address having a link-only scope,
>>                             indicated by having the prefix (FE80::/10),
>>  You might want to lower-case the prefix (i.e., to "fe80::/10").

This is not fully addressed as the case is still mixed (Sections 7.1
and 24 use upper case hex).

>> - Section 5.2
>>   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].
>>  s/RFC2462/RFC4862/.

and there are still more references to RFC2462.

>> - Section 5.4
>> [...] the requesting router MUST set the valid lifetime in those
>> advertisements to be no later than the valid lifetime specified in
>> the IA_PD Prefix option.
>>  "no later than" sounds awkward as the lifetime is a duration, not
>>  a particular point in time.

This is simply open as before.

>> - Section 8.1
[...]

>> site-scope unicast address has been deprecated.  Also, the phrase
>> "global or ULA" is awkward as ULA is a global (scoped) address.

The 08 version states:

                           This is typically a globally unique
                           address or unique local address (ULA)
                           [RFC4193],

This is still awkward to me, since in a sense ULAs are also "globally
unique" (even if the uniqueness is not 100% guaranteed).  Personally
I'd simply avoid mentioning ULAs unless there is a specific to reason
to refer to it in the context (and I don't see such a reason here),
but if we want to refer to ULAs here, I'd say, e.g., "a global address
(including unique local addresses)".

>> - Section 10

>> [...] The DUID is designed to be unique across all DHCP clients and
>> servers, and stable for any specific client or server - that is,
>> the DUID used by a client or server SHOULD NOT change over time if
>> at all possible;

>> I guess this property is now changing because of the privacy
>> concerns.

The main change that may be related to this comment is probably the
following new sentence:

   [...]  The client may change its DUID as specific in [RFC7844].

I personally don't think this fully addresses the point of the
comment, although I can live with it.  btw, I believe  there's a typo:
s/specific/specified/.

>> - Section 15.11

>>   -  the message was not unicast to the client.

>> I'm not sure why we bother to say this, and only for Reconfigure.
>> Is there any case where a DHCPv6 message to a client isn't
>> unicasted at all?

There doesn't seem to be any change regarding this comment.  I was not
sure if it was intentional or oversight.

>> - Section 17.1.10.1
>> "no later than" sounds awkward for these lifetimes (see also Sec
>> 5.4).

>> - Section 17.1.10.1
[...]
>> Specifically, the bullet description seems to lead to multiple
>> separate state machines for different bindings.

These two don't seem to be addressed.

>> - Section 18.1.1
>>  s/global, ULA [RFC4193] or site-scoped/global/ (see comment on Sec 8.1)

The revised text still has an issue:

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global or unique local [RFC4193] address

"global or unique local" is redundant since ULAs are global addresses
(scope wise).

>> - Section 18.1.2
>> s/global or site-scoped/global/ (see above)

Same here.

>> - Section 19.4
[...]
>> This statement now sounds awkward since this is now the only
>> defined authentication protocol. (see also comment on Section
>> 17.2.2)

There doesn't seem to be any change to address this point.

>> - Section 20.7
>>   encapsulated in the container MUST NOT by in the Option Request, see
>>  s/Option Request/Option Request option/

'option' (after 'Request') is still missing.

>> - Section 20.22
[...]
>> This choice of valid/preferred lifetime in an IA prefix and the
>> (possible) relationship between them and those lifetimes advertised
>> in the delegated site do not make perfect sense to me. [...]

I don't think the revised version addresses the main point.  The new
text simply avoids saying specifics about these lifetimes, but then
it's even more unclear about what these lifetimes are (especially the
preferred lifetime).

>> - Section 20.23
[...]
>> The expected usage is not very clear to me here.  Is it intended to
>> be used for Advertise and apply the value to the ongoing
>> Solicit-Advertise exchange?  Or is it mainly intended to be used
>> for a possible subsequent restart of a DHCPv6 session?

I guess it was supposed to be addressed by the newly added paragraph
at the end of the section:

   The requirement for the client to request SOL_MAX_RT serves two
   purposes.  First, it distinguishes between legacy and modern clients.
   Second, it allows modern clients to take advantage of the
   configurable SOL_MAX_RT values, even if the server is a legacy one.

of which I don't understand the second purpose: if the server is
legacy, how the client can benefit from the option?

--
JINMEI, Tatuya