Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 05 August 2010 17:57 UTC

Return-Path: <charles.perkins@earthlink.net>
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 0EB213A6B36 for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 10:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599]
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 JY-nBn7RPpfB for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 10:57:35 -0700 (PDT)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id CF44F3A6A7D for <autoconf@ietf.org>; Thu, 5 Aug 2010 10:57:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ubvk+lQGudu4giKYPWD7k9NUqm2HiAfPMggxanqpmnHTBOjrxATylPW0nIEK8Yht; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Oh4he-0007Hq-VD; Thu, 05 Aug 2010 13:58:04 -0400
Message-ID: <4C5AFB9F.3040206@earthlink.net>
Date: Thu, 05 Aug 2010 10:57:51 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
References: <4C528979.7010006@oracle.com> <201008040756.04650.henning.rogge@fkie.fraunhofer.de> <4C596602.1060308@earthlink.net> <201008051039.03011.henning.rogge@fkie.fraunhofer.de>
In-Reply-To: <201008051039.03011.henning.rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5236d1d18acb711b6850ba8845406fe08c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)
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, 05 Aug 2010 17:57:36 -0000

Hello Henning,

Comments/follow-up below...

On 8/5/2010 1:38 AM, Henning Rogge wrote:

>> What if your host gets an address by running
>> "autoconf.exe", which is not a routing program?
> Does your host set up a route towards the next router and maintains it if the
> topology data from the router changes ? If yes I would say it's a primitive
> router too. If no, it's not.

What if it treats a particular route table
entry as a point-to-point link?  What if it
treats a particular route table entry as a
default route?  What if it hears a RA
message from a neighbor?

Seems to me we're having to bend over backwards
to call things "routers" in order to justify
making a wrong name for the document.


>> What if the host does not?  Or, do you mean to say
>> that this discussion is a way to legislate that all
>> hosts must use DHCP?
> I don't think I ever said this. I just presented an example that the address
> model is not necessary for running a node in a MANET that use the autoconf
> address model.
>
> Yes, you CAN use it... but you don't need to.

I'm glad to hear that.  But some hosts are still going
to have to abide by the autoconf addressing model, unless
unnecessary restrictions are put into place.  Changing the
name of the document, it seems to me, increases the danger
that these unnecessary restrictions _will_ be enacted.


>>  ...  suppose at some point there is an autoconf.exe.
>> It should be a way for a host to get an address.
>> Its connection to the MANET would, presumably allow
>> it to use this address.  Or, do you mean to say that
>> "address allocation" == "connection"?

> I don't see any reason why an autoconfiguration protocol developed by this
> group would only run on interfaces of routers.

I'm glad to hear that.  So why make the restriction on
the document name??

>
>>> If you have a router with a policy that limits the routers functionality
>>> (in terms of the routing protocol), you could just write a
>>> compact/optimized version of the needed software part for it.
>>
>> main()
>> {
>> 	system ("get_address");
>> 	if (routing) fail();   /* My compact routing code */
>> }
>>
>> Am I a router?
> I don't see any routing code of a routing protocol. But I don't see your
> problem too.

I'm sorry you don't like my routing code.
Wasn't it claimed that a node can be a router
even if it always advertised  willingness  ==  0?

My problem is that in order to justify the restrictive
title, some people are bending over backwards to call
darned near anything a router.


>> This is a political argument not based on the needs
>> of the addressability, connectivity, or goals of
>> making an ad hoc network.  Insofar as you may be
>> nonetheless correct, I begin to believe that I have
>> zero insight into the technical goals of the discussion.
>>
>>> (I don't say they are right, but we will get people with strange comments
>>> on the address model with both titles)
>>
>> Please tell me if my comments are "strange".

> I think the problem you stated is that people can say "the title says it's
> only for routers, so it is not enough for my usecase and I need something
> different".

_my_ usecase??  My usecase is that hosts should be
able to get addresses.  Do you think this is a
corner case?


> If we not change the title we might get "the title says it's for all nodes,
> but I cannot force my users to install a special interface configuration on
> their smartphones, so I need something different."


Using this argument, we must immediately
destroy the great majority of IETF protocol
specifications.


> There are nodes in MANET that are a grey area between host and router. Because
> of this we cannot make a clear statement on what nodes the autoconf address
> model should be used.


As far as I can recall, no one has made ANY nonpolitical
argument to indicate why hosts do not adhere to the addressing
model for [autoconf].  Do you remember any?


> Most of the WG seems to think it's better to restrict the scope a little bit
> more and let people use it for other things than the defined scope if they
> think it's right (at least that's how I understand the consensus of the
> group).


I still think it's silly to make an [autoconf] protocol
that is prohibited for use by hosts.  Of course, any host
that wanted to use it would have to actually execute the
code -- isn't that a tautology?  So the smartphone point
has absolutely zero force in making this determination.

I do not understand the consensus of the group.  I only
speak for myself, and I'm honestly trying to see if there
is even an iota of technical justification for this change.
I might be wrong!  But until you or someone enlightens me I'll
still need to try to understand the relevance of your points.

Regards,
Charlie P.