Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications
"Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com> Thu, 26 August 2010 14:20 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 0B59A3A69CC for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 07:20:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.667
X-Spam-Level:
X-Spam-Status: No, score=-6.667 tagged_above=-999 required=5 tests=[AWL=-0.068, 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 gRalShsl49Dc for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 07:20:58 -0700 (PDT)
Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id BD34A3A683C for <autoconf@ietf.org>; Thu, 26 Aug 2010 07:20:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.56,273,1280703600"; d="scan'208";a="84112578"
Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 26 Aug 2010 15:21:28 +0100
Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7QELRr5028039; Thu, 26 Aug 2010 15:21:27 +0100
Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 15:21:27 +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: Thu, 26 Aug 2010 15:21:27 +0100
Message-ID: <ABE739C5ADAC9A41ACCC72DF366B719D03609914@GLKMS2100.GREENLNK.NET>
In-Reply-To: <4C767360.7050805@earthlink.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] Closing summary on consensus-call for RFC5889modifications
Thread-Index: ActFJvxhJVV4i5zaQ0GEywDfRN5ioAAAcYGQ
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>
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-OriginalArrivalTime: 26 Aug 2010 14:21:27.0713 (UTC) FILETIME=[F89BD910:01CB4529]
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: Thu, 26 Aug 2010 14:20:59 -0000
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. 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. 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). Otherwise you are asking me to prove a negative, and we know how easy that is. -- 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: 26 August 2010 15:00 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 Christopher, I didn't ask what functions YOUR routers performed. I asked what functions a node would be REQUIRED to perform in order to communicate in an ad hoc network. A host does NOT have to pick MPRs in order to forward packets to a default router. A host does NOT have to run a routing protocol in order to identify one or more default routers. A host does NOT have to run a routing protocol in order to select among network interfaces for delivering packets to one of its possibly several default routers. Surely it must be possible to have a discussion about this without meandering afar from the point. Regards, Charlie P. On 8/25/2010 8:17 AM, Dearlove, Christopher (UK) wrote: > I didn't have time to pick up all your points (and I don't > really have time even for this, so it will be brief). > > You asked what router functions the example I gave satisfied: > > - It's running a routing protocol, and actively participating in > it. For example running OLSR it picks MPRs and communicates > them. > > - When a host on that node sends a packet, it chooses which > neighbour is to be the next hop (possibly even which interface > to use to do that) in order to route correctly. > > That'll do to be going on from. > > As for what my mobile is running to pick different points of > attachment, it's running an entire UMTS protocol stack (and > a GSM one) to select between base stations. And it's a much > more asymmetric relationship than any in an ad hoc network. > ******************************************************************** 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. ********************************************************************
- [Autoconf] Closing summary on consensus-call for … Thomas Heide Clausen
- Re: [Autoconf] Closing summary on consensus-call … Jari Arkko
- Re: [Autoconf] Closing summary on consensus-call … Thomas Heide Clausen
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Emmanuel Baccelli
- Re: [Autoconf] Closing summary on consensus-call … reshmi r
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … reshmi r
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Juliusz Chroboczek
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Alexandru Petrescu
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Alexandru Petrescu
- Re: [Autoconf] Closing summary on consensus-call … Alexandru Petrescu
- Re: [Autoconf] Closing summary on consensus-call … reshmi r
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Alexandru Petrescu
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Alexandru Petrescu
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Charles E. Perkins
- Re: [Autoconf] Closing summary on consensus-call … Teco Boot
- Re: [Autoconf] Closing summary on consensus-call … Dearlove, Christopher (UK)