Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-rfc3315bis-05 - respond by August 8th

From: Ian Farrer <[email-masked]>
Date: Thu, 4 Aug 2016 19:40:13 +0200

Hi,

Here is my comments on rfc3315-bis-05.

Cheers,
Ian

Section 1.4
Paragraph 2 is a repetition of the beginning of paragraph 12

13.2
T1/T2 times and how they are selected are discussed in this section, but the
purpose of the T1/T2 timers is not described until section 17.1.4. A brief overview
of their purpose would help readers.

16.1 Para 1
The sentence:
"However, the client MAY send the message through another interface if the interface is a logical
interface without direct link attachment"
is ambiguous, suggested reword:
However, the client MAY send the message through another interface if the interface which
configuration is being requested for is a logical interface without direct link attachment  

17.1 DISCUSSION
Is this really a discussion point? The provided text for considerations regarding
the use of unicast with relays seems straightforward enough and the discussion doesn’t pose any questions.

17.1.2
The client includes a Reconfigure Accept option indicating whether or not...
The text here is not accurate (the option is only included if it is supported) - Suggested reword:
The client includes a Reconfigure Accept option (see Section 20.20) if the
client is willing to accept Reconfigure messages from the server.

17.1.10.1 Para beginning ‘When a client had received...'
There are a number of grammatical errors in this paragraph. Suggested re-word:

When a client receives a configuration option in an earlier Reply,
then sends a Renew, Rebind or Information-Request and the requested
option is not present in the Reply, the client MUST stop using
the previously received configuration information.  In other words, the client
should behave as if it never received this configuration option and return
to the relevant default state.  If there is no viable way to stop using the received configuration 
information, the values received/configured from the option MAY persist
if there are no other sources for that data and they have no external impact.
For example, a client that previously received a Client FQDN option and
used it to set up its hostname is allowed to continue using it if
there is no reasonable way for a host to unset its hostname and it
has no external impact.  As a counter example, a client that previously
received an NTP server address from the DHCP server and does not
receive it any more, MUST stop using the configured NTP server IPv6
address.  The client SHOULD be open to other sources of the same
configuration information.  This behavior does not apply to any IA
containers, as their processing is described in detail in other parts
of this document.

* Suggest also that the 'MUST stop using' is replaced with SHOULD, as the
next paragraph describes an exception to the MUST requirement.
* Also, it would be worth extending this to say that if a requested option
is received that has an updated value, then use of the previous value should be
discontinued and replaced with the new value.

17.2 Para 2
s/server sends Advertise message/server sends an Advertise message/

17.2.1 Para 6
"Sending this option back to the client may useful using the server selection
process."  
Current text is unclear, propose:
Sending this option back to the client may be useful for the server selection
process.

17.2.2 Para 6
The term 'prefixes on included addresses' is used (twice). Suggest 'prefixes of'
is used instead.

17.2.9 Para 6
"IA_IA" is listed here. Assume IA_TA was meant.

17.2.11 Para 2
Describes the server including an ORO option to say what is changed/added, but
there is no corresponding text in 17.1.11 saying how the client should use
a received ORO in a reconf. message. (I see Bernie got this one as well)

18.1.1
s/If not addresses/if no addresses/

19 & 19.2
Both sections describe that RFC3315 delayed authentication is obsolete. Is the 
repetition necessary?

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 16 Aug 2016 12:04:16 +0200

On 08.07.2016 19:03, Tomek Mrugalski wrote:
> Hi all,
> 
> So the day finally has come. Authors working on RFC3315bis believe that
> after over two years of work, this document is ready for working group
> last call. This call initiates the working group last call on
> draft-ietf-dhc-rfc3315bis-05 [1]. Since this is a large document (130+
> pages), there's upcoming meeting and a holiday period, chairs decided to
> do an extended last call that will last 4 weeks. Please post your
> comments by August 8th.
> 
> We do have a slot reserved for this work in Berlin. We will present the
> overview of the document (some areas are organized differently than
> original 3315), go over the most important changes and will discuss any
> comments raised to date.
> 
> If you would like to review more important changes, looking at
> appendices A anb B seems like a good place to start. If you like to see
> the list of tickets addressed, see [2]. Many smaller issues were
> discussed on dhcpv6bis mailing list [3].
> 
> This is the most important document the DHC working group is currently
> working on. Please review it thoroughly. Since both co-chairs are also
> co-authors, our shepherd, Ralph Droms, will determine consensus and wrap
> up the WGLC. Thank you Ralph for stepping up and helping with this!
> 
> 1. https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-05
> 2. https://tools.ietf.org/group/dhcpv6bis/
> 3. https://www.ietf.org/mailman/listinfo/dhcpv6bis
> 
> Cheers,
> Bernie & Tomek
> 

