Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
Yusuke DOI <yusuke.doi@toshiba.co.jp> Sun, 16 March 2014 05:28 UTC
Return-Path: <yusuke.doi@toshiba.co.jp>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3301A02BB for <dhcwg@ietfa.amsl.com>; Sat, 15 Mar 2014 22:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.839
X-Spam-Level:
X-Spam-Status: No, score=-0.839 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Er2YOojhzdEc for <dhcwg@ietfa.amsl.com>; Sat, 15 Mar 2014 22:28:01 -0700 (PDT)
Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2945E1A0033 for <dhcwg@ietf.org>; Sat, 15 Mar 2014 22:28:00 -0700 (PDT)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id s2G5Rq20003422 for <dhcwg@ietf.org>; Sun, 16 Mar 2014 14:27:52 +0900 (JST)
Received: (from root@localhost) by arc1.toshiba.co.jp id s2G5Rqkt014796 for dhcwg@ietf.org; Sun, 16 Mar 2014 14:27:52 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA14795; Sun, 16 Mar 2014 14:27:52 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id s2G5Rpxr018730 for <dhcwg@ietf.org>; Sun, 16 Mar 2014 14:27:51 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s2G5Rpqe022656; Sun, 16 Mar 2014 14:27:51 +0900 (JST)
Received: from [133.196.16.135] (ncg-dhcp135.isl.rdc.toshiba.co.jp [133.196.16.135]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id 8F8DD97D99; Sun, 16 Mar 2014 14:27:51 +0900 (JST)
Message-ID: <53253658.8010700@toshiba.co.jp>
Date: Sun, 16 Mar 2014 14:27:52 +0900
From: Yusuke DOI <yusuke.doi@toshiba.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Matthew Ryan <Matt.Ryan@nominum.com>
References: <20140313143942.7850.75117.idtracker@ietfa.amsl.com> <53224737.7090109@toshiba.co.jp> <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
In-Reply-To: <A0DCD435-A103-4F88-835F-A80B29A1AAED@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/LJzTEnnWIqM4HN-h9esQ3bLKt7M
Cc: dhcwg@ietf.org, Matthew.Gillmore@itron.com
Subject: Re: [dhcwg] Review Request (Fwd: I-D Action: draft-ietf-roll-mpl-parameter-configuration-00.txt)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 05:28:04 -0000
Matt, Thank you very much for your comment. (2014-03-15 03:05), Matthew Ryan wrote: > Having an optional fragment at the head of an option will > likely require custom code specific to this option in anything > that has to read or write it (as opposed to just relaying > it) and may be an impediment to adoption. See section 6 of > draft-ietf-dhc-option-guidelines. > > Since the only difference between the two forms is whether > the address is present or not, you should place the address > at the end of the option, and mark it as optional, as suggested > by section 5 of the option guidelines draft. > > Note that, regardless of whether you place the address at the > front of the option or the end of the option, you will not > be able to count on any particular alignment of the address, > or anything else, since there are no alignment guarantees > in the protocol (section 19 of the option guidelines draft). Sorry for confusion. The format I sent in the e-mail is what I tried to avoid some non-octet fields (P, C_K, DM_K). The version became awkward and I dropped the idea. The submitted version follows the guideline. The format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_MPL_PARAMETERS | option_len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Z | C_K | Z2 | DM_K | SE_LIFETIME | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DM_IMIN | DM_IMAX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DM_T_EXP | C_IMIN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C_IMAX | C_T_EXP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (if option_len = 32 ) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MPL Domain Address (128bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont'ed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont'ed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (cont'ed) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The draft also defines unsigned short floating point (section 2.1) for the timers. There are some reasons to define a new type: 1) Timers could be very short (*_IMIN in 10 ms.) or long (SE_LIFETIME may be in weeks) 2) Linear precision is not needed (There are no reason to say 1 week and 10ms.) 3) Packet should be short enough 4) Timer is unsigned and should be base-10 (not base-2) An unsigned short floating point: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | exp.| significand | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Timer values are significand * 10**exp in millisecond unit. If you know similar value type already used in DHCPv6, please let me know. Regards, Yusuke