[mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 30 March 2012 12:36 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4467021F8702 for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 05:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.141
X-Spam-Level:
X-Spam-Status: No, score=-9.141 tagged_above=-999 required=5 tests=[AWL=1.108, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4dXx2LW-CZc for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 05:36:52 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 08D8F21F86BA for <mif@ietf.org>; Fri, 30 Mar 2012 05:36:51 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q2UCapRM006401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Fri, 30 Mar 2012 14:36:51 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q2UCaoob003128 for <mif@ietf.org>; Fri, 30 Mar 2012 14:36:51 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q2UCaoRx018281 for <mif@ietf.org>; Fri, 30 Mar 2012 14:36:50 +0200
Message-ID: <4F75A8E2.1010606@gmail.com>
Date: Fri, 30 Mar 2012 14:36:50 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: mif <mif@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: [mif] Summary issues after meeting, draft-ietf-mif-dhcpv6-route-option-04
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2012 12:36:53 -0000

We discussed on the email list and at the meeting about issues related
to draft-ietf-mif-dhcpv6-route-option-04.

The following issues were presented during the meeting:

> MAC address not configured
>
> Answer: it doesn’t need to be. MAC derived via ND.

This is not what was said on the email list, and even less at the mic.
On the mailing list, the range of comments were from "no MAC" to "maybe
MAC".  To me the latter seemed more agreed.

> Lifetime is 32, not 16 bits
>
> Answer: Does not appear to be a problem, timing calculation is OS
> dependent, but it is done on 32 or 64 bit counters.

In the recent emails on the mailing list there seemed to be convergence.
  But not the way you mention it.

At the mic there seemed to exist as many supportive comments of doing
lifetime (be it 16 or 32) as of doing no lifetime at all.

In addition, the following issues were listed by email, with discussion.

1. Separate specific routes from default routes.
    Authors disagree with me, and Ted agrees with authors.

2. Message size better be smaller.
    Author indicates the length is 30bytes by now.
    But I'd suggest it could be 20bytes if the encoding were not split
    as nexthop-prefixoption (as is now).

3. Only one default route?
    Discussion seems to indicate that maybe the presence of several
    default routes would be in scope here.  And if coupled with a novel
    source address selection scheme may constitute new work maybe 6man.

Alex
PS: Chairs, if you believe I should stop tracking these issues then
     please let me know.