As a co-author of this document I strongly support moving it forward. I
have read the entire document and provide a couple of
comments/suggestions below.

Marcin

1.1.  Relation to previous DHCPv6 standards

OLD:
"prefix delegation [RFC3633],stateless [RFC3736], "

NEW:
"prefix delegation [RFC3633], stateless DHCPv6 service [RFC3736],"

1.2.  Relation to DHCP in IPv4

OLD:
"The operational models and relevant configuration information for
   DHCPv4 [RFC2132][RFC2131]"

NEW:
"The operational models and relevant configuration information for
   DHCPv4 [RFC2131]"

1.4.  Client-server Exchanges Involving Two Messages

Didn't we at some point consider removing sections 1.4 and 1.5 as they
present exchanges of messages before we even got to the terminology?

We may consider mentioning after the following paragraph:
"The server sends a Reply message to the client with the new
   lifetimes, allowing the client to continue to use the address or
   delegated prefix without interruption"

that

"If the server is unable to extend the lifetime of an address or
delegated prefix it indicates that by returning the address or delegated
prefix with lifetimes of 0. At the same time, the server may assign
another address or delegated prefix instead."

4.2.  DHCP Terminology
binding: this should be updated to also include delegated prefixes.

Currently it says:

"A binding (or, client binding) is a group of server data records
containing the information the server has about the addresses in an IA"

and further it says:
"... where IA-type is the type of address in the IA ..."

So again, no mention of delegated prefixes.

Similarly, for the IA, is this ok to say:
" Each IA holds one type of address ..." ?. It implies that the prefix
is an address.

IA_PD: I think the following can be removed:
" Each IA_PD has an associated IAID.  A requesting router may have more
than one IA_PD assigned to it; for example, one for each of its
interfaces."

as it duplicates the text for "IA".

singleton option: this seems to be underspecified. In particular,
"appear only once". The question is where? In a message or other option.

6.3.  DHCP Message Types
Message descriptions should probably be updated to use the term
"leases", instead of addresses.

7.  Client/Server Message Formats
msg-type: In wonder if we should add that: "additional message types are
defined in other specifications", to not create impression that those in
section 6.3 are the only valid messages. For example those in RFC7341.

13.1.  Rate Limiting

OLD:
 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed."

NEW:
 "This method of bounding burstiness also guarantees that the long-term
transmission rate will not exceed:" (colon, rather than period at the end).

15.  Message Validation
OLD:
UnSpecFail

NEW:
UnspecFail

17.  DHCP Configuration Exchanges
Some paragraphs of this section require fixing punctuation.

The enumeration of reasons why the client would start DHCP message
exchange could be better placed earlier in this section. Perhaps, right
after the first paragraph.

The paragraph starting with:
"A server may initiate a message exchange with a client by sending a
   Reconfigure message to cause the client to send a Renew, Rebind or..."

could be moved to the end of the section, after the paragraphs
describing client-initiated exchanges.

17.1.3
"In any situation when a client may have moved to a new link and the
   client does not have any delegated prefixes obtained from the DHCP
   server..."

This assumes that the client has delegated prefixes and is interested in
continuing to use them. But, is this also possible that the client
switching to a new link is no longer interested in using delegated
prefixes and simply wants to Confirm the addresses assigned? Is this ok
to send Confirm to verify that the addresses it has are correct, even
though it had received prefixes in previous transaction?

17.1.4. Creation and Transmission of Renew Messages
"The server determines new
   lifetimes for the leases according to the administrative
   configuration of the server.  The server may also add leases to the
   IAs.  The server can remove leases from the IAs by returning IA
   Address options (for IA_NA and IA_TA) and IA Prefix options (for
   IA_PD) with preferred and valid lifetimes set to 0."

This text is server specific and should be better moved to the server
section, or alternatively we may want to consider updating this text to
be more of a client-side type, e.g.

"The client MUST be prepared that the server removes or adds new leases
to the IAs. The leases are removed when server sets their preferred and
valid lifetimes to 0, in which case the client MUST stop using them."

