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