Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications

"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Fri, 27 August 2010 08:26 UTC

Return-Path: <Chris.Dearlove@baesystems.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 62AFA3A6B6E for <autoconf@core3.amsl.com>; Fri, 27 Aug 2010 01:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.666
X-Spam-Level:
X-Spam-Status: No, score=-6.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 BcL9S-cPdtrL for <autoconf@core3.amsl.com>; Fri, 27 Aug 2010 01:26:29 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id AD6043A699C for <autoconf@ietf.org>; Fri, 27 Aug 2010 01:26:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,277,1280703600"; d="scan'208";a="84234501"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 27 Aug 2010 09:27:00 +0100
Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7R8QxGA010316; Fri, 27 Aug 2010 09:27:00 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 09:26:59 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Date: Fri, 27 Aug 2010 09:26:58 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D03609AE8@GLKMS2100.GREENLNK.NET>
In-Reply-To: <4C773080.8010601@earthlink.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications
Thread-Index: ActFl7YnX0ea92nMS465kqZlbAaEQQAKGXVQ
References: <AANLkTi=MZORvNSW7wHdHYOzkOwNZojBars26GfSPgWc9@mail.gmail.com> <ABE739C5ADAC9A41ACCC72DF366B719D035CA5CE@GLKMS2100.GREENLNK.NET> <4C741EBB.8060909@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D03609170@GLKMS2100.GREENLNK.NET> <4C75308C.1090506@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D036094AB@GLKMS2100.GREENLNK.NET> <4C767360.7050805@earthlink.net> <ABE739C5ADAC9A41ACCC72DF366B719D03609914@GLKMS2100.GREENLNK.NET> <4C773080.8010601@earthlink.net>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-OriginalArrivalTime: 27 Aug 2010 08:26:59.0629 (UTC) FILETIME=[9E4185D0:01CB45C1]
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications
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: Fri, 27 Aug 2010 08:26:30 -0000

I'm failing to see how any of the examples you quote (which I
agree, would not make a node a router) are sufficient for all 
of the functionality I noted. I really would like (but I'll
be unable to reply to for at least some days - it's a long
weekend coming up) to know how you get the functionality.
Ideally I'd like equivalent functionality to the OLSR example,
what I wouldn't count is where a host node is permanently
(albeit wirelessly) attached to a single other router node.
How far from the latter and close to the former can you get?
(I can see how to get from the one permanent point of
attachment to occasionally changing that, with transients,
using Mobile IP.)

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Charles E. Perkins [mailto:charles.perkins@earthlink.net] 
Sent: 27 August 2010 04:27
To: Dearlove, Christopher (UK)
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Closing summary on consensus-call for
RFC5889modifications


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
 

Hello Chris,

I'm responding again, because I'd like to have a fruitful
discussion.

On 8/26/2010 7:21 AM, Dearlove, Christopher (UK) wrote:

> This started from the specific example, so that is clearly quite
> to the point. You may now be discussing other cases, but that's
> another matter.

Do you mean the specific example of your nodes running
OLSR and identifying MPRs?  I'm happy to agree that your
nodes are routers.

If I discussed other cases, it was only to reach the
goal of identifying the boundary between hostness and
routerness.  Is that sufficiently to the point?


> If by a node we mean a physically separate entity (in a
> wireless network) and if we allow that node to be independently
> mobile and to connect to other nodes (otherwise it's not really
> an ad hoc node) and it is to be unicast reachable from elsewhere
> in the network via one of those other nodes, then it has to be
> running something.

Obviously...  it's running some computer programs.

If a node runs ARP, is it a router?

>             It's for you to indicate what that something
> is and why that isn't a routing protocol, despite having some
> (agreed, not all) routing functions, and how it will work in a
> MANET with wireless links (with the usual non-transitive
> properties).

I already mentioned several examples.  Should I do it
again?  What about a node running ND?  What about a node
snooping the airwaves?  What about a node running Mobile IP?
I've just scratched the surface of examples.  In fact
I'll even play dirty and keep you in suspense to wait for
a new Internet Draft I am co-authoring on this subject.

> Otherwise you are asking me to prove a negative, and we know
> how easy that is.

I'm asking you to accept that a node can beneficially
reside in an ad hoc network without being a router.
What is negative about that?

Unless I completely misunderstand your point of view,
this is not in any way asking you to prove a negative.
Of course it is possible to prove a negative proposition.
But, I have not asked you to do so.  Or, what negative
proposition do you believe I have postulated for your
consideration?  If I put "not" in any point of discussion,
have I exceeded my boundaries of feasible communication?

Regards,
Charlie P.





********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************