17.1.9. Receipt of Advertise Messages

I'd suggest we put this paragraph at the beginning of the section:

 "Upon receipt of one or more valid Advertise messages, the client
   selects one or more Advertise messages based upon the following
   criteria."

as it is the first for the client to select the Advertise message.

Then, it should be followed by: "The client MUST ignore any Advertise...
with the exception of SOL_MAX_RT and INF_MAX_RT", because we want the
client to process SOL_MAX_RT and INF_MAX_RT from a selected Advertise
message, not from all messages.

17.1.10.1. Reply for Solicit (with Rapid Commit), Request, Renew or Rebind.

The new text starting with:
" When a client had received a configuration option in earlier Reply,
   then sent Renew, Rebind or Information-Request and that requested
   option does not appear in in the Reply any more, it MUST stop using..."

includes Information-request but this section is not about the
Information-request case. One of the option would be to include
Information-request in the section title, but then there is a lot of
text in this section that is not relevant to Information-request.
Perhaps it would be better to have a separate section that includes this
text, e.g. "Lack of Previously Received Options in Reply"

17.2. Server Behavior
Spurious "In most instances".

Duplicated "as indicated by the Reconfigure".

17.2.1. Receipt of Solicit Messages
OLD:
"the servers discard the Solicit message"

NEW:
"the server discards the Solicit message"

OLD:
 "Sending this option back to the client may useful using server
   selection process."

NEW:
 "Sending this option back to the client may be useful in server
   selection process."

17.2.6. Receipt of Information-request Messages
In the following sentence:
"The server includes options containing configuration information to
   be returned to the client as described in Section 17.2. "

it sounds odd to direct the reader to section 17.2. while the reader is
in fact in section 17.2. (specifically 17.2.6).

17.2.9. Creation and Transmission of Advertise Messages
OLD:
"Prefix Excluded"

NEW:
"Prefix Exclude"

24. Obsoleted mechanisms
Together with obsoleting the lifetime hints we obsoleted T1/T2 hints,
which we should probably mention here

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Aug 2016 09:30:44 -0700

> do an extended last call that will last 4 weeks. Please post your

I've reviewed rfc3315bis-05.  As for whether to advance it, I'd
"abstain": personally, I don't like to give such a large spec a go
without an experiment of implementing it.  It's quite possible that it
has a serious issue that is hard to identify just by reading the text,
e.g., a critical oversight for some corner cases or inter-section
inconsistency.  Often these kinds of defects can be only noticed when
someone actually tries to implement it, or even better, when checking
interoperability between different implementations.  Unfortunately I
don't have that time myself, and I think it's irresponsible for me to
say it's good to go (I understand the motto of "believing in running
code" is more or less a thing of the past in the IETF already, so I'm
not insisting this be a requirement to advance the doc).

On a related question: is there anyone/group that actually implements
the major changes in this bis spec?  I wonder this since I believe
some relatively trivial errors (like the second comment on Section
20.4 below) can be quite easily detected once one tries to implement
it.  The fact that this level of issues still remains seems to suggest
that implementation status of the spec is actually quite poor, and
that makes me nervous (again, I know this is not an official
prerequisite for this doc to be published; it's just my personal
concern).

I also have some higher level concerns:

- 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).  As security/privacy is generally considered to be a critical
  part of any IETF spec today rather than just an optional "nice thing
  to have", I imagine this can be a big concern for the IESG.  If my
  observation is simply incorrect, that's fine; I'm not intending to
  raise this point as a blocking issue.  But if I'm right, it will be
  quite tricky issue.  I don't think it's realistic to introduce a new
  authentication mechanism to rfc3315bis, but then I have no good idea
  on how to address the concern.  My suggestion at this point is to
  consult a security AD sooner than later (i.e., in this last call
  period) to see whether the current approach can be a blocking issue
  or not, and if it is, how we could address it.

- I think overall tone of privacy considerations will have to be
  modernized.  It seems rfc3315bis currently still has the same (maybe
  implicit) assumptions that DHCP(v6) is generally free from privacy
  issues.  As we now all know the trend has been significantly changed
  in the IETF in general, and dhc is not an exception.  I've pointed
  out some specific text on this issue below, but I think it should
  also be considered a general issue.

