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

["Bernie Volz (volz)" <[e-mail]>]

Hi Jinmei:

Thanks for reviewing. Comments from me inline below (BV>).

You can view the changes to the XML made from these comments at:

https://github.com/dhcwg/rfc3315bis/commit/357e98d84f728e5909598a82672562b0889f1f13

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ????
Sent: Tuesday, May 23, 2017 4:18 PM
To: Bernie Volz (volz) <[e-mail]>
Cc: [e-mail]; Ralph Droms <[e-mail]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

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).

BV> We are working on sedhcpv6 but this has not been so simple and quick. And, DHCPv6 is in use and deployed today without an authentication protocol. There are other actions that can be taken such as stated in section 22:

   Many of these rogue server attacks can be mitigated by making use of
   the mechanism described in [RFC7610].

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

BV> We decided as a WG not to remove IA_TA. See https://trac.tools.ietf.org/group/dhcpv6bis/ticket/124.

>>   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).

BV> OK. The FF0x: cases were just missed. This is now fixed.

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

and there are still more references to RFC2462.

BV> This is by design. RFC4862 does not mention the M & O bits so we can't reference that RFC. We documented the reason for this in Appendix A:

   26.  ...
                                        Note that in a few
        places, older obsoleted RFCs (such as RFC2462 related to M and O
        bit handling) are still referenced as the material cited was not
        added in the replacement RFC.

BV> The other place we uses is when mentioning "stateful address autoconfiguration protocol" as RFC 4862 does not use this terminology except in Appendix C:

   o  Avoided the wording of "stateful configuration", which is known to
      be quite confusing, and simply used "DHCPv6" wherever appropriate.

BV> I hope this explains to you why we leave this reference in the 4 places (excepting Appendix A) where it is still used.


>> - 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.

BV> Unless you suggest some text, we will leave this be. I think the point of the text is rather clear.

>> - 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)".

BV> Unless you suggest some text, we will leave it be. I don't see that this is necessarily in conflict - yes, ULA is in the "global address space". But I also think it adds value to explicitly mention ULAs here as otherwise someone could confuse the subtly that ULA is allowed.


>> - 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/.

BV> Thanks for catching typo, will be fixed. As you can live with it, we will leave alone otherwise.

>> - 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.

BV> This is intentional as the specification clearly does NOT allow for multicast Reconfigure to be valid. Perhaps a future draft will support this, but for now this prohibition is appropriate.

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

BV> See above.

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

BV> I believe we addressed this by other text in the document - for example, see in 18.2.4 the following text:

   The server controls the time at which the client should contact the
   server to extend the lifetimes on assigned leases through the T1 and
   T2 parameters assigned to an IA.  However, as the client Renews/
   Rebinds all IAs from the server at the same time, the 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 (earliest
   T1/T2).

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).

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

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

Same here.

BV> See comment earlier as I think mention both does no harm and helps to clarify that it would be either.

>> - 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.

BV> While it does sound a bit awkward, we left this in given seDHCPv6 work as there would be little point in using RKAP if that was used. We can remove "the client and server are not using any other authentication protocol" and assume the seDHCPv6 will make this clear.

>> - 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.

BV> OK, this must have just been missed.

>> - 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).

BV> Unless you provide text, I think we'll leave this alone as mentioned earlier we feel that this document is not the one that should describe how these lifetimes are to be used.

>> - 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?

BV> I'm not sure why we would want this paragraph at all. So I think best to just remove it.
BV> You original question was I think about why SOL_MAX_RT MUST be in ORO. It MUST be as per RFC 7083 so that clients can get updated SOL_MAX_RT values. And, yes, the idea is that the Advertise with the SOL_MAX_RT value is used (even if it offers no leases) so that the client applies this value for any future requests. I don't see the need for this to be spelled out?

--
JINMEI, Tatuya