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

"Alvaro Retana (aretana)" <aretana@cisco.com> Tue, 16 June 2015 00:31 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EE8EE1ACCF4; Mon, 15 Jun 2015 17:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g_tqULH9dwUt; Mon, 15 Jun 2015 17:31:44 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B9E1B37F0; Mon, 15 Jun 2015 17:31:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12710; q=dns/txt; s=iport; t=1434414704; x=1435624304; h=from:to:cc:subject:date:message-id:mime-version; bh=3lsoZem72j+G+HwtYGWjJGvXzZULNK3PYd4GIxhQt7g=; b=enA8jI5xhtLVWE8vWTHpCWxuRKb4/Hpo2W4rXK9evez9OgEkNKue98M4 QAhH5QHcXzuhztzVEHeKXqnx3V407jDKhZZJ/+RFS6c66Bab/+hzFSik1 atp9TYmGH02AGdP/ydIglPsBsvZwvaCBduxHdOhji0TQVT8CpryrQxu2L E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,622,1427760000"; d="scan'208,217";a="159755872"
Received: from rcdn-core-10.cisco.com ([]) by alln-iport-5.cisco.com with ESMTP; 16 Jun 2015 00:31:43 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com []) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5G0Vhje001260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Jun 2015 00:31:43 GMT
Received: from xmb-aln-x15.cisco.com ([]) by xhc-rcd-x12.cisco.com ([]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 19:31:43 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org" <draft-ietf-roll-mpl-parameter-configuration@tools.ietf.org>
Thread-Topic: AD Review of draft-ietf-roll-mpl-parameter-configuration
Thread-Index: AQHQp8vRQMajtavr+EaCvSKBOhrHTg==
Date: Tue, 16 Jun 2015 00:31:42 +0000
Message-ID: <D1A4F4BA.B8391%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1A4F4BAB8391aretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/JGxqhZkQ1gO09pVu0WjBql9lCwc>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, Ines Robles <maria.ines.robles@ericsson.com>
Subject: [Roll] AD Review of draft-ietf-roll-mpl-parameter-configuration
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 00:31:47 -0000


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.




  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.


  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.


  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.