- I wonder whether we should still keep IA_TA.  I don't know whether
  there's any real-world deployment of it (I personally don't know of
  any.  And, if it's not actually deployed, wouldn't the same argument
  apply as deprecating the delayed authentication protocol?  IA_TA is
  not just (almost or totally) unused, but can also do harm by
  introducing tricky corner cases as we discussed in RFC7550.

- On a somewhat related point, it was not clear to me how much of
  RFC7550 is integrated into rfc3315bis.  In particular, it's not
  clear whether it clearly specifies (and effectively enforces) the
  concept of using a single DHCPv6 session for all IA types.  This is
  another instance that made me think I can only abstain; if I
  actually tried to implement the spec I might be able to know it's
  well already described or identify inconsistency or lack of
  description.  But just by reading this size of doc it's quite
  difficult to tell for sure.

Specific comments on the text follow:

- Section 1

   DHCPv6 is the "stateful address autoconfiguration protocol" and the
   "stateful autoconfiguration protocol" referred to in "IPv6 Stateless
   Address Autoconfiguration" [RFC4862].

  This paragraph isn't necessary anymore and should be removed.
  RFC4862 already just refers to DHCPv6 (there's even no reference to
  the odd phrase of "stateful address autoconfiguration protocol" in
  RFC4862).

- Section 1.1

   number of follow up extensions published over the years.  Several
   notable extensions were published: prefix delegation [RFC3633],
   stateless [RFC3736], update to SOL_MAX_RT and INF_MAX_RT option

  A minor point, but I don't think RFC3736 is an "extension" as the
  RFC pretty clearly says in its abstraction.

- Section 3

   IPv6 Stateless Address Autoconfiguration [RFC4862] specifies
   [...] In addition, the
   protocol interaction by which a node begins stateless or stateful
   autoconfiguration is specified.

  Actually, RFC4862 doesn't specify "the protocol interaction"
  anymore (because we failed to cleanly define how M/O bits work).

- Section 4.1, on the description of "link"

                             IP.  Examples are Ethernet (simple or
                             bridged); Token Ring; PPP and PPPoE links,
                             X.25, Frame Relay, or ATM networks; and
                             Internet (or higher) layer "tunnels", such
                             as tunnels over IPv4 or IPv6 itself.

  This is not incorrect, but the examples include technologies almost
  dead today and now look a bit awkward.  You might want to modernize
  the examples.

- Section 4.1

   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").
  Although not necessarily for cases like RFCs, RFC5952 generally
  recommends to use lower-case letters.  rfc3315bis itself uses
  lower-cased version in other places, so it would at least be better
  to be consistent.

- Section 5.2

   the "stateful address autoconfiguration protocol" for IPv6 [RFC2462].

  s/RFC2462/RFC4862/. In general, unless you have a specific reason for
  referring to the older version all of these references should be
  updated to the latest version.  I won't repeat this sense of
  comment, but there are several other such cases.

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

- Section 6.3

   RENEW (5)       A client sends a Renew message to the server that
                   originally provided the client's addresses and [...]

  What about prefixes?  Same for REBIND, and there seem to be other
  cases where the integration of address assignment and prefix
  delegation isn't enough.

- Section 8.1

      link-address         An address that will be used by the server to
                           identify the link on which the client is
                           located.  This is typically global, site-
                           scoped or ULA [RFC4193], but see discussion
                           in Section 18.1.1.

  site-scope unicast address has been deprecated.  Also, the phrase
  "global or ULA" is awkward as ULA is a global (scoped) address.
  You might be interested in draft-carpenter-6man-whats-global-00.

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

- Section 12.1

         [...]  The link address field refers to the link-
         address field of the Relay-Forward message, and the link-
         address fields in any Relay-Forward messages that may be nested
         within the Relay-Forward message.

  I failed to understand this sentence (especially the part after
  "and").  If this is not a wording error, I guess some more
  explanation will be needed.

- Section 12.3

   [...] Each IA_TA
   option contains at most one temporary address for each of the
   prefixes on the link to which the client is attached.

- Section 14

   A client is not expected to listen for a response during the entire
   period between transmission of Solicit or Information-request
   messages.

  I don't understand what this (addition to the original 3315) tries
  to say.

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

- Section 17.1.1

   [...] In
   the case of a Solicit message transmitted when DHCP is initiated by
   IPv6 Neighbor Discovery, the delay gives the amount of time to wait

  IPv6 ND would not "initiate" DHCP anymore (see also the comment on
  Section 3 above).

