[Roll] [roll] #171 (draft-doi-roll-mpl-parameter-configuration): Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06

["roll issue tracker" <[e-mail]>]

#171: Int-Dir review of draft-ietf-roll-mpl-parameter-configuration-06

 Int-Dir review for draft-ietf-roll-mpl-parameter-configuration-06 from
 Bernie Volz

 Source: http://www.ietf.org/mail-archive/web/int-dir/current/msg00129.html

 "Hi:



 I am an assigned INT directorate reviewer for draft-ietf-roll-mpl-
 parameter-configuration-06. These comments were written primarily for the
 benefit of the Internet Area Directors. Document editors and shepherd(s)
 should treat these comments just like they would treat comments from any
 other IETF contributors and resolve them along with any other Last Call
 comments that have been received. For more details on the INT Directorate,
 see http://www.ietf.org/iesg/directorate.html.





 Disclaimer: I’m primarily reading this draft primarily from the DHCP
 perspective. Thus, in some cases my questions might seem odd to those that
 understand the MPL concepts and issues. I will admit that I have only
 minimally studied the MPLs drafts.



 Executive Summary: I do not feel the document is ready. While there are no
 significant issues, there are several medium issues that do require
 resolution and may require some rework of the document. The document does
 follow RFC 7227 guidelines.



 Significant Issues:

 ·         None. The document generally follows the requirements set forth
 in RFC 7227 for new DHCPv6 options and seems reasonably straight forward
 to implement from the DHCPv6 client and server perspective.



 Medium:

 ·         General - This is one of the few options that is not a singleton
 (see RFC 7227, section 16). The use of multiple options seems appropriate
 here. However, it would be best to clarify that clients (section 2.2) and
 servers (section 2.4) must be able to support multiple instances of this
 option.

 ·         In section 2.6 (Operational Considerations), the text is a bit
 odd. Why should a parameter set not be updated more often than twice the
 Information Refresh Time? Explain updated were (on the server by an
 administrator or ?). Also, how does the failure to refresh the option play
 with text in section 2.3 that indicates a missing option means to keep the
 previously communicated settings? Perhaps defining what “failure to
 refresh” means (i.e., I think it refers to lack of a DHCPv6 server
 response to a Renew or Information Request). Note also that Information
 Refresh Time is only applicable to Information-Request messages (see RFC
 4242) so work may be needed as to how this this sections relate to
 Renew/Rebind operations?

 It would improve this section if it was clear as to WHOM the Operational
 Considerations listed apply? And, if these are mostly with respect to
 Client behavior, why not include in section 2.2 or 2.3?

 ·         In section 2.3 (MPL Forwarder Behavior), perhaps this is clear
 to people using this draft (and perhaps it should be added in 2.1 – see
 nit comment below) as to exactly what this MPL Domain Address is and how
 it matches something (does the receipt of an option with an MPL Domain
 Address cause the creation of a new domain or is this something that must
 have been previously configured via some other means). Perhaps this is
 discussed in [I-D.ietf-roll-trickle-mcast]; if so perhaps an appropriate
 reference is useful?

 ·         I assume Appendix A is intended to be dropped when published as
 an RFC? So:

 o   I would recommend swapping appendix A and B as I assume B is intended
 to stay as part of the RFC.

 o   I would recommend explicit instructions to the RFC editor to remove
 the appendix.

 If you didn’t intend the appendix to be dropped, you should! The RFC is
 the final product and how it got to be an RFC is a matter of other IETF
 archives and not generally retained in the document.

 ·         In section 4 (Security Considerations), would a reference to
 [I-D.ietf-roll-trickle-mcast]’s security considerations also be
 appropriate?



 Nits:

 ·         Abstract: Would “a network can easily be configured with a
 single set of MPL parameters.” be better? (Easily at the end is somewhat
 odd?)

 ·         While 2119 allows use of MUST and SHALL interchangeable, perhaps
 sticking to MUST is better? But not a big deal.

 ·         In section 2.1, I think it would be best to include “MPL Domain
 Address” in the list of fields and describe it here?

 ·         In section 2.2 (DHCPv6 Client Behavior), 2nd paragraph – why
 would a client discard the option if the reserved bits are set? I would
 think you’d want to use a new option if you’re changing things
 drastically? But it certainly is your choice as to whether you want to do
 that. Perhaps a better reason is if one of the not-permitted values is
 used (such as 0 and ‘all-bits-set’) where are clearly reserved? 0 in many
 of these case could be bad since that would yield 0 time values? This
 really is up to you, but do think about what you might want to do any
 maintain backwards compatibility. Adding a new flag bit to the reserved
 field is probably not going to break things if existing implementations
 ignore the bit(s)? But it is always difficult to say what the future will
 hold?

 ·         In section 2.3:

 o   In 1st paragraph, “a node may fail is to join” … I think “is” needs to
 be dropped?

 o   In the last paragraph, “In the case,” … should be “In this case,”.

 ·         In Section 3 (IANA Considerations), please include the URL for
 the DHCPv6 registry (http://www.iana.org/assignments/dhcpv6-parameters).
 It just helps to reduce any possible chance of error.

 ·         In Appendix B, first sentence of 2nd paragraph, shouldn’t it be
 “sets” not set? Or something is odd about this sentence."

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  [e-mail]          |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-doi-roll-mpl-      |    Version:
  parameter-configuration            |   Keywords:
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/171>
roll <http://tools.ietf.org/wg/roll/>