Re: [Autoconf] Comments on adhoc-addr-model-00

Zach Shelby <zach@sensinode.com> Thu, 19 November 2009 11:37 UTC

Return-Path: <zach@sensinode.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A29D28C0E8 for <autoconf@core3.amsl.com>; Thu, 19 Nov 2009 03:37:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0nBfwZLMFVd for <autoconf@core3.amsl.com>; Thu, 19 Nov 2009 03:37:04 -0800 (PST)
Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 22C083A6A35 for <autoconf@ietf.org>; Thu, 19 Nov 2009 03:37:03 -0800 (PST)
Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nAJBaumh027215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Nov 2009 13:36:57 +0200
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Zach Shelby <zach@sensinode.com>
In-Reply-To: <25c114b90911190253ra808d8cwc80c27efcc1ab065@mail.gmail.com>
Date: Thu, 19 Nov 2009 13:37:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB5E57FD-B8D4-4A4C-9BC3-12A7C50645D9@sensinode.com>
References: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> <25c114b90911190253ra808d8cwc80c27efcc1ab065@mail.gmail.com>
To: Ulrich Herberg <ulrich@herberg.name>
X-Mailer: Apple Mail (2.1077)
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Comments on adhoc-addr-model-00
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2009 11:37:05 -0000

Ulrich,

On Nov 19, 2009, at 12:53 , Ulrich Herberg wrote:

>> 2. I like the "link of undetermined properties"... however you might want to point to a document like draft-baccelli-multi-hop-wireless-communications to point out why links end up like that. RFC4861 also explains that a link might be non-transitive, so that could also be referenced.
> 
> I agree that the baccelli draft is very useful. I am undecided on
> whether to include a reference to that draft in the address model.
> While I think it could be very useful as a rationale for the address
> model, I also understand that the chairs are afraid of going this
> direction. The reason is that autoconf is only chartered for a single
> document, namely the address model. We are already years behind
> schedule. Producing a second document -- and including a reference
> from the address-model ID -- which we are not chartered for, could be
> difficult to argue for in the IESG.

Yep, makes sense. So instead just summarize the reasons why such a link might be categorized like this with a short paragraph in the adhoc-addr-model document. You may still point at RFC4861, as non-transitivity is mentioned there as well.

> 
>> 6.  The second bullet point of Section 6.2 needs some expansion not to be misunderstood. In addition to the existing sentence, also add text like: ", unless an assumption can be made about connectivity in which case the prefix may be /64." The point being that if you can assume connectivity with a router (who somehow advertises a prefix), you may be able to autoconfigure an address using a shared prefix. This is what we do in 6lowpan.
> 
> 
> One could argue that this is already implicit due to the sentence in section 3:
>   "When more specific assumptions can be made regarding the connectivity
>   between interfaces, these SHOULD be considered when configuring
>   subnet prefixes."

Right, so there could be a pointer to Section 3 at least in that bullet point to remind the reader of this exception? 

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.