- Section 17.1.10.1

      [...] 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 for these lifetimes (see also Sec
  5.4).

- Section 17.1.10.1

  This bullet:

   -  Sends a Request message if any of the IAs in the Reply message
      contains the NoBinding status code.  [...]

  and this sentence seem to contradict each other.

   [...]  This facilitates the client using a single state machine
   for all bindings.

  Specifically, the bullet description seems to lead to multiple
  separate state machines for different bindings.

- Section 17.1.12: why can't we simply use CONFIRM for this purpose?

- Section 17.2.2

   [...]  If the
   reconfigure mechanism is supported, the server is supposed to send
   Authentication option with Reconfigure Key (see Section 19.4 for
   details).

  What if we re-introduce securer authentication (whether it's
  sedhcpv6 or not)?  Should we still keep using Reconfigure Key, which
  contains a private key in plain text?  (see also comment on Section
  19.4)

- Section 17.2.9

   [...]  If the Option Request option includes a container option the
   server MUST include all the options that are eligible to be
   encapsulated in the container.

  Is the term "container option" defined somewhere?  If not maybe it
  should in the terminology section.

- Section 17.2.9: incomplete sentence (or perhaps just a missing period)

   server MUST NOT include this address or delegated prefix in the
   Advertise message

- Section 18.1.1

   If the relay agent received the message to be relayed from a client,
   the relay agent places a global, ULA [RFC4193] or site-scoped address
   with a prefix assigned to the link on which the client should be
   assigned an address in the link-address field.

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

- Section 18.1.1

   [...]  If not addresses of
   other scopes are available the relay agent may fill in the link-
   address field with a link-local address from the interface the
   original message was received on.  That is not recommended as it

  s/If not/If no/ (?)
  Also, the term 'other scopes' sounds awkward with deprecation of
  unicast site-local.  I suggest: 'If no global address is available..."

- Section 18.1.2

   If the source address from the IP datagram header of the received
   message is a global or site-scoped address (and the device on which

 s/global or site-scoped/global/ (see above)

- Section 19.1

                           [...]  The information in DHCP messages is
                           not generally considered confidential, so
                           encryption need not be used (i.e., NULL
                           encryption can be used).

  This doesn't seem to reflect the our consensus accurately (always
  enabling encryption in sedhcpv6).  I'm not saying rfc3315bis should
  define DHCPv6 encryption, but I believe general statement like this
  should be consistent with our latest view (or at least not
  clearly inconsistent with it).

- Section 19.1

      Key management       Because the relay agents and servers are used
                           within an organization, public key schemes
                           are not necessary.  Because the relay agents

  This argument sounds weak.  With that logic we should also be able
  to say public key schemes are not necessary between clients and
  servers.  Perhaps the real intent is that both relay agents and
  servers tend to be managed by the same administrator (or admin
  group) so managing shared secret is acceptable?

- Section 19.4

   The Reconfigure Key protocol is used (initiated by the server) only
   if the client and server are not using any other authentication
   protocol and the client and server have negotiated to use Reconfigure
   messages.

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

- Section 20.4

      IAID                 [...] The number
                           space for IA_NA IAIDs is separate from the
                           number space for IA_TA IAIDs.

  This should also list IA_PD IAIDs.  Same for IAID of other types of
  IAs.

- Section 20.4

   In a message sent by a client to a server, the T1 and T2 fields
   SHOULD be set to 0.  The server MUST ignore any values in these
   fields in messages received from a client.

  With this, this doesn't make sense to me:

   If a server receives an IA_NA with T1 greater than T2, and both T1
   and T2 are greater than 0, the server ignores the invalid values of
   T1 and T2 and processes the IA_NA as though the client had set T1 and
   T2 to 0.

  Shouldn't the first para simply say the server MUST ignore these
  values whatever they are?  Then the second para is simply redundant;
  if not, and if the second para means the server can accept such
  non-0 T1/T2 as long as T1 <= T2, then it's not consistent with the
  first para.

- Section 20.6

      IPv6 address         An IPv6 address.

  Maybe we should note that no "associated prefix length" is implied
  for this address, and, in particular, that clients MUST NOT assume
  any length of prefix that matches this address is on-link, referring
  to RFC7421.

