[Roll] [roll] #172 (draft-doi-roll-mpl-parameter-configuration): Describe which parameters are considered time values

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Thu, 06 August 2015 10:43 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
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 9A1971B2C6B for <roll@ietfa.amsl.com>; Thu, 6 Aug 2015 03:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E5OZyuNtRqwU for <roll@ietfa.amsl.com>; Thu, 6 Aug 2015 03:43:14 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADCD91B2C6D for <roll@ietf.org>; Thu, 6 Aug 2015 03:43:14 -0700 (PDT)
Received: from localhost ([::1]:40398 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1ZNIdj-00038F-E4; Thu, 06 Aug 2015 03:43:11 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "roll issue tracker" <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.5
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.5, by Edgewall Software
To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com
X-Trac-Project: roll
Date: Thu, 06 Aug 2015 10:43:11 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/172
Message-ID: <067.479dcc53142e0a2758cf77a95e643ee8@trac.tools.ietf.org>
X-Trac-Ticket-ID: 172
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: yusuke.doi@toshiba.co.jp, mariainesrobles@gmail.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/hVTwC1YITONxJj9W5KGlgGAlPNg>
Cc: roll@ietf.org
Subject: [Roll] [roll] #172 (draft-doi-roll-mpl-parameter-configuration): Describe which parameters are considered time values
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: 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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 06 Aug 2015 10:43:16 -0000

#172: Describe which parameters are considered time values

 From Alia Atlas 07-08, source: https://datatracker.ietf.org/doc/draft-

 In general, this draft is well-written and easy to understand.  I do have
 a few points of technical clarity that I think are important.

 First, a minor point on the "Reserved" bits.  In Sec 2.1, it says "Z (7
 bits):  Reserved.  Should be 0." and then in Sec 2.2:
 "   Clients MUST discard the MPL Parameter Configuration Option if it is
 invalid (e.g., it sets reserved bits)."  Frequently,
 Reserved bits are available for future enhancements - so setting to zero
 on write and ignoring the value on read is a useful
 default.  If these bits are really always going to be zero and interpreted
 as an error, then could you rename them to MBZ (Must Be Zero) and indicate
 in the field definition that a value other than zero is an error.   Also,
 from what I read in the rest of the draft,
 if an invalid option is received, that could cause the client to be
 removed from the MPL region.  Could you clarify in the document what the
 expected behavior is if an invalid option is discarded?  Is that like
 having no option?  Is that pretending that the client didn't get one and
 staying with the previous option?  It seems like it would be pretty easy
 to remove a client from the MPL region by flipping a bit.  I would also
 like to see better clarification of how an option is considered invalid;
 while it may seem obvious, it's these details that impact
 interoperability.  In the write-up, I don't see any indications that there
 have been interoperable implementations yet?

 Second, given that the meaning of the *_IMAX values is based on RFC6206
 (as indicated in the update history) and that the *_IMAX and *_IMIN are
 confusing values, PLEASE have a reference to RFC6206.   To continue, it
 seems that DATA_MESSAGE_IMIN and DATA_MESSAGE_IMAX have different units -
 as is explained in RFC6206 where *_IMAX is the number of doublings and
 *_IMIN is the value in milliseconds.  However, in draft-ietf-roll-trickle-
 mcast-12, Section 5.4, the definition of DATA_MESSAGE_IMIN and
 DATA_MESSAGE_IMAX and C_IMIN and C_IMAX are given as:

 "   DATA_MESSAGE_IMIN  The minimum Trickle timer interval, as defined in
       [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMIN
       has a default value of 10 times the expected link-layer latency.

    DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
       [RFC6206], for MPL Data Message transmissions.  DATA_MESSAGE_IMAX
       has a default value equal to DATA_MESSAGE_IMIN.

    CONTROL_MESSAGE_IMIN  The minimum Trickle timer interval, as defined
       in [RFC6206], for MPL Control Message transmissions.
       CONTROL_MESSAGE_IMIN has a default value of 10 times the worst-
       case link-layer latency.

    CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined
       in [RFC6206], for MPL Control Message transmissions.
       CONTROL_MESSAGE_IMAX has a default value of 5 minutes.

 Clearly, if DATA_MESSAGE_IMIN is a 16 bit value and DATA_MESSAGE_IMAX is
 only an 8-bit value, they are expected to have different ranges.
 Additionally, it's quite unclear which actually needs to be divided by
 TUNIT.  The draft describes this as happening for DM_IMIN and C_IMIN, but
 then goes on to say
   " Note that all time values (Trickle timers and expiration periods) are
    in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
    data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
    DM_IMIN shall be set to 50."

 Unfortunately, the draft doesn't describe which parameters are time values
 and apparently draft-ietf-roll-trickle-mcast-12
 has some confusion as well.  For instance, CONTROL_MESSAGE_IMAX is defined
 as a time value (5 minutes).

 I suspect that the solution here is to clarify/fix draft-ietf-roll-
 trickle-mcast-12, add references in Sec 2 to where the parameters
 are defined, indicate which are considered "time values", and clean up the
 language in Sec 2.1.

 Thanks!  It looks like a useful document to address an operational problem
 once these clarity issues are addressed.

 Reporter:                           |      Owner:
  mariainesrobles@gmail.com          |  yusuke.doi@toshiba.co.jp
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-doi-roll-mpl-      |    Version:
  parameter-configuration            |   Keywords:
 Severity:  Submitted WG Document    |

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