[Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration

["Alvaro Retana (aretana)" <[e-mail]>]

Hi!

I just finished reading this document.

I think the document is almost ready to move forward — I have one major comment (below) related to sending the Option as it relates to the potential of mismatched options.  I am going to start the IETF Last Call, but expect at least a discussion about that comment before putting the draft in front of the IESG.

Thanks!

Alvaro.


Major:

  1.  Sending this Option.  It is "RECOMMENDED that all MPL Interfaces attached to the same link of a given MPL Domain use the same values for the Trickle Parameters” (I’m quoting draft-ietf-roll-trickle-mcast because it is not a MUST, even though rfc6206 talks about “unintended behaviors”).   This document says  (Section 2.4) that "the server will send MPL Parameter Configuration Option only if configured…and the client requested it”..and (Section 2.2) says that a client "MAY request MPL Parameter Configuration Option”.  In summary, the server won’t send the Option unless the client requests it; is that what is intended?  Furthermore, the request is optional (I’m assuming there may be resource considerations here), so there may be cases in which not all clients request the Option, resulting in potentially mismatched parameters.  Am I interpreting the text correctly?  If so, why was it specified this way (instead of having the server send the Option (when configured for a specific MPL Domain) always?  Does the client then require configuration to be able to request the additional configuration parameters?
     *   I don’t necessarily want to change the behavior proposed, as I’m assuming it has been discussed in the WG and there are good reasons behind it.
     *   Instead, I would like to see some discussion about it  in the Operational Considerations section.  Pointing to rfc6206 may be enough to remind people who are implementing this Option.
     *   Related to this point: I recommend moving the discussion in Appendix B to the Operational Considerations section.

Minor:

  1.  Section 1 (Introduction): "Some managed wireless mesh networks may have a DHCP server to configure network parameters.”  How common is the use of DHCP?  “Some..may” doesn’t sound like this extension will be used a lot.  How do other networks configure their parameters?  I’m assuming manually..
  2.  Section 2.1. (MPL Parameter Configuration Option Format).  The descriptions of the fields need to be very specific, specially if invalid contents are to be discarded (per 2.2 and rfc7227).
     *   When is P set?  It may be obvious that it is set when PROACTIVE_FORWARDING is TRUE, but please specify it.
     *   TUNIT: "Unit time of times”, what does that mean?
     *   DM_T_EXP/C_T_EXP: DATA_MESSAGE_TIMER_EXPIRATIONS/CONTROL_MESSAGE_TIMER_EXPIRATIONS are defined as the number of expirations, so how do you end with ms?
     *   The "MPL Domain Address” field is not defined.
  3.  Section 2.3 (MPL Forwarder Behavior)  Joining and leaving the domain.  I must be missing something..
     *   "the node MAY join the MPL domain given by the option”  Why would the client request the Option and then not join the domain?
     *   "A node MAY leave from an MPL domain..”  The conditions seem to say that the domain in the Option changed, is that true?  If the domain in the option changed, why would the node not leave the domain?
  4.  Section 4. (Security Considerations)  Please include references and comments (where needed) to the security considerations in rfc3315 and rfc7227.

Nits:

  1.  The word “draft” is used in a couple of places to refer to this document and MPL; use “document” instead.
  2.  Section 2 (MPL Parameter Configuration Option) s/there are following 10 parameters/there are the following 10 parameters
  3.  2.5. (DHCPv6 Relay Behavior).  A reference to rfc6422 would be nice.
  4.  Section 2.6. (Operational Considerations) "A parameter set for an MPL domain SHOULD NOT be updated more often than two times of expected refresh interval.”  I’m assuming that the “expected refresh interval” is Information Refresh Time, right?  If so, please call it what it is.
  5.  I would consider rfc7227 a Normative Reference.