- Section 20.6

   [...]  A server [...]
   and ignores the values for T1 and T2 set by the client if
   those values are greater than the preferred lifetime.

  The 'if' condition seems unnecessary (see comment on 20.4) or
  perhaps the whole "and ignores..." part is unnecessary.

- Section 20.7

   encapsulated in the container MUST NOT by in the Option Request, see

  s/MUST NOT by/MUST NOT/ (?)
  s/Option Request/Option Request option/

- Section 20.21

   If a delegating router receives an IA_PD with T1 greater than T2, and
   both T1 and T2 are greater than 0, the delegating router ignores the
   invalid values of T1 and T2 and processes the IA_PD as though the
   requesting router had set T1 and T2 to 0.

  So is it okay for a delegating router to accept non-0 T1 or T2?  If
  so, why it's different from the "first para" I referred to in my
  comment on Section 20.4 (see above)?

- Section 20.22

   In a message sent by a delegating router the preferred and valid
   lifetimes should be set to the values of AdvPreferredLifetime and
   AdvValidLifetime as specified in section 6.2.1, "Router Configuration
   Variables" of [RFC2461], unless administratively configured.

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.  Consider a
requesting router which has an upstream interface, I1, on which PD is
performed, and a downstream interface I2, to which it sends router
advertisements for end hosts.  Unless there's a specific reason to use
different values, I'd expect valid and preferred lifetimes in the
router advertisement sent out from I2 to be AdvValidLifetime (30 days)
and AdvPreferredLifetime.  I'd also expect they do not change in
subsequent RAs unless prefix renumbering is taking place.

But it's not impossible if we strictly honor the sense of the IA
prefix lifetimes, since the lifetimes are (effectively) decreasing to
0 until the next Renew-Reply exchange, and, logically, lifetimes of
the RA can't be larger than the lifetimes of the "site prefix".

So I think the recommended lifetimes of an IA prefix should at least
take into account some margin for the duration until the next renew.
It would also be better if we clarify the relationship between these
two types of lifetimes more explicitly, but one might think it's
beyond the scope of the base DHCPv6 protocol spec.

- Section 20.22

   A delegating router [...] and ignores the values
   for T1 and T2 set by the requesting router if those values are
   greater than the preferred lifetime.

Same comment as that for 20.21 applies.

- Section 20.23

   A DHCP client MUST include the SOL_MAX_RT option code in any Option
   Request option (see Section 20.7) it sends.

  I don't understand the need for this MUST.  If it's a MUST, can't
  the server simply assume as if it were actually included in an
  option request option and respond accordingly?  Or, perhaps it's for
  distinguishing legacy implementations that don't support the
  SOL_MAX_RT option from newer ones? (If so, I think it's worth noting
  explicitly; otherwise some other people may wonder the same point).

- Section 20.23

   If a DHCP client receives a message containing a SOL_MAX_RT option
   that has a valid value for SOL_MAX_RT, the client MUST set its
   internal SOL_MAX_RT parameter to the value contained in the
   SOL_MAX_RT option.

  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?

- Section 21

   Because a requesting router and delegating routers must each have at
   least one assigned IPv6 address, the routers may be able to use IPsec
   for authentication of DHCP messages.

  The statement in the "because" clause seems too strong to me.
  (Assuming a link-local address is not an "assigned IPv6 address" in
  this context) isn't it completely possible that a requesting router
  bootstraps just with a link-local address, starting a fresh DHCPv6
  session to get IAPD (and maybe IANA for its own address)?  Then
  "must each have at least one assigned IPv6 address" does not always
  hold.

- Section 22: s/It/In/

   [RFC7824].  It particular, Section 3 of said document discuss various

- Appendix A: I strongly suggest this be kept with substantial revise,
  instead of just instructing the RFC editor to remove it.
  See https://www.ietf.org/mail-archive/web/dhcwg/current/msg17524.html

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Tue, 16 Aug 2016 09:38:38 -0700

>    prefixes on the link to which the client is attached.

Sorry, please ignore this.  I pasted the wrong part of text in my
draft review and forgot to remove it before submitting the message.

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Wed, 31 Aug 2016 16:28:21 -0400

Ian, this goes back a while, so you may not remember, but your comment
about 1.4 mentions a paragraph 12.   There aren't that many paragraphs in
1.4.   What did you actually mean?

On Thu, Aug 4, 2016 at 1:40 PM, Ian Farrer <[email-masked]> wrote:

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>