Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)

"Bernie Volz (volz)" <> Mon, 07 July 2014 17:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 373F81A014C; Mon, 7 Jul 2014 10:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tuI2pZwEpIcT; Mon, 7 Jul 2014 10:19:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AB611A02EF; Mon, 7 Jul 2014 10:19:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2168; q=dns/txt; s=iport; t=1404753552; x=1405963152; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9B0EsN0ekVZokkeaJiz2S9FHwNZb8jvNoX1FT+zWCRo=; b=YTSnOUEy6b8wXu8hY3ivom4WHGOCFXXI+DdGM7RrqIk6IWNeBsHISwzd Gs3Z4ZjfYIRqNC3o5WfsgVskNuAV86Q6/PhGn27SaNVJBRjWm3KOo+J4W dY1zlcwiWynyQpRIVJtSdswBvN6SNzUbQ2BKtYYAAlhwWEyrEyfYwlrT6 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,619,1400025600"; d="scan'208";a="58876672"
Received: from ([]) by with ESMTP; 07 Jul 2014 17:19:11 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s67HJBYM031148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Jul 2014 17:19:11 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Mon, 7 Jul 2014 12:19:11 -0500
From: "Bernie Volz (volz)" <>
To: Andre Kostur <>, Yusuke DOI <>
Thread-Topic: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)
Thread-Index: AQHPmgEd2TBAYfQHIEyalFuCcQCzlpuU2QvA
Date: Mon, 07 Jul 2014 17:19:11 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 07 Jul 2014 10:19:47 -0700
Cc: "" <>, Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] [dhcwg] MPL config draft (Re: I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Jul 2014 17:19:14 -0000


Not sure I'd suggest adding 10 (or 11) options for this?

But I certainly would suggest, as Andre did, much simpler values - flags and "compressed" data just make for much more complex and error prone processing on both client and server. A structure which would have all these values but in a much more standard set of data formats would be better.

Perhaps there is a middle grown to have groups of values (i.e., have 3-4 options)? I'm really not that familiar with MPL, but perhaps there are some logical groupings that make sense (seems that there are data and control messages would could be one logical separation).

Might also be nice in the Abstract to define MPL? 

- Bernie

-----Original Message-----
From: dhcwg [] On Behalf Of Andre Kostur
Sent: Monday, July 07, 2014 12:32 PM
To: Yusuke DOI
Cc:; Routing Over Low power and Lossy networks
Subject: Re: [dhcwg] MPL config draft (Re: [Roll] I-D Action: draft-ietf-roll-mpl-parameter-configuration-01.txt)

A couple of quick thoughts (keeping in mind RFC 7227 - Guidelines for Creating New DHCPv6 Options):

- An encoded option is frowned upon.  Split all of those into separate options, and the "Reserved" parts simply disappear.  A "sub-optioned"
option is also frowned upon (section 9, RFC 7227).
- Why add the additional complexity of the floating point?   Why not
use a 32-bit unsigned integer representing milliseconds which gets you a little over 40 days?  Not the 18 weeks that you currently can represent, but is there a practical use for timers over a month long in MPL?
- If you do go with separate options, consider what it would mean if certain options don't exist.  ietf-roll-trickle-mcast appears to define defaults, perhaps reference that draft to say that if an option is missing, the client is to use the default defined in that draft?
- Speaking of RFC 7227...  I-D.ietf-dhc-option-guidelines got published in May

Andre Kostur

dhcwg mailing list