[dhcwg] Mostly nits in draft-ietf-dhc-rfc8415bis-05

Hi:

Thanks for moving this forward Tim and in anticipation that we can hopefully send this onwards soon, here’s my review by comparing changes from RFC 8415 to this lastest 05 bis version:

The following change in Section 4.2 might be worth restoring to plurals, as not sure why it was changed (likely by me) to be singular:

In RFC8415:

   IA                        Identity Association: a collection of
                             leases assigned to a client.  Each IA has
                             an associated IAID (see below).  A client
                             may have more than one IA assigned to it --
                             for example, one for each of its
                             interfaces.  Each IA holds one type of
                             lease; for example, an identity association
                             for temporary addresses (IA_TA) holds
                             temporary addresses, and an identity
                             association for prefix delegation (IA_PD)
                             holds delegated prefixes.  Throughout this
                             document, "IA" is used to refer to an
                             identity association without identifying
                             the type of a lease in the IA.  At the time
                             of writing this document, there are three
                             IA types defined: IA_NA, IA_TA, and IA_PD.
                             New IA types may be defined in the future.

In draft-ietf-dhc-rfc8415-bis-05:

   IA                        Identity Association: a collection of
                             leases assigned to a client.  Each IA has
                             an associated IAID (see below).  A client
                             may have more than one IA assigned to it --
                             for example, one for each of its
                             interfaces.  Each IA holds one type of
                             lease; for example, an identity association
                             for non-temporary addresses (IA_NA) holds
                             an address, and an identity association for
                             prefix delegation (IA_PD) holds a delegated
                             prefix.  Throughout this document, "IA" is
                             used to refer to an identity association
                             without identifying the type of a lease in
                             the IA.  At the time of writing this
                             document, there are three IA types defined:
                             IA_NA, IA_TA (obsoleted), and IA_PD.  One
                             other IA type was defined (see [RFC8947])
                             and more may be defined in the future.
So, I propose:

   IA                        Identity Association: a collection of
                             leases assigned to a client.  Each IA has
                             an associated IAID (see below).  A client
                             may have more than one IA assigned to it --
                             for example, one for each of its
                             interfaces.  Each IA holds one type of
                             lease; for example, an identity association
                             for non-temporary addresses (IA_NA) holds
                             addresses, and an identity association for
                             prefix delegation (IA_PD) holds delegated
                             prefixes.  Throughout this document, "IA"
                             is used to refer to an identity association
                             without identifying the type of a lease in
                             the IA.  At the time of writing this
                             document, there are three IA types defined:
                             IA_NA, IA_TA (obsoleted), and IA_PD.  One
                             other IA type was defined (see [RFC8947])
                             and more may be defined in the future.
 

In new text added to 18.2.12 in the bis document, we could remove unnecessary commas (though the RFC Editor may catch this). Currently it reads:

   Specific algorithms for detecting network attachment changes are out
   of scope for this document.  Two possible mechanisms for detecting
   situations where refreshing configuration information may be needed,
   are defined in [RFC6059], and [RFC4957].
 
And could be changed to:

   Specific algorithms for detecting network attachment changes are out
   of scope for this document.  Two possible mechanisms for detecting
   situations where refreshing configuration information may be needed
   are defined in [RFC6059] and [RFC4957].
 

In Table 3 (section 21.13), for the UseMulticast Status Code entry, the “no” before “longer used” is missing:

       | UseMulticast  |    5 | Sent by a server to a client to   |
       |               |      | force the client to send messages |
       |               |      | to the server using the           |
       |               |      | All_DHCP_Relay_Agents_and_Servers |
       |               |      | multicast address.  Obsoleted;    |
       |               |      | longer used.                      |
 

It should be:

       | UseMulticast  |    5 | Sent by a server to a client to   |
       |               |      | force the client to send messages |
       |               |      | to the server using the           |
       |               |      | All_DHCP_Relay_Agents_and_Servers |
       |               |      | multicast address.  Obsoleted; no |
       |               |      | longer used.                      |
 

And, we may have missed adding some folks to the Acknowledgement sections for the recent changes? I think the source ports was raised by Tomoyuki Sahara and the IA Address option encapsulation was raised by Jen Linkova. Neither are currently in Acknowledgements.

Otherwise, I find the document to be in good shape.

I think at this point we should hold off on updates until after IETF meeting as hopefully additional reviews will occur.

- Bernie Volz

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]