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.


-          Bernie Volz