From emmanuel.baccelli@gmail.com Fri Jun 1 03:27:02 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F207F21F867E for ; Fri, 1 Jun 2012 03:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 j0kzI8Z+Nvw9 for ; Fri, 1 Jun 2012 03:27:02 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB3B21F867D for ; Fri, 1 Jun 2012 03:27:02 -0700 (PDT) Received: by qabj40 with SMTP id j40so317449qab.15 for ; Fri, 01 Jun 2012 03:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=0ZgiyytwchkUx6z7KJ60rdyLWqOFBITi5gNpej8HrLM=; b=r1OYjVyMJ8ZEYl1dYEMMP7Vrm6AMDcAVFp+8O1NKdcYq8QR+CiPpfcpy+kyO3XQUwH t6A/qUAvx705j8QkjVflbaN4tej0qVpQJA44h7USB6x6GAIPMdazjDbcqKsJJloKRJv/ hKtZLcKBOmTju7xEUqkmA9hnMbPTHdXy5L3hRInqaA7QWTovr0n6DM52EoagBCieIhS0 wJoZ+AmcMagbnIV8wvIypUtCbF71ELyX52c4IE57grTDCA7Y3DsFIvA9xX1yynsZKZzk lthvA9eVRxGUlbq/tsV1SFdr+0KjpTk+J6q0RTCFRjhyZJU25+0RKtAE7K/lbRqYrhL+ l9/w== Received: by 10.224.72.210 with SMTP id n18mr3659570qaj.10.1338546421697; Fri, 01 Jun 2012 03:27:01 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.222.18 with HTTP; Fri, 1 Jun 2012 03:26:40 -0700 (PDT) In-Reply-To: References: From: Emmanuel Baccelli Date: Fri, 1 Jun 2012 12:26:40 +0200 X-Google-Sender-Auth: CG_7sidTH1UXjSy-sCZsXFveOc0 Message-ID: To: manet Content-Type: multipart/alternative; boundary=20cf306f72fcfb0d4f04c1669f32 Subject: Re: [manet] draft-baccelli-manet-multihop-communication-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 10:27:03 -0000 --20cf306f72fcfb0d4f04c1669f32 Content-Type: text/plain; charset=ISO-8859-1 Hi Abdussalam, On Thu, May 31, 2012 at 10:24 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > > > What is the different between : a) specific IP interface > configuration, as described in RFC 5889, and b) specific routing > protocols running on these interfaces, such as > [RFC3626], [RFC3561], [RFC5449] ? > > The difference is quite self-explanatory. On one hand RFC 5889 describes default rules that should apply when assigning IP addresses/prefixes to an interface on a wireless multihop network (for instance, a MANET). On the other hand RFC3626, RFC3561, and RFC5449 specify each a routing protocol, that can function on a wireless multihop network. regards, Emmanuel --20cf306f72fcfb0d4f04c1669f32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Abdussalam,


On Thu, May 31, 2012 = at 10:24 PM, Abdussalam Baryun <abdussalambaryun@gmail.com>= ; wrote:


What is the different between : a) specific IP interface
configuration, as described in RFC 5889, and b) specific routing
protocols running on these interfaces, such as
[RFC3626], [RFC3561], [RFC5449] ?


=A0
The differen= ce is quite self-explanatory. On one hand=A0RFC 5889 describes=A0default ru= les that should apply when assigning IP addresses/prefixes to an interface = on a wireless multihop network (for instance, a MANET). On the other hand= =A0RFC3626,=A0RFC3561, and RFC5449 specify each a routing protocol, that ca= n function on=A0a wireless multihop network.

regards,

Emmanuel
<= /div> --20cf306f72fcfb0d4f04c1669f32-- From abdussalambaryun@gmail.com Fri Jun 1 04:11:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2B21F8658 for ; Fri, 1 Jun 2012 04:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.107 X-Spam-Level: X-Spam-Status: No, score=-3.107 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] 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 5tMFa2h2Cod4 for ; Fri, 1 Jun 2012 04:11:57 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02C21F8646 for ; Fri, 1 Jun 2012 04:11:57 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1345297vcq.31 for ; Fri, 01 Jun 2012 04:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tiHfejD83uqyCHu6G4ed2IwYZovdzBGsSaYLiIS2wAA=; b=oDJg37FXw1J4sQEIe+xPYmwRffnDhTWKCNIA4DdEf4LVznkZpypH+/st2XaDJiG8e+ nj0xzWRgRi9KsUfWVxGJonNlLJfb8KN5tpyxAhd6Aj0BU2mPu+3IlCReol2flTZoC+z1 Qk8GIo6DxLXJHvOiZTG14IaPMet3PzlwX1vSnpDBQ4l3GauAH/EbQwfCb6Dyv6VWh8Ky unMwDxCRmrDnJkpdJOhUhc/5cpWOfjI9iwCTw5tl4r1BTl4nntR+RnzphzhUsqxYteqk nYoVk0aM22CiFn/amygW/i8C3A/lBlc/hb+0MdIxIuxt9WliRxHJq8BfA6MMUeK9xTby 6sVA== MIME-Version: 1.0 Received: by 10.220.150.205 with SMTP id z13mr1999441vcv.19.1338549116549; Fri, 01 Jun 2012 04:11:56 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 1 Jun 2012 04:11:56 -0700 (PDT) Date: Fri, 1 Jun 2012 13:11:56 +0200 Message-ID: From: Abdussalam Baryun To: Don Sturek , "Charles E. Perkins" , manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Comments For AODVv2 (manet-dymo-22) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 11:11:58 -0000 Hi Charlie, Don, and All I want to add another optional enhancement for this Integrated-Network (LLN+MANET=I-NET); 5) the node ability (energy consumption issue, routing issue, and environment-event issue), it is good for some originators to know the node ability ( to route, or continue to route, minimal-routing, or node-survive, or other abilities), but not sure if it is available in the DYMO nor sure if it can make side effects to performance. The node-ability may be joined with enhancement-1 or -2, in their tables or some technique. To trad-off among points of the Don's enhancement-points and Charlie's protocol-issue-points Protocol Enhancements >>>> 1) Neighbor table management supported by exchanging one hop messages >>>> containing LQI between one hop neighbors. This would be nicely supported >>>> via Packet BB. >>>> 2) Pruning of neighbor table entries to ensure two way communication >>>> (allows for use of forward routing path as the return routing path) >>>> 3) Multicast route replies from data sink devices (many to one feature) >>>> 4) Optimization of route tables to reduce size (have a look at AODV Jr in >>>> SourceForge) Protocol-Issues >>> 1. protocol complexity >>> 2. packet size >>> 3. neighborhood detection the simplicity is needed within all LLN-routers but not important in some MANET-routers, therefore, node-ability is good to be known between neighbors to enhance the overall I-NET performance. The routing-overheads is always the issue in ad hoc nets, but using multicast, and anycast will help alot in the I-NET. Regarding neighborhood detection and enhancement-1&2, I think DLEP or underlaying detections may solve it for the MANET-routers, but these solution may not apropriate for LLN-routers. In conclusion, AODV-network multihop management-optimizations are able to be simplified if the protocol recognises different node/router abilities. Regards, Abdussalam Baryun University of glamorgan, UK ( One may be wrong, or may be right, but it does not matter if we work as a group to discuss and resolve all issues ) ******************************************************************** 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. ******************************************************************** ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/31/12, Don Sturek wrote: > Hi Charlie, > > I think updating AODV would be a great idea. We have some experience with > AODV in a commercial deployment. Here are some enhancements to consider: > 1) Neighbor table management supported by exchanging one hop messages > containing LQI between one hop neighbors. This would be nicely supported > via Packet BB. > 2) Pruning of neighbor table entries to ensure two way communication > (allows for use of forward routing path as the return routing path) > 3) Multicast route replies from data sink devices (many to one feature) > 4) Optimization of route tables to reduce size (have a look at AODV Jr in > SourceForge) > > Overall, AODV has many benefits that would be useful as an enhanced RFC. > > Don > > From: "Charles E. Perkins" > Organization: Saratoga Blue Skies > Date: Thursday, May 31, 2012 8:47 AM > To: Abdussalam Baryun > Cc: manet > Subject: Re: [manet] A view on packet-BB > > Hello Abdussalam, > > DYMO was exactly designed as "AODVv2" and "DSRv2". The source routing > feature > of DSR was renamed to be "Path Accumulation". We did a lot of testing and > discovered > that path accumulation was strangely unhelpful for improving performance. > There > may be circumstances for which accumulating a source route is advantageous > for > routing, but they haven't been clearly articulated to my knowledge. On > the > other > hand, accumulating a source route does present advantages for security. > > After a too-long hiatus in progress with DYMO, I had found that AODV had a > lot better name recognition and I thought, with some encouragement from > other > people, that since path accumulation was no longer mandated, there was > much > to be gained by reverting to the better-recognized name of AODV, but with > the > clear intention of aligning the protocol with recent experience. > > The value of having one standard reactive protocol instead of two > experimental ones is, in part, to make it easier for customers to know > which protocol to use. This is still a good idea, regardless of various > specializations that have occurred. > > Regards, > Charlie P. > > > On 5/31/2012 4:30 AM, Abdussalam Baryun wrote: >> >> Hi Charlie, and All >> >> I don't mind to have DYMO and AODVv2 without divergence, just from the >> protocol name and draft-understanding, DYMO was derived from AODV+DSR, >> and >> from the change of name to AODVv2 it made me think more about the >> extending of >> AODV. Therefore, I may suggest that it is interested to see DSRv2 ( which >> I >> thought new DYMO may take that direction), and was thinking if the authors >> of >> DSR or others in WG are happy to extend that protocol. >> >> If we can get a new DSRv2 that is able to use RFC5444 or use a modified >> format >> of RFC5444, it will be great. Because if OLSRv2-15 is now deleting its >> source-routing option as was included in OLSRv2-14, and AODVv2 is not >> doing >> source routing, then it is interested to have a routing protocol that is >> able >> to source route. >> >> >> >> Abdussalam Baryun, >> >> University of Glamorgan, UK. >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> On Wed, May 30, 2012 at 8:12 PM, Charles E. Perkins >> >> wrote: >> >>> >>> Hello folks, >>> >>> I think it's a good idea to enable alternate metrics in AODVv2/DYMO >>> and for LOADng for that matter. In fact, LOADng already has a form of >>> alternate metric. >>> >>> >>> On 5/29/2012 6:07 AM, Abdussalam Baryun wrote: >>> >>>> I have another thought for AODVv2 and RFC5444 (some call it >>>> packet-bb). I think it is possible to change hop-count-distance to >>>> metric-type in AODVv2, and to add metric-type in the RFC5444 (modified >>>> format) if you think it is better for the protocol, this is a way that >>>> makes AODVv2 more different than LOADng. Having in mind not to worry >>>> about using any RFC now, because any update to a RFC or draft is >>>> possible but as long as it is convensing and discussed on the list. >>>> >>> >>> >>> Check. >>> >>> >>> >>>> >>>>> to be clear, we can standardize AODVv2 *with* packet-BB >>>>> right now, and submit for consideration another document for >>>>> AODVv2 that does not require packet-BB. Or, we can enable both >>>>> ways in the next revision. Or, we can standardize AODVv2 >>>>> that does NOT use packet-BB, and then submit for consideration >>>>> another document that DOES use packet-BB. All cases are just >>>>> fine with me, depending on what the working group wants. >>>>> >>>> In MANET reactive protocols may be good idea to have DYMO without >>>> 5444-format (special formats for DYMO), and AODVv2 with using >>>> modified-5444-format (as below suggestion of adding metric-type), and >>>> LOADng fully using RFC5444. So we may join LOADng in MANET. >>>> >>> >>> >>> >>> I understand this point. However, I have always believed that AODV is >>> also >>> applicable for LLNs and sensor networks. Previous work to focus AODV >>> for >>> better performance in specific networks has produced quite interesting >>> and >>> good results. It would have been very appropriate to bring these >>> modifications >>> into the [manet] WG for adoption into the evolved WG documents. Making >>> an oversimplification, it seems that the areas where DYMO/AODV have >>> been >>> viewed as inadequate for networks with reduced-functionality nodes are >>> mostly as follows: >>> 1. protocol complexity >>> 2. packet size >>> 3. neighborhood detection >>> >>> 1) is clearly an area where discussion in [manet] should have happened, >>> and is happening now thanks to LOADng development >>> 2) is a problem sometimes difficult to solve in the IETF >>> 3) was mostly resolved by specifically enabling DYMO/AODVv2 to use >>> any appropriate neighborhood detection algorithm. In fact, this >>> was >>> always possible even with AODV, but somehow the HELLO messages >>> were viewed as a central part of AODV even after the publication of >>> SMURF and other related efforts. >>> >>> In particular I would not be happy to see any divergence between a >>> protocol >>> named "DYMO" and a protocol named "AODVv2". >>> >>> Regards, >>> Charlie P. >>> >> >> >> > > > > -- > Regards, > Charlie P. > > _______________________________________________ manet mailing list > manet@ietf.org https://www.ietf.org/mailman/listinfo/manet > > From internet-drafts@ietf.org Fri Jun 1 13:26:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5221F8745; Fri, 1 Jun 2012 13:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 69Qlow4qTkHG; Fri, 1 Jun 2012 13:26:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B7E21F8739; Fri, 1 Jun 2012 13:26:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120601202619.24432.15010.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2012 13:26:19 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-14.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 20:26:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Mobile Ad-hoc Networks Working Group = of the IETF. Title : Definition of Managed Objects for the Neighborhood Disco= very Protocol Author(s) : Ulrich Herberg Robert G. Cole Ian D Chakeres Filename : draft-ietf-manet-nhdp-mib-14.txt Pages : 64 Date : 2012-06-01 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects for configuring parameters of the Neighborhood Discovery Protocol (NHDP) process on a router. The MIB module defined in this memo, denoted NHDP-MIB, also reports state, performance information and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues during neighbor discovery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-14.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ From abdussalambaryun@gmail.com Sat Jun 2 01:02:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8AF21F8A4E for ; Sat, 2 Jun 2012 01:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cj8NP9tsnbHI for ; Sat, 2 Jun 2012 01:02:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93E21F8A4D for ; Sat, 2 Jun 2012 01:02:44 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1922722vcq.31 for ; Sat, 02 Jun 2012 01:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DZJA/075JDn+yDvaLTKcTcFKahrrk8XIhcdir2RE3qM=; b=IBQNZo8i8LTpDXcC7icSTexMPeW0YcB4Db75/FYPXz3/75wAnNUQB5JMWIA3KjbJ+C TN/p7GibALzsZOElL0uVi+TZKzT5CTy+h0MIYUsUOh4y8NawbJatBOox+siTFcL//Xpm zMt5cQ3WOKgj9aJU8nle5iIPIPQdoZk/0G50rqkDPf0GAf+se3pP9FAwvnWDomzT3w5d O2PapZ0EVJP9Drk1FDHdeY0nVc8oz5/M4lqJ9NuZaDqIzgYVCShvsV0hWKCBd8Mp8W4k qWgh7Ea4k4T5taoNo8xszLyU0gpylLAgeK2TpkvFMWVq5FGTegxWCjcOGqkeQ/Ng1Xqg JMLQ== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr4845225vds.117.1338624163675; Sat, 02 Jun 2012 01:02:43 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 2 Jun 2012 01:02:43 -0700 (PDT) In-Reply-To: References: Date: Sat, 2 Jun 2012 10:02:43 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Emmanuel.Baccelli" Subject: Re: [manet] draft-baccelli-manet-multihop-communication-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 08:02:45 -0000 Hi Emmanuel, The confusion is when I read the new draft updated 23 May 2012, of the addition section 5 in the draft as I included below, is that it gives two options of IP runing on wireless multihop nets and [FUNKFEUER], [FREIFUNK], using a) OR b) , and my question was/is what is the difference as usually we need a interface-configuration-model, and routing-model together to run. In addition IMO we need also to include/define the subnet-model. I think this was mentioned in a wg meeting by Mr.Cole. Secondly, I think routing protocols interfaces/links are defined differently by some routers (OLSR definitions). IMO having the DLEP protocol in mind now will change the old concepts in MANET. Please see the following comments: 1- Comments on RFC5889 5889> however, there is no canonical method for determining a given IP inte= rface configuration. AB> RFC5889 is a production of autoconfig WG which is closed now, and I think we should discuss in our group if this RFC5889 really discribes the ad hoc configuration. 5889> Link-level connectivity is generally qualified as undetermined when it is unplanned and/or time-varying in character. Ad hoc networks are typical examples of networks with undetermined link-level connectivity. AB> what is meaning undetermined links? it is not right/logical way to discribe such links behavior/logic. I think it will be correct only for RFC3626 and RFC6130 interfaces not for RFC3561, but in the draft it includes AODV as using the interface config of RFC5889. AB> RFC5889 does not define links or interfaces like in RFC3626. IMO I realy take the definition in RFC3753 as the more correct. 2- Comments/discussions in one of WG meetings In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): BC> that subnet-models are not defined But in DLEP it looks at two subnet-models (different models; e.g. radio subnet-models, sat-subnet-models). We are defining IP over a subnet, but the subnet is not defined. Then we don=92t know how to define control protocols, data-packet-formats, and managements-models without having a subnet model in mind. TB> In sat-comms the up-link and down-link can be very different. So for different nodes on same carrier can be different data rates, SNR, etc. so it is important that DLEP include the link metrics, even if it is a full connected subnet. BC> the subnet depends on the link of the subnet-underlying model, The semantics of link up and down are determined by the underlying. In conclusion, I hope you consider these comments in the future virsions of draft, which I beleive can make big difference in avoiding my confusions and the group's concerns as they discussed in the meeting 82. Best regards Abdussalam Baryun University of glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++ The draft draft-baccelli-manet-multihop-communication-01 adds section 5: 5. IP over Multi-hop Ad Hoc Wireless While the above-described characteristics of packet transmission ove= r multi-hop ad hoc wireless networks are not the default characteristics expected by IP [RFC6250], it is possible and desirable to run IP over such networks. Over the last decade, numerous example of such networks running IP have turned up, including [FUNKFEUER], [FREIFUNK] among many other examples. IP has been running over such networks through the use of: specific IP interface configuration, as described in RFC 5889 [RFC5889], or specific routing protocols running on these interfaces, such as [RFC3626] [RFC3561] [RFC5449] for instance. Thus, even though the physical effects described in this document impose significant requirements for enhancing the robustness of protocol designs for routing and topology management, the experience in the projects described in the cited references shows that useful networks can be designed and operated using well-understood techniques. It is thus possible to shield other IP protocols runnin= g on other interfaces from the unusual characteristics experienced ove= r multi-hop ad hoc wireless networks. Note however that some protocol= s are still more appropriate than others when interfaces to multi-hop ad hoc wireless networks are involved in the communication. For instance, for applications written to run over both UDP and TCP, the latter choice may be preferred in situations with relatively high packet loss rates. But such choices must be based on application requirements. ++++++++++++++++++ On 5/31/12, Abdussalam Baryun wrote: > Hi > > this new document draft 'baccelli-manet-multihop-comm.' is now > referencing 5889, but not sure if we need it in the draft or in the > group, the model it represents is not understood so far for me, but I > think it needs to be discussed. The question is: > > What is the different between : a) specific IP interface > configuration, as described in RFC 5889, and b) specific routing > protocols running on these interfaces, such as > [RFC3626], [RFC3561], [RFC5449] ? > > Thanking you, > AB > From abdussalambaryun@gmail.com Sat Jun 2 01:12:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4AC21F8A6F for ; Sat, 2 Jun 2012 01:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KYy34LxL2hHu for ; Sat, 2 Jun 2012 01:12:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B430321F8A65 for ; Sat, 2 Jun 2012 01:12:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1922009vbb.31 for ; Sat, 02 Jun 2012 01:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=eikjc0xP529k7EtRdkRO+6uromjcqMTiCG9A24giYZQ=; b=podoxY367YU37uKijoMIoeetlIwLxM8YYrD2DQcU1lezf90UR1WEMACpDKZOEpQ8eZ Egu02alKZb6ul+dO7TacKS4rjXrAQCZVkHXw8/UJBXJc3rpUf/drgBh4Gz3BzB/gbZPk UbbSMo6ReEkihNj9FqtsgOLzY4R+qR7b7bqsVLMXJXEV9OoGYUTS4OoX+2E6YrzuPw30 Xf14DABevjqZL59Q5giJ0x1/bLa1DwnvHmqHqmQ7rvlcPGHYgHpqpoJtOK0qPqEwNteA Ye3TIW6I2yq/E4+i+y6RwCbNMaHeTjA0GX3zyPbMJxU8/CroegiyA2QXK6TR6L7ibL6V S9kQ== MIME-Version: 1.0 Received: by 10.220.150.205 with SMTP id z13mr5513425vcv.19.1338624776039; Sat, 02 Jun 2012 01:12:56 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 2 Jun 2012 01:12:55 -0700 (PDT) Date: Sat, 2 Jun 2012 10:12:55 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: robert.cole@jhuapl.edu Subject: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jun 2012 08:12:58 -0000 Hi All I want to discuss this subnet definition issue that was raised in the 82 meeting, could we discuss about it please. Will we need to put it in a draft or include it in our active draft working in progress, please advise, Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++ In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): BC> that subnet-models are not defined But in DLEP it looks at two subnet-models (different models; e.g. radio subnet-models, sat-subnet-models). We are defining IP over a subnet, but the subnet is not defined. Then we don=92t know how to define control protocols, data-packet-formats, and managements-models without having a subnet model in mind. TB> In sat-comms the up-link and down-link can be very different. So for different nodes on same carrier can be different data rates, SNR, etc. so it is important that DLEP include the link metrics, even if it is a full connected subnet. BC> the subnet depends on the link of the subnet-underlying model, The semantics of link up and down are determined by the underlying. ++++++++++++++++++++++++++++++++++++++++++++++++++ ******************************************************************** 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. ******************************************************************** From charliep@computer.org Sat Jun 2 23:21:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05FE011E809A for ; Sat, 2 Jun 2012 23:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] 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 9O5TzJ8D59WQ for ; Sat, 2 Jun 2012 23:21:36 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03711E8099 for ; Sat, 2 Jun 2012 23:21:35 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sb4By-0003qM-SD; Sun, 03 Jun 2012 02:21:34 -0400 Message-ID: <4FCB0261.9020405@computer.org> Date: Sat, 02 Jun 2012 23:21:21 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86656865e64187963e210466acfd408e0c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet , robert.cole@jhuapl.edu Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 06:21:37 -0000 Hello folks, I would be opposed to requiring the subnet model as a mandatory component of any current [manet] working group charter item. We have had at least ten years of experience showing that requiring subnets can derail practically any wireless network discussion within the sphere of applicability of manet protocols. The reasons are many and varied -- and, I must admit, really very interesting. It was the death of another working group which really should have been allowed to go forward except for disagreements about certain subnet-related constructs. Let's not consign ourselves to the same fate. Regards, Charlie P. On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: > Hi All > > I want to discuss this subnet definition issue that was raised in the > 82 meeting, could we discuss about it please. Will we need to put it > in a draft or include it in our active draft working in progress, > please advise, > > Abdussalam Baryun, > University of Glamorgan, UK > ++++++++++++++++++++++++++++++ > > In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): > BC> that subnet-models are not defined But in DLEP it looks at two > subnet-models (different models; e.g. radio subnet-models, > sat-subnet-models). We are defining IP over a subnet, but the subnet > is not defined. Then we don’t know how to define control protocols, > data-packet-formats, and managements-models without having a subnet > model in mind. > TB> In sat-comms the up-link and down-link can be very different. So > for different nodes on same carrier can be different data rates, SNR, > etc. so it is important that DLEP include the link metrics, even if it > is a full connected subnet. > BC> the subnet depends on the link of the subnet-underlying model, > The semantics of link up and down are determined by the underlying. > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > ******************************************************************** > 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. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > -- Regards, Charlie P. From abdussalambaryun@gmail.com Sun Jun 3 01:24:21 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0807721F85FB for ; Sun, 3 Jun 2012 01:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7cgj9Yun7Sj9 for ; Sun, 3 Jun 2012 01:24:20 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40C21F84FE for ; Sun, 3 Jun 2012 01:24:20 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2246629vcq.31 for ; Sun, 03 Jun 2012 01:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=6R4dlO7qe61CqJnU2rVS8+pBthEiERn3eLx+p0GzwAM=; b=uG2+dMDp2xIOu4QPZoSXsV0TAe3x3sQHGOJZRpAfjOmDL866D7DljjXGACMzXF1iGf 5Pyu/X7hG1HO+UzkCsbMB6e+7eRx9ACTyyZQidfTWZ8+KdU5f3AWeLzh5xVBi6EtmKc2 cgfML8lNTjYzf2R1GWYDssW2C9HnoJu07isLpjEZIHjBEIEtto0jjPbVLHqZNPFg3Adl b95jSIun28c7SzB7BTV7PfrpkWLilPTtlfZyFyOHwDhzfg8w/NKpgwxAeKNS2RP46ENg ZBdUkSFfloYyvWvRYfwCOAlu8/TC1BIVEf92bB4bOTgMxFKb/A7Gdo+0b1eU4O6OuPTj daFA== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr7499530vdb.66.1338711858717; Sun, 03 Jun 2012 01:24:18 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 01:24:18 -0700 (PDT) In-Reply-To: <4FCB0261.9020405@computer.org> References: <4FCB0261.9020405@computer.org> Date: Sun, 3 Jun 2012 10:24:18 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 08:24:21 -0000 Hi Charlie, and All The discussion started in meeting 82 and there was no oppose of starting it. Please note that I just notice it from the minutes so I wanted to know opinions/views so we go forward not like closed discussion WG. IMO agree that it should not be a mandatory of any/all current manet protocol, but I think IF we draft a general purpose draft-issue/protocol, then subnet-model MUST be mandatory component (i.e. defining the subnet-model). Only specific purpose or determined purposes or drafts that specify its network technology use-case MAY not include a subnet-model definition. For example, DLEP draft includes two subnet-models which it is using and I think that is start forward. However, the discussion on this issue is very important, which we may change direct our considerations to the best solution. So we don't have same fate of WG-death, is not to ignore network requirements' definitions, but to make them understood and managed. Maybe another way to solve the issue is to specify the MANET WG purpose attached to defined subnet-models applicable to the WG in the MANET WG charter, because from Cole and Teco discussion, there are many subnet-models having different conditions that is not considered by some general purpose works. Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++ On 6/3/12, Charles E. Perkins wrote: > > Hello folks, > > I would be opposed to requiring the subnet model as a mandatory > component of any current [manet] working group charter item. > > We have had at least ten years of experience showing that requiring > subnets can derail practically any wireless network discussion within > the sphere of applicability of manet protocols. The reasons are many > and varied -- and, I must admit, really very interesting. > > It was the death of another working group which really should have > been allowed to go forward except for disagreements about certain > subnet-related constructs. Let's not consign ourselves to the same > fate. > > Regards, > Charlie P. > > > > On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >> Hi All >> >> I want to discuss this subnet definition issue that was raised in the >> 82 meeting, could we discuss about it please. Will we need to put it >> in a draft or include it in our active draft working in progress, >> please advise, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++ >> >> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >> BC> that subnet-models are not defined But in DLEP it looks at two >> subnet-models (different models; e.g. radio subnet-models, >> sat-subnet-models). We are defining IP over a subnet, but the subnet >> is not defined. Then we don=92t know how to define control protocols, >> data-packet-formats, and managements-models without having a subnet >> model in mind. >> TB> In sat-comms the up-link and down-link can be very different. So >> for different nodes on same carrier can be different data rates, SNR, >> etc. so it is important that DLEP include the link metrics, even if it >> is a full connected subnet. >> BC> the subnet depends on the link of the subnet-underlying model, >> The semantics of link up and down are determined by the underlying. >> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ******************************************************************** >> 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. >> ******************************************************************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Sun Jun 3 01:49:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8975521F861C for ; Sun, 3 Jun 2012 01:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 c03lV8uMWire for ; Sun, 3 Jun 2012 01:49:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE08221F861B for ; Sun, 3 Jun 2012 01:49:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2248621vbb.31 for ; Sun, 03 Jun 2012 01:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=koSr1pq7rAr8ksMMyLZSJQ84gRkdTyqYdg6bxmIovWQ=; b=JVDLofXXCRTNECtzJiMfvmb1nMb+RxhdyNp0Qd/XM7v/Dqk40k0czXN7scvQcqBFOk Nz5ZpT/ln9QGZ7pXtOGXKlQSmZjDNRTFACmdxcJEZYlVAuN7D0vkikQmVB0qfQ4eQnqK HIGKXSJMyzy/tHwjS9369n1E9PtaERaE/0EIFn5/iEIvZEaqZ1WYFVKMaJNnaTK2ODiq cuW+dMuNhb4e9SI2kmgIVg4kezJYKjNBag5O/a8nuAjYsnThhv/YBXm8thmbnZfv2B0P Fnhxxujgsg7HtrnE32FsqWXZOCwpfatgVEk2i1cGt/WAOMof1eOH9HftOzD9qZ5MV4jr QfsQ== MIME-Version: 1.0 Received: by 10.220.149.15 with SMTP id r15mr2171353vcv.1.1338713384234; Sun, 03 Jun 2012 01:49:44 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 01:49:44 -0700 (PDT) Date: Sun, 3 Jun 2012 10:49:44 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Interests in DSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 08:49:45 -0000 Hi Folks, I started working on the first draft of DSRv2 to submit to the MANET-WG, and want to know if any is interested in the DSRv2 work, please advise, Will open discussion on the work progress within one month, if you have any question please reply, Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Subject: Re: [manet] A view on packet-BB From: Stan Ratliff Date: Thu, 31 May 2012 10:50:09 -0400 If you have an interest in some sort of DSRv2, then I would encourage you to author a draft and propose it to the WG. Stan > From abdussalambaryun@gmail.com Sun Jun 3 02:34:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F88A21F866A for ; Sun, 3 Jun 2012 02:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.457 X-Spam-Level: X-Spam-Status: No, score=-3.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SHpzYRh8GlNi for ; Sun, 3 Jun 2012 02:34:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AB87221F8668 for ; Sun, 3 Jun 2012 02:34:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2256288vbb.31 for ; Sun, 03 Jun 2012 02:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OxnYq4sGwVf7XI9nPQcsdkqDJeFSVmICShyisySFDmk=; b=OKOpXmzr97DNNOj2dPQevBQ0Sp5UswH/wUqOmZWM4zkUmo7PrtHsxBIJKr9aLaWWWF dQRL+YpXfz9/uYlvQGNxhy9BiKaagVKUK5q6OCFP2FQ6s8UW6/KXN/8Zx47lg+Qpa7yL Ixwf5Cd+T5m0WNq13ivjlb7jf/c6tiaJmCb50Kon2DIzXc9kcWP92aOEOiR9UzsXyzqT 8mxm2Lf72V8rSaBPSHr6K8mI7ldf0tyj7AERKNXaI4X9svyPFzqzt2IyJ/sBInH0lJfp pimLDZY/DiWU/XZqi76/dwP2rFLdGGtj6spRDWFmvZm1zFZv5W9prKDPWR35upUVMHg/ IRYg== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr7591745vdb.66.1338716064003; Sun, 03 Jun 2012 02:34:24 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 02:34:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jun 2012 11:34:23 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 09:34:25 -0000 Hi All, >From the questions on the list and from some meeting requests, I try to summary of things that we MAY need to discuss on the list are as follows but not restricted to them: - Discussing or review of DYMO-22 draft (AODVv2). - Discussing or review of DLEP-02 draft. - Discussing or review of NHDP-sec-02 draft. - Discussing or review of NHDP-sec-threats-00 draft. - Issue of using RFC5444 (packet-bb format) by more MANET protocols, (questioning why and why not) because its a MANET-format and its flexible. - Issue of accomodating LOADng protocol in MANET WG. - Issue of defining subnet-models in MANET. If I missed some open things, please add on this thread, so we don't forget, Abdussalam Baryun, University of Glamorgan, UK ===================== One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. Working groups are mostly right as long as they have more open discussions. From hrogge@googlemail.com Sun Jun 3 02:46:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA45C21F865F for ; Sun, 3 Jun 2012 02:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 v74SrRO+hQ85 for ; Sun, 3 Jun 2012 02:46:16 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2415221F865A for ; Sun, 3 Jun 2012 02:46:16 -0700 (PDT) Received: by dacx6 with SMTP id x6so4492327dac.31 for ; Sun, 03 Jun 2012 02:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=umkRNv+L9GYk/gRBQrRP+OqphdalhvHKxnbMn/rXvfA=; b=dXr5SUlYKjly9g4tQC/A6flFJx+wUBCn/RQTPmk0/pOUyYamquTXNyMIjBPVXNJKhw G11VvLPwyXDdjC7aOwjRtxD+B7sk5iehurhC0or3fLcwqQCggXPfAKuwRiJosdV13qwe MZLpRWYod9kYQPSUwWbGOsv2ggW0touzts4XRfhLcD/8ByFP+iLavIAGC1gtavXUiQ8r ZVNjpY0pA7dqX3l1rLCsnJEDvas10YehG9wgHi7h3tn0vzRkS4N9GSP6IToUztY1oqaf qqmMqhKMV063a0o2H4iQtMPaIstegMvbMC/n+NfiTwMiixXXR1hlK3IBtrTWMa+ZNWRP d6Ng== Received: by 10.68.232.232 with SMTP id tr8mr27699787pbc.73.1338716775748; Sun, 03 Jun 2012 02:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Sun, 3 Jun 2012 02:45:55 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Sun, 3 Jun 2012 11:45:55 +0200 Message-ID: To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 09:46:17 -0000 On Sun, Jun 3, 2012 at 11:34 AM, Abdussalam Baryun wrote: > Hi All, > > - Discussing or review of DLEP-02 draft. The status of DLEP (not just draft 02) IS a very important point. Last feedback was that the authors wanted to discuss internally how they want to continue with it, but that was more than a month ago. I would really like to hear what is going on their, the concept of DLEP is too important to just bury it. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ulrich@herberg.name Sun Jun 3 06:19:07 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3183721F8698 for ; Sun, 3 Jun 2012 06:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 U-cOnI4S7wYf for ; Sun, 3 Jun 2012 06:19:06 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6086B21F8697 for ; Sun, 3 Jun 2012 06:19:06 -0700 (PDT) Received: by yenq13 with SMTP id q13so2824103yen.31 for ; Sun, 03 Jun 2012 06:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DW+4eCnqcfZTDYDxzTgwCcSPA79gZg0nq+9ERHgN/eU=; b=p+OllxU2bVzKJDuKMrWEkGI6D2BrVpI1ADkvy2qfro+4UUmfWrNFVP1HLnqaKdqYZ+ P9UUBx+8Dnoo3R1bS8HeSAKlesHaZ+pJUjEo2S0zD5a3SDjcAGVe2d/TUu44vgPDTnRg cF7FSdR7XHAO9MR5MhrTmGRna8kQsxWwb6pbo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DW+4eCnqcfZTDYDxzTgwCcSPA79gZg0nq+9ERHgN/eU=; b=ABwKl2wdLA0EtVYsET8oFtxZhR/plDaRG222bUPBqYBKvgjjMY7l0hot1diV1+thmC 6jG75ZBlRl3SbiAA5pdAgGFTNpyb27yyc7GLC+uu443Hs81NyYzvrq4ehgX67LHsrxpW pQEgSAeLeRzX+Roa0HW5uFSP3GmLEtcb5+OeSwMrS6iR4l7nWDRgoaJsR7ZunzhVIPRr mqFbkhKzOqb6zEcUuzwQhTg1myR2ryki/wj7TMLdVZxlNpeTNSPpuNxzcpCyV8eBYnu2 rlIXDs3xVXTMUyclyqaE4bRqdkZ1Rk9JBlUojlAZ9rab6pqWFtC7829KZhDdm5ClAu0H 065Q== MIME-Version: 1.0 Received: by 10.236.193.67 with SMTP id j43mr4007442yhn.17.1338729545981; Sun, 03 Jun 2012 06:19:05 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Sun, 3 Jun 2012 06:19:05 -0700 (PDT) In-Reply-To: <4FCB0261.9020405@computer.org> References: <4FCB0261.9020405@computer.org> Date: Sun, 3 Jun 2012 06:19:05 -0700 Message-ID: From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkPXiqTdJNUhymGTDxyX1FySAmQlCyQadZ+rAEw7X9hZSTuSiScTPd/5Sqxl0fSs/O1b0JD Cc: manet , robert.cole@jhuapl.edu, Abdussalam Baryun Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 13:19:07 -0000 +1 On Sat, Jun 2, 2012 at 11:21 PM, Charles E. Perkins wrote: > > Hello folks, > > I would be opposed to requiring the subnet model as a mandatory > component of any current [manet] working group charter item. > > We have had at least ten years of experience showing that requiring > subnets can derail practically any wireless network discussion within > the sphere of applicability of manet protocols. =A0The reasons are many > and varied -- and, I must admit, really very interesting. > > It was the death of another working group which really should have > been allowed to go forward except for disagreements about certain > subnet-related constructs. =A0Let's not consign ourselves to the same > fate. > > Regards, > Charlie P. > > > > > On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >> >> Hi All >> >> I want to discuss this subnet definition issue that was raised in the >> 82 meeting, could we discuss about it please. Will we need to put it >> in a draft or include it in our active draft working in progress, >> please advise, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++ >> >> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >> BC> =A0that subnet-models are not defined But in DLEP it looks at two >> subnet-models (different models; e.g. radio subnet-models, >> sat-subnet-models). We are defining IP over a subnet, but the subnet >> is not defined. Then we don=92t know how to define control protocols, >> data-packet-formats, and managements-models without having a subnet >> model in mind. >> TB> =A0In sat-comms the up-link and down-link can be very different. So >> for different nodes on same carrier can be different data rates, SNR, >> etc. so it is important that DLEP include the link metrics, even if it >> is a full connected subnet. >> BC> =A0the subnet depends on the link of the subnet-underlying model, >> The semantics of link up and down are determined by the underlying. >> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ******************************************************************** >> 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. >> ******************************************************************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > -- > Regards, > Charlie P. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From d.sturek@att.net Sun Jun 3 07:15:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD3221F853F for ; Sun, 3 Jun 2012 07:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599] 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 8ILMLBm630GG for ; Sun, 3 Jun 2012 07:15:02 -0700 (PDT) Received: from nm34-vm7.bullet.mail.ne1.yahoo.com (nm34-vm7.bullet.mail.ne1.yahoo.com [98.138.229.87]) by ietfa.amsl.com (Postfix) with SMTP id 0373421F853E for ; Sun, 3 Jun 2012 07:15:01 -0700 (PDT) Received: from [98.138.90.56] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2012 14:14:58 -0000 Received: from [68.142.200.226] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jun 2012 14:14:58 -0000 Received: from [66.94.237.109] by t7.bullet.mud.yahoo.com with NNFMP; 03 Jun 2012 14:14:58 -0000 Received: from [127.0.0.1] by omp1014.access.mail.mud.yahoo.com with NNFMP; 03 Jun 2012 14:14:58 -0000 X-Yahoo-Newman-Id: 520533.88306.bm@omp1014.access.mail.mud.yahoo.com Received: (qmail 93254 invoked from network); 3 Jun 2012 14:14:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1338732898; bh=ZFTzgkzSd0iBJM26vGtfXivpdm1eQbp3L7sp8hh6HEA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=avyqc1GQiysspGdqEEAecvjS9nn9OpjUZ8astXAcJNf0gp893yfI44lWNZlsbAAsVg/75LLbbah+5eYngXfRfAWHz2Mk7lOsvCIGOZ5y7UPu5a8eaYBcxou5eMhfkt8YZIRx5gHU4mUoPa6iyQQMIxnuOtL6GD0XoENp6BqNdZw= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BBMbRKEVM1kG0Uoxw93I10itOf0UuRiiVwnQxDenxntlSp8 nLoge7esx4jUBnQLMvah.pL_ne0NFW6uUI7KALkEOYeVt7Gm0iaPYskxmPeN d2sAh4SfCWTOoUCM.VjjtmZyHdND9evVYCyOKwZCFIC4sFMLhp8AfYjyac3L MbzvkyBLpSf_PVap_0bePcCfm6Itlovw4CJGjtH.z55a343yZIjQEgmUFyHb DIxy2FypdfBIe4vVtI8tLv8JMJJXKbJ7nMl_rBvt1n25YfTqeG5ijVCIdUhx HjBQDPVWkY3fy4FIiC19u8aVrVQGzu_gMBQ.y3B2nRcmqUZUhiwjpeLZDAUo ZQkHRfTMW.wJDyzI9ah_mtf7FGo_4rS4yrtYYCi8Bvy8SajngtD4fY6awBk_ Xs3DwAIbW_aMoCetaBt0lIGGPXr1fSTiRKfykBN4OBVIUuVzVPu0- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.108.49.68 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 03 Jun 2012 07:14:58 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Sun, 03 Jun 2012 07:12:27 -0700 From: Don Sturek To: "Charles E. Perkins" , Abdussalam Baryun Message-ID: Thread-Topic: [manet] Defining subnet models used by our protocols In-Reply-To: <4FCB0261.9020405@computer.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: manet , robert.cole@jhuapl.edu Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 14:15:03 -0000 +1 On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: > >Hello folks, > >I would be opposed to requiring the subnet model as a mandatory >component of any current [manet] working group charter item. > >We have had at least ten years of experience showing that requiring >subnets can derail practically any wireless network discussion within >the sphere of applicability of manet protocols. The reasons are many >and varied -- and, I must admit, really very interesting. > >It was the death of another working group which really should have >been allowed to go forward except for disagreements about certain >subnet-related constructs. Let's not consign ourselves to the same >fate. > >Regards, >Charlie P. > > > >On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >> Hi All >> >> I want to discuss this subnet definition issue that was raised in the >> 82 meeting, could we discuss about it please. Will we need to put it >> in a draft or include it in our active draft working in progress, >> please advise, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++ >> >> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >> BC> that subnet-models are not defined But in DLEP it looks at two >> subnet-models (different models; e.g. radio subnet-models, >> sat-subnet-models). We are defining IP over a subnet, but the subnet >> is not defined. Then we don=B9t know how to define control protocols, >> data-packet-formats, and managements-models without having a subnet >> model in mind. >> TB> In sat-comms the up-link and down-link can be very different. So >> for different nodes on same carrier can be different data rates, SNR, >> etc. so it is important that DLEP include the link metrics, even if it >> is a full connected subnet. >> BC> the subnet depends on the link of the subnet-underlying model, >> The semantics of link up and down are determined by the underlying. >> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ******************************************************************** >> 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. >> ******************************************************************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > >--=20 >Regards, >Charlie P. > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Sun Jun 3 14:46:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B321F86FC for ; Sun, 3 Jun 2012 14:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Hv-AL6JITBUY for ; Sun, 3 Jun 2012 14:46:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 85D7221F86FA for ; Sun, 3 Jun 2012 14:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=3253; q=dns/txt; s=iport; t=1338760002; x=1339969602; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=I5HMt83niwOo0C1+8pJjIIyqWPERlQe2ZVL2H6av+8o=; b=C2uB1B36z7NFW+QyNYTlisI8gaS1hlxlq98i8qX6fFMHP0Kg9EAFAdWC YIU6xNwdDpfGFJBtvLgYVaWT5JxohR/S8ENXnVWhN6UqG1TOL52LmU+W+ RjIecZn3Qcnh0fUa129936gd9ey9MiOLp66plZHN24/OuwE06toIvYPXX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIPay0+tJXG9/2dsb2JhbABEtCKBB4IYAQEBBAEBAQ8BVAcLEAsYLicwBhMih2kLlnCeTgSLEYUwYAORP4NcjhCBZoJ8gUM X-IronPort-AV: E=Sophos;i="4.75,710,1330905600"; d="scan'208";a="89059244" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 03 Jun 2012 21:46:42 +0000 Received: from rtp-sratliff-8711.cisco.com (rtp-sratliff-8711.cisco.com [10.116.179.210]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q53LkfNW009458; Sun, 3 Jun 2012 21:46:41 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Stan Ratliff In-Reply-To: Date: Sun, 3 Jun 2012 17:46:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <58FF25A8-CB06-4AEB-AFE3-2433D779DE3B@cisco.com> References: <4FCB0261.9020405@computer.org> To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun , robert.cole@jhuapl.edu Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2012 21:46:43 -0000 +2 On Jun 3, 2012, at 9:19 AM, Ulrich Herberg wrote: > +1 >=20 > On Sat, Jun 2, 2012 at 11:21 PM, Charles E. Perkins > wrote: >>=20 >> Hello folks, >>=20 >> I would be opposed to requiring the subnet model as a mandatory >> component of any current [manet] working group charter item. >>=20 >> We have had at least ten years of experience showing that requiring >> subnets can derail practically any wireless network discussion within >> the sphere of applicability of manet protocols. The reasons are many >> and varied -- and, I must admit, really very interesting. >>=20 >> It was the death of another working group which really should have >> been allowed to go forward except for disagreements about certain >> subnet-related constructs. Let's not consign ourselves to the same >> fate. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>=20 >>=20 >> On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>>=20 >>> Hi All >>>=20 >>> I want to discuss this subnet definition issue that was raised in = the >>> 82 meeting, could we discuss about it please. Will we need to put it >>> in a draft or include it in our active draft working in progress, >>> please advise, >>>=20 >>> Abdussalam Baryun, >>> University of Glamorgan, UK >>> ++++++++++++++++++++++++++++++ >>>=20 >>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>> BC> that subnet-models are not defined But in DLEP it looks at two >>> subnet-models (different models; e.g. radio subnet-models, >>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>> is not defined. Then we don=92t know how to define control = protocols, >>> data-packet-formats, and managements-models without having a subnet >>> model in mind. >>> TB> In sat-comms the up-link and down-link can be very different. = So >>> for different nodes on same carrier can be different data rates, = SNR, >>> etc. so it is important that DLEP include the link metrics, even if = it >>> is a full connected subnet. >>> BC> the subnet depends on the link of the subnet-underlying model, >>> The semantics of link up and down are determined by the underlying. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>=20 >>=20 >> -- >> Regards, >> Charlie P. >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From henning.rogge@fkie.fraunhofer.de Sun Jun 3 23:55:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C99521F86DB for ; Sun, 3 Jun 2012 23:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.244 X-Spam-Level: X-Spam-Status: No, score=-1.244 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 v1GXRLV5VVAZ for ; Sun, 3 Jun 2012 23:55:54 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (a.mx.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC1021F8703 for ; Sun, 3 Jun 2012 23:55:52 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SbRCh-0001mL-CO for manet@ietf.org; Mon, 04 Jun 2012 08:55:51 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1SbRCh-0002kT-9n for manet@ietf.org; Mon, 04 Jun 2012 08:55:51 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 4 Jun 2012 08:55:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 4 Jun 2012 08:55:50 +0200 Message-ID: <4FCC5BEF.108@fkie.fraunhofer.de> Date: Mon, 4 Jun 2012 08:55:43 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: References: <4FCB0261.9020405@computer.org> <58FF25A8-CB06-4AEB-AFE3-2433D779DE3B@cisco.com> In-Reply-To: <58FF25A8-CB06-4AEB-AFE3-2433D779DE3B@cisco.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040004090306070204010102" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 Jun 2012 06:55:51.0100 (UTC) FILETIME=[140677C0:01CD421F] X-Virus-Scanned: yes (ClamAV 0.97.3/14995/Sat Jun 2 20:35:41 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 8a842d9e11f1c1d58316de1cda04e013 Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:55:55 -0000 --------------ms040004090306070204010102 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable +3 On 06/03/2012 11:46 PM, Stan Ratliff wrote: > +2 > > On Jun 3, 2012, at 9:19 AM, Ulrich Herberg wrote: > >> +1 >> >> On Sat, Jun 2, 2012 at 11:21 PM, Charles E. Perkins >> wrote: >>> >>> Hello folks, >>> >>> I would be opposed to requiring the subnet model as a mandatory >>> component of any current [manet] working group charter item. >>> >>> We have had at least ten years of experience showing that requiring >>> subnets can derail practically any wireless network discussion within= >>> the sphere of applicability of manet protocols. The reasons are many= >>> and varied -- and, I must admit, really very interesting. >>> >>> It was the death of another working group which really should have >>> been allowed to go forward except for disagreements about certain >>> subnet-related constructs. Let's not consign ourselves to the same >>> fate. --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms040004090306070204010102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDbjCCA2oCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIBzjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA2MDQwNjU1NDhaMCMGCSqGSIb3DQEJBDEWBBSbIJFtw230yUGDBZ4XctKLNXW9YzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBqhS9l57PdAefnbLimLHuIrHRGXJoerwuKGsSgzODhSVyXsCcVy8c0/xpB0kbo tj5/vBhc1Dy2twiaeXy2RK5Xs8wTK5VKzKLhtZqcWv3pylCUbMKd3Iy3fRn5iqS9xRme6wIA 6ip4JnFXyQyRhwKrnHU2qAZvkWDi5JwqcWn1+8v7RQRwzqQQxgn/ncu3VSOxZj3pUJmXdOos 48NY88qzj7g/NT4qiHH9Gm+KoQGvnuKvocGRMXWRad2+jhV3D0gDbF7rxk/KczdVOsEAaW5v cWxO3hbNMWbmun9Lyzig2LDk9vS/4gptPacLkFUE1rH4AmeCMtrK7OpGvPfJOvPEAAAAAAAA --------------ms040004090306070204010102-- From abdussalambaryun@gmail.com Mon Jun 4 00:40:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9969221F872D for ; Mon, 4 Jun 2012 00:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Yj8La1kXBPq3 for ; Mon, 4 Jun 2012 00:40:15 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DE7C521F872A for ; Mon, 4 Jun 2012 00:40:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2597039vbb.31 for ; Mon, 04 Jun 2012 00:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+vGkIK6f3yV2seWnmUkbsLnuslia34wdE4d0yYfg42g=; b=zCFHjJTjK3UhGxeKN/TWTWfoSKhrBmVH6+ruKl8x1j0qTC9wHzE1mvMXiztOUDZZLq viTg71RtTzmxjBEcQ1zvl+WX5q7qId5UnfXrwGrjGf5iWSnJXTT6oXKtd0VN2y1ScV+U +AevFk7jD656bqboZfgCtnVjtighq41E09LGHGWZcIrXmCmseaCXtXvfThRH+oL3395l SLZ7mYdeaQ/J44XhRfRgV+f/KaT4XhNLH2zrfgGj6bW9RM0FZDKJ+xHITNj8JXUCdpkp IysrLWTy7N3IbsK/5ppxilsa0MgWuVaoTlvDjKetvfwFf4sKYA04O00Nvcz0UIW55yTt dSMw== MIME-Version: 1.0 Received: by 10.220.150.205 with SMTP id z13mr11317390vcv.19.1338795614323; Mon, 04 Jun 2012 00:40:14 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Mon, 4 Jun 2012 00:40:13 -0700 (PDT) In-Reply-To: References: <4FCB0261.9020405@computer.org> Date: Mon, 4 Jun 2012 09:40:13 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 07:40:15 -0000 Hi All, After many aposes, maybe we can draft a work of defining the subnet-model for MANET, without in any draft, maybe this way it will be better for all, then we discuss the new draft issue only without mixing with other concepts of protocols. If you give me a go ahead I will do that, Regards Abdussalam From abdussalambaryun@gmail.com Mon Jun 4 01:03:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DD121F87A3 for ; Mon, 4 Jun 2012 01:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 gPRp49pRLdF3 for ; Mon, 4 Jun 2012 01:03:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0A46421F879F for ; Mon, 4 Jun 2012 01:03:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2606373vbb.31 for ; Mon, 04 Jun 2012 01:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=I8mgfwdcGrP2Xy/RrxAFFLFIzrA3Haf/uzntnhv5Dj4=; b=QNcjNGVqcfR/hpnjWm3+5zDTaOrajXK07D1ywzg+5QdktZN5V3+K3HbmKNXzGTvg6A 9gZqWW63gGyIfHNPZCislVpSqT2umCFiJDn3NqeUjm8iuG6kITzpbqUviLjqfIimpoLL 73yofbB3u7qougXhXynJ7Sj+rgjglZcXj1q9HUx1X3UAB0B13kKep6klCv8FnInRRSDt sjpqTiGDN5d1l2alNdWCG1SO2tuGQlPBufjsHDoH0wXyJCq46iC96ezzlUdmJDUlBsPx gNe7qRk+TUPnBLeIa7e2KUKvnKXTt4S9v5CaQSBuc01WoeQkvn8tnre44wfcdp5J9HXd RBVw== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr9722846vds.117.1338797036458; Mon, 04 Jun 2012 01:03:56 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Mon, 4 Jun 2012 01:03:56 -0700 (PDT) In-Reply-To: References: <4FCB0261.9020405@computer.org> Date: Mon, 4 Jun 2012 10:03:56 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [manet] Fwd: Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:03:58 -0000 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DPossible Dup= lication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Hi All I would like to know your opinion about why we don't define subnets for MAN= ET? On 6/3/12, Don Sturek wrote: > +1 > > On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: Could we discuss why we don't define subnets models? I don't understand adding (+1). I hope the chair does not ask me to close this thread too :) The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 so living for about 6 years only. What was the reason for the proposed close of it? please read the DA Jari's reasons below. IMO it because it had low/no useful discussions and only produced one RFC which is RFC5889, why only one? what happend within 6 years? IMO any WG should have more discussions, discussions are mandatory activity for WG. Not discussing issues is like ignoring the value input to group progress. Healthy discussions are more important than producing more documents produced, because discussions are really the source of correct documents (don't mean it has to be perfect, but should not be misleading). WGs should be compared in terms of the amount of discussions not in amount of documents forwarded/submitted. According to Chakeres and Maker (2006) [1] quoated below: [The autoconf WG is chartered to initially develop two documents. The first document is a document defining the MANET architecture and how MANET relates to IP networks and the Internet. The second document is to define the terminology, problem statement and goals for autoconf. These autoconf documents will be discussed on the autoconf mailing list.] That WG did not produce the definition of MANET architecture. Which I think is related to the subnet-model definition importance for MANET. So i understand the authors see the importance of defining something for MANET in 2006. Now, Do we have a network architecture definition of MANET in one RFC? > On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: >>Hello folks, >> >>I would be opposed to requiring the subnet model as a mandatory >>component of any current [manet] working group charter item. >> >>We have had at least ten years of experience showing that requiring >>subnets can derail practically any wireless network discussion within >>the sphere of applicability of manet protocols. The reasons are many >>and varied -- and, I must admit, really very interesting. >> >>It was the death of another working group which really should have >>been allowed to go forward except for disagreements about certain >>subnet-related constructs. Let's not consign ourselves to the same >>fate. In future the death of the WG will be because they don't discuss things on the list, or don't have what to discuss, please read the reasons mentioned by Jari Arkko below. IMO for the future, some day any WGs possibly will close and other days new WGs comes. >> >>Regards, >>Charlie P. References: [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the IETF', Mobile Computing and communication review, volume 1, Number 2, 2006. Best regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: "autoconf at ietf.org" Subject: [Autoconf] closing the working group? From: Jari Arkko Date: Tue, 29 Mar 2011 08:48:47 +0200 ---------------------------------------------------------------------------= ----- I have looked at the discussions on the list (or lack thereof). I also cannot see too many internet drafts on the topics belonging to the group's charter. I am very happy with the RFC that has been produced by the working group, but we also seem to have some actual protocol work happening elsewhere (e.g., in the context of the ROLL WG). I discussed this matter with the chairs and my co-AD, and we are wondering if it would be time to close the working group. I do know that there is at least one implementation team that is still in the process of describing their DHCP-based solution, maybe there are similar efforts on the distributed solution space. My proposal is that we close the working group and I'be VERY happy to AD sponsor all such solutions to Experimental RFCs as soon as we have those proposals in some reasonable shape. Thoughts? Jari +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: IETF-Announce at ietf.org Subject: WG Review: Ad Hoc Network configuration (autoconf) From: The IESG Date: Wed, 27 Jul 2005 14:28:49 -0400 ---------------------------------------------------------------------------= ----- A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the = IESG mailing list (iesg at ietf.org) by August 3rd. +++++++++++++ Ad Hoc Network configuration (autoconf) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group Chairs: TBD Internet Area Director(s): Mark Townsley Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: manetautoconf at ml.free.fr To Subscribe: manetautoconf-request at ml.free.fr Description of the WG: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) may need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. Ad hoc networks present several new challenges. Unlike in traditional IP networks, each ad hoc node, besides being a traffic end-point, should be capable of forwarding traffic destined for other hosts. Additionally, nodes constituting an ad-hoc network do not share access to a single multicast-capable link for signaling. Many protocol specifications used in traditional IP networks e.g. RFCs 2462, 2463 etc. do, however, assume that subnet-local signals (e.g. link-local multicast signal) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are expected to support multi-hop communication by running a MANET routing protocol, e.g. those developed by the IETF MANET WG. However, this may or may not mean that an AUTOCONF mechanism will be dependent on any specific MANET routing protocol. With this in mind, the goals of AUTOCONF WG are to: - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 stateless autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a stateful address autoconfiguration mechanism to be used by ad hoc nodes for configuring globally routable unique addresses, if an address providing entity such as DHCPv6 server is available. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Goals and Milestones: Oct 05 : Submit "terminology and problem statement" document for WG review Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms and design frameworks Feb 06: Submit "terminology and problem statement" document to IESG for publication as an informational RFC Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" for WG review Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" for WG review Apr 06: Submit initial -ID of "configured address uniqueness maintenance" for WG review Aug 06: Revise WG documents and review Dec 06 Revise documents based upon implementation experience Apr 07: Submit "stateless autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "stateful autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "configured address uniqueness maintenance" specification and supporting documentation to IESG for publications as Proposed Standard Oct 07: Close or recharter the WG _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> >> >>On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>> Hi All >>> >>> I want to discuss this subnet definition issue that was raised in the >>> 82 meeting, could we discuss about it please. Will we need to put it >>> in a draft or include it in our active draft working in progress, >>> please advise, >>> >>> Abdussalam Baryun, >>> University of Glamorgan, UK >>> ++++++++++++++++++++++++++++++ >>> >>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>> BC> that subnet-models are not defined But in DLEP it looks at two >>> subnet-models (different models; e.g. radio subnet-models, >>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>> is not defined. Then we don=B9t know how to define control protocols, >>> data-packet-formats, and managements-models without having a subnet >>> model in mind. >>> TB> In sat-comms the up-link and down-link can be very different. So >>> for different nodes on same carrier can be different data rates, SNR, >>> etc. so it is important that DLEP include the link metrics, even if it >>> is a full connected subnet. >>> BC> the subnet depends on the link of the subnet-underlying model, >>> The semantics of link up and down are determined by the underlying. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >>-- >>Regards, >>Charlie P. >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > > From abdussalambaryun@gmail.com Mon Jun 4 01:33:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ECB21F86E8 for ; Mon, 4 Jun 2012 01:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.48 X-Spam-Level: X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TWV9V+lqD7TW for ; Mon, 4 Jun 2012 01:33:03 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C1BBE21F861D for ; Mon, 4 Jun 2012 01:33:03 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2622854vcq.31 for ; Mon, 04 Jun 2012 01:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=i+s4XH47Yzs0mEnWd034GozajlUzExX6JP5w+hy4UeI=; b=aY7Ja9AJMdIeaa8kyQlD47fFGqwqxNWnaXQ4ubxfjo5ioaG306fdfqawGJSTnXGwpF q+YBNIrVd9iVJYpbsdeqILYGNeUwRgBtWYbAfjz4uFgn5bb62DwvYXJ3IZi5AYz6RTWt JGVN3DDtFNWo7zEa18o1vkLZU1UkTf/mT9QlN3kUDIvckZQ6whW5x2Sheo6GW+Qa/Em0 GkZT0GJoUWXeUjkETVEmfyp/2GgODtiIXJkzoaobRlsVsHJSpnUWKJrePmzBNfvYyiF4 XPNXo6pS+PamW+d0TtY9riRByUMrcaF9U1rWppES6vnwx2H5Y5+EO6dKWJPOQx2iTuZY PRJQ== MIME-Version: 1.0 Received: by 10.220.157.14 with SMTP id z14mr11426185vcw.73.1338798783156; Mon, 04 Jun 2012 01:33:03 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Mon, 4 Jun 2012 01:33:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jun 2012 10:33:02 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Interests in DSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 08:33:04 -0000 Hi folks, The start conclusion of my ideas of DSRv2 are that it does not applicable to LLN nor routing as ROLL, but it is more like DLEP use-cases/purposes. I thought it is important that this new version extends RFC4728 to IPv6 DSR, and uses [RFC5444] MANET-packets and also adaptive the neighbor-and-link discovery of NHDP [RFC6130] and/or DLEP. Any other ideas, comment or advise, please reply if any Abdussalam Baryun University of Glamorgan, UK ============================================ From d.sturek@att.net Mon Jun 4 06:26:26 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3AA21F8792 for ; Mon, 4 Jun 2012 06:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599] 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 CqQ50cVDk2-a for ; Mon, 4 Jun 2012 06:26:25 -0700 (PDT) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by ietfa.amsl.com (Postfix) with SMTP id AF89C21F8779 for ; Mon, 4 Jun 2012 06:26:25 -0700 (PDT) Received: from [98.139.52.193] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jun 2012 13:26:21 -0000 Received: from [68.142.200.226] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jun 2012 13:26:21 -0000 Received: from [66.94.237.107] by t7.bullet.mud.yahoo.com with NNFMP; 04 Jun 2012 13:26:21 -0000 Received: from [127.0.0.1] by omp1012.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2012 13:26:21 -0000 X-Yahoo-Newman-Id: 860806.47504.bm@omp1012.access.mail.mud.yahoo.com Received: (qmail 92888 invoked from network); 4 Jun 2012 13:26:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1338816381; bh=7c8ovuPCxmtGImcDZbFCBOe7zrI7SeFXFE1DyUu01gc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=yiQZFBMggQ8UPQjcnr54Pxc86phOezIvg38DHj+5iFwBXWDA3sn9EgzaaAYWIcaklfXnZJe1MYF/9+uMgRw/IcBw7ZEtbE1s5kqKMglGEeG733+mIQXUR6wjaAZKhjRT0FJZnp1XDfGohaRXvrhGRs95LHtjMfU56KG/iudyqi4= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MnQnlqMVM1lZD1qTddbgaDICaTlrBWtYzv8j7TYu1Z6rdmX rR.a5kN.lzXFWGIOZjHtpDfpqOJ0.xMdpnFEdelo8iehLjFt_omjGVsEGoAh 9VPycwr9cTHybf1EeKumqZnyKp.1S3Mpk0VsGX2ac0n6gu1MyqkkMIXHKNws EZBdZGCY9YAkHH7LOcEbExlsJeHTFbxGx.FBQf3Fk9YkNHw6wjqrF5Hww.2R JR7SyKGJkpjeq5zD_OCE3lmYET8_UHJQcUeel5.MDVU7arysTH.FAZzUQ..G dY6sXJl24M5nGJxeynMZkFIx_lWmSMjweC9tEwFPYiARTtJ3eNjTyY.fAjwB zSyIzPgekI49MaPPK9jEUopwN_8bv2N1z6I5AL.Hum796lDWcPptHQjuKrJG RMa55S7pufugxc7suBhIWuOZ1CAsTy5JxdUWMoItHPR1uJPuV4e1XbtQ- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.139.102 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 04 Jun 2012 06:26:21 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 04 Jun 2012 06:26:19 -0700 From: Don Sturek To: Abdussalam Baryun , manet Message-ID: Thread-Topic: [manet] Defining subnet models used by our protocols In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:26:26 -0000 I am opposed to tying any subnet model to work within MANET. That said, individual drafts can be created by anyone..... Don On 6/4/12 12:40 AM, "Abdussalam Baryun" wrote: >Hi All, > >After many aposes, maybe we can draft a work of defining the >subnet-model for MANET, without in any draft, maybe this way it will >be better for all, then we discuss the new draft issue only without >mixing with other concepts of protocols. > >If you give me a go ahead I will do that, > >Regards >Abdussalam >_______________________________________________ >manet mailing list >manet@ietf.org >https://www.ietf.org/mailman/listinfo/manet From d.sturek@att.net Mon Jun 4 06:36:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9962B21F87E7 for ; Mon, 4 Jun 2012 06:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=-0.748, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, MIME_QP_LONG_LINE=1.396] 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 T-SelxkhuBY9 for ; Mon, 4 Jun 2012 06:36:36 -0700 (PDT) Received: from nm22-vm0.bullet.mail.bf1.yahoo.com (nm22-vm0.bullet.mail.bf1.yahoo.com [98.139.212.126]) by ietfa.amsl.com (Postfix) with SMTP id 6111021F87AD for ; Mon, 4 Jun 2012 06:36:33 -0700 (PDT) Received: from [98.139.215.142] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2012 13:36:32 -0000 Received: from [68.142.200.225] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 04 Jun 2012 13:36:32 -0000 Received: from [66.94.237.98] by t6.bullet.mud.yahoo.com with NNFMP; 04 Jun 2012 13:36:32 -0000 Received: from [127.0.0.1] by omp1003.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2012 13:36:32 -0000 X-Yahoo-Newman-Id: 576958.28889.bm@omp1003.access.mail.mud.yahoo.com Received: (qmail 13053 invoked from network); 4 Jun 2012 13:36:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1338816992; bh=WvEwzBLd9rAPlnRWwvVEbpizpqCsOSrW3QXdzGN5UsU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=xf0lf2u3GEuHk+GjTGN9GOJO8p39DeLEv9wbN1y+mLd/+F5u42rrKIcmh3w8YpobguBo1Z2XoQe/9pjFSE3npqOc6dRyXflXY1GOWeBQ8CHRPeWhyEm8RbTYQCEt3i0ypLIHA/AzH+yVuce4d0ukyjajDUHssG3NEcnn+k5zgFY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: EJf.M74VM1mOdW7E5sUUmTsXzWdbp3eCkwJtmIz9tclADR. C0gvS9Jg3dyMD15ifaivKqHed5FMxp9IXepCIIe.GWO.3V78PrUKfm0VrXCX josimu_fRga7Q_dtSWLoiOz7GIuIu0eGz5pMK7qGz5Kq.L3MTUR3sKs0UzAf BJx.pVnTmEVl3p3nAWaA96rcOJJDiWlfAWGSN6.qgxO5Jk3f_ACcweMfwOP0 yTyoBIfDWY6.SEBqk5fFgMIoeBTAsdjB2bAEM0KXGSweG5KsE8VaHLcZXbCt q_59l9nKvvE0GM48wf.i4cAvdy5Co01imWQVcm8QtGIfHEMat5ZoftoRW9TX uw_e85OFjkStkjKtqKI_SHGIbHBwQFKgzskp2bp5_vYNbcfXBr7fuUk4vwRq wa_k0C8MaFeqk.niUaGefyTJOAqf2nScGB83YpiRfhZrVYslkFsvUnuRvJf4 9a7kHP_RrCvmjWd8oNGpp0uXjrToA3XEYGTsEd_41sBVCo7oy9PfMwbct3aS DAADF7_ev8HyP5csVebrQAzNo64X3Zguaqwo3yYxyAHZPDtSjoBcQt9hHKgl C_8vy.37piigeCKYLha_SRT9eHPvSoIcqHfaoiuy9ap6TNb7GkHPNEUba0wr LZiQ- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.139.102 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 04 Jun 2012 06:36:31 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 04 Jun 2012 06:35:11 -0700 From: Don Sturek To: Abdussalam Baryun , manet , Message-ID: Thread-Topic: [manet] Defining subnet models used by our protocols In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable X-Mailman-Approved-At: Mon, 04 Jun 2012 06:37:20 -0700 Cc: ietf , "Emmanuel.Baccelli" , jari.arkko@piuha.net, Stan Ratliff Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:36:37 -0000 Hi Abdullalam, I think basing a routing protocol (like those in MANET and also ROLL) on some standard definition of subnets is: 1) not needed in my experience with virtually every deployment scenario I have seen 2) conflates the network topology with the pratical issue of providing peer to peer route discovery and establishment Don On 6/4/12 12:17 AM, "Abdussalam Baryun" wrote: >Hi Don, and All, > >I would like to know your opinion about why we don't define subnets for >MANET? > >On 6/3/12, Don Sturek wrote: >> +1 >> >> On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: > >Could we discuss why we don't define subnets models? I don't >understand adding (+1). I hope the chair does not ask me to close this >thread too :) > >The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 >so living for about 6 years only. What was the reason for the proposed >close of it? please read the DA Jari's reasons below. > >IMO it because it had low/no useful discussions and only produced one >RFC which is RFC5889, why only one? what happend within 6 years? IMO >any WG should have more discussions, discussions are mandatory >activity for WG. Not discussing issues is like ignoring the value >input to group progress. Healthy discussions are more important than >producing more documents produced, because discussions are really the >source of correct documents (don't mean it has to be perfect, but >should not be misleading). WGs should be compared in terms of the >amount of discussions not in amount of documents forwarded/submitted. > >According to Chakeres and Maker (2006) [1] quoated below: > >[The autoconf WG is chartered to initially develop >two documents. The first document is a document >defining the MANET architecture and how MANET >relates to IP networks and the Internet. The second >document is to define the terminology, problem statement >and goals for autoconf. These autoconf documents >will be discussed on the autoconf mailing list.] > >That WG did not produce the definition of MANET architecture. Which I >think is related to the subnet-model definition importance for MANET. >So i understand the authors see the importance of defining something >for MANET in 2006. Now, Do we have a network architecture definition >of MANET in one RFC? > >> On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: >>>Hello folks, >>> >>>I would be opposed to requiring the subnet model as a mandatory >>>component of any current [manet] working group charter item. >>> >>>We have had at least ten years of experience showing that requiring >>>subnets can derail practically any wireless network discussion within >>>the sphere of applicability of manet protocols. The reasons are many >>>and varied -- and, I must admit, really very interesting. >>> >>>It was the death of another working group which really should have >>>been allowed to go forward except for disagreements about certain >>>subnet-related constructs. Let's not consign ourselves to the same >>>fate. > >In future the death of the WG will be because they don't discuss >things on the list, or don't have what to discuss, please read the >reasons mentioned by Jari Arkko below. IMO for the future, some day >any WGs possibly will close and other days new WGs comes. > >>> >>>Regards, >>>Charlie P. > >References: >[1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the >IETF', Mobile Computing and communication review, volume 1, Number 2, >2006. > >Best regards > >Abdussalam Baryun >University of Glamorgan, UK >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >To: "autoconf at ietf.org" >Subject: [Autoconf] closing the working group? >From: Jari Arkko >Date: Tue, 29 Mar 2011 08:48:47 +0200 > >-------------------------------------------------------------------------- >------ >I have looked at the discussions on the list (or lack thereof). I also >cannot see too many internet drafts on the topics belonging to the >group's charter. I am very happy with the RFC that has been produced >by the working group, but we also seem to have some actual protocol >work happening elsewhere (e.g., in the context of the ROLL WG). > >I discussed this matter with the chairs and my co-AD, and we are >wondering if it would be time to close the working group. I do know >that there is at least one implementation team that is still in the >process of describing their DHCP-based solution, maybe there are >similar efforts on the distributed solution space. My proposal is that >we close the working group and I'be VERY happy to AD sponsor all such >solutions to Experimental RFCs as soon as we have those proposals in >some reasonable shape. >Thoughts? > >Jari >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >To: IETF-Announce at ietf.org >Subject: WG Review: Ad Hoc Network configuration (autoconf) >From: The IESG >Date: Wed, 27 Jul 2005 14:28:49 -0400 >Cc: manetautoconf at ml.free.fr >List-help: >List-id: ietf-announce.ietf.org >List-post: >List-subscribe: >, > >List-unsubscribe: >, > >Reply-to: iesg at ietf.org >Sender: ietf-announce-bounces at ietf.org > >-------------------------------------------------------------------------- >------ >A new IETF working group has been proposed in the Internet Area. The >IESG has not >made any determination as yet. The following draft charter was >submitted, and is >provided for informational purposes only. Please send your comments to >the IESG >mailing list (iesg at ietf.org) by August 3rd. > >+++++++++++++ > >Ad Hoc Network configuration (autoconf) >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Current Status: Proposed Working Group > >Chairs: >TBD > >Internet Area Director(s): >Mark Townsley >Margaret Wasserman > >Internet Area Advisor: >Margaret Wasserman > >Mailing Lists: >General Discussion: manetautoconf at ml.free.fr >To Subscribe: manetautoconf-request at ml.free.fr > >Description of the WG: > >In order to communicate among themselves, ad hoc nodes (refer to RFC >2501) may need to configure their network interface(s) with local >addresses that are valid within an ad hoc network. Ad hoc nodes may >also need to configure globally routable addresses, in order to >communicate with devices on the Internet. > >Ad hoc networks present several new challenges. Unlike in traditional >IP networks, each ad hoc node, besides being a traffic end-point, >should be capable of forwarding traffic destined for other hosts. >Additionally, nodes constituting an ad-hoc network do not share access >to a single multicast-capable link for signaling. Many protocol >specifications used in traditional IP networks e.g. RFCs 2462, 2463 >etc. do, however, assume that subnet-local signals (e.g. link-local >multicast signal) are received by each of the hosts on the particular >subnet without being forwarded by the routers defining the subnet >boundary. > >The main purpose of the AUTOCONF WG is to standardize mechanisms to be >used by ad hoc nodes for configuring unique local and/or globally >routable IPv6 addresses. The ad hoc nodes under consideration are >expected to support multi-hop communication by running a MANET routing >protocol, e.g. those developed by the IETF MANET WG. However, this may >or may not mean that an AUTOCONF mechanism will be dependent on any >specific MANET routing protocol. With this in mind, the goals of >AUTOCONF WG are to: > >- Produce a "terminology and problem statement" document, defining the >problem statement and goals for AUTOCONF. > >- Develop an IPv6 stateless autoconfiguration mechanism to be used by >ad hoc nodes for configuring unique local addresses as well as, in >cases where Internet connectivity exists, globally routable unique >addresses. > >- Develop a stateful address autoconfiguration mechanism to be used by >ad hoc nodes for configuring globally routable unique addresses, if an >address providing entity such as DHCPv6 server is available. > >- Develop a mechanism to promote configured address uniqueness in the >situation where different ad hoc networks merge. > >Issues and requirements related to prefix and/or address providing >entities, such as an Internet gateway, will be addressed within the >group to the extent that they are directly related to the AUTOCONF >mechanisms. Security concerns related to AUTOCONF mechanisms will also >be discussed within the group. > >The working group will reuse existing specifications whenever >reasonable and possible. > >Goals and Milestones: > >Oct 05 : Submit "terminology and problem statement" document for WG >review >Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms >and design frameworks >Feb 06: Submit "terminology and problem statement" document to IESG for >publication as an informational RFC >Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" >for WG review >Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" >for WG review >Apr 06: Submit initial -ID of "configured address uniqueness >maintenance" for WG review >Aug 06: Revise WG documents and review >Dec 06 Revise documents based upon implementation experience >Apr 07: Submit "stateless autoconfiguration mechanism" specification >and supporting documentation to IESG for publications as Proposed >Standard >Apr 07: Submit "stateful autoconfiguration mechanism" specification and >supporting documentation to IESG for publications as Proposed Standard >Apr 07: Submit "configured address uniqueness maintenance" >specification and supporting documentation to IESG for publications as >Proposed Standard >Oct 07: Close or recharter the WG > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce at ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce > > > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>> >>>On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>>> Hi All >>>> >>>> I want to discuss this subnet definition issue that was raised in the >>>> 82 meeting, could we discuss about it please. Will we need to put it >>>> in a draft or include it in our active draft working in progress, >>>> please advise, >>>> >>>> Abdussalam Baryun, >>>> University of Glamorgan, UK >>>> ++++++++++++++++++++++++++++++ >>>> >>>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>>> BC> that subnet-models are not defined But in DLEP it looks at two >>>> subnet-models (different models; e.g. radio subnet-models, >>>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>>> is not defined. Then we don=A9=F6t know how to define control protocols, >>>> data-packet-formats, and managements-models without having a subnet >>>> model in mind. >>>> TB> In sat-comms the up-link and down-link can be very different. So >>>> for different nodes on same carrier can be different data rates, SNR, >>>> etc. so it is important that DLEP include the link metrics, even if it >>>> is a full connected subnet. >>>> BC> the subnet depends on the link of the subnet-underlying model, >>>> The semantics of link up and down are determined by the underlying. >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> ******************************************************************** >>>> 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. >>>> ******************************************************************** >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>> >>> >>>-- >>>Regards, >>>Charlie P. >>> >>>_______________________________________________ >>>manet mailing list >>>manet@ietf.org >>>https://www.ietf.org/mailman/listinfo/manet >> >> >> From abdussalambaryun@gmail.com Mon Jun 4 00:17:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3C311E8072; Mon, 4 Jun 2012 00:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 j2-Sab99fdjJ; Mon, 4 Jun 2012 00:17:51 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF8F21F85A4; Mon, 4 Jun 2012 00:17:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2587694vbb.31 for ; Mon, 04 Jun 2012 00:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8aqhCUAkQkiahAlngyxsmMnxYd3VH1Sp2KqZgtlqKw8=; b=CXz0+2OEJz39Yypk1b/L4wjbCvSMKGVrjxvMCiKLB9f5IIoS+quc8OhE1J9dRraycD 6gUngRBNrzPRcJnPH8W4qmWSyDaxVQUUvh5q3oHusfKXErxq8vlSsKsH+wAWBU1YjkIZ hH31vI565Z43fSyy5Q4ocGgUey2WPFlSTuhqLN/8WXuBBbaYy5TDoPI+jO/Qfl/U+CUb TpfPgmFzDQ043Dg2pLkvRYBHoiNq9+bK1/bSFr90jnRpPlxayAXv/NxXG2pZaEpOoss9 NC7uvmbcF4rBQjs/NMzjdhM1n7OBwZG9cYuITVn0hjHWQsu5KBkze4n2eFUk/9eF+Kx2 Zasg== MIME-Version: 1.0 Received: by 10.52.36.116 with SMTP id p20mr9688983vdj.129.1338794270279; Mon, 04 Jun 2012 00:17:50 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Mon, 4 Jun 2012 00:17:50 -0700 (PDT) In-Reply-To: References: <4FCB0261.9020405@computer.org> Date: Mon, 4 Jun 2012 09:17:50 +0200 Message-ID: From: Abdussalam Baryun To: Don Sturek , manet , autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 04 Jun 2012 06:37:21 -0700 Cc: ietf , "Emmanuel.Baccelli" , jari.arkko@piuha.net, Stan Ratliff Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 07:17:52 -0000 Hi Don, and All, I would like to know your opinion about why we don't define subnets for MAN= ET? On 6/3/12, Don Sturek wrote: > +1 > > On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: Could we discuss why we don't define subnets models? I don't understand adding (+1). I hope the chair does not ask me to close this thread too :) The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 so living for about 6 years only. What was the reason for the proposed close of it? please read the DA Jari's reasons below. IMO it because it had low/no useful discussions and only produced one RFC which is RFC5889, why only one? what happend within 6 years? IMO any WG should have more discussions, discussions are mandatory activity for WG. Not discussing issues is like ignoring the value input to group progress. Healthy discussions are more important than producing more documents produced, because discussions are really the source of correct documents (don't mean it has to be perfect, but should not be misleading). WGs should be compared in terms of the amount of discussions not in amount of documents forwarded/submitted. According to Chakeres and Maker (2006) [1] quoated below: [The autoconf WG is chartered to initially develop two documents. The first document is a document defining the MANET architecture and how MANET relates to IP networks and the Internet. The second document is to define the terminology, problem statement and goals for autoconf. These autoconf documents will be discussed on the autoconf mailing list.] That WG did not produce the definition of MANET architecture. Which I think is related to the subnet-model definition importance for MANET. So i understand the authors see the importance of defining something for MANET in 2006. Now, Do we have a network architecture definition of MANET in one RFC? > On 6/2/12 11:21 PM, "Charles E. Perkins" wrote: >>Hello folks, >> >>I would be opposed to requiring the subnet model as a mandatory >>component of any current [manet] working group charter item. >> >>We have had at least ten years of experience showing that requiring >>subnets can derail practically any wireless network discussion within >>the sphere of applicability of manet protocols. The reasons are many >>and varied -- and, I must admit, really very interesting. >> >>It was the death of another working group which really should have >>been allowed to go forward except for disagreements about certain >>subnet-related constructs. Let's not consign ourselves to the same >>fate. In future the death of the WG will be because they don't discuss things on the list, or don't have what to discuss, please read the reasons mentioned by Jari Arkko below. IMO for the future, some day any WGs possibly will close and other days new WGs comes. >> >>Regards, >>Charlie P. References: [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the IETF', Mobile Computing and communication review, volume 1, Number 2, 2006. Best regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: "autoconf at ietf.org" Subject: [Autoconf] closing the working group? From: Jari Arkko Date: Tue, 29 Mar 2011 08:48:47 +0200 ---------------------------------------------------------------------------= ----- I have looked at the discussions on the list (or lack thereof). I also cannot see too many internet drafts on the topics belonging to the group's charter. I am very happy with the RFC that has been produced by the working group, but we also seem to have some actual protocol work happening elsewhere (e.g., in the context of the ROLL WG). I discussed this matter with the chairs and my co-AD, and we are wondering if it would be time to close the working group. I do know that there is at least one implementation team that is still in the process of describing their DHCP-based solution, maybe there are similar efforts on the distributed solution space. My proposal is that we close the working group and I'be VERY happy to AD sponsor all such solutions to Experimental RFCs as soon as we have those proposals in some reasonable shape. Thoughts? Jari +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: IETF-Announce at ietf.org Subject: WG Review: Ad Hoc Network configuration (autoconf) From: The IESG Date: Wed, 27 Jul 2005 14:28:49 -0400 Cc: manetautoconf at ml.free.fr List-help: List-id: ietf-announce.ietf.org List-post: List-subscribe: , List-unsubscribe: , Reply-to: iesg at ietf.org Sender: ietf-announce-bounces at ietf.org ---------------------------------------------------------------------------= ----- A new IETF working group has been proposed in the Internet Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the = IESG mailing list (iesg at ietf.org) by August 3rd. +++++++++++++ Ad Hoc Network configuration (autoconf) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group Chairs: TBD Internet Area Director(s): Mark Townsley Margaret Wasserman Internet Area Advisor: Margaret Wasserman Mailing Lists: General Discussion: manetautoconf at ml.free.fr To Subscribe: manetautoconf-request at ml.free.fr Description of the WG: In order to communicate among themselves, ad hoc nodes (refer to RFC 2501) may need to configure their network interface(s) with local addresses that are valid within an ad hoc network. Ad hoc nodes may also need to configure globally routable addresses, in order to communicate with devices on the Internet. Ad hoc networks present several new challenges. Unlike in traditional IP networks, each ad hoc node, besides being a traffic end-point, should be capable of forwarding traffic destined for other hosts. Additionally, nodes constituting an ad-hoc network do not share access to a single multicast-capable link for signaling. Many protocol specifications used in traditional IP networks e.g. RFCs 2462, 2463 etc. do, however, assume that subnet-local signals (e.g. link-local multicast signal) are received by each of the hosts on the particular subnet without being forwarded by the routers defining the subnet boundary. The main purpose of the AUTOCONF WG is to standardize mechanisms to be used by ad hoc nodes for configuring unique local and/or globally routable IPv6 addresses. The ad hoc nodes under consideration are expected to support multi-hop communication by running a MANET routing protocol, e.g. those developed by the IETF MANET WG. However, this may or may not mean that an AUTOCONF mechanism will be dependent on any specific MANET routing protocol. With this in mind, the goals of AUTOCONF WG are to: - Produce a "terminology and problem statement" document, defining the problem statement and goals for AUTOCONF. - Develop an IPv6 stateless autoconfiguration mechanism to be used by ad hoc nodes for configuring unique local addresses as well as, in cases where Internet connectivity exists, globally routable unique addresses. - Develop a stateful address autoconfiguration mechanism to be used by ad hoc nodes for configuring globally routable unique addresses, if an address providing entity such as DHCPv6 server is available. - Develop a mechanism to promote configured address uniqueness in the situation where different ad hoc networks merge. Issues and requirements related to prefix and/or address providing entities, such as an Internet gateway, will be addressed within the group to the extent that they are directly related to the AUTOCONF mechanisms. Security concerns related to AUTOCONF mechanisms will also be discussed within the group. The working group will reuse existing specifications whenever reasonable and possible. Goals and Milestones: Oct 05 : Submit "terminology and problem statement" document for WG review Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms and design frameworks Feb 06: Submit "terminology and problem statement" document to IESG for publication as an informational RFC Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" for WG review Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" for WG review Apr 06: Submit initial -ID of "configured address uniqueness maintenance" for WG review Aug 06: Revise WG documents and review Dec 06 Revise documents based upon implementation experience Apr 07: Submit "stateless autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "stateful autoconfiguration mechanism" specification and supporting documentation to IESG for publications as Proposed Standard Apr 07: Submit "configured address uniqueness maintenance" specification and supporting documentation to IESG for publications as Proposed Standard Oct 07: Close or recharter the WG _______________________________________________ IETF-Announce mailing list IETF-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> >> >>On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>> Hi All >>> >>> I want to discuss this subnet definition issue that was raised in the >>> 82 meeting, could we discuss about it please. Will we need to put it >>> in a draft or include it in our active draft working in progress, >>> please advise, >>> >>> Abdussalam Baryun, >>> University of Glamorgan, UK >>> ++++++++++++++++++++++++++++++ >>> >>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>> BC> that subnet-models are not defined But in DLEP it looks at two >>> subnet-models (different models; e.g. radio subnet-models, >>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>> is not defined. Then we don=B9t know how to define control protocols, >>> data-packet-formats, and managements-models without having a subnet >>> model in mind. >>> TB> In sat-comms the up-link and down-link can be very different. So >>> for different nodes on same carrier can be different data rates, SNR, >>> etc. so it is important that DLEP include the link metrics, even if it >>> is a full connected subnet. >>> BC> the subnet depends on the link of the subnet-underlying model, >>> The semantics of link up and down are determined by the underlying. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >> >> >>-- >>Regards, >>Charlie P. >> >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > > From sratliff@cisco.com Mon Jun 4 07:28:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6C21F8889; Mon, 4 Jun 2012 07:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, 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 KzoE2YSkOLsP; Mon, 4 Jun 2012 07:28:58 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 13DDB21F8883; Mon, 4 Jun 2012 07:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=8326; q=dns/txt; s=iport; t=1338820138; x=1340029738; h=from:subject:date:message-id:cc:to:mime-version; bh=2DkLthGkQP8+q0e7qun+RnGfxqkTiQW7jNK/+F9v/eE=; b=ihgfhCHyPq9wEkJ6Dl2hSb69FSK3d9KtTr+t7ZsvoLJMffOSZ3UFwS1D kkB6r+4agHgIn98F9wSeZCGfcw/0SxLnMbMOFrZAn/gws6t6TMcHerUMY G/4CIspCH7z/krpaJ9v9bI+Di8vfFsgDqIPvYv+BBM+xo4R9ouQutsMQr M=; X-Files: OLSRv2-writeup.txt : 7330 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAOTEzE+tJXG+/2dsb2JhbABEtCyBB4IxAVMTgVEih2kLlxCfKZBBYAOON4ZkgQ+NAYFmgnw X-IronPort-AV: E=Sophos;i="4.75,713,1330905600"; d="txt'?scan'208";a="89280793" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jun 2012 14:28:57 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q54ESvKC009489; Mon, 4 Jun 2012 14:28:57 GMT From: Stan Ratliff Content-Type: multipart/mixed; boundary="Apple-Mail=_2A49F70F-4BD9-47D6-9E6C-6C1448F5046F" Date: Mon, 4 Jun 2012 10:28:56 -0400 Message-Id: <2C111214-BFA9-455E-AB92-FF503CDAE878@cisco.com> To: ietf-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: manet-chairs@tools.ietf.org, manet IETF Subject: [manet] Please publish draft-ietf-manet-olsrv2-15 as a Standards Track RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:28:59 -0000 --Apple-Mail=_2A49F70F-4BD9-47D6-9E6C-6C1448F5046F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Shepherd's writeup is attached. Regards, Stan --Apple-Mail=_2A49F70F-4BD9-47D6-9E6C-6C1448F5046F Content-Disposition: attachment; filename=OLSRv2-writeup.txt Content-Type: text/plain; name="OLSRv2-writeup.txt" Content-Transfer-Encoding: quoted-printable (1) The request is to publish this document as a Standards Track RFC, = and this is indicated in the document header.=20 OLSRv2 reflects approximately 8 years of experiences with OLSR, = published as experimental RFC3626, and multiple independent = implementations and deployments exist. It is built on the Proposed = Standard "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol = (NHDP)" (RFC 6130) that was spun-off from it. (2) Document Announcement Write-Up. Technical Summary The abstract of this document is included below. =C2=A0=C2=A0This document describes version 2 of the Optimized Link = State Routing (OLSRv2) protocol for mobile ad hoc networks. =C2=A0The = protocol is an=C2=A0optimization of the classical link state algorithm = tailored to the requirements of a mobile wireless LAN. =C2=A0=C2=A0The key optimization of OLSRv2 is that of multipoint relays, = providing an efficient mechanism for network-wide broadcast of = link-state information. =C2=A0A secondary optimization is that OLSRv2 = employs partial link-state information: each node maintains information = of all destinations, but only a subset of links. This allows that = only=C2=A0select nodes diffuse link-state advertisements (i.e. reduces = the number of network-wide broadcasts) and that these advertisements = contain only a subset of links (i.e. reduces the size of each = network-wide broadcast). =C2=A0The partial link-state information thus = obtained allows each OLSRv2 node to at all times maintain optimal (in = terms of number of hops) routes to all destinations in the network. =C2=A0=C2=A0OLSRv2 imposes minimum requirements to the network by not = requiring sequenced or reliable transmission of control traffic. = =C2=A0Furthermore, the only interaction between OLSRv2 and the IP stack = is routing table management. =C2=A0=C2=A0OLSRv2 is particularly suitable for large and dense networks = as the =C2=A0technique of MPRs works well in this context. Working Group Summary o OLSRv2 is the routing protocol, which uses as = constituent parts (and from which was spun off) =C2=A0the already = published by the MANET Working Group RFCs 5148, 5444, 5497, and 6130. The = document also=20 uses RFC 5498 - also already published by the MANET = Working Group. =09 This document is, therefore, an integral part of the = Working Group deliverables, and its publication completes the charter = item of a "proactive MANET protocol". =09 o OLSRv2 was first submitted as an individual draft in = July 2005 (draft-clausen-manet-olsrv2-00), and accepted as a = Working Group document in August 2005. =09 o A key difference between RFC3626 and OLSRv2 is the = introduction of support for link metrics. An individual draft (draft-dearlove-olsrv2-metrics-00) was submitted in = 2007, discussing the design options, culminating in 2010 with draft-dearlove-olsrv2-metrics-05 documenting Working = Group consensus on this matter. Metrics support was, then, folded into = OLSRv2. =09 o This version of OLSRv2 was given a one month WGLC, so as = to ensure sufficient time to review the document. =09 o The Working Group is actively working on the associated = MIB document (draft-ietf-manet-olsrv2-mib) There was an issue concerning the differences between the -14 and -15 = revisions of the document, brought up by one WG member. The consensus = opinion from the WG is that the document should proceed, without = additional edits.=20 Document Quality There is a number of independent implementations of OLSRv2. = Those listed below have, explicitly, consented to be nominatively = mentioned: o Ecole Polytechnique, France=20 (Contact: Thomas Clausen) =09 o CRC - Communications Research Centre Canada=20 (Contact: Yannick Lacharite) =09 o INRIA, France=20 (Contact: Cedric Adjih) =09 o Hitachi Yokohama Research Lab, Japan=20 (Contact: Hiroki Satoh) o BAE Systems Advanced Technology Centre, UK (Contact Christopher Dearlove) Finally, in the open-source world: =09 o Fraunhofer FKIE is working on the olsr.org = implementation of OLSRv2 (Contact: Henning Rogge) =09 o Niigata University, Japan=20 =C2=A0http://www2.net.ie.niigata-u.ac.jp/nuOLSRv2/ (Contact: Hiroei Imai) Over the years, several interoperability events have been = organized, in France, Canada, Japan, Austria, .... Personnel The Document Shepherd is Stan Ratliff (sratliff@cisco.com); the = responsible Area Directors are Adrian Farrel and Stewart Bryant.=20 (3) The document Shepherd has participated in review both in the Working = Group, and has run the "idnits" tool against the draft.=20 (4) The Document Shepherd has no concerns about the reviews of the = document; they have been very thorough. (5) The authors do not believe that additional reviews are required, = aside from the usual directorate reviews during IETF last call.=20 (6) The Document Shepherd has no concerns with the document. (7) All authors have confirmed that they are unaware of any IPR needing = disclosure; there are no known IPR claims related to this document.=20 (8) No IPR disclosures have been filed, as none are required.=20 (9) WG consensus appears to be strong. (10) As mentioned earlier, one WG participant has expressed displeasure = to the AD's. As of this writing, the issue seems to be closed, and no = further action is required.=20 (11) No ID nits were found.=20 (12) Mib Doctor, media type, and URI reviews are not required.=20 (13) All references have been defined as either normative or = informative.=20 (14) No normative references exist to documents not ready for = advancement. Of the normative references, all are to already published = RFC's.=20 (15) This document contains a downref to RFC5148. RFC5148 was published = as "Informational", as this document provides guidance as to how to = schedule message transmissions so as to avoid collisions on some common = (in MANET) media types. As RFC5148 does not prescribe behavior that = impacts interoperability, the understanding with the responsible AD when = publishing RFC5148 was that this would not cause any process-problems so = long as it was called out. (16) Publication of this document will NOT change the status of any = existing RFC. (17) The Document Shepherd has reviewed the IANA considerations section = of the document, and it appears wholly consistent with the body of said = document. Extensions are associated with the appropriate reservations in = IANA registries. All IANA registries have been clearly defined.=20 (18) Impact on IANA registries : =C2=A0=C2=A0This specification defines one Message Type, which must be = allocated from the "Message Types" repository of [RFC5444], two Message = TLV Types, which must be allocated from the "Message TLV = Types"=C2=A0repository of [RFC5444], and four Address Block TLV Types, = which must=C2=A0be allocated from the "Address Block TLV Types" = repository of =C2=A0[RFC5444].=20 =C2=A0=C2=A0Each TLV type incurs creation of a "Type Extension" = registry. This document requests these registry creations, and (by way = of referencing allocation procedures from [RFC5444]) also specifies = allocation policies. =C2=A0=C2=A0Each Message type incurs creation of a Message-Type-specific = TLV registry. This document requests these registry creations, and (by = way of referencing allocation procedures from [RFC5444]) also specifies = allocation policies. =C2=A0=C2=A0IANA registry creation and allocations are done exactly as = in RFC6130. (19) The Document Shepherd has run the idnits tool against the document; = all issues have been resolved.= --Apple-Mail=_2A49F70F-4BD9-47D6-9E6C-6C1448F5046F-- From sratliff@cisco.com Mon Jun 4 11:51:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0C11E80BB for ; Mon, 4 Jun 2012 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 ert6VsZOn++F for ; Mon, 4 Jun 2012 11:51:31 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 40D9811E80B5 for ; Mon, 4 Jun 2012 11:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=14871; q=dns/txt; s=iport; t=1338835885; x=1340045485; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9eRFrApdehs+OGgHC237tzG7IR6as0nEFqgSho1prs4=; b=TylhvDzCECFUbNNhuhbeilLxmovm7GajmafO/bVlvph923T7EfcNk5gt C7OEqTcL0fJX6h+WhAfiDulpRS4urTIanuBkz7pfgTaft1+asqDaEQt5x FyDqmsABAU2xYGxG0c8iOzrxIcPcEIOc6s2hsAqsd7KwTU6arxERh16hg Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALQCzU+tJV2b/2dsb2JhbABFtC+BB4IYAQEBAwEBAQEPATsZBwsFCwsRAQIBAgEMGwcnChUDBggGDwQBCBICBAGHWwMGBQuXG48ThlIFiVaLERqFFmADkT+DXIEPjQGBZoJ8gUM X-IronPort-AV: E=Sophos;i="4.75,714,1330905600"; d="scan'208";a="89144211" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 04 Jun 2012 18:51:24 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q54IpOpF009367; Mon, 4 Jun 2012 18:51:24 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Stan Ratliff In-Reply-To: Date: Mon, 4 Jun 2012 14:51:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> References: <4FCB0261.9020405@computer.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: Jari Arkko , "Emmanuel.Baccelli" , manet IETF Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:51:38 -0000 On Jun 4, 2012, at 3:17 AM, Abdussalam Baryun wrote: > Hi Don, and All, >=20 > I would like to know your opinion about why we don't define subnets = for MANET? >=20 > On 6/3/12, Don Sturek wrote: >> +1 >>=20 >> On 6/2/12 11:21 PM, "Charles E. Perkins" = wrote: >=20 > Could we discuss why we don't define subnets models? I don't > understand adding (+1). I hope the chair does not ask me to close this > thread too :) This co-chair won't ask for the thread to close unless/until it becomes = non-productive=85 >=20 > The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 > so living for about 6 years only. What was the reason for the proposed > close of it? please read the DA Jari's reasons below. For that, I would suggest looking at the group's email archive : = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html >=20 > IMO it because it had low/no useful discussions and only produced one > RFC which is RFC5889, why only one? what happend within 6 years? IMO > any WG should have more discussions, discussions are mandatory > activity for WG. Not discussing issues is like ignoring the value > input to group progress. Healthy discussions are more important than > producing more documents produced, because discussions are really the > source of correct documents (don't mean it has to be perfect, but > should not be misleading). WGs should be compared in terms of the > amount of discussions not in amount of documents forwarded/submitted. >=20 > According to Chakeres and Maker (2006) [1] quoated below: >=20 > [The autoconf WG is chartered to initially develop > two documents. The first document is a document > defining the MANET architecture and how MANET > relates to IP networks and the Internet. The second > document is to define the terminology, problem statement > and goals for autoconf. These autoconf documents > will be discussed on the autoconf mailing list.] >=20 > That WG did not produce the definition of MANET architecture. Which I > think is related to the subnet-model definition importance for MANET. > So i understand the authors see the importance of defining something > for MANET in 2006. Now, Do we have a network architecture definition > of MANET in one RFC? Based on my experiences implementing mobile and ad-hoc networks for my = customers, the main subnet model in use is - "There is NO subnet model = in use". Or rather, "N" subnet models used, depending on the aspects of = the specific deployment, and hence, IMO, the issues in the (now defunct) = working group you mention. The subnet model for any given research = project doesn't match the subnet model necessary for first-responders = (police and fire brigades), which doesn't match the subnet model for = broader disaster response deployments (e.g. Hurricane Katrina), which = doesn't match the subnet model for a military deployment, which *most = definitely* doesn't match the subnet model for a *multi-country* = (military coalition) deployment. It's chaos. Or, possibly, ad-hoc=85 = ;-) I guess it depends on the way you look at it.=20 As someone I know and respect within the IETF says, "In these MANET = networks, you basically wind up throwing host routes around pretty = quickly."=20 Oh, and since you mentioned that you don't understand adding "+1" to an = email - it means that the person *completely agrees* with the earlier = poster. And I completely agree with Charlie - we shouldn't consign = ourselves to the same fate as "The Working Group whose name shall not be = mentioned:=85 Stan >=20 >> On 6/2/12 11:21 PM, "Charles E. Perkins" = wrote: >>> Hello folks, >>>=20 >>> I would be opposed to requiring the subnet model as a mandatory >>> component of any current [manet] working group charter item. >>>=20 >>> We have had at least ten years of experience showing that requiring >>> subnets can derail practically any wireless network discussion = within >>> the sphere of applicability of manet protocols. The reasons are = many >>> and varied -- and, I must admit, really very interesting. >>>=20 >>> It was the death of another working group which really should have >>> been allowed to go forward except for disagreements about certain >>> subnet-related constructs. Let's not consign ourselves to the same >>> fate. >=20 > In future the death of the WG will be because they don't discuss > things on the list, or don't have what to discuss, please read the > reasons mentioned by Jari Arkko below. IMO for the future, some day > any WGs possibly will close and other days new WGs comes. >=20 >>>=20 >>> Regards, >>> Charlie P. >=20 > References: > [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the > IETF', Mobile Computing and communication review, volume 1, Number 2, > 2006. >=20 > Best regards >=20 > Abdussalam Baryun > University of Glamorgan, UK > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > To: "autoconf at ietf.org" > Subject: [Autoconf] closing the working group? > From: Jari Arkko > Date: Tue, 29 Mar 2011 08:48:47 +0200 >=20 > = --------------------------------------------------------------------------= ------ > I have looked at the discussions on the list (or lack thereof). I also > cannot see too many internet drafts on the topics belonging to the > group's charter. I am very happy with the RFC that has been produced > by the working group, but we also seem to have some actual protocol > work happening elsewhere (e.g., in the context of the ROLL WG). >=20 > I discussed this matter with the chairs and my co-AD, and we are > wondering if it would be time to close the working group. I do know > that there is at least one implementation team that is still in the > process of describing their DHCP-based solution, maybe there are > similar efforts on the distributed solution space. My proposal is that > we close the working group and I'be VERY happy to AD sponsor all such > solutions to Experimental RFCs as soon as we have those proposals in > some reasonable shape. > Thoughts? >=20 > Jari > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > To: IETF-Announce at ietf.org > Subject: WG Review: Ad Hoc Network configuration (autoconf) > From: The IESG > Date: Wed, 27 Jul 2005 14:28:49 -0400 > Cc: manetautoconf at ml.free.fr > List-help: > List-id: ietf-announce.ietf.org > List-post: > List-subscribe: > , > > List-unsubscribe: > , > > Reply-to: iesg at ietf.org > Sender: ietf-announce-bounces at ietf.org >=20 > = --------------------------------------------------------------------------= ------ > A new IETF working group has been proposed in the Internet Area. The > IESG has not > made any determination as yet. The following draft charter was > submitted, and is > provided for informational purposes only. Please send your comments to = the IESG > mailing list (iesg at ietf.org) by August 3rd. >=20 > +++++++++++++ >=20 > Ad Hoc Network configuration (autoconf) > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Proposed Working Group >=20 > Chairs: > TBD >=20 > Internet Area Director(s): > Mark Townsley > Margaret Wasserman >=20 > Internet Area Advisor: > Margaret Wasserman >=20 > Mailing Lists: > General Discussion: manetautoconf at ml.free.fr > To Subscribe: manetautoconf-request at ml.free.fr >=20 > Description of the WG: >=20 > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) may need to configure their network interface(s) with local > addresses that are valid within an ad hoc network. Ad hoc nodes may > also need to configure globally routable addresses, in order to > communicate with devices on the Internet. >=20 > Ad hoc networks present several new challenges. Unlike in traditional > IP networks, each ad hoc node, besides being a traffic end-point, > should be capable of forwarding traffic destined for other hosts. > Additionally, nodes constituting an ad-hoc network do not share access > to a single multicast-capable link for signaling. Many protocol > specifications used in traditional IP networks e.g. RFCs 2462, 2463 > etc. do, however, assume that subnet-local signals (e.g. link-local > multicast signal) are received by each of the hosts on the particular > subnet without being forwarded by the routers defining the subnet > boundary. >=20 > The main purpose of the AUTOCONF WG is to standardize mechanisms to be > used by ad hoc nodes for configuring unique local and/or globally > routable IPv6 addresses. The ad hoc nodes under consideration are > expected to support multi-hop communication by running a MANET routing > protocol, e.g. those developed by the IETF MANET WG. However, this may > or may not mean that an AUTOCONF mechanism will be dependent on any > specific MANET routing protocol. With this in mind, the goals of > AUTOCONF WG are to: >=20 > - Produce a "terminology and problem statement" document, defining the > problem statement and goals for AUTOCONF. >=20 > - Develop an IPv6 stateless autoconfiguration mechanism to be used by > ad hoc nodes for configuring unique local addresses as well as, in > cases where Internet connectivity exists, globally routable unique > addresses. >=20 > - Develop a stateful address autoconfiguration mechanism to be used by > ad hoc nodes for configuring globally routable unique addresses, if an > address providing entity such as DHCPv6 server is available. >=20 > - Develop a mechanism to promote configured address uniqueness in the > situation where different ad hoc networks merge. >=20 > Issues and requirements related to prefix and/or address providing > entities, such as an Internet gateway, will be addressed within the > group to the extent that they are directly related to the AUTOCONF > mechanisms. Security concerns related to AUTOCONF mechanisms will also > be discussed within the group. >=20 > The working group will reuse existing specifications whenever > reasonable and possible. >=20 > Goals and Milestones: >=20 > Oct 05 : Submit "terminology and problem statement" document for WG > review > Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF = mechanisms > and design frameworks > Feb 06: Submit "terminology and problem statement" document to IESG = for > publication as an informational RFC > Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" > for WG review > Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" > for WG review > Apr 06: Submit initial -ID of "configured address uniqueness > maintenance" for WG review > Aug 06: Revise WG documents and review > Dec 06 Revise documents based upon implementation experience > Apr 07: Submit "stateless autoconfiguration mechanism" specification > and supporting documentation to IESG for publications as Proposed > Standard > Apr 07: Submit "stateful autoconfiguration mechanism" specification = and > supporting documentation to IESG for publications as Proposed Standard > Apr 07: Submit "configured address uniqueness maintenance" > specification and supporting documentation to IESG for publications as > Proposed Standard > Oct 07: Close or recharter the WG >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce at ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>=20 >>>=20 >>>=20 >>> On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>>> Hi All >>>>=20 >>>> I want to discuss this subnet definition issue that was raised in = the >>>> 82 meeting, could we discuss about it please. Will we need to put = it >>>> in a draft or include it in our active draft working in progress, >>>> please advise, >>>>=20 >>>> Abdussalam Baryun, >>>> University of Glamorgan, UK >>>> ++++++++++++++++++++++++++++++ >>>>=20 >>>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>>> BC> that subnet-models are not defined But in DLEP it looks at two >>>> subnet-models (different models; e.g. radio subnet-models, >>>> sat-subnet-models). We are defining IP over a subnet, but the = subnet >>>> is not defined. Then we don=B9t know how to define control = protocols, >>>> data-packet-formats, and managements-models without having a subnet >>>> model in mind. >>>> TB> In sat-comms the up-link and down-link can be very different. = So >>>> for different nodes on same carrier can be different data rates, = SNR, >>>> etc. so it is important that DLEP include the link metrics, even if = it >>>> is a full connected subnet. >>>> BC> the subnet depends on the link of the subnet-underlying model, >>>> The semantics of link up and down are determined by the underlying. >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>=20 >>>> = ******************************************************************** >>>> 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. >>>> = ******************************************************************** >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>=20 >>>=20 >>> -- >>> Regards, >>> Charlie P. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From boberry@cisco.com Mon Jun 4 12:20:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3921F8703 for ; Mon, 4 Jun 2012 12:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, 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 2KnqB-P68ijJ for ; Mon, 4 Jun 2012 12:20:10 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AE70621F8702 for ; Mon, 4 Jun 2012 12:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=boberry@cisco.com; l=16090; q=dns/txt; s=iport; t=1338837609; x=1340047209; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=PMEgqHb8PaQMEgPn1FpUbBzFlxiFoSEHqWHwHqxYUb4=; b=QzhETV1ervv34IujisClvzMIBmkoMh2KAPn9vgpk4uWv2TNFof2UD7S4 1C5B1DMSdB/uYzDnZlsMXGgMMiEcMI2+x3jIyeVMu1Jm/ctsOet1aiIFZ BlGZgmhNnGi2FEOXcZ+0jkzqgiYF+Zq5T1p3/nXduDFug+/2Ny8D/gnzC c=; X-IronPort-AV: E=Sophos;i="4.75,714,1330905600"; d="scan'208";a="89357519" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jun 2012 19:20:09 +0000 Received: from dhcp-10-150-34-101.cisco.com (dhcp-10-150-34-101.cisco.com [10.150.34.101]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q54JK8i1016203; Mon, 4 Jun 2012 19:20:08 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Bo Berry In-Reply-To: <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> Date: Mon, 4 Jun 2012 15:20:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <95BF575E-9973-4E6B-AC7B-0747B8C0E3FD@cisco.com> References: <4FCB0261.9020405@computer.org> <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Cc: "Emmanuel.Baccelli" , manet IETF , Jari Arkko , Abdussalam Baryun Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 19:20:12 -0000 Stan, On Jun 4, 2012, at 2:51 PM, Stan Ratliff wrote: >=20 > On Jun 4, 2012, at 3:17 AM, Abdussalam Baryun wrote: >=20 >> Hi Don, and All, >>=20 >> I would like to know your opinion about why we don't define subnets = for MANET? >>=20 >> On 6/3/12, Don Sturek wrote: >>> +1 >>>=20 >>> On 6/2/12 11:21 PM, "Charles E. Perkins" = wrote: >>=20 >> Could we discuss why we don't define subnets models? I don't >> understand adding (+1). I hope the chair does not ask me to close = this >> thread too :) >=20 > This co-chair won't ask for the thread to close unless/until it = becomes non-productive=85 >=20 >>=20 >> The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 >> so living for about 6 years only. What was the reason for the = proposed >> close of it? please read the DA Jari's reasons below. >=20 > For that, I would suggest looking at the group's email archive : = http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html A good suggestion. Lots of history here. >=20 >> IMO it because it had low/no useful discussions and only produced one >> RFC which is RFC5889, why only one? what happend within 6 years? IMO >> any WG should have more discussions, discussions are mandatory >> activity for WG. Not discussing issues is like ignoring the value >> input to group progress. Healthy discussions are more important than >> producing more documents produced, because discussions are really the >> source of correct documents (don't mean it has to be perfect, but >> should not be misleading). WGs should be compared in terms of the >> amount of discussions not in amount of documents forwarded/submitted. >>=20 >> According to Chakeres and Maker (2006) [1] quoated below: >>=20 >> [The autoconf WG is chartered to initially develop >> two documents. The first document is a document >> defining the MANET architecture and how MANET >> relates to IP networks and the Internet. The second >> document is to define the terminology, problem statement >> and goals for autoconf. These autoconf documents >> will be discussed on the autoconf mailing list.] >>=20 >> That WG did not produce the definition of MANET architecture. Which I >> think is related to the subnet-model definition importance for MANET. >> So i understand the authors see the importance of defining something >> for MANET in 2006. Now, Do we have a network architecture definition >> of MANET in one RFC? >=20 > Based on my experiences implementing mobile and ad-hoc networks for my = customers, the main subnet model in use is - "There is NO subnet model = in use". Or rather, "N" subnet models used, depending on the aspects of = the specific deployment, and hence, IMO, the issues in the (now defunct) = working group you mention. The subnet model for any given research = project doesn't match the subnet model necessary for first-responders = (police and fire brigades), which doesn't match the subnet model for = broader disaster response deployments (e.g. Hurricane Katrina), which = doesn't match the subnet model for a military deployment, which *most = definitely* doesn't match the subnet model for a *multi-country* = (military coalition) deployment. It's chaos. Or, possibly, ad-hoc=85 = ;-) I guess it depends on the way you look at it.=20 +1, supporting Stan, Charlie, Dan, and others; the manet subnet model is = there are no subnets. > As someone I know and respect within the IETF says, "In these MANET = networks, you basically wind up throwing host routes around pretty = quickly."=20 >=20 > Oh, and since you mentioned that you don't understand adding "+1" to = an email - it means that the person *completely agrees* with the earlier = poster. And I completely agree with Charlie - we shouldn't consign = ourselves to the same fate as "The Working Group whose name shall not be = mentioned:=85 >=20 > Stan >=20 >=20 >>=20 >>> On 6/2/12 11:21 PM, "Charles E. Perkins" = wrote: >>>> Hello folks, >>>>=20 >>>> I would be opposed to requiring the subnet model as a mandatory >>>> component of any current [manet] working group charter item. >>>>=20 >>>> We have had at least ten years of experience showing that requiring >>>> subnets can derail practically any wireless network discussion = within >>>> the sphere of applicability of manet protocols. The reasons are = many >>>> and varied -- and, I must admit, really very interesting. >>>>=20 >>>> It was the death of another working group which really should have >>>> been allowed to go forward except for disagreements about certain >>>> subnet-related constructs. Let's not consign ourselves to the same >>>> fate. >>=20 >> In future the death of the WG will be because they don't discuss >> things on the list, or don't have what to discuss, please read the >> reasons mentioned by Jari Arkko below. IMO for the future, some day >> any WGs possibly will close and other days new WGs comes. >>=20 >>>>=20 >>>> Regards, >>>> Charlie P. >>=20 >> References: >> [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the >> IETF', Mobile Computing and communication review, volume 1, Number 2, >> 2006. >>=20 >> Best regards >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> To: "autoconf at ietf.org" >> Subject: [Autoconf] closing the working group? >> From: Jari Arkko >> Date: Tue, 29 Mar 2011 08:48:47 +0200 >>=20 >> = --------------------------------------------------------------------------= ------ >> I have looked at the discussions on the list (or lack thereof). I = also >> cannot see too many internet drafts on the topics belonging to the >> group's charter. I am very happy with the RFC that has been produced >> by the working group, but we also seem to have some actual protocol >> work happening elsewhere (e.g., in the context of the ROLL WG). >>=20 >> I discussed this matter with the chairs and my co-AD, and we are >> wondering if it would be time to close the working group. I do know >> that there is at least one implementation team that is still in the >> process of describing their DHCP-based solution, maybe there are >> similar efforts on the distributed solution space. My proposal is = that >> we close the working group and I'be VERY happy to AD sponsor all such >> solutions to Experimental RFCs as soon as we have those proposals in >> some reasonable shape. >> Thoughts? >>=20 >> Jari >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> To: IETF-Announce at ietf.org >> Subject: WG Review: Ad Hoc Network configuration (autoconf) >> From: The IESG >> Date: Wed, 27 Jul 2005 14:28:49 -0400 >> Cc: manetautoconf at ml.free.fr >> List-help: >> List-id: ietf-announce.ietf.org >> List-post: >> List-subscribe: >> , >> >> List-unsubscribe: >> , >> >> Reply-to: iesg at ietf.org >> Sender: ietf-announce-bounces at ietf.org >>=20 >> = --------------------------------------------------------------------------= ------ >> A new IETF working group has been proposed in the Internet Area. The >> IESG has not >> made any determination as yet. The following draft charter was >> submitted, and is >> provided for informational purposes only. Please send your comments = to the IESG >> mailing list (iesg at ietf.org) by August 3rd. >>=20 >> +++++++++++++ >>=20 >> Ad Hoc Network configuration (autoconf) >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Current Status: Proposed Working Group >>=20 >> Chairs: >> TBD >>=20 >> Internet Area Director(s): >> Mark Townsley >> Margaret Wasserman >>=20 >> Internet Area Advisor: >> Margaret Wasserman >>=20 >> Mailing Lists: >> General Discussion: manetautoconf at ml.free.fr >> To Subscribe: manetautoconf-request at ml.free.fr >>=20 >> Description of the WG: >>=20 >> In order to communicate among themselves, ad hoc nodes (refer to RFC >> 2501) may need to configure their network interface(s) with local >> addresses that are valid within an ad hoc network. Ad hoc nodes may >> also need to configure globally routable addresses, in order to >> communicate with devices on the Internet. >>=20 >> Ad hoc networks present several new challenges. Unlike in traditional >> IP networks, each ad hoc node, besides being a traffic end-point, >> should be capable of forwarding traffic destined for other hosts. >> Additionally, nodes constituting an ad-hoc network do not share = access >> to a single multicast-capable link for signaling. Many protocol >> specifications used in traditional IP networks e.g. RFCs 2462, 2463 >> etc. do, however, assume that subnet-local signals (e.g. link-local >> multicast signal) are received by each of the hosts on the particular >> subnet without being forwarded by the routers defining the subnet >> boundary. >>=20 >> The main purpose of the AUTOCONF WG is to standardize mechanisms to = be >> used by ad hoc nodes for configuring unique local and/or globally >> routable IPv6 addresses. The ad hoc nodes under consideration are >> expected to support multi-hop communication by running a MANET = routing >> protocol, e.g. those developed by the IETF MANET WG. However, this = may >> or may not mean that an AUTOCONF mechanism will be dependent on any >> specific MANET routing protocol. With this in mind, the goals of >> AUTOCONF WG are to: >>=20 >> - Produce a "terminology and problem statement" document, defining = the >> problem statement and goals for AUTOCONF. >>=20 >> - Develop an IPv6 stateless autoconfiguration mechanism to be used by >> ad hoc nodes for configuring unique local addresses as well as, in >> cases where Internet connectivity exists, globally routable unique >> addresses. >>=20 >> - Develop a stateful address autoconfiguration mechanism to be used = by >> ad hoc nodes for configuring globally routable unique addresses, if = an >> address providing entity such as DHCPv6 server is available. >>=20 >> - Develop a mechanism to promote configured address uniqueness in the >> situation where different ad hoc networks merge. >>=20 >> Issues and requirements related to prefix and/or address providing >> entities, such as an Internet gateway, will be addressed within the >> group to the extent that they are directly related to the AUTOCONF >> mechanisms. Security concerns related to AUTOCONF mechanisms will = also >> be discussed within the group. >>=20 >> The working group will reuse existing specifications whenever >> reasonable and possible. >>=20 >> Goals and Milestones: >>=20 >> Oct 05 : Submit "terminology and problem statement" document for WG >> review >> Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF = mechanisms >> and design frameworks >> Feb 06: Submit "terminology and problem statement" document to IESG = for >> publication as an informational RFC >> Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" >> for WG review >> Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" >> for WG review >> Apr 06: Submit initial -ID of "configured address uniqueness >> maintenance" for WG review >> Aug 06: Revise WG documents and review >> Dec 06 Revise documents based upon implementation experience >> Apr 07: Submit "stateless autoconfiguration mechanism" specification >> and supporting documentation to IESG for publications as Proposed >> Standard >> Apr 07: Submit "stateful autoconfiguration mechanism" specification = and >> supporting documentation to IESG for publications as Proposed = Standard >> Apr 07: Submit "configured address uniqueness maintenance" >> specification and supporting documentation to IESG for publications = as >> Proposed Standard >> Oct 07: Close or recharter the WG >>=20 >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce at ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf-announce >>=20 >>=20 >>=20 >>=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>>>=20 >>>>=20 >>>>=20 >>>> On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>>>> Hi All >>>>>=20 >>>>> I want to discuss this subnet definition issue that was raised in = the >>>>> 82 meeting, could we discuss about it please. Will we need to put = it >>>>> in a draft or include it in our active draft working in progress, >>>>> please advise, >>>>>=20 >>>>> Abdussalam Baryun, >>>>> University of Glamorgan, UK >>>>> ++++++++++++++++++++++++++++++ >>>>>=20 >>>>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>>>> BC> that subnet-models are not defined But in DLEP it looks at = two >>>>> subnet-models (different models; e.g. radio subnet-models, >>>>> sat-subnet-models). We are defining IP over a subnet, but the = subnet >>>>> is not defined. Then we don=B9t know how to define control = protocols, >>>>> data-packet-formats, and managements-models without having a = subnet >>>>> model in mind. >>>>> TB> In sat-comms the up-link and down-link can be very different. = So >>>>> for different nodes on same carrier can be different data rates, = SNR, >>>>> etc. so it is important that DLEP include the link metrics, even = if it >>>>> is a full connected subnet. >>>>> BC> the subnet depends on the link of the subnet-underlying = model, >>>>> The semantics of link up and down are determined by the = underlying. >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>=20 >>>>> = ******************************************************************** >>>>> 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. >>>>> = ******************************************************************** >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Regards, >>>> Charlie P. >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet ---- boberry@cisco.com This email may contain confidential and privileged material for the sole = use of the intended recipient. This email may contain information that = is protected by NDA. Any unauthorized review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. From valerio.arnaboldi@iit.cnr.it Tue Jun 5 02:07:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A0421F8683 for ; Tue, 5 Jun 2012 02:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 TP09QKTUdXAP for ; Tue, 5 Jun 2012 02:07:36 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id 758D721F8711 for ; Tue, 5 Jun 2012 02:07:34 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id C9A723D826F; Tue, 5 Jun 2012 11:07:01 +0200 (CEST) Date: Tue, 05 Jun 2012 11:07:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4fcdcc35.FxZfFaidaJd7NJV9%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] SustainIT 2012 - Call for short papers and demos - Deadline fast approaching X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:07:38 -0000 [Apologies for possible multiple copies] ------------------------------------------------------------------------ Call for WORK-IN-PROGRESS papers and DEMOS SustainIT 2012 Second IFIP Conference on Sustainable Internet and ICT for Sustainability http://cnd.iit.cnr.it/sustainit2012/ October 4-5, 2012 Pisa, Tuscany, Italy ******* WIP/DEMO PAPER SUBMISSION DEADLINE: June 11, 2012 ******* Conference proceedings in IEEE Xplore ------------------------------------------------------------------------ SustainIT 2012 invites Work in Progress (WIP) papers and technical demonstrations (DEMOs) showing innovative and original research in the areas of Sustainable Internet and ICT for Sustainability. Submissions from both industry and academia are strongly encouraged. WIP papers are expected to report on early or ongoing research activities, while DEMO papers are expected to present innovative applications and tools. The WIP and DEMO sessions will provide a forum to discuss novel ideas and emerging results, presenting innovative applications and tools, and bring about novel research questions, approaches, and directions. TOPICS: Topics of interest include, but are not limited to: - Green Internet - Power-aware Internet applications - Energy-efficient network architecture and protocols - Green wireless networking - Energy-efficient network technologies - Cross-layer optimization for green networking - Standards and metrics for green communications - Energy-efficient management of network resources - Energy efficiency in data centers - Energy efficiency, Quality of Service, and reliability - Algorithms for reduced power, energy and heat - ICT for energy efficiency in buildings - ICT for sustainable smart cities - ICT for sustainable transports and logistics - ICT for green mobility - ICT for energy efficiency in industrial environments - ICT for smart grids - Sustainability achievements due to ICT-based optimization - Energy consumption measurements, models, and monitoring tools - Measurement and evaluation of the Internet sustainability - Test-bed and prototype implementations SUBMISSION GUIDELINES: Authors are requested to submit original, unpublished manuscripts in standard IEEE proceedings format in PDF. The IEEE LaTeX and Microsoft Word templates, as well as related information, can be found at the IEEE Computer Society website (http://www.computer.org/portal/web/cscps/formatting). Submitted papers must include the contact information of all the authors. Manuscripts must be submitted electronically through EDAS. When submitting, please select the appropriate Track for your paper (i.e., WIP or Demo). WIP papers must be, at most, 5 pages in size (including figures, tables, and references). They are expected to present early or ongoing research activities. Novel approaches and preliminary results are especially appreciated. Demo papers must be up to 4 pages in size (including figures, tables, and references). They should explicitly state what will be demonstrated to the audience, and how the attendees will be able to interact, enjoy, and experiment. The submitted manuscripts will be reviewed by members of the SustainIT 2012 Technical Program Committee. All the accepted papers will be presented during the conference. At least one author of each accepted paper must register and attend the conference to present it. The accepted papers will be published in the conference proceedings by IEEE, and will be included in the Digital Library. IMPORTANT DATES: Paper submissions: June 11, 2012 Notification of acceptance: July 15, 2012 Camera-ready copy due: July 30, 2012 Conference date: October 4-5, 2012 ============================================== Valerio Arnaboldi - SUSTAINIT2012 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: +39 050 315 2195 email: valerio.arnaboldi@iit.cnr.it From abdussalambaryun@gmail.com Tue Jun 5 02:18:24 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B8921F86C5 for ; Tue, 5 Jun 2012 02:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fCMYMvwhvVtx for ; Tue, 5 Jun 2012 02:18:23 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79D1A21F86B9 for ; Tue, 5 Jun 2012 02:18:23 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3384489vbb.31 for ; Tue, 05 Jun 2012 02:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BcuFr3qtlpe56xEgulZiL3amQRnE9sZRLwb9bOZUOM4=; b=C0iM6LKe4o/tRJLBEDEWg82NBN6QcKBiITV8Y29hwk8yVcGA8TJiK5ZflxSDVEet3k RJiI9hV3ezt/mItaNmVicQgB+7bmqY0Kem9YkI2MwN2injDrvrU9YG1ttDpdE5ZST4p7 YBaoDKYlw3v8I6rjLlug9VnIioCTQbAmvJCy+irh8nEPemdMG9LNO4MFVEExVnHBVK7a YywH8B4KxdW7VIR8OOyDPDMXIZQnnnuTGNflkupZyCP4cAHWDie31OBtis4gFECkZJKK 9/45oNH8Ag3QfLmhBw5032KC5lK/zCd7p8bTrY0ENekhffNfK5I1O1fL6IulQ2IW0SR7 tV5Q== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr13443899vdb.66.1338887902899; Tue, 05 Jun 2012 02:18:22 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 5 Jun 2012 02:18:22 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 11:18:22 +0200 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:18:24 -0000 Hi Don, I agree to oppose as well, it was not my idea in the first place, Robert Cole presented the interest-input to the WG 82 meeting and I found that not much discussed it or covered the issue so far, I needed to see the response more clear from the WG, however, I don't intend to want to leave it open without quick close and understanding. In the same time, I really see in the draft authored by Emmanual and Perkins, regarding models, which it gives examples about *often* physical-subnets of MANET, this input draft plus DLEP, and the input of Mr.Cole and others input in the meeting, made me think to discuss about the MANET definitions and assumptions but NOT the specifications. Please note that we have two drafts that define possible MANET subnets or *often* subnets, [DLEP] and [draft-baccelli-manet-multihop-communication-01]. Therefore, the question and confusion of Mr.Cole may happen to any one or many memebr in the future while reading our standards and specifications, I RECOMMEND to find a way to solve this issue, or that I draft one informative track document that contains *often* and Sat-com possible MANET subnets. Best regards Abdussalam Baryun ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/4/12, Don Sturek wrote: > I am opposed to tying any subnet model to work within MANET. > > That said, individual drafts can be created by anyone..... > > Don > > > > On 6/4/12 12:40 AM, "Abdussalam Baryun" wrote: > >>Hi All, >> >>After many aposes, maybe we can draft a work of defining the >>subnet-model for MANET, without in any draft, maybe this way it will >>be better for all, then we discuss the new draft issue only without >>mixing with other concepts of protocols. >> >>If you give me a go ahead I will do that, >> >>Regards >>Abdussalam >>_______________________________________________ >>manet mailing list >>manet@ietf.org >>https://www.ietf.org/mailman/listinfo/manet > > > From henning.rogge@fkie.fraunhofer.de Tue Jun 5 02:27:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263221F86A2 for ; Tue, 5 Jun 2012 02:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.269 X-Spam-Level: X-Spam-Status: No, score=-1.269 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_PBL=0.905] 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 NRKs5QoQTcnO for ; Tue, 5 Jun 2012 02:27:12 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [IPv6:2001:638:401:102:1aa9:5ff:fe5f:7f22]) by ietfa.amsl.com (Postfix) with ESMTP id BF00D21F869C for ; Tue, 5 Jun 2012 02:27:11 -0700 (PDT) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fkie.fraunhofer.de) by a.mx.fkie.fraunhofer.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Sbq2g-0004ir-9k for manet@ietf.org; Tue, 05 Jun 2012 11:27:10 +0200 Received: from mailserv1.fkie.fgan.de ([128.7.96.101] helo=mailserv1.lorien.fkie.fgan.de) by mailhost.fkie.fraunhofer.de with esmtp (Exim 4.72) (envelope-from ) id 1Sbq2g-0005lo-7A for manet@ietf.org; Tue, 05 Jun 2012 11:27:10 +0200 Received: from MAILSERV2ACAS.lorien.fkie.fgan.de ([128.7.96.54]) by mailserv1.lorien.fkie.fgan.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jun 2012 11:27:10 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 5 Jun 2012 11:27:09 +0200 Message-ID: <4FCDD0EC.6080802@fkie.fraunhofer.de> Date: Tue, 5 Jun 2012 11:27:08 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120602 Thunderbird/13.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060802070500090000060208" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 05 Jun 2012 09:27:10.0021 (UTC) FILETIME=[61E59F50:01CD42FD] X-Virus-Scanned: yes (ClamAV 0.97.3/15003/Tue Jun 5 10:12:08 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ce4bc42c0f341c6b36ab5749a0b03868 Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:27:13 -0000 --------------ms060802070500090000060208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 06/05/2012 11:18 AM, Abdussalam Baryun wrote: > Hi Don, > > I agree to oppose as well, it was not my idea in the first place, > Robert Cole presented the interest-input to the WG 82 meeting and I > found that not much discussed it or covered the issue so far, I needed > to see the response more clear from the WG, however, I don't intend to > want to leave it open without quick close and understanding. Either you oppose it or not... saying you oppose it but pushing for=20 doing it anyways is self-contradicting. The fate of the Autoconf group shows that trying to nail down the=20 subnet-definition of Manet is both very time-consuming, frustrating and=20 nearly pointless. Manets have proven to work with nearly any kind of subnet setting,=20 because many of them just work with host-routes. Henning Rogge --=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-961, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --------------ms060802070500090000060208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUYDCC BC4wggMWoAMCAQICAgEMMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQK ExNEZXV0c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVy MSMwIQYDVQQDExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNzEyMDUxNTE4NTha Fw0xOTA2MzAyMzU5NTlaMGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMSEw HwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9mZXIg Um9vdCBDQSAyMDA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwz0eyWWNW4g3 9z7BIbZU3rA6VxsaHO6YCHQBWm+13zZXK0RFzvNGE2V2lZhUx6iFFW4SpBfoC+EhpzE9Kd3/ o9ZP0rSJ/WNK2qtT71kFtE/iOyqRmcDLZVeBozCTkA7Jvf0VMjIIpEh8VgXyuzaJ4kjCb0uS DCVFvq0+1McB7bHIErQwCG6nb396IKe7tOU1gFQsGY/ZS8Adq0P4YRSU+7AdXbeR7GLAkdFe 3acLsy0fZjkYPK4EFOXSfTbZss2nE7DMRZ1WBFFxMzZcL11RE55PSJAOl1pLcNu5edmh1pTI ktCl+2C/La2ecQAXhsD9SGadFEwFTkzRcUQL0HoPsQIDAQABo4HZMIHWMB8GA1UdIwQYMBaA FDHDeRu69VPXF+CJei0XbAqzK50zMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUL0VCHjEF gNVw2PgdV8tbetU9nPcwEgYDVR0TAQH/BAgwBgEB/wIBATBwBgNVHR8EaTBnMGWgY6Bhhl9o dHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2aWNlL2FmX0Rvd25sb2FkQVJMLmNy bD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVyPURUX1JPT1RfQ0FfMjANBgkqhkiG9w0BAQUF AAOCAQEAGrdMejzl3cJjst6GJU5FYkz08o9fXdfljc4O1/WU4YuTMTanmiPnZ+FSwVoY1pnh gGQ4D0o1M11meijcOH83cs1SdW4Qjmx9jPcp63fCuRkF1Lc9YbroBRLUUGJT7yJUYvxNAcNe 1A2DdGlR1TyerNukK3xthJbTcU3P1S1xo5LEP1XPmz0jdwdX6cjOHZe2M/uRl2CWD/f23m8l kBKrGUfVRCOuwZI1KL8qQ14P6gdd0kTQhYLjErxH6iyt+PBBUn02uiKfeqAy70u8+ToHtinG fThfNVV+OPI/fLPuLW4heF+5E8/v3mWAyCX1Zi1USq3O2S4OMM+AM6eLGXLqQTCCBMYwggOu oAMCAQICCmEdMxkAAAAAAAMwDQYJKoZIhvcNAQEFBQAwZzELMAkGA1UEBhMCREUxEzARBgNV BAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4G A1UEAxMXRnJhdW5ob2ZlciBSb290IENBIDIwMDcwHhcNMDcxMjEyMTQ0OTM1WhcNMTkwNjMw MjM1OTU5WjBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMY RnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0Eg MjAwNzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMJ0EFHLddGB8Ss1nVqCOq+S rs0C/K7I+yB3Dv9oEhWQSadnfGgkX/oOJhplPkqeCQrTh08zEYprVaJLTaVPVhvjx3h5+KML 3lVGZIfajA89TolhLwk+ml29VbqV5nLhNrSwdZy157b6dCu5JffxvpO5wXCn95Z/TLyLdeux gVHs/MnhczvmBbBRS+Ow9UoKn+PZvyYmUEdOHg8cA5PGFaRP9q88q734VnlI+W4+y7BoN5wt uqVrqWbbpOQ2sHYo9riv3b+x5WdsMrVieKGApQ/dNvgB5vuuAchRnsANZHgpAiPCzP7/QFYY qk2undcxEXwPgo72oifB3uQZ3xHOV/cCAwEAAaOCAXIwggFuMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFE8dr4jKbbiqHAn5xdER7Vm0k/oLMA4GA1UdDwEB/wQEAwIBBjAfBgNV HSMEGDAWgBQvRUIeMQWA1XDY+B1Xy1t61T2c9zB1BgNVHR8EbjBsMGqgaKBmhjFodHRwOi8v Y3JsLnBraS5mcmF1bmhvZmVyLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JshjFodHRwOi8vY3Js LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy1yb290LWNhLTIwMDcuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXJv b3QtY2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtp LmRlL2ZoZy1yb290LWNhLTIwMDcuY2VyMA0GCSqGSIb3DQEBBQUAA4IBAQAAd2yMM/nuVwQl ysuIOeZOTKTOwpZLGYZNuERXwpWpEDfsMFUxX/Wetbu1a1qhd+x6SyXY4V1CzcFDOGF3wA7b yIV/6dyC53I9luZTjy9zjUsjLZucD4jeNja3QEu39sQsYsuE3MTfFFJgr/NeAFMHVkkHGx3l VXb+F3J3+9xeXHk/wB/yIKd/RIiMMTT4+a+ra2MTCsYAe4kgJ0vz2TXYGN8tujjCgsUUbwfJ C9wrOiCJMNJM1i7sUVqVKIoswW7h5QpWUNu1E4RAsDEz7depXCYaAIwPprEIkr0dE63zqHhm M4egS7iGmBfNQohUO6jJOWNcJ9dIxqc0c/4WUHg8MIIFqDCCBJCgAwIBAgIKNBvreAAAAAC6 5zANBgkqhkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEh MB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVy IFVzZXIgQ0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNV BAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQ ZW9wbGUxFjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDGyBP1VGWGIStoEyrMjSDmeQ+tJOnuPlNL8ZOMqGLCbKviFnpW66uAOFMy6XPs lEtkkxcmoTCMQGo+IegZMSSAeXXro/+XHY6v6P1eIc9g/EmMM69GRayvD5Ja6LJpxuuhJNoP DPucDfxHbuNdRIQrKLRKaFdiIFQiGHX+wR/+4OaL2gGF+PqA6PMz+8szs0mqLvQITpQxrQ+H xHsf6vBheFCVVZnNScq+3o4kUngcsm+brEet6I6tT3uQ+XCLdhBlTELjf2Bg9jTCYUSZ100c 5DZ+O2ShBhH0iAZZ8/e9tDydfFRMiU6FLnH2xJpJT+lNgEm/vFjKM+tL1IgaXlupAgMBAAGj ggJhMIICXTAOBgNVHQ8BAf8EBAMCBsAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2ll LmZyYXVuaG9mZXIuZGUwHQYDVR0OBBYEFAF+BKuwGS5faYqP3YNRvNbSLSvzMB8GA1UdIwQY MBaAFE8dr4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwu cGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJh dW5ob2Zlci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB +jA+BggrBgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXIt Y2EtMjAwNy5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRl L2ZoZy11c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2Et MjAwNy5vY3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11 c2VyLWNhLTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wEwYDVR0lBAwwCgYIKwYBBQUH AwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRwOi8vcGtp LmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQA5rI5kuTR9B+FDsjRDOfor O4PiLGvO15JchMe7VEn3/fF5umUSbpgj+PAws0Wd+CVer70j6saMT8/FI5bqorwIDfUMijyp eGzG+98XfKsXMcvODIJxZ2jF6vZi98qkkl/HQEo8Yy+4B5Mmnkv4+5ZwaS+YNv/BHAAk5+M1 KiQ11zbuTdP4dO1c2wytDMZZ4hkWcr6lJCb+BagNft01kTn3b8OrxGnzeN53CXkIMEp3QHo8 MIzu+wQD0/70v3/XjYf/W7qBhU2VHsaGyMKNS2y+kNmsw80B3bBUA+iqInRat8b8gS4DlLJK 575p5+Vu8zENPVxYWeKCGJq1ZhvHA2Y8MIIFtDCCBJygAwIBAgIKNBvo6AAAAAC65jANBgkq hkiG9w0BAQUFADBnMQswCQYDVQQGEwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UE CxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIg Q0EgMjAwNzAeFw0xMDAyMDExMTQwMzRaFw0xNjAxMzExMTQwMzRaMFoxCzAJBgNVBAYTAkRF MRMwEQYDVQQKEwpGcmF1bmhvZmVyMQ0wCwYDVQQLEwRGS0lFMQ8wDQYDVQQLEwZQZW9wbGUx FjAUBgNVBAMTDUhlbm5pbmcgUm9nZ2UwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCiy6VbXF1fXG4ehffqb8Dr1J8PC9+xeatiAjSqFIOCi9GdbFPrh3EIrb69T4uyQ+ejWbRE lNFsqBWjo7yPX+hT84FWmLzYMz3uZYxTFgSnB4ot2r5E5Nk9TAVjxB/PwQn9xmPKsQFizw3E B9E8VFYZ34GuQo0i8H2avvs9Br+sD6oS41OYpjQ1uXhUCDCYZXftEUDYIvPfzBzji6WgkkrJ ggDsJsgxp7eSNQrL1hjnmTKOAJjdzbX9hXiu44TAG73J8QGbHHQTU/T98Hsbf7t3qQEv5q8/ 9CHBiZ0mMWxqthKZSlen0/X5zwcVPDlNgZQu2Px/8VZCWZGNYPNJy3h5AgMBAAGjggJtMIIC aTAOBgNVHQ8BAf8EBAMCBDAwKwYDVR0RBCQwIoEgaGVubmluZy5yb2dnZUBma2llLmZyYXVu aG9mZXIuZGUwHQYDVR0OBBYEFGKv/4QFgBRbo8Gnqxgea4ZfX5+yMB8GA1UdIwQYMBaAFE8d r4jKbbiqHAn5xdER7Vm0k/oLMHUGA1UdHwRuMGwwaqBooGaGMWh0dHA6Ly9jcmwucGtpLmZy YXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmyGMWh0dHA6Ly9jcmwuZnJhdW5ob2Zl ci1wa2kuZGUvZmhnLXVzZXItY2EtMjAwNy5jcmwwggEKBggrBgEFBQcBAQSB/TCB+jA+Bggr BgEFBQcwAoYyaHR0cDovL2NlcnQucGtpLmZyYXVuaG9mZXIuZGUvZmhnLXVzZXItY2EtMjAw Ny5jZXIwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jZXJ0LmZyYXVuaG9mZXItcGtpLmRlL2ZoZy11 c2VyLWNhLTIwMDcuY2VyMDsGCCsGAQUFBzABhi9odHRwOi8vZmhnLXVzZXItY2EtMjAwNy5v Y3NwLnBraS5mcmF1bmhvZmVyLmRlLzA7BggrBgEFBQcwAYYvaHR0cDovL2ZoZy11c2VyLWNh LTIwMDcub2NzcC5mcmF1bmhvZmVyLXBraS5kZS8wHwYDVR0lBBgwFgYKKwYBBAGCNwoDBAYI KwYBBQUHAwQwRAYDVR0gBD0wOzA5BgsrBgEEAYYKUAMBATAqMCgGCCsGAQUFBwIBFhxodHRw Oi8vcGtpLmZyYXVuaG9mZXIuZGUvY3AvMA0GCSqGSIb3DQEBBQUAA4IBAQAE9gjUduqKmz/S j7aboa7DDvKz/kX76pJg+rrDgK2XK4+6ktl0rMRW5nafV+ilm4Sd1PIJOrwNQnBlco8QhgpA aGRsU3LcgNocHlUdpfQmypXgOyAPpdraOcQFCmLLxHEwo/mZjk1FLiM7on5sWOsyIpuMOXO8 knHLqSrLx5+PEfpF0yMbFBFwxLgRROzsNG7fwDzVcQZqqq2NzA3efcS8lRVwHNefrcGZvhuC /VToNhcUxIxySyyxqmax0vQQ9coBYFFyzCi562NEFcgV+7XEoUg23DJrHpEJnJwARd10ULqP /cFW+LqI0VITVVVDH4dDPUSEYFynzRbeqci+g7VSMYIDezCCA3cCAQEwdTBnMQswCQYDVQQG EwJERTETMBEGA1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3Jh dGUgUEtJMSAwHgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvreAAAAAC65zAJ BgUrDgMCGgUAoIIB2zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjA2MDUwOTI3MDhaMCMGCSqGSIb3DQEJBDEWBBRH/uD4Rk27n4CLNdOCWPDaqvarADBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIGEBgkrBgEEAYI3EAQxdzB1MGcxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpGcmF1bmhvZmVy MSEwHwYDVQQLExhGcmF1bmhvZmVyIENvcnBvcmF0ZSBQS0kxIDAeBgNVBAMTF0ZyYXVuaG9m ZXIgVXNlciBDQSAyMDA3Ago0G+joAAAAALrmMIGGBgsqhkiG9w0BCRACCzF3oHUwZzELMAkG A1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZyYXVuaG9mZXIgQ29y cG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIwMDcCCjQb6OgAAAAA uuYwDQYJKoZIhvcNAQEBBQAEggEAODvMGL0aN7ywlsIYFdlresG1EBAK9UH7SClkIhtmreb5 WdmH/Sbj8dNluOJsZ9pPeAHt8RC8qIoXWfTHiHIzwpOS7K/dAElUM1Uu1mUiZNdqdfM4QB/T KIa/h8MWJxOWKgyioYt2LsEOq0fdtRuShDi0lwZqK0Oc+ZGPTmUEj1lRPjDJ01Io6tN8eGY/ kVMHeIT2Dw53Gf4yWsNwOa2NXKpOTOSQjFvyTUHmbNvmlSEMN2s+X1Tf1UxPrapKXd1dqxME LwsJl3V9rcGBUGrmeQqpt4qykRq/kghDSLRNuR7BufK/r3xiAoS8vpYymd3KxIVyXSFv8fY1 c1zVjInV4wAAAAAAAA== --------------ms060802070500090000060208-- From abdussalambaryun@gmail.com Tue Jun 5 02:50:04 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999BD21F8621 for ; Tue, 5 Jun 2012 02:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.188 X-Spam-Level: X-Spam-Status: No, score=-3.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 mw0uPYO39Wa9 for ; Tue, 5 Jun 2012 02:50:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B15B021F8620 for ; Tue, 5 Jun 2012 02:50:02 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3398593vbb.31 for ; Tue, 05 Jun 2012 02:50:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Kjk0IdYNHgu8Q5fl0LPWI6PkU9M9rTraLLgZCK3mlsc=; b=o4przUWgGzY8PJIMAp3eYMLaxUYJWc0m0eCCIhiwdkoALaC2ufQqopRgIbR5tnXYyq kzRxBMbnQROBlGO+Ke2lH2YARYZ80cRFLjmjqD4iNT/YLHPYAf4XGplwG8VP5HHo4/xH hbWIKYq5AQcApYxgncc3VZnv9o5RYIrpDWxjx6buoYX55hXar6Xb7siJDLQxhbFzKVJ3 p4B130hlkG/EjRb8cVVSgYNPmIqLFQhU8TnS8h2snciPHNA8Md0Gaudx+ayZnr88SDH8 p+XxN5Xwc4LDxARrkwIM+O5ZJZm8qeT+nIeXdC4weBeMqAO0dRi5UyLjomOey4wn4Hm3 kbSQ== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr15585631vcv.12.1338889802027; Tue, 05 Jun 2012 02:50:02 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 5 Jun 2012 02:50:01 -0700 (PDT) In-Reply-To: <95BF575E-9973-4E6B-AC7B-0747B8C0E3FD@cisco.com> References: <4FCB0261.9020405@computer.org> <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> <95BF575E-9973-4E6B-AC7B-0747B8C0E3FD@cisco.com> Date: Tue, 5 Jun 2012 11:50:01 +0200 Message-ID: From: Abdussalam Baryun To: Bo Berry , Stan Ratliff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "Emmanuel.Baccelli" , manet IETF Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 09:50:04 -0000 Hi Stan and Bo, +1 Furthermore, I was thinking of two level models one logical level and the other physical (as Mrs.Sue has mention in the 82 meeting), but both are not reality model (i.e. wireless+mobility=3D unstable systems), and the physical model is closer to the real one. The logical model is the specification implementation and knowledge. Also was thinking not to mix between specifications and use-case informations. The issue I think is that most of our protocols are general purpose MANET protocols which after Mr.Perkins comments I now wanted them to stay and think of a way to avoid memebrs confusion, because you cannot ignore such issue and still people waste time not benefiting from old efforts or discussions. Therefore, I RECOMMENT the draft authored by Emmanuel about MANET-models, to mention that it specifies the most possible MANET models (not all models) as logical-models, because new protocols may have new logical models. Overall, I am happy with our outcome so far of the discussion. Thank you Stan to tell me about things that help me understand :) Abdussalam Baryun University of glamorgan ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/4/12, Bo Berry wrote: > Stan, > > > On Jun 4, 2012, at 2:51 PM, Stan Ratliff wrote: > >> >> On Jun 4, 2012, at 3:17 AM, Abdussalam Baryun wrote: >> >>> Hi Don, and All, >>> >>> I would like to know your opinion about why we don't define subnets for >>> MANET? >>> >>> On 6/3/12, Don Sturek wrote: >>>> +1 >>>> >>>> On 6/2/12 11:21 PM, "Charles E. Perkins" wrote= : >>> >>> Could we discuss why we don't define subnets models? I don't >>> understand adding (+1). I hope the chair does not ask me to close this >>> thread too :) >> >> This co-chair won't ask for the thread to close unless/until it becomes >> non-productive=85 >> >>> >>> The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011 >>> so living for about 6 years only. What was the reason for the proposed >>> close of it? please read the DA Jari's reasons below. >> >> For that, I would suggest looking at the group's email archive : >> http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html > > A good suggestion. Lots of history here. > >> >>> IMO it because it had low/no useful discussions and only produced one >>> RFC which is RFC5889, why only one? what happend within 6 years? IMO >>> any WG should have more discussions, discussions are mandatory >>> activity for WG. Not discussing issues is like ignoring the value >>> input to group progress. Healthy discussions are more important than >>> producing more documents produced, because discussions are really the >>> source of correct documents (don't mean it has to be perfect, but >>> should not be misleading). WGs should be compared in terms of the >>> amount of discussions not in amount of documents forwarded/submitted. >>> >>> According to Chakeres and Maker (2006) [1] quoated below: >>> >>> [The autoconf WG is chartered to initially develop >>> two documents. The first document is a document >>> defining the MANET architecture and how MANET >>> relates to IP networks and the Internet. The second >>> document is to define the terminology, problem statement >>> and goals for autoconf. These autoconf documents >>> will be discussed on the autoconf mailing list.] >>> >>> That WG did not produce the definition of MANET architecture. Which I >>> think is related to the subnet-model definition importance for MANET. >>> So i understand the authors see the importance of defining something >>> for MANET in 2006. Now, Do we have a network architecture definition >>> of MANET in one RFC? >> >> Based on my experiences implementing mobile and ad-hoc networks for my >> customers, the main subnet model in use is - "There is NO subnet model i= n >> use". Or rather, "N" subnet models used, depending on the aspects of the >> specific deployment, and hence, IMO, the issues in the (now defunct) >> working group you mention. The subnet model for any given research proje= ct >> doesn't match the subnet model necessary for first-responders (police an= d >> fire brigades), which doesn't match the subnet model for broader disaste= r >> response deployments (e.g. Hurricane Katrina), which doesn't match the >> subnet model for a military deployment, which *most definitely* doesn't >> match the subnet model for a *multi-country* (military coalition) >> deployment. It's chaos. Or, possibly, ad-hoc=85 ;-) I guess it depends= on >> the way you look at it. > > +1, supporting Stan, Charlie, Dan, and others; the manet subnet model is > there are no subnets. > > >> As someone I know and respect within the IETF says, "In these MANET >> networks, you basically wind up throwing host routes around pretty >> quickly." >> >> Oh, and since you mentioned that you don't understand adding "+1" to an >> email - it means that the person *completely agrees* with the earlier >> poster. And I completely agree with Charlie - we shouldn't consign >> ourselves to the same fate as "The Working Group whose name shall not be >> mentioned:=85 >> >> Stan >> >> >>> >>>> On 6/2/12 11:21 PM, "Charles E. Perkins" wrote= : >>>>> Hello folks, >>>>> >>>>> I would be opposed to requiring the subnet model as a mandatory >>>>> component of any current [manet] working group charter item. >>>>> >>>>> We have had at least ten years of experience showing that requiring >>>>> subnets can derail practically any wireless network discussion within >>>>> the sphere of applicability of manet protocols. The reasons are many >>>>> and varied -- and, I must admit, really very interesting. >>>>> >>>>> It was the death of another working group which really should have >>>>> been allowed to go forward except for disagreements about certain >>>>> subnet-related constructs. Let's not consign ourselves to the same >>>>> fate. >>> >>> In future the death of the WG will be because they don't discuss >>> things on the list, or don't have what to discuss, please read the >>> reasons mentioned by Jari Arkko below. IMO for the future, some day >>> any WGs possibly will close and other days new WGs comes. >>> >>>>> >>>>> Regards, >>>>> Charlie P. >>> >>> References: >>> [1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the >>> IETF', Mobile Computing and communication review, volume 1, Number 2, >>> 2006. >>> >>> Best regards >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> To: "autoconf at ietf.org" >>> Subject: [Autoconf] closing the working group? >>> From: Jari Arkko >>> Date: Tue, 29 Mar 2011 08:48:47 +0200 >>> >>> -----------------------------------------------------------------------= --------- >>> I have looked at the discussions on the list (or lack thereof). I also >>> cannot see too many internet drafts on the topics belonging to the >>> group's charter. I am very happy with the RFC that has been produced >>> by the working group, but we also seem to have some actual protocol >>> work happening elsewhere (e.g., in the context of the ROLL WG). >>> >>> I discussed this matter with the chairs and my co-AD, and we are >>> wondering if it would be time to close the working group. I do know >>> that there is at least one implementation team that is still in the >>> process of describing their DHCP-based solution, maybe there are >>> similar efforts on the distributed solution space. My proposal is that >>> we close the working group and I'be VERY happy to AD sponsor all such >>> solutions to Experimental RFCs as soon as we have those proposals in >>> some reasonable shape. >>> Thoughts? >>> >>> Jari >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> To: IETF-Announce at ietf.org >>> Subject: WG Review: Ad Hoc Network configuration (autoconf) >>> From: The IESG >>> Date: Wed, 27 Jul 2005 14:28:49 -0400 >>> Cc: manetautoconf at ml.free.fr >>> List-help: >>> List-id: ietf-announce.ietf.org >>> List-post: >>> List-subscribe: >>> , >>> >>> List-unsubscribe: >>> , >>> >>> Reply-to: iesg at ietf.org >>> Sender: ietf-announce-bounces at ietf.org >>> >>> -----------------------------------------------------------------------= --------- >>> A new IETF working group has been proposed in the Internet Area. The >>> IESG has not >>> made any determination as yet. The following draft charter was >>> submitted, and is >>> provided for informational purposes only. Please send your comments to >>> the IESG >>> mailing list (iesg at ietf.org) by August 3rd. >>> >>> +++++++++++++ >>> >>> Ad Hoc Network configuration (autoconf) >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Current Status: Proposed Working Group >>> >>> Chairs: >>> TBD >>> >>> Internet Area Director(s): >>> Mark Townsley >>> Margaret Wasserman >>> >>> Internet Area Advisor: >>> Margaret Wasserman >>> >>> Mailing Lists: >>> General Discussion: manetautoconf at ml.free.fr >>> To Subscribe: manetautoconf-request at ml.free.fr >>> >>> Description of the WG: >>> >>> In order to communicate among themselves, ad hoc nodes (refer to RFC >>> 2501) may need to configure their network interface(s) with local >>> addresses that are valid within an ad hoc network. Ad hoc nodes may >>> also need to configure globally routable addresses, in order to >>> communicate with devices on the Internet. >>> >>> Ad hoc networks present several new challenges. Unlike in traditional >>> IP networks, each ad hoc node, besides being a traffic end-point, >>> should be capable of forwarding traffic destined for other hosts. >>> Additionally, nodes constituting an ad-hoc network do not share access >>> to a single multicast-capable link for signaling. Many protocol >>> specifications used in traditional IP networks e.g. RFCs 2462, 2463 >>> etc. do, however, assume that subnet-local signals (e.g. link-local >>> multicast signal) are received by each of the hosts on the particular >>> subnet without being forwarded by the routers defining the subnet >>> boundary. >>> >>> The main purpose of the AUTOCONF WG is to standardize mechanisms to be >>> used by ad hoc nodes for configuring unique local and/or globally >>> routable IPv6 addresses. The ad hoc nodes under consideration are >>> expected to support multi-hop communication by running a MANET routing >>> protocol, e.g. those developed by the IETF MANET WG. However, this may >>> or may not mean that an AUTOCONF mechanism will be dependent on any >>> specific MANET routing protocol. With this in mind, the goals of >>> AUTOCONF WG are to: >>> >>> - Produce a "terminology and problem statement" document, defining the >>> problem statement and goals for AUTOCONF. >>> >>> - Develop an IPv6 stateless autoconfiguration mechanism to be used by >>> ad hoc nodes for configuring unique local addresses as well as, in >>> cases where Internet connectivity exists, globally routable unique >>> addresses. >>> >>> - Develop a stateful address autoconfiguration mechanism to be used by >>> ad hoc nodes for configuring globally routable unique addresses, if an >>> address providing entity such as DHCPv6 server is available. >>> >>> - Develop a mechanism to promote configured address uniqueness in the >>> situation where different ad hoc networks merge. >>> >>> Issues and requirements related to prefix and/or address providing >>> entities, such as an Internet gateway, will be addressed within the >>> group to the extent that they are directly related to the AUTOCONF >>> mechanisms. Security concerns related to AUTOCONF mechanisms will also >>> be discussed within the group. >>> >>> The working group will reuse existing specifications whenever >>> reasonable and possible. >>> >>> Goals and Milestones: >>> >>> Oct 05 : Submit "terminology and problem statement" document for WG >>> review >>> Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms >>> and design frameworks >>> Feb 06: Submit "terminology and problem statement" document to IESG for >>> publication as an informational RFC >>> Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism" >>> for WG review >>> Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism" >>> for WG review >>> Apr 06: Submit initial -ID of "configured address uniqueness >>> maintenance" for WG review >>> Aug 06: Revise WG documents and review >>> Dec 06 Revise documents based upon implementation experience >>> Apr 07: Submit "stateless autoconfiguration mechanism" specification >>> and supporting documentation to IESG for publications as Proposed >>> Standard >>> Apr 07: Submit "stateful autoconfiguration mechanism" specification and >>> supporting documentation to IESG for publications as Proposed Standard >>> Apr 07: Submit "configured address uniqueness maintenance" >>> specification and supporting documentation to IESG for publications as >>> Proposed Standard >>> Oct 07: Close or recharter the WG >>> >>> >>> _______________________________________________ >>> IETF-Announce mailing list >>> IETF-Announce at ietf.org >>> https://www1.ietf.org/mailman/listinfo/ietf-announce >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>>> >>>>> >>>>> >>>>> On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >>>>>> Hi All >>>>>> >>>>>> I want to discuss this subnet definition issue that was raised in th= e >>>>>> 82 meeting, could we discuss about it please. Will we need to put it >>>>>> in a draft or include it in our active draft working in progress, >>>>>> please advise, >>>>>> >>>>>> Abdussalam Baryun, >>>>>> University of Glamorgan, UK >>>>>> ++++++++++++++++++++++++++++++ >>>>>> >>>>>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >>>>>> BC> that subnet-models are not defined But in DLEP it looks at two >>>>>> subnet-models (different models; e.g. radio subnet-models, >>>>>> sat-subnet-models). We are defining IP over a subnet, but the subnet >>>>>> is not defined. Then we don=B9t know how to define control protocols= , >>>>>> data-packet-formats, and managements-models without having a subnet >>>>>> model in mind. >>>>>> TB> In sat-comms the up-link and down-link can be very different. S= o >>>>>> for different nodes on same carrier can be different data rates, SNR= , >>>>>> etc. so it is important that DLEP include the link metrics, even if >>>>>> it >>>>>> is a full connected subnet. >>>>>> BC> the subnet depends on the link of the subnet-underlying model, >>>>>> The semantics of link up and down are determined by the underlying. >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>> >>>>>> ******************************************************************** >>>>>> 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. >>>>>> ******************************************************************** >>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>>> >>>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > ---- > boberry@cisco.com > This email may contain confidential and privileged material for the sole = use > of the intended recipient. This email may contain information that is > protected by NDA. Any unauthorized review, use, distribution or disclosur= e > by others is strictly prohibited. If you are not the intended recipient (= or > authorized to receive for the recipient), please contact the sender by re= ply > email and delete all copies of this message. > > > > From abdussalambaryun@gmail.com Tue Jun 5 04:25:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA34221F8663 for ; Tue, 5 Jun 2012 04:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 1AI1Pc1u-t65 for ; Tue, 5 Jun 2012 04:25:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 469AA21F865A for ; Tue, 5 Jun 2012 04:25:24 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3446262vcq.31 for ; Tue, 05 Jun 2012 04:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=zqQ8mB7YJzjseppXZDUM851URsoq6fSTnqQF30gS188=; b=dJvfdNWGq/fSw0WDBtilFuFIOupw2Gko04UY8l3nC1C5iYdJV1DqYiiYde8/Spi9ho SRS3ovHFfYLYeIazdymHaXUslLAMmqMQXSlb/Vfvywfv16rD2QrLv00CNVKnD7sJKMvC wn6y2TcNqzv+M/naqjzfpC6yM6HN9EIT1jlDDE6o8/CsiLloGHnidvX/P+4+WoBJlhQl Kjxy1s0I3IvekGKecyGeQbWNBAyBysziYoMXFZ3ZKHv8AeHc716sGxvCivfcSO0NaJ8Z I4ikz6ILTA60IZeToAmI2fRZNknKq/EOtnvEuf2J13/m1I9WYcAUDeCWcg6pJQofDphl AkQA== MIME-Version: 1.0 Received: by 10.52.36.116 with SMTP id p20mr13826359vdj.129.1338895523743; Tue, 05 Jun 2012 04:25:23 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 5 Jun 2012 04:25:23 -0700 (PDT) Date: Tue, 5 Jun 2012 13:25:23 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 11:25:30 -0000 Hi Henning, >Either you oppose it or not... saying you oppose it but pushing for doing it >anyways is self-contradicting. >The fate of the Autoconf group shows that trying to nail down the subnet-definition >of Manet is both very time-consuming, frustrating and nearly pointless. Not necessarily, we can manage time and define knowledge like MANET nodes do, >Manets have proven to work with nearly any kind of subnet setting, because many >of them just work with host-routes. Yes, but not all networks, if we read in drafts of ROLL they consider that MANET-protocols do not perform well in such nets, that is why we have new versions, and new WGs like ROLL and 6LoWPAN, which they consider Ad-Hoc networks but different than MANET. >Henning Rogge -- You may misunderstood my reactions on this important subject. First I was with action of defining models into all drafts of MANET, and oppose to general purpose drafts *not defining physical subnets model* submitted to MANET WG. Then after Mr.Perkins email and others agreeing, I had a change in beleive, and interested to have only one RFC produced for this issue of physical models definition. However, I admit I may be contradicting if we don't consider the time period of sent emails was sent and the replies, but usually our protocols do consider so I will do the same :) Best Wishes, Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From abdussalambaryun@gmail.com Tue Jun 5 08:30:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656CC21F8484 for ; Tue, 5 Jun 2012 08:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.486 X-Spam-Level: X-Spam-Status: No, score=-3.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 eGSacP6S02df for ; Tue, 5 Jun 2012 08:30:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AEBB621F847D for ; Tue, 5 Jun 2012 08:30:45 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3630883vcq.31 for ; Tue, 05 Jun 2012 08:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qGE/iFtZACj9egX8lNChM+ULXPS9rdspCxSGtftMfMk=; b=SM7pG/tfmB1Tq3ALFddG7OWbN4uE9NvVX4rdz1efkcnYSwYB9ljTnq1gdHU11mzC8i W1KNLMYpHvtZpi1O3V7v1RpOHlJP1vDmWAl+csLx3Gmqdss413WsNpbQVPQoavbyGQIe e2r8tHtATC+OvOVLC+52wxgzbcJ9/jJVE/wjnMowgXVwSr/8CRLtsBFmqzS4YcNYIO2v NlTW/hoI6nt4fCKSPYLxXAydB42bPMhkRQ37u+feZe6i1dfQZPxnHailcX6xIDUs3hN5 rffJzutiI3ToSO3xEStouOrGCCGTM6qKkuKFSSnb+j25vc7C+nvEzuqhL3GdnbI0VBpI R/Mg== MIME-Version: 1.0 Received: by 10.220.157.14 with SMTP id z14mr17122062vcw.73.1338910244954; Tue, 05 Jun 2012 08:30:44 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 5 Jun 2012 08:30:44 -0700 (PDT) Date: Tue, 5 Jun 2012 17:30:44 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Interests in DSRv2 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 15:30:46 -0000 Hi, DSRv2 draft idea is to accomodate RFC5444 and RFC6130 and test the performance. In addition want to add a mechanism of Node-participation-Ability (NAP), that enhance performance. I am now defining physical subnet models for DSRv2 in the applicability-statement section of the draft that are similar to the DLEP use-cases. I will try read useful information regarding subnet-models in literature and IETF groups discussion. If you have any idea please advise, Thanking you, ============================== [Done] The protocol initial operation ideas [Done] Drafting introduction and informative sections [Process] Discussing interests and dsrv2 input ideas [Process] The subnet used definition [?] Close subject of interests [End June] The Draft Discussion open [?] Asking advise from Chair [?] Draft Submission ============================== Regards Abdussalam Baryun University of Glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: manet Subject: Re: [manet] Interests in DSRv2 From: Abdussalam Baryun Date: Mon, 4 Jun 2012 10:33:02 +0200 Hi folks, The start conclusion of my ideas of DSRv2 are that it does not applicable to LLN nor routing as ROLL, but it is more like DLEP use-cases/purposes. I thought it is important that this new version extends RFC4728 to IPv6 DSR, and uses [RFC5444] MANET-packets and also adaptive the neighbor-and-link discovery of NHDP [RFC6130] and/or DLEP. Any other ideas, comment or advise, please reply if any Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ To: manet Subject: [manet] Interests in DSRv2 From: Abdussalam Baryun Date: Sun, 3 Jun 2012 10:49:44 +0200 Hi Folks, I started working on the first draft of DSRv2 to submit to the MANET-WG, and want to know if any is interested in the DSRv2 work, please advise, Will open discussion on the work progress within one month, if you have any question please reply, Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Subject: Re: [manet] A view on packet-BB From: Stan Ratliff Date: Thu, 31 May 2012 10:50:09 -0400 If you have an interest in some sort of DSRv2, then I would encourage you to author a draft and propose it to the WG. Stan > From charliep@computer.org Tue Jun 5 13:27:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4021F8736 for ; Tue, 5 Jun 2012 13:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] 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 KnjBR7xhPFeY for ; Tue, 5 Jun 2012 13:27:41 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id EA43E21F8643 for ; Tue, 5 Jun 2012 13:27:38 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sc0Lq-00089c-FF; Tue, 05 Jun 2012 16:27:38 -0400 Message-ID: <4FCE6BB4.6060403@computer.org> Date: Tue, 05 Jun 2012 13:27:32 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8683ef35ce307f1ba96158c82978307bdc350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet Subject: [manet] Subnet definition within -- the AODV story X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 20:27:42 -0000 Hello folks, AODV has specified a way handling subnets. I think it properly captures the essence of the problem at layer 3 and allocates the proper division of responsibility between layer 3 and layer 2. The main problem for wireless is to identify what _is_ the subnet. There isn't typically any natural way to look and see it, in contrast to the case for wired subnets. Establishing layer-2 connectivity which would define the extent of the subnet is canonically out of scope for IETF. AODV defines something called a "subnet router" which advertises responsibility for reaching any hosts within the address range defined by the routing prefix for that subnet. AODV does not specify how the subnet router fulfills that responsibility. If there are no subnet routers, then as far as AODV is concerned there are no subnets. If there is a subnet router, then hosts on that subnet do NOT respond directly to RREQ and do NOT generate RREP (or other AODV messages). There are other relevant details, but the above captures the main points, I think. -- Regards, Charlie P. From russw@riw.us Tue Jun 5 15:19:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E7521F85F7 for ; Tue, 5 Jun 2012 15:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 L7bsdAQRP10X for ; Tue, 5 Jun 2012 15:19:58 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id 656A021F848F for ; Tue, 5 Jun 2012 15:19:57 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sc26W-0000p4-Lz for manet@ietf.org; Tue, 05 Jun 2012 15:19:56 -0700 Message-ID: <4FCE8611.8020201@riw.us> Date: Tue, 05 Jun 2012 18:20:01 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <4FCB0261.9020405@computer.org> In-Reply-To: <4FCB0261.9020405@computer.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 22:19:59 -0000 +1 Russ On 6/3/2012 2:21 AM, Charles E. Perkins wrote: > > Hello folks, > > I would be opposed to requiring the subnet model as a mandatory > component of any current [manet] working group charter item. > > We have had at least ten years of experience showing that requiring > subnets can derail practically any wireless network discussion within > the sphere of applicability of manet protocols. The reasons are many > and varied -- and, I must admit, really very interesting. > > It was the death of another working group which really should have > been allowed to go forward except for disagreements about certain > subnet-related constructs. Let's not consign ourselves to the same > fate. > > Regards, > Charlie P. > > > > On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: >> Hi All >> >> I want to discuss this subnet definition issue that was raised in the >> 82 meeting, could we discuss about it please. Will we need to put it >> in a draft or include it in our active draft working in progress, >> please advise, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++ >> >> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): >> BC> that subnet-models are not defined But in DLEP it looks at two >> subnet-models (different models; e.g. radio subnet-models, >> sat-subnet-models). We are defining IP over a subnet, but the subnet >> is not defined. Then we don’t know how to define control protocols, >> data-packet-formats, and managements-models without having a subnet >> model in mind. >> TB> In sat-comms the up-link and down-link can be very different. So >> for different nodes on same carrier can be different data rates, SNR, >> etc. so it is important that DLEP include the link metrics, even if it >> is a full connected subnet. >> BC> the subnet depends on the link of the subnet-underlying model, >> The semantics of link up and down are determined by the underlying. >> ++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> ******************************************************************** >> 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. >> ******************************************************************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > -- <>< riwhite@verisign.com russw@riw.us From russw@riw.us Tue Jun 5 15:29:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAFC11E8093 for ; Tue, 5 Jun 2012 15:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rhMOmXDeTXlc for ; Tue, 5 Jun 2012 15:29:31 -0700 (PDT) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B23D511E808D for ; Tue, 5 Jun 2012 15:29:31 -0700 (PDT) Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1Sc2Fn-0000wv-Hb for manet@ietf.org; Tue, 05 Jun 2012 15:29:31 -0700 Message-ID: <4FCE8850.2020608@riw.us> Date: Tue, 05 Jun 2012 18:29:36 -0400 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <4FCB0261.9020405@computer.org> <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> In-Reply-To: <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2012 22:29:32 -0000 > As someone I know and respect within the IETF says, "In these MANET networks, you basically wind up throwing host routes around pretty quickly." I would argue that most ad-hoc networks are precisely host routing, or "all networks are of length x," and with no overlapping prefixes through aggregation. If, in the future, the problem of routing with this constraint in hand is "solved," then we can start talking about subnets and overlapping prefixes, and whether or not we actually have a solid business case for such a thing. Steer clear until we have the experience and requirements to back the work up, IMHO. Russ -- <>< riwhite@verisign.com russw@riw.us From thomas@thomasclausen.org Tue Jun 5 18:23:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8005C11E80C1 for ; Tue, 5 Jun 2012 18:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] 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 ICy4KoESxXx6 for ; Tue, 5 Jun 2012 18:23:31 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A706511E80AC for ; Tue, 5 Jun 2012 18:23:31 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 6FC27558187 for ; Tue, 5 Jun 2012 18:23:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 680081C0786; Tue, 5 Jun 2012 18:23:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.6.29] (ip-64-134-238-20.public.wayport.net [64.134.238.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 436341C04A7; Tue, 5 Jun 2012 18:23:30 -0700 (PDT) References: <4FCB0261.9020405@computer.org> <03563E8B-4E93-4567-B4D4-156ACFD97BEF@cisco.com> <4FCE8850.2020608@riw.us> In-Reply-To: <4FCE8850.2020608@riw.us> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <746BBB90-65E6-41A0-9C07-5EF3BE94AA61@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Tue, 5 Jun 2012 18:23:29 -0700 To: Russ White Cc: "manet@ietf.org" Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 01:23:32 -0000 +1 --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 5 Jun 2012, at 15:29, Russ White wrote: >=20 >> As someone I know and respect within the IETF says, "In these MANET netwo= rks, you basically wind up throwing host routes around pretty quickly."=20 >=20 > I would argue that most ad-hoc networks are precisely host routing, or > "all networks are of length x," and with no overlapping prefixes through > aggregation. If, in the future, the problem of routing with this > constraint in hand is "solved," then we can start talking about subnets > and overlapping prefixes, and whether or not we actually have a solid > business case for such a thing. >=20 > Steer clear until we have the experience and requirements to back the > work up, IMHO. >=20 > Russ >=20 >=20 > --=20 > <>< > riwhite@verisign.com > russw@riw.us > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From Chris.Dearlove@baesystems.com Wed Jun 6 01:42:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE821F8842 for ; Wed, 6 Jun 2012 01:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IRG10Kd85Kd2 for ; Wed, 6 Jun 2012 01:42:55 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA121F875E for ; Wed, 6 Jun 2012 01:42:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,723,1330905600"; d="scan'208";a="243878415" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 06 Jun 2012 09:42:54 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q568grVB029843 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Jun 2012 09:42:53 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Wed, 6 Jun 2012 09:42:53 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" , Abdussalam Baryun Thread-Topic: [manet] Defining subnet models used by our protocols Thread-Index: AQHNQJeIhTgADTeBR0a4HrtaXe+UKpboEDyAgATu4MA= Date: Wed, 6 Jun 2012 08:42:53 +0000 Message-ID: References: <4FCB0261.9020405@computer.org> In-Reply-To: <4FCB0261.9020405@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , "robert.cole@jhuapl.edu" Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 08:42:56 -0000 +1 --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of C= harles E. Perkins Sent: 03 June 2012 07:21 To: Abdussalam Baryun Cc: manet; robert.cole@jhuapl.edu Subject: Re: [manet] Defining subnet models used by our protocols ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello folks, I would be opposed to requiring the subnet model as a mandatory component of any current [manet] working group charter item. We have had at least ten years of experience showing that requiring subnets can derail practically any wireless network discussion within the sphere of applicability of manet protocols. The reasons are many and varied -- and, I must admit, really very interesting. It was the death of another working group which really should have been allowed to go forward except for disagreements about certain subnet-related constructs. Let's not consign ourselves to the same fate. Regards, Charlie P. On 6/2/2012 1:12 AM, Abdussalam Baryun wrote: > Hi All > > I want to discuss this subnet definition issue that was raised in the > 82 meeting, could we discuss about it please. Will we need to put it > in a draft or include it in our active draft working in progress, > please advise, > > Abdussalam Baryun, > University of Glamorgan, UK > ++++++++++++++++++++++++++++++ > > In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): > BC> that subnet-models are not defined But in DLEP it looks at two > subnet-models (different models; e.g. radio subnet-models, > sat-subnet-models). We are defining IP over a subnet, but the subnet > is not defined. Then we don't know how to define control protocols, > data-packet-formats, and managements-models without having a subnet > model in mind. > TB> In sat-comms the up-link and down-link can be very different. So > for different nodes on same carrier can be different data rates, SNR, > etc. so it is important that DLEP include the link metrics, even if it > is a full connected subnet. > BC> the subnet depends on the link of the subnet-underlying model, > The semantics of link up and down are determined by the underlying. > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > ******************************************************************** > 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. > ******************************************************************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --=20 Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Jun 6 02:58:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB321F86D1 for ; Wed, 6 Jun 2012 02:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zTvxnmlw+fhr for ; Wed, 6 Jun 2012 02:58:28 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8F21F86AD for ; Wed, 6 Jun 2012 02:58:28 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4182053vcq.31 for ; Wed, 06 Jun 2012 02:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K+JzAY63GpfsEJy5bPGjv4AnFuOWGtGitPG0AuV8mrk=; b=JA7wjV7GTAASDwmkkddz3nwHRcUISmvgcUoA1mja/n7brXCbM/b/ThG0Cdp/CLM7r4 43sS1FZJUF6YtQ1bILrfKxVxGn9vB2090CTJpEoASsA0AQzbXBlfOspTv31z2SODMhZr 6EY3HiS5WhXCLcRnxuGeIxnml6C+7pzekjPio904GM22xbwsprcl1uyvGJ6th8qx21RL qrV5iqdWvAp1ibcvX06oFS4Z8pqpJyflFhZ+iyF5J4KWsOUmHe8vZafQHHCltQKf+xLr UHD28BiIsNWCb08LtOTNcU0rhf8BwtZAb2vgcECcnQMjQX9g+qNP+3LupgPwdzD/zCwV rfFA== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr17255181vds.117.1338976707950; Wed, 06 Jun 2012 02:58:27 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 6 Jun 2012 02:58:27 -0700 (PDT) In-Reply-To: <4FCE6BB4.6060403@computer.org> References: <4FCE6BB4.6060403@computer.org> Date: Wed, 6 Jun 2012 11:58:27 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Emmanuel.Baccelli" , manet Subject: Re: [manet] Subnet definition within -- the AODV story X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 09:58:29 -0000 Hi Charlie, and All Thank you for your comments Charlie, it gave me more understanding about AODV, Do you oppose the produce of only one new draft for defining physical-subnets (L2) for MANET (or the subnets of usual use in MANET so far)? and if yes Why? As an Abstract to my below comments: My main problem/confusion and discussions aim is to improve the use of all protocols submitted in MANET-WG. I think also Mr.Cole was confused at 82-meeting only after DLEP appeared. I want the benefit from DLEP-Ideas and its use in MANET routing, otherwise, we MAY NOT benefit from it. It is necessary to discuss this issue of defining subnets, because we seen DLEP-Ideas in MANET WG. I received your email in another subject than the above, quote [ I would be opposed to requiring the subnet model as a mandatory component of any current [manet] working group charter item.], which many memebr of WG agree completly, and then I changed my mind and agreed as well to oppose it. So not need mandatory, and not against defining it if an author likes to. But what about adding a draft that defines subnets as L2 and different way of the draft you co-author. I agree with you about the AODV-story but there are different routing protocols like OLSR (there maybe other protocols in future) that has different router-interface model than AODV. I really hope our draft-work-in-progress of [titled: Multi-hop Ad Hoc Wireless Communication, Authors: Baccelli, and Perkins, (2012) ] will captures this issue/difference. More Comments are in lines: On 6/5/12, Charles E. Perkins wrote: > > Hello folks, > > AODV has specified a way handling subnets. I think it properly > captures the essence of the problem at layer 3 and allocates the > proper division of responsibility between layer 3 and layer 2. > I really like the way AODV protocol defines the general-logical-subnet (working for all types) or responsibilities, but it is not the way OLSR does define. AODV-interfaces are different than OLSR-interfaces, their logical-subnet models are differently defined in their specifications. Therefore, we have different MANET-interface models, which was indicated some how in OLSRv2 as ; MANET-interface and non-MANET-interface, so it means different router-interface, because it defines MANET-interface as an interface running RFC6130 protocol. If we have different interfaces then we have different Link-Models, so AODV-links are not same as OLSR-links and same way for other routing-protocol. > The main problem for wireless is to identify what _is_ the subnet. > There isn't typically any natural way to look and see it, in contrast > to the case for wired subnets. Establishing layer-2 connectivity > which would define the extent of the subnet is canonically out of > scope for IETF. AODV defines something called a "subnet router" > which advertises responsibility for reaching any hosts within the > address range defined by the routing prefix for that subnet. > AODV defines subnet-router as logical. I think we have logic-subnet-connection, physical-subnet-connection, and real-wireless-connection. (mobility+wireless = unstable system). IMHO the main problem is how we defined our LINKS (so router-interface not subnet-router), because if number of links break then we MAY have no MANET (usually we have this behavior) or many small manets. I agree that AODV defines subnet-router and address routing prefix, which I like that, but AODV and OLSR don't define the underlying LINKS (i.e. L2 links). We know that the main elements in any network is the NODE and LINK, any network MUST be at least two NODEs and at least one LINK. Therefore AODV and OLSR in a time period MAY miss the point of no MANET, because they MAY don't see into different LINK-models, they beleive all link-models are same models as they define (that is not true there are different link-models as Mr.Cole presented in WG-82 meeting). DLEP now is a very good approach to solve the problem or as you named it the main problem, it solves it because DLEP defines the physical-subnet for the router, each physical-subnet-model. Please note that AODV and OLSR do not exclude there ability to use underlying L2 information, but if they did exclude I MAY think differently. Therefore, DLEP (i.e. is at L2) and other L2 services can be providing information to AODV and OLSR and these routers MAY benefit only if they notice the difference of underlying physical-subnet issues, OR only if ALL underlying subnets provide same service to the upperlayers. Regarding IETF scope, now I have seen that there are interests/wellingness to work together with ITU organisation, which now there are drafts of procedure of interconnecting knowledges between. Engineers in ITU will want to understand our RFCs-standards and we want to consider their standards as well. Not sure in the future how things will go but maybe the WG DA can advise me with this issue. > AODV does not specify how the subnet router fulfills that > responsibility. If there are no subnet routers, then as far as > AODV is concerned there are no subnets. If there is a subnet > router, then hosts on that subnet do NOT respond directly to > RREQ and do NOT generate RREP (or other AODV messages). > In Conclusion, 1) I RECOMMEND that defining interfaces and links to routers will enhance the performance of our WG routing protocols, or even providing information to our routers as the way DLEP will provide our routers or any other way. 2) RECOMMEND that the draft [Baccelli, and Perkins, (2012)] includes the all logical-subnets. 3) If I can know WG opinion about a new one draft to include the define physical-subnets for MANETs. > There are other relevant details, but the above captures the > main points, I think. > > -- > Regards, > Charlie P. I thank you very much Charlie for your comments which I learned from, and my comments above are opinions. Please note that this reply was intended not to argue the issue, but productive discuss, and just brain storming for the progress and to help me understand and learn from WG, improving in future replies/comments :) Best Regards Abdussalam Baryun +++++++++++++++++++++++++++++++++++++++++++++++++++++++ < I may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ From abdussalambaryun@gmail.com Wed Jun 6 05:15:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F18321F8685 for ; Wed, 6 Jun 2012 05:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Cz70IYPZk4VC for ; Wed, 6 Jun 2012 05:15:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB3A21F883F for ; Wed, 6 Jun 2012 05:15:44 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4254169vcq.31 for ; Wed, 06 Jun 2012 05:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZExvzG4ED51gnloQMy6SSi/crrlh2VnlK8EbKz/EngE=; b=x45d58d0w7be8u2bwPup7bXTFrBVpwx4Sbjxv+S55HOLHO4fFj/ftR4sTQkcOmlpl2 TNkBKw6eoVkDb5ZrGV72qv5L+NZWU0lp2w57mHx/l2WvkzGVoxVHbOg8x458hOySBd1b /u2eJoGgFUCJXKoswtDST3jN0p0fkRIaaBOoNalXorL7kgrZB4fqmZsCShA6bIbjc8tz EtomQtXSfqdq9HZ4AuUQdXysZ2HwHrdY+6xuaEjMWce6wBzG9M5zb9cRznhwNf7FpBaM dpGnG9SFk5apetFOaZBVRt5cH+uyf2xXz36fUz36fPYh4koc1moOyengr0MIPTf8O3VI UE0w== MIME-Version: 1.0 Received: by 10.52.36.116 with SMTP id p20mr17735324vdj.129.1338984944095; Wed, 06 Jun 2012 05:15:44 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 6 Jun 2012 05:15:43 -0700 (PDT) Date: Wed, 6 Jun 2012 14:15:43 +0200 Message-ID: From: Abdussalam Baryun To: adrian Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: [manet] A Question to the WG AD X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 12:15:45 -0000 Hi Adrian, I want to understand about future of interaction of our standards and ITU-standards, because I seen one draft about procedures as below: [Titled: Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines, (2012) draft-iab-rfc3356bis-01] QUOTE from the draft: ========= The current level of cooperation between the ITU-T and the IETF should be built upon to ensure that the competence and experience of each organization is brought to bear in the most effective manner and in collaboration with the other. This document provides guidelines for collaboration between the ITU-T and the IETF. ========= The question: Is establishing layer-2 connectivity which would define the extent of the subnet out of scope for IETF, or we may do because in future IETF is colaborating with ITU? thanking you, Abdussalam Baryun University of Glamorgan, UK. From abdussalambaryun@gmail.com Wed Jun 6 10:42:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192C621F888D for ; Wed, 6 Jun 2012 10:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.502 X-Spam-Level: X-Spam-Status: No, score=-3.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SPFb2o+ojnxt for ; Wed, 6 Jun 2012 10:42:19 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C15D21F87D0 for ; Wed, 6 Jun 2012 10:42:14 -0700 (PDT) Received: by vcqp1 with SMTP id p1so4505207vcq.31 for ; Wed, 06 Jun 2012 10:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=G5h6/xzrmnPLQ5CxiCHQcizqtrdLK72WlwPemF/oANk=; b=ofg5Ip7vWCmPyaz44YaGjuCMrIjjRwLJJ1Frkzv+jXK/6MCih+eupsw9YRhQEnoANd zpdjtSu+d0bzdGqR/q3aZz0cMne3h+OrDgKY3/11DYtOEv81kUXx7kzV56TWgnw7bps3 O3HMYesnrnXzJrguc78eUe81VIwrU86VDQTPGO3oCZIggPE0HlKP1NR+XKNM8XIwqhvc LhJdvyTQ8adUY3DzxqxEj4lZ9eT50FspxNIM/Josxs9AmwK5Spa5trL/lP8r9k3DrBmB zvSJdh7p+m54dDra44ZXuvrBqvrjBtU7+aIhYQUyx5i2R/SNYiuMje9FT5OwO6Si5MLx 1A6g== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr18822196vdb.103.1339004533800; Wed, 06 Jun 2012 10:42:13 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 6 Jun 2012 10:42:13 -0700 (PDT) Date: Wed, 6 Jun 2012 19:42:13 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: corson@isr.umd.edu, macker@itd.nrl.navy.mil Subject: [manet] Could we Update RFC2501? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 17:42:20 -0000 Hi Folks, the RFC2501 is the best RFC I read and I like it because it is easy to read, understandable, and covers solid issues of MANET. I hope the authors give us a feedback if they want to make new one as Version 2. I see that it is old (1999), and it may be interesting to update it some how, I hope the authors can update its issues and evaluation, now we got new RFCs and industries have new needs than 90s, it does not cover different devices constraints as sensors and LLNs, and IPv6, 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are getting renew versions. As I can see OLSRv2 and AODVv2 are going in progress, why we don't try to update RFC2501 as well, it will only take few days or a month, to draft and submit so why leave it old-documents with old considerations? Please advise, Abdussalam Baryun University of Glamorgan, UK. ========================================================= From fred@cisco.com Wed Jun 6 11:13:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE70121F87E5 for ; Wed, 6 Jun 2012 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.488 X-Spam-Level: X-Spam-Status: No, score=-110.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 1LnYjlNBuzTk for ; Wed, 6 Jun 2012 11:13:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0D12221F87DF for ; Wed, 6 Jun 2012 11:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2188; q=dns/txt; s=iport; t=1339006393; x=1340215993; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=5tpQZf9QpDBe7OoC3MSWDeNw1bNGAHjXaZNUEST2Z3c=; b=TGSFvScj51KmMqDz6P45AbJam0/h1ohB2EryHXpPB+Hk8xo82njSg5WK A+ySDl+F6eDt2oAXd+Hg5WJfuI1nieqYSeieI7qvdaFTf930k7g6hQSoC TduJhMKS3LigHSbFEkvp+mNXKxE0Rd1BTwHsI7qifgxFJO1X6NszJR15C s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOWcz0+rRDoG/2dsb2JhbABFtDaBB4IZAQEEEgEnPxBRVwY1h2iYWp9wkFFgA4hAjF2FU4hBgWaCfw X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="47825257" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 06 Jun 2012 18:13:12 +0000 Received: from sjc-vpn4-530.cisco.com (sjc-vpn4-530.cisco.com [10.21.82.18]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q56ICNQK024775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 18:13:11 GMT Received: from [127.0.0.1] by sjc-vpn4-530.cisco.com (PGP Universal service); Wed, 06 Jun 2012 12:13:11 -0600 X-PGP-Universal: processed; by sjc-vpn4-530.cisco.com on Wed, 06 Jun 2012 12:13:11 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4FCE6BB4.6060403@computer.org> Date: Wed, 6 Jun 2012 11:13:48 -0600 Message-Id: <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> References: <4FCE6BB4.6060403@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:13:13 -0000 One thing I have never quite understood, and would appreciate some = insight on, is why a manet or roll network needs a different definition = of a subnet than any other subnetwork does. Help? The IPv4/IPv6 definition of a subnet might perhaps be "a set of = interfaces that are reachable via one Internet layer hop from a router = within the subnet, at least from the perspective of a host outside the = subnet", and by extension are (at least in concept) mutually reachable = by all of the interfaces within the subnet without leaving the subnet. I = could imagine relaxing that model to support a multi-star network - = everyone in the same subnet is reachable *via*any*router* with an = interface in the subnet - but even so, the key attribute is that the = subnet is contiguous from a perspective of subnet routing. I model it, = conceptually, in a manner similar to the L1/L2 distinction in IS-IS; L2 = aggregates using subnets, but within the L1 domain uses host routing (as = in TRILL). Within an Ethernet LAN, for example, I might have a sprawling switched = network with hundreds or even thousands of Ethernet interfaces, but = unless someone is actually aware of the switches (eg, operating at the = Ethernet layer), they can be viewed from layer 3 as if they were = physically attached to a common physical cable. In an AODV or OLSR = world, we might use the IP header to do host routing within the subnet, = but from the viewpoint of anyone outside the subnet, they send a = datagram to any connecting router, and it hands the datagram to the = IP-connected device as its at-least-conceptual next hop (modulo TTL, = which still needs to be handled). Ditto a RPL world. When we discuss a separate subnet model for manet/roll/etc, it tells me = that we want to somehow enable discontiguous subnets - I can no longer = assume that interfaces within the same subnet know how to reach each = other without leaving the subnet, and I can no longer assume that it is = sufficient for routing in other parts of the network to get datagrams to = the subnet in order to reach an interface within the subnet. That = worries me. What am I missing?= From charliep@computer.org Wed Jun 6 11:40:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9371921F863F for ; Wed, 6 Jun 2012 11:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] 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 xV7oFQ0jwXLg for ; Wed, 6 Jun 2012 11:40:29 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id E108D21F85F2 for ; Wed, 6 Jun 2012 11:40:28 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ScL9g-0002Yb-0B; Wed, 06 Jun 2012 14:40:28 -0400 Message-ID: <4FCFA41A.1020100@computer.org> Date: Wed, 06 Jun 2012 11:40:26 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fred Baker References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad863957eeb9cb357db387a25b6c7391f0a4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 18:40:29 -0000 Hello Fred, The point of my email was that we _don't_ need a different definition. From my perspective, some ad hoc networks don't have any, and some others might have subnets. But it's not the business of [manet] to create the subnets. I hope you'll agree that the definition for "subnet router" that I discussed in the earlier email embodies the notion that the responsibility for creating the layer-2 connectivity enabling a subnet resides at layer 2, not layer 3. I don't think we ought to create a different subnet model. And I agree with everything else in your email below. I hesitate to go into any more details, because it seems that diving into the mechanics of how to create a working subnet is quite far afield from the work of [manet]. If there is a mailing list dedicated to subnet arguments, I'll be happy to subscribe and join the fun. Really we could go on for years -- never a dull moment. Regards, Charlie P. On 6/6/2012 10:13 AM, Fred Baker wrote: > One thing I have never quite understood, and would appreciate some insight on, is why a manet or roll network needs a different definition of a subnet than any other subnetwork does. Help? > > The IPv4/IPv6 definition of a subnet might perhaps be "a set of interfaces that are reachable via one Internet layer hop from a router within the subnet, at least from the perspective of a host outside the subnet", and by extension are (at least in concept) mutually reachable by all of the interfaces within the subnet without leaving the subnet. I could imagine relaxing that model to support a multi-star network - everyone in the same subnet is reachable *via*any*router* with an interface in the subnet - but even so, the key attribute is that the subnet is contiguous from a perspective of subnet routing. I model it, conceptually, in a manner similar to the L1/L2 distinction in IS-IS; L2 aggregates using subnets, but within the L1 domain uses host routing (as in TRILL). > > Within an Ethernet LAN, for example, I might have a sprawling switched network with hundreds or even thousands of Ethernet interfaces, but unless someone is actually aware of the switches (eg, operating at the Ethernet layer), they can be viewed from layer 3 as if they were physically attached to a common physical cable. In an AODV or OLSR world, we might use the IP header to do host routing within the subnet, but from the viewpoint of anyone outside the subnet, they send a datagram to any connecting router, and it hands the datagram to the IP-connected device as its at-least-conceptual next hop (modulo TTL, which still needs to be handled). Ditto a RPL world. > > When we discuss a separate subnet model for manet/roll/etc, it tells me that we want to somehow enable discontiguous subnets - I can no longer assume that interfaces within the same subnet know how to reach each other without leaving the subnet, and I can no longer assume that it is sufficient for routing in other parts of the network to get datagrams to the subnet in order to reach an interface within the subnet. That worries me. What am I missing? > -- Regards, Charlie P. From fred@cisco.com Wed Jun 6 12:01:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B4B11E80DC for ; Wed, 6 Jun 2012 12:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.196 X-Spam-Level: X-Spam-Status: No, score=-110.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 eKZpoT0quQ0q for ; Wed, 6 Jun 2012 12:01:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB511E80FC for ; Wed, 6 Jun 2012 12:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4297; q=dns/txt; s=iport; t=1339009257; x=1340218857; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=+A6yWaeW1j/KMzVwnwrA1SEREa3s60V2Dwzg72D0O38=; b=dKD7nfG88ITWaX9DMn12xanK8ZUH9u4/HMKBDtemHcpxMhOe7HKVurq6 8Jsnh4ekBu0G/Wc7swj0WlhBzq7fbbsQLl8ITWh57SNg7XBlDFd9WsMGO iUY1u1sD0G7dSqOTYmBoPlOGHb0kmvPpNEorqPF+d2Vfy0A9MkjRktaVi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQFAIuoz0+rRDoJ/2dsb2JhbABFsFmDXYEHghgBAQEDARIBJzQCCQULCxgMIlcGNYdkBJhgn3KLGIU5YAOIQIxdhVOIQYFmgn+BQA X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="47831464" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 Jun 2012 19:00:55 +0000 Received: from sjc-vpn4-530.cisco.com (sjc-vpn4-530.cisco.com [10.21.82.18]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q56J0qj0023953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 19:00:54 GMT Received: from [127.0.0.1] by sjc-vpn4-530.cisco.com (PGP Universal service); Wed, 06 Jun 2012 13:00:54 -0600 X-PGP-Universal: processed; by sjc-vpn4-530.cisco.com on Wed, 06 Jun 2012 13:00:54 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4FCFA41A.1020100@computer.org> Date: Wed, 6 Jun 2012 13:00:48 -0600 Message-Id: <610196B0-AEDB-4E18-A6A5-20BBEC4C7654@cisco.com> References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FCFA41A.1020100@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 19:01:13 -0000 On Jun 6, 2012, at 12:40 PM, Charles E. Perkins wrote: >=20 > Hello Fred, >=20 > The point of my email was that we _don't_ need a different definition. > =46rom my perspective, some ad hoc networks don't have any, and some > others might have subnets. But it's not the business of [manet] to = create > the subnets. I hope you'll agree that the definition for "subnet = router" > that I discussed in the earlier email embodies the notion that the > responsibility for creating the layer-2 connectivity enabling a subnet > resides at layer 2, not layer 3. Well, ... I think we 80% agree.=20 That said, to me, the data link layer tells me how to layer message = exchange onto the physical layer and as a result get a message from one = end to another of a single physical medium. When I start concatenating = physical connectivity and have routing questions, I'm in the network = layer; the question is "where". To my small mind, the Internet layer is = an upper sub-layer of the Network Layer, and Ethernet/ATM/IP Tunnels/IP = re-used within a manet|roll domain and etc are in a lower sub-layer I = call the "Intranet" sub-layer. But yes, I think we agree that the LAN, = however comprised, is in a sub-layer lower than the Internet layer. > I don't think we ought to create a different subnet model. And I = agree > with everything else in your email below. I thought we were in agreement. I do note that both roll and manet have = proposed alternative subnet models, which is at least in part what = prompted your note. > I hesitate to go into any more details, because it seems that diving = into > the mechanics of how to create a working subnet is quite far afield = from > the work of [manet]. > If there is a mailing list dedicated to subnet arguments, I'll be = happy > to subscribe and join the fun. Really we could go on for years -- = never > a dull moment. :-( > Regards, > Charlie P. >=20 >=20 >=20 > On 6/6/2012 10:13 AM, Fred Baker wrote: >> One thing I have never quite understood, and would appreciate some = insight on, is why a manet or roll network needs a different definition = of a subnet than any other subnetwork does. Help? >>=20 >> The IPv4/IPv6 definition of a subnet might perhaps be "a set of = interfaces that are reachable via one Internet layer hop from a router = within the subnet, at least from the perspective of a host outside the = subnet", and by extension are (at least in concept) mutually reachable = by all of the interfaces within the subnet without leaving the subnet. I = could imagine relaxing that model to support a multi-star network - = everyone in the same subnet is reachable *via*any*router* with an = interface in the subnet - but even so, the key attribute is that the = subnet is contiguous from a perspective of subnet routing. I model it, = conceptually, in a manner similar to the L1/L2 distinction in IS-IS; L2 = aggregates using subnets, but within the L1 domain uses host routing (as = in TRILL). >>=20 >> Within an Ethernet LAN, for example, I might have a sprawling = switched network with hundreds or even thousands of Ethernet interfaces, = but unless someone is actually aware of the switches (eg, operating at = the Ethernet layer), they can be viewed from layer 3 as if they were = physically attached to a common physical cable. In an AODV or OLSR = world, we might use the IP header to do host routing within the subnet, = but from the viewpoint of anyone outside the subnet, they send a = datagram to any connecting router, and it hands the datagram to the = IP-connected device as its at-least-conceptual next hop (modulo TTL, = which still needs to be handled). Ditto a RPL world. >>=20 >> When we discuss a separate subnet model for manet/roll/etc, it tells = me that we want to somehow enable discontiguous subnets - I can no = longer assume that interfaces within the same subnet know how to reach = each other without leaving the subnet, and I can no longer assume that = it is sufficient for routing in other parts of the network to get = datagrams to the subnet in order to reach an interface within the = subnet. That worries me. What am I missing? >>=20 >=20 >=20 > --=20 > Regards, > Charlie P. >=20 From charliep@computer.org Wed Jun 6 14:16:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6FC21F8751 for ; Wed, 6 Jun 2012 14:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_54=0.6] 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 k90hDxL2rM61 for ; Wed, 6 Jun 2012 14:16:44 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id C078621F8745 for ; Wed, 6 Jun 2012 14:16:44 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ScNau-0002tv-CG; Wed, 06 Jun 2012 17:16:44 -0400 Message-ID: <4FCFC8BB.10800@computer.org> Date: Wed, 06 Jun 2012 14:16:43 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fred Baker References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FCFA41A.1020100@computer.org> <610196B0-AEDB-4E18-A6A5-20BBEC4C7654@cisco.com> In-Reply-To: <610196B0-AEDB-4E18-A6A5-20BBEC4C7654@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86f454e37b6d2fe718ef37ad2bc73d7564350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:16:45 -0000 Hello Fred, 1.5 small points below... On 6/6/2012 12:00 PM, Fred Baker wrote: > That said, to me, the data link layer tells me how to layer message > exchange onto the physical layer and as a result get a message from > one end to another of a single physical medium. When I start > concatenating physical connectivity and have routing questions Could they be bridging questions? > , I'm in the network layer; the question is "where". In my understanding, there isn't any ambiguity about this because, in the network layer, network addresses are used. In layer 2, layer 2 addresses are used (e.g., for bridging). > To my small mind, C'mon Fred -- you're not fooling anyone here certainly not me! > the Internet layer is an upper sub-layer of the Network Layer, and > Ethernet/ATM/IP Tunnels/IP re-used within a manet|roll domain and etc > are in a lower sub-layer I call the "Intranet" sub-layer. But yes, I > think we agree that the LAN, however comprised, is in a sub-layer > lower than the Internet layer. Do you envision that an "Intranet" layer would use Internet addresses at all? >> I don't think we ought to create a different subnet model. And I agree >> with everything else in your email below. > I thought we were in agreement. I do note that both roll and manet have proposed alternative subnet models, which is at least in part what prompted your note. I don't remember a new "subnet model" for [manet]. If it happened, I must have reinterpreted it to conform to the subnet model already existing in my understanding. I also don't remember it for [roll], but I couldn't keep up with that working group. Regards, Charlie P. From prvs=497ee5e08=mukul@uwm.edu Wed Jun 6 14:36:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3965C21F84D0 for ; Wed, 6 Jun 2012 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BY5TZgCowmwL for ; Wed, 6 Jun 2012 14:36:11 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0521F84CF for ; Wed, 6 Jun 2012 14:36:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEEAP3Lz09/AAAB/2dsb2JhbABFhU6sRoVEAQEBBAEBASBLCwwPEQQBAQMCDRkCIwYoCAYTh30DCwuldYh/DUqJAASBI4kVYIR3gRIDiECMXYp+hHyCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0362812E3BA; Wed, 6 Jun 2012 16:36:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lg4eTw-OZPTn; Wed, 6 Jun 2012 16:36:07 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9641512E3AE; Wed, 6 Jun 2012 16:36:07 -0500 (CDT) Date: Wed, 6 Jun 2012 16:36:07 -0500 (CDT) From: Mukul Goyal To: Fred Baker Message-ID: <276197359.615946.1339018567495.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:36:12 -0000 >I could imagine relaxing that model to support a multi-star network - everyone in the same subnet is reachable *via*any*router* with an interface in the subnet - but even so, the key attribute is that the subnet is contiguous from a perspective of subnet routing. I think this model allows an LLN/MANET to be considered one subnet except that reaching the ultimate destination from the entry into the subnet might involve multiple IP hops. Thanks Mukul ----- Original Message ----- From: "Fred Baker" To: "Charles E. Perkins" Cc: "manet" , "Abdussalam Baryun" Sent: Wednesday, June 6, 2012 12:13:48 PM Subject: [manet] Subnet definition -- why do we need one that is different than standard IP? One thing I have never quite understood, and would appreciate some insight on, is why a manet or roll network needs a different definition of a subnet than any other subnetwork does. Help? The IPv4/IPv6 definition of a subnet might perhaps be "a set of interfaces that are reachable via one Internet layer hop from a router within the subnet, at least from the perspective of a host outside the subnet", and by extension are (at least in concept) mutually reachable by all of the interfaces within the subnet without leaving the subnet. I could imagine relaxing that model to support a multi-star network - everyone in the same subnet is reachable *via*any*router* with an interface in the subnet - but even so, the key attribute is that the subnet is contiguous from a perspective of subnet routing. I model it, conceptually, in a manner similar to the L1/L2 distinction in IS-IS; L2 aggregates using subnets, but within the L1 domain uses host routing (as in TRILL). Within an Ethernet LAN, for example, I might have a sprawling switched network with hundreds or even thousands of Ethernet interfaces, but unless someone is actually aware of the switches (eg, operating at the Ethernet layer), they can be viewed from layer 3 as if they were physically attached to a common physical cable. In an AODV or OLSR world, we might use the IP header to do host routing within the subnet, but from the viewpoint of anyone outside the subnet, they send a datagram to any connecting router, and it hands the datagram to the IP-connected device as its at-least-conceptual next hop (modulo TTL, which still needs to be handled). Ditto a RPL world. When we discuss a separate subnet model for manet/roll/etc, it tells me that we want to somehow enable discontiguous subnets - I can no longer assume that interfaces within the same subnet know how to reach each other without leaving the subnet, and I can no longer assume that it is sufficient for routing in other parts of the network to get datagrams to the subnet in order to reach an interface within the subnet. That worries me. What am I missing? _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From fred@cisco.com Wed Jun 6 14:46:51 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF1121F856D for ; Wed, 6 Jun 2012 14:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.183 X-Spam-Level: X-Spam-Status: No, score=-110.183 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 iQeJc0FFHct5 for ; Wed, 6 Jun 2012 14:46:50 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 53F4921F8546 for ; Wed, 6 Jun 2012 14:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2747; q=dns/txt; s=iport; t=1339019168; x=1340228768; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=2HXpn4jL2N9cj8ING8kw+PX2u5je8xY9J95fbv4Fmu0=; b=FSmjfh9XXBwQQqSjLDLrb0b1SYw47YKsD5GZ1J+amHzW2aBZjyRo+Jjx 03RfU+n1heDOaET6KMd5neqWh50TueMb+X4C7KWYvmyvAKyxEGZ8QALrH aq8It8Xmt0+9uYTB/VOmiEQEJco0hHbw1P7IU0hOX3rSBux7CnVeLvAZu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGAE3Pz0+rRDoH/2dsb2JhbABFsFyBOIIlgQeCGAEBAQMBEgEnNgkFCwsYLlcGNYdkBJhvn3GLGIUpYAOIQIxdhVOIQYFmgn+BQA X-IronPort-AV: E=Sophos;i="4.75,726,1330905600"; d="scan'208";a="47853140" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Jun 2012 21:46:08 +0000 Received: from sjc-vpn4-530.cisco.com (sjc-vpn4-530.cisco.com [10.21.82.18]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q56Lk7Z6030331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 21:46:07 GMT Received: from [127.0.0.1] by sjc-vpn4-530.cisco.com (PGP Universal service); Wed, 06 Jun 2012 15:46:08 -0600 X-PGP-Universal: processed; by sjc-vpn4-530.cisco.com on Wed, 06 Jun 2012 15:46:08 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4FCFC8BB.10800@computer.org> Date: Wed, 6 Jun 2012 15:45:20 -0600 Message-Id: <5D8B4D90-1CC0-49EF-B8C9-0C6EB2743500@cisco.com> References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FCFA41A.1020100@computer.org> <610196B0-AEDB-4E18-A6A5-20BBEC4C7654@cisco.com> <4FCFC8BB.10800@computer.org> To: "Charles E. Perkins" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:46:51 -0000 On Jun 6, 2012, at 3:16 PM, Charles E. Perkins wrote: > Hello Fred, >=20 > 1.5 small points below... >=20 > On 6/6/2012 12:00 PM, Fred Baker wrote: >> That said, to me, the data link layer tells me how to layer message = exchange onto the physical layer and as a result get a message from one = end to another of a single physical medium. When I start concatenating = physical connectivity and have routing questions >=20 > Could they be bridging questions? here you hark back to a debate that actually kinda-sorta made sense 20 = years ago, but makes no sense in this context. IEEE 802.1, and = specifically 802.1d, is a routing technology. It doesn't route in the = sense that OSPF or BGP do, but it figures out how to get packets across = a network from point A to point B. >> , I'm in the network layer; the question is "where". >=20 > In my understanding, there isn't any ambiguity about this because, in > the network layer, network addresses are used. In layer 2, layer 2 = addresses > are used (e.g., for bridging). again, harking back to a discussion that is kind of irrelevant. Are you = going to tell me that an IP address used by two layers, one of which is = doing subnet routing using, say, OSPF, and the other is doing host = routing through AODV, are not both in the network layer? If so, then why = would a network doing two layers of routing, one of which is using = subnet routing using, say, OSPF, and the other is doing host routing = through 802.1d, is not both in the network layer? >> the Internet layer is an upper sub-layer of the Network Layer, and = Ethernet/ATM/IP Tunnels/IP re-used within a manet|roll domain and etc = are in a lower sub-layer I call the "Intranet" sub-layer. But yes, I = think we agree that the LAN, however comprised, is in a sub-layer lower = than the Internet layer.=20 >=20 > Do you envision that an "Intranet" layer would use Internet addresses = at all? RPL is a pretty good example of a routing protocol that makes that = assumption. If AODV is used and the node ID is an IP address - very = reasonable - sure. >>> I don't think we ought to create a different subnet model. And I = agree >>> with everything else in your email below. >> I thought we were in agreement. I do note that both roll and manet = have proposed alternative subnet models, which is at least in part what = prompted your note. >=20 > I don't remember a new "subnet model" for [manet]. If it happened, I = must have > reinterpreted it to conform to the subnet model already existing in my = understanding. >=20 > I also don't remember it for [roll], but I couldn't keep up with that > working group. >=20 > Regards, > Charlie P. >=20 >=20 From fred@cisco.com Wed Jun 6 14:51:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC62C21F862A for ; Wed, 6 Jun 2012 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 660GPuIXn+vj for ; Wed, 6 Jun 2012 14:51:42 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCD021F8627 for ; Wed, 6 Jun 2012 14:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=537; q=dns/txt; s=iport; t=1339019502; x=1340229102; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=NczOUZb6wgnVnP9mQeNyLGI8UlZV08GOXERGSSdmpIc=; b=cHZ5F6w1hooFy6tD3zUf+D+hZW42rwDOxtqiT2xNeJ1Mi13GsdrTJZGp W7iRvbEpsGCDoIcmZUHqCvx2uCf7iXi2IVCUUdcPiwTk57lwJvGF2mQNB o1GA3mgo5oJeYANz4cLmy5FHIzmMP1pUyK0mostzYnqaby9NgtX3EXoB2 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAPbPz0+rRDoG/2dsb2JhbABFDrIGgiWBB4IYAQEBAwESASc/EAtGVwY1h2QEmGmfcYsYhSlgA4hAjF2FU4hBgWaCJ1g X-IronPort-AV: E=Sophos;i="4.75,726,1330905600"; d="scan'208";a="45365503" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 06 Jun 2012 21:51:42 +0000 Received: from sjc-vpn4-530.cisco.com (sjc-vpn4-530.cisco.com [10.21.82.18]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q56LpTpH017774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 21:51:40 GMT Received: from [127.0.0.1] by sjc-vpn4-530.cisco.com (PGP Universal service); Wed, 06 Jun 2012 15:51:41 -0600 X-PGP-Universal: processed; by sjc-vpn4-530.cisco.com on Wed, 06 Jun 2012 15:51:41 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <276197359.615946.1339018567495.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 6 Jun 2012 15:51:39 -0600 Message-Id: References: <276197359.615946.1339018567495.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 21:51:42 -0000 On Jun 6, 2012, at 3:36 PM, Mukul Goyal wrote: >> I could imagine relaxing that model to support a multi-star network - = everyone in the same subnet is reachable *via*any*router* with an = interface in the subnet - but even so, the key attribute is that the = subnet is contiguous from a perspective of subnet routing. >=20 > I think this model allows an LLN/MANET to be considered one subnet = except that reaching the ultimate destination from the entry into the = subnet might involve multiple IP hops. Pretty much.= From rdroms@cisco.com Wed Jun 6 15:05:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8E11E80E4 for ; Wed, 6 Jun 2012 15:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 TfJeykbOzAdq for ; Wed, 6 Jun 2012 15:05:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E454211E80A1 for ; Wed, 6 Jun 2012 15:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=793; q=dns/txt; s=iport; t=1339020320; x=1340229920; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WDuZ5sHbnBhR/xVL0a/Ru7NmwAGMzic+9PONhCc/JGI=; b=mQPqmJNkZprql+rV6BQUCd2yc0Xx8SpGFjbKXfkgFubNmtNB+sf0Oy86 TfquseTFVxoslqGrOcqZ/8iogxjypPb3H1L+EAg2F6nvxbZVb0xjlhwOM ur/GulqzpwAzLZb8c57L6A7/EyjTSmJUvhBu2a079bZqO9v2rhufENkDh w=; X-IronPort-AV: E=Sophos;i="4.75,726,1330905600"; d="scan'208";a="90186353" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 06 Jun 2012 22:05:19 +0000 Received: from rtp-rdroms-8912.cisco.com (rtp-rdroms-8912.cisco.com [10.116.164.51]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q56M5Iqr017917; Wed, 6 Jun 2012 22:05:18 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Wed, 6 Jun 2012 18:05:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <195E4426-C9CA-4EDF-8593-C09FDC05820D@cisco.com> References: <276197359.615946.1339018567495.JavaMail.root@mail17.pantherlink.uwm.edu> To: Fred Baker X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 22:05:45 -0000 On Jun 6, 2012, at 5:51 PM 6/6/12, Fred Baker wrote: >=20 > On Jun 6, 2012, at 3:36 PM, Mukul Goyal wrote: >=20 >>> I could imagine relaxing that model to support a multi-star network = - everyone in the same subnet is reachable *via*any*router* with an = interface in the subnet - but even so, the key attribute is that the = subnet is contiguous from a perspective of subnet routing. >>=20 >> I think this model allows an LLN/MANET to be considered one subnet = except that reaching the ultimate destination from the entry into the = subnet might involve multiple IP hops. >=20 > Pretty much. =3D=3D multi-link subnet? - Ralph > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Wed Jun 6 15:12:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA7321F84A6 for ; Wed, 6 Jun 2012 15:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 b+nu7nvIso1B for ; Wed, 6 Jun 2012 15:12:13 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3928821F8593 for ; Wed, 6 Jun 2012 15:12:00 -0700 (PDT) Received: by yenq13 with SMTP id q13so6064079yen.31 for ; Wed, 06 Jun 2012 15:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=sQF45Pg+s3cUn3NhKIkN+zpCLtpd/oKVB2lwcZDpdXk=; b=HVi30phElDEiBV94qqNImJBPp/UL/SkuBKhSuEb5XhFqxOa0aiPZXjQWd8J3n5SwF0 qiNHu0kvl/OzaBxhs2QG/JbiBX1wp1RcpgICiUjME37Gs8Vo29EPc60DtxpLcgCI7dR3 1Ju+py+tM4/RzOzZ1zc2HlnASxLmt/ny+mUro= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=sQF45Pg+s3cUn3NhKIkN+zpCLtpd/oKVB2lwcZDpdXk=; b=NOj2/LFulk2fa7WcAQa1918UrIomYOnlStnIU42lII8jokHOSXas8lieob3ifG5hqO DkmXTZUkxVFS9pd3RA97Q5HAyyrvLpc7V0w/DnXygInaESTpxdzGsrsy3N6YbtAM40HA AHcYqmK3qRovdqQldPQ4DAZ23YbLtmRWN0yfYr7U19p+LJkc4czBwIASqPLiiH15nwtj NpkgEwfhrsJFpDVf3OqydYB9tSTL5xkABsPB0nnc4J1wx8dTZw9AReLCgog6TFD6s6ae pBpN5Bd/+XuUwa+JmvitoDSk0yvFY/84rVoGf2/k7XpwDqZW3keVaKtMDYUtYcCJvsGQ exAw== MIME-Version: 1.0 Received: by 10.101.73.20 with SMTP id a20mr6944986anl.88.1339020719744; Wed, 06 Jun 2012 15:11:59 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Wed, 6 Jun 2012 15:11:59 -0700 (PDT) In-Reply-To: <195E4426-C9CA-4EDF-8593-C09FDC05820D@cisco.com> References: <276197359.615946.1339018567495.JavaMail.root@mail17.pantherlink.uwm.edu> <195E4426-C9CA-4EDF-8593-C09FDC05820D@cisco.com> Date: Wed, 6 Jun 2012 15:11:59 -0700 Message-ID: From: Ulrich Herberg To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl4TfjGQi26HHIzxhyJ0O6yrZLvtylyNHIrdOYRqKb/3Mbs5ezIXVMjUJyPArqBPbUMJnDE Cc: manet , Fred Baker , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 22:12:14 -0000 On Wed, Jun 6, 2012 at 3:05 PM, Ralph Droms wrote: > > > > >>> I could imagine relaxing that model to support a multi-star network -= everyone in the same subnet is reachable *via*any*router* with an interfac= e in the subnet - but even so, the key attribute is that the subnet is cont= iguous from a perspective of subnet routing. > >> > >> I think this model allows an LLN/MANET to be considered one subnet exc= ept that reaching the ultimate destination from the entry into the subnet m= ight involve multiple IP hops. > > > > Pretty much. > > =3D=3D multi-link subnet? I think it would be wrong to define such a multi-link subnet (for the reasons the IAB described in in RFC4903, and that we tried to convey at length in AUTOCONF). We had a long discussion about the reasons in AUTOCONF (which led to RFC5889), and I don't think we should revive this discussion in MANET. Ulrich From charliep@computer.org Wed Jun 6 16:06:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587D411E8096 for ; Wed, 6 Jun 2012 16:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] 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 csly9OY7gKba for ; Wed, 6 Jun 2012 16:06:00 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACB211E807F for ; Wed, 6 Jun 2012 16:06:00 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ScPId-0004Du-S5; Wed, 06 Jun 2012 19:05:59 -0400 Message-ID: <4FCFE257.7060801@computer.org> Date: Wed, 06 Jun 2012 16:05:59 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Fred Baker References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FCFA41A.1020100@computer.org> <610196B0-AEDB-4E18-A6A5-20BBEC4C7654@cisco.com> <4FCFC8BB.10800@computer.org> <5D8B4D90-1CC0-49EF-B8C9-0C6EB2743500@cisco.com> In-Reply-To: <5D8B4D90-1CC0-49EF-B8C9-0C6EB2743500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad863596f042c47295357cacef26e9d1e854350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jun 2012 23:06:01 -0000 Hello Fred, I'd greatly prefer to keep the terms as simple as is reasonably possible. To me it makes so much sense to have the network layer be the one that uses network-layer addresses, and likewise for layer-2. I recognize that bridging and routing both get packets from point A to point B, but unless you want to completely conflate the link layer with the network layer I don't see why we should equate the term "bridging" with the term "routing". A bit more below... On 6/6/2012 2:45 PM, Fred Baker wrote: > here you hark back to a debate that actually kinda-sorta made sense 20 years ago, but makes no sense in this context. IEEE 802.1, and specifically 802.1d, is a routing technology. It doesn't route in the sense that OSPF or BGP do, but it figures out how to get packets across a network from point A to point B. IEEE thinks that 802.1d is a bridging technology. > again, harking back to a discussion that is kind of irrelevant. Are > you going to tell me that an IP address used by two layers, one of > which is doing subnet routing using, say, OSPF, and the other is doing > host routing through AODV, are not both in the network layer? Isn't routing hierarchical? That doesn't negate the value of having layers of the protocol stack. > If so, then why would a network doing two layers of routing, one of > which is using subnet routing using, say, OSPF, and the other is doing > host routing through 802.1d, is not both in the network layer? If the "host routing" is based on layer-2 addresses, then it's bridging (in my 20 year old understanding of the protocol stack). If the "host routing" is based on layer-3 addresses, then according to those old guidelines it is routing. It seems to me that anyway we share reasonable understanding about how packets are moved from point A to point B and that our disagreement is purely definitional. In fact, there have been in the past variations of most ad hoc network protocols that work with layer-2 addresses (even DSDV did that). Honestly, I cannot see any value in blurring the definitions even though switches and routers and bridges (etc.) share many electronic features and caching strategies. If there is value, please explain -- but is that value really worth not being able to decide what a subnet is? Theoretically, (to take a much more extreme case) we could also conflate routing with DNS hierarchy, but then it would be just that much easier to get confused. -- Regards, Charlie P. From abdussalambaryun@gmail.com Thu Jun 7 01:50:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A5821F8750 for ; Thu, 7 Jun 2012 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6lHhGHaLlQBa for ; Thu, 7 Jun 2012 01:50:24 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF921F855D for ; Thu, 7 Jun 2012 01:50:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so208169vbb.31 for ; Thu, 07 Jun 2012 01:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3rc+rjegv5OE999OMmusid0rsVDXzfd+TDnRfppOB4U=; b=1H55iKQ7ZoIRVqg6OETfP4cSi8VT+0bztweuwzEC68Q3AHKKvJGRgCuiahymNB2JDk htSNuoKbXXOVsKs87fQQYboAO2bDZX/68PBhV5kAqPDMDiXaeKBiYng599eN655FE0HI fdWgQ8RlPDxNb4FOCjhBNBWZCUIYR1pVK9Mbv638M/es4GLLD9ys3qcsCyOfozuGQSfN Jq9kLL8d3+0Qkcfwop8Rgmf8Q0uu59WKZsDQquKqbBTMcNNSrFGXVvqgAzU3u7x4smP1 1XPY7nKY/eoYqtprJqHJPnT328mWbpkErHCmWs9Sjj54BjXjeZIBJ2XJtttXeWD29guM 7c5g== MIME-Version: 1.0 Received: by 10.220.157.14 with SMTP id z14mr1159291vcw.73.1339059023677; Thu, 07 Jun 2012 01:50:23 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 7 Jun 2012 01:50:23 -0700 (PDT) In-Reply-To: <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> Date: Thu, 7 Jun 2012 10:50:23 +0200 Message-ID: From: Abdussalam Baryun To: Fred Baker , manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 08:50:25 -0000 Hi Fred, and All I thank you for your discussions and important comments, I encourage you to discuss in the list because some times I feel that I am alown. I have some opinion/comment points which are aimed to improve WGs in IETF and MANET-WG. Then I will answer Fred's question and comment on some inputs to the subject. As an abstract I will answer the subject title of your post:/ I prefer to define subnets on All three levels of layers L3, L2 and L1, but in WG trying to push for defining nets at L2 now, not worried about nets at L3 or above, nets definition of L1 is out of the IETF scope and it is the job of ITU, but I think L2 nets are a place of both interests of IETF and ITU now and in the future to come. Things are changing :) Firstly, it seems that MANET WG avoided defining things in the past and now they MAY continue, but I beleive that it MUST get to an END some day in future. All IETF WGs SHOULD understand to; *see* by the eyes of the Internet (or Internet of Things= IoT) including all underlyning communication-facilities. To *think* with the brains of IETF-Intellegence, and *listen and Speak* in the way of Productive-Discussion-on-List AND face-to-face-meeting. IMO some WG live in ROOM, or discuss in a ROOM, think in a ROOM, and listen only to what is in a ROOM, this SHOULD change, so we can progress. WGs should be connected some how (like having a gateway router, or getting feedback of performance) and WGs need communicate input-knowledge for the purpose of their productions and for the consistency of IETF output-standards. We have no evaluation process to our WGs which makes production random not encouraged. Secondly, it is noticed from the IETF procedure that WGs AD are responsible to help the WG complete the BIG picture and purpose of the all WGs, so if document/idea/input is done in one Area it should not be repeated in another, AND if some-input related to a WG then WG should be informed in some-ways of what was done in others so that WGs output do not collide and make a disaster. Therefore, MANET WG should discuss and define more productively and stop ignoring facts (i.e. ignore is not progress) that the internet-community and engineers-knowledge are changing (e.g. up or down, does not matter). Please read in line the answers On 6/6/12, Fred Baker wrote: > One thing I have never quite understood, and would appreciate some insight > on, is why a manet or roll network needs a different definition of a subnet > than any other subnetwork does. Help? > because MANET and ROLL are dynamic networks located at Layer 3 (L3) and MAY probably in some time-periods become disapearing and apearing again, therefore, the WGs need to define L2 network technologies. > When we discuss a separate subnet model for manet/roll/etc, it tells me that > we want to somehow enable discontiguous subnets - I can no longer assume > that interfaces within the same subnet know how to reach each other without > leaving the subnet, and I can no longer assume that it is sufficient for > routing in other parts of the network to get datagrams to the subnet in > order to reach an interface within the subnet. That worries me. What am I > missing? I don't want to separate of to integrate, you should think that it is the choice of the customer or user or administrator or the market, to make that decision. I want to define subnets in L2 because they are different in ROLL and MANET application scenarios, I hope you see the interest of making things flexible for the protocols and users. The missing point is that routers are connected to L2 subnets through their logical interfaces and through the IP-layer-interface (this interface connects between L3 and L2), and each router may have more than one interface, therefore, the ROUTER can communicate to all L2 subnets in the same time, but each router can have many L3 subnets, depending on the configuration of IP addressing model. CP> I don't think we ought to create a different subnet model. And I agree > with everything else in your email below. FB>I thought we were in agreement. I do note that both roll and manet have > proposed alternative subnet models, which is at least in part what prompted > your note. Yes, I agree Fred that ROLL and MANET WGs are both working on different subnets in L2 that is my point of my posts before yours. MANET WG oppose the defining as we can read clearly on the discussion list, I am try now to write a draft that defines to make the WG face the problem. Yes, After the request to open ROLL WG means the community already made the change and the community already are defining subnets, but IMHO that MANET WG some day will relise the importance, lets see :) CP>I don't remember a new "subnet model" for [manet]. If it happened, I must have > reinterpreted it to conform to the subnet model already existing in my >understanding. I also don't remember it for [roll], but I couldn't keep up with that >working group. Hi Charlie, yes there is no *subnet model* defined that was the point Mr.Robert Cole has addressed in the WG 82-meeting, and him and Teco have presented the importance for DLEP protocol. ROLL did define there subnets, because they had to do that otherwise they will not be accepted because their routing is dynamic routing we are doing the same idea but different underlying subnet. Therefore, MANET SHOULD think in a way to solve this issue quickly, I RECOMMENDED as long as many opposed which Charlie, you were the first, so I now think we produce a draft for defining subnets at L2, and really want to draft it and submit and hope you and Fred Baker (also if Mr.Cole wants to join), will co-author if you do not mind. UH>I think it would be wrong to define such a multi-link subnet (for the >reasons the IAB described in in RFC4903, and that we tried to convey >at length in AUTOCONF). We had a long discussion about the reasons in >AUTOCONF (which led to RFC5889), and I don't think we should revive >this discussion in MANET. Hi Herberg, I think we should not beary our self just because autoconfig WG had died I think its discussions were not productive so that it was ended. In IETF discussion is more important than drafting papers/documents. Knowledge should be distributed and open to All, not to restrict knowledge-distribution because we MAY NOT be able to discuss productively or to get to solution. It is the CHAIR's job to solve unproductive issues, and WGs advising their AD to help as well for progress. IMHO, it is always the WG memebrs' and the WG Chair's fault/welling if such WG will/have die(d). Best Wishes Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Please note that it is important to consider that this message or reply is aimed to purpose of improving the progress of the WG Discussion and IETF Processes ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ < I may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. IETF WGs are always right > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ **************************************************************************************** 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. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any purpose other than IETF procedures purposes. **************************************************************************************** From jasteven@rockwellcollins.com Thu Jun 7 07:36:30 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBB821F86A1 for ; Thu, 7 Jun 2012 07:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6] 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 ZbFj26yqTkBV for ; Thu, 7 Jun 2012 07:36:29 -0700 (PDT) Received: from secvs02.rockwellcollins.com (secvs02.rockwellcollins.com [205.175.225.241]) by ietfa.amsl.com (Postfix) with ESMTP id 234AA21F8675 for ; Thu, 7 Jun 2012 07:36:28 -0700 (PDT) Received: from nosuchhost.198.131.in-addr.arpa (HELO collinscrsmtp02.rockwellcollins.com) ([131.198.63.133]) by mail-virt.rockwellcollins.com with ESMTP; 07 Jun 2012 09:36:28 -0500 To: manet@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes 652HF1303 November 21, 2007 From: jasteven@rockwellcollins.com Message-ID: Date: Thu, 7 Jun 2012 09:36:27 -0500 X-MIMETrack: Serialize by Router on CollinsCRSMTP02/CedarRapids/RockwellCollins(Release 8.5.2FP2 HF162|May 16, 2011) at 06/07/2012 09:36:27 AM, Serialize complete at 06/07/2012 09:36:27 AM Content-Type: multipart/alternative; boundary="=_alternative 00503CD886257A16_=" Subject: [manet] MANET Routing Below IP (spin off from Subnet Definition thread) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:36:30 -0000 This is a multipart message in MIME format. --=_alternative 00503CD886257A16_= Content-Type: text/plain; charset="US-ASCII" On Jun 6, 2012 at 154:45:20 (-0600), Fred Baker wrote: > On Jun 6, 2012, at 3:16 PM, Charles E. Perkins wrote: >> On 6/6/2012 12:00 PM, Fred Baker wrote: >>> That said, to me, the data link layer tells me how to layer message exchange onto the physical layer and as a result get a message from one >>> end to another of a single physical medium. When I start concatenating physical connectivity and have routing questions >> >> Could they be bridging questions? > >here you hark back to a debate that actually kinda-sorta made sense 20 years ago, but makes no sense in this context. IEEE 802.1, and specifically >802.1d, is a routing technology. It doesn't route in the sense that OSPF or BGP do, but it figures out how to get packets across a network from >point A to point B. Actually, this debate makes a lot of sense today. In fact, this is the way that a lot of companies have been developing & fielding multihop, mobile ad hoc networks for over 4 decades now - going all the way back to the original DARPA funded Packet Radio work in 1970s as part of the original Internet project. Namely multihop routing below IP, so that the multihop wireless network below IP looks like a 1 hop IP link no matter how many wireless hops it takes. In other words, the wireless network does routing analogous to ethernet switching (routing) below IP. And we are still going strong this way today with over a dozen different MANET wireless technologies today that are working with multihop routing below IP - both from my company and other companies. I believe that in total, there are over 100,000 fielded wireless nodes of one type or another of these MANET technologies. Some of these wireless technologies with MANET routing below IP that have been described in public domain documentation include Mil-Std-188-220, MARLIN (STANAG 4691), Link 22 (although the final fielded standard dropped support for IP at layer 3), EPLRS, and FlexNet. Some of these waveforms call this sub-layer below IP the Intranet, others the wireless Subnet, others the Data Link. As an aside, you may ask why are there so many different types of wireless technologies? Well the answer is that there are lots of different requirements with different RF channel conditions with different fading conditions, frequency allocations (different freq bands and bandwidths), data rates (from burst rates with kbps to 100s of Mbps), threats (jamming or not jamming), user traffic with different QOS requirements (from ETE latencies of 10s of milliseconds to minutes, ETE message successful delivery rates (from 90% to 99.999% success), traffic mixes (unicast only, broadcast only, to mix of uni-, multi- & broadcast), etc. >>> , I'm in the network layer; the question is "where". >> >> In my understanding, there isn't any ambiguity about this because, in >> the network layer, network addresses are used. In layer 2, layer 2 addresses >> are used (e.g., for bridging). > >again, harking back to a discussion that is kind of irrelevant. Are you going to tell me that an IP address used by two layers, one of which is >doing subnet routing using, say, OSPF, and the other is doing host routing through AODV, are not both in the network layer? If so, then why would a >network doing two layers of routing, one of which is using subnet routing using, say, OSPF, and the other is doing host routing through 802.1d, is >not both in the network layer? The reason all of the waveforms that I mentioned do routing below IP is that they are all omnidirectional wireless and multihop networks (without base stations or access points with out-of-band infrastructure to use for routing). Thus, MANET operation for these networks is much more than just routing. It includes determining what is a good neighbor and under what conditions (e.g. predicted transmission success probability for given FEC, transmit power, frequency, antenna setting, etc). It includes figuring out which neighbors to address for any given transmission as well as accounting for the self-interference caused by the transmissions. It also includes allocating more resources (e.g. time slots) to adapt to QOS and traffic loading at different nodes in an RF neighborhood. In general, then MANET in these networks means cross-layer optimization of the physical modulation, the channel access, and the Intranet routing. (For example, see my IETF MANET 12 Jul 2002 13:18:43 email, and follow on discussion threads, on "Interference in RF networks.") In general, I claim that since this cross layer optimization cannot be performed by IP MANET routing alone, it makes architectural sense to do MANET Intranet routing below IP and just provide an abstracted IP link cost to the IP routing for that wireless MANET network technology. As an aside, IMO most work in the IETF MANET has been concerned with 802.11 networks and cross-layer optimization have focused on its CTS/RTS MAC layer. This is why work was done to allow jitter to be inserted by the MANET protocols as a type of cross-layer optimization for 802.11 as an Internet Draft circa 2007 and included in RFC 6130 NHDP in 2011. Well Packet Radio already had that optimization included back in 1970s and in Mil-Std-188-220 in 1990s. So, do I think that the IETF MANET work makes sense? Yes! For example, some of the wireless Intranet technologies I mentioned above are using optimized variants of IETF MANET protocols, namely OLSR. The most common optimization is to eliminate the use of Hellos for neighbor discovery (because it is part of the MAC function) as well as using the local MAC layer information to route to nodes that may be 1 or 2 hops away. However, I think that some of the IETF MANET work is not applicable to these Intranet MANETs. For example, Hello messages should be optional if the MAC layer can provide that information directly. In fact, trying to determine neighbors from just hellos alone can lead to poor performance in many of these networks because it doesn't take into account interference as an example and doesn't help select which good nodes to use as good neighbors. Twenty years ago, I used to say that wireless MANET routing **must** be below IP to enable such cross layer optimization. I no longer claim that because I now see some wireless technologies where IP layer MANET routing alone works just fine. However, I am now concerned when people claim that wireless MANET routing must be at IP layer only - because they don't know or understand the issues involved with the cross layer optimization I discussed above. And, it confuses non-networking people who say "if the IETF MANET says it, then it must be true." >>> the Internet layer is an upper sub-layer of the Network Layer, and Ethernet/ATM/IP Tunnels/IP re-used within a manet|roll domain and etc >>> are in a lower sub-layer I call the "Intranet" sub-layer. But yes, I think we agree that the LAN, however comprised, is in a sub-layer >>> lower than the Internet layer. >> >> Do you envision that an "Intranet" layer would use Internet addresses at all? > >RPL is a pretty good example of a routing protocol that makes that assumption. If AODV is used and the node ID is an IP address - very reasonable - >sure. I have seen multiple different types of addressing used in the Intranet below the IP layer. In most cases, the wireless Intranet has its own address separate from the IP address. In many cases, this Intranet address maps to an IP subnet address (say the lower octect or two) for that wireless network. Hence this is why some of the above mentioned wireless MANETs call this layer below IP the Subnet Layer rather than the Intranet layer. In other cases, the wireless Intranet has its own address and a ARP or ARP-like function maps the Intranet address to the IP address. Jim Stevens --=_alternative 00503CD886257A16_= Content-Type: text/html; charset="US-ASCII"
On Jun 6, 2012 at 154:45:20 (-0600), Fred Baker wrote:

> On Jun 6, 2012, at 3:16 PM, Charles E. Perkins wrote:
>> On 6/6/2012 12:00 PM, Fred Baker wrote:
>>> That said, to me, the data link layer tells me how to layer message exchange onto the physical layer and as a result get a message from one

>>> end to another of a single physical medium. When I start concatenating physical connectivity and have routing questions
>>
>> Could they be bridging questions?
>
>here you hark back to a debate that actually kinda-sorta made sense 20 years ago, but makes no sense in this context. IEEE 802.1, and specifically >802.1d, is a routing technology. It doesn't route in the sense that OSPF or BGP do, but it figures out how to get packets across a network from >point A to point B.

Actually, this debate makes a lot of sense today.  In fact, this is the way that a lot of companies have been developing & fielding multihop, mobile ad hoc networks for over 4 decades now - going all the way back to the original DARPA funded Packet Radio work in 1970s as part of the original Internet project.  Namely multihop routing below IP, so that the multihop wireless network below IP looks like a 1 hop IP link no matter how many wireless hops it takes.  In other words, the wireless network does routing analogous to ethernet switching (routing) below IP.

And we are still going strong this way today with over a dozen different MANET wireless technologies today that are working with multihop routing below IP - both from my company and other companies.  I believe that in total, there are over 100,000 fielded wireless nodes of one type or another of these MANET technologies. Some of these wireless technologies with MANET routing below IP that have been described in public domain documentation include Mil-Std-188-220, MARLIN (STANAG 4691), Link 22 (although the final fielded standard dropped support for IP at layer 3), EPLRS, and FlexNet.  Some of these waveforms call this sub-layer below IP the Intranet, others the wireless Subnet, others the Data Link.  

As an aside, you may ask why are there so many different types of wireless technologies?  Well the answer is that there are lots of different requirements with different RF channel conditions with different fading conditions, frequency allocations (different freq bands and bandwidths), data rates (from burst rates with kbps to 100s of Mbps), threats (jamming or not jamming), user traffic with different QOS requirements (from ETE latencies of 10s of milliseconds to minutes, ETE message successful delivery rates (from 90% to 99.999% success), traffic mixes (unicast only, broadcast only, to mix of uni-, multi- & broadcast), etc.  


>>> , I'm in the network layer; the question is "where".
>>
>> In my understanding, there isn't any ambiguity about this because, in
>> the network layer, network addresses are used.  In layer 2, layer 2 addresses
>> are used (e.g., for bridging).
>
>again, harking back to a discussion that is kind of irrelevant. Are you going to tell me that an IP address used by two layers, one of which is >doing subnet routing using, say, OSPF, and the other is doing host routing through AODV, are not both in the network layer? If so, then why would a >network doing two layers of routing, one of which is using subnet routing using, say, OSPF, and the other is doing host routing through 802.1d, is >not both in the network layer?

The reason all of the waveforms that I mentioned do routing below IP is that they are all omnidirectional wireless and multihop networks (without base stations or access points with out-of-band infrastructure to use for routing).  Thus, MANET operation for these networks is much more than just routing.  It includes determining what is a good neighbor and under what conditions (e.g. predicted transmission success probability for given FEC, transmit power, frequency, antenna setting, etc). It includes figuring out which neighbors to address for any given transmission as well as accounting for the self-interference caused by the transmissions. It also includes allocating more resources (e.g. time slots) to adapt to QOS and traffic loading at different nodes in an RF neighborhood. In general, then MANET in these networks means cross-layer optimization of the physical modulation, the channel access, and the Intranet routing. (For example, see my IETF MANET 12 Jul 2002 13:18:43 email, and follow on discussion threads, on "Interference in RF networks.")  In general, I claim that since this cross layer optimization cannot be performed by IP MANET routing alone, it makes architectural sense to do MANET Intranet routing below IP and just provide an abstracted IP link cost to the IP routing for that wireless MANET network technology.

As an aside, IMO most work in the IETF MANET has been concerned with 802.11 networks and cross-layer optimization have focused on its CTS/RTS MAC layer.  This is why work was done to allow jitter to be inserted by the MANET protocols as a type of cross-layer optimization for 802.11 as an Internet Draft circa 2007 and included in RFC 6130 NHDP in 2011. Well Packet Radio already had that optimization included back in 1970s and in Mil-Std-188-220 in 1990s.

So, do I think that the IETF MANET work makes sense? Yes! For example, some of the wireless Intranet technologies I mentioned above are using optimized variants of IETF MANET protocols, namely OLSR. The most common optimization is to eliminate the use of Hellos for neighbor discovery (because it is part of the MAC function) as well as using the local MAC layer information to route to nodes that may be 1 or 2 hops away.

However, I think that some of the IETF MANET work is not applicable to these Intranet MANETs. For example, Hello messages should be optional if the MAC layer can provide that information directly. In fact, trying to determine neighbors from just hellos alone can lead to poor performance in many of these networks because it doesn't take into account interference as an example and doesn't help select which good nodes to use as good neighbors.

Twenty years ago, I used to say that wireless MANET routing **must** be below IP to enable such cross layer optimization. I no longer claim that because I now see some wireless technologies where IP layer MANET routing alone works just fine.  However, I am now concerned when people claim that wireless MANET routing must be at IP layer only - because they don't know or understand the issues involved with the cross layer optimization I discussed above.  And, it confuses non-networking people who say "if the IETF MANET says it, then it must be true."


>>> the Internet layer is an upper sub-layer of the Network Layer, and Ethernet/ATM/IP Tunnels/IP re-used within a manet|roll domain and etc

>>> are in a lower sub-layer I call the "Intranet" sub-layer. But yes, I think we agree that the LAN, however comprised, is in a sub-layer
>>> lower than the Internet layer.
>>
>> Do you envision that an "Intranet" layer would use Internet addresses at all?
>
>RPL is a pretty good example of a routing protocol that makes that assumption. If AODV is used and the node ID is an IP address - very reasonable - >sure.

I have seen multiple different types of addressing used in the Intranet below the IP layer.  In most cases, the wireless Intranet has its own address separate from the IP address.  In many cases, this Intranet address maps to an IP subnet address (say the lower octect or two) for that wireless network.  Hence this is why some of the above mentioned wireless MANETs call this layer below IP the Subnet Layer rather than the Intranet layer.   In other cases, the wireless Intranet has its own address and a ARP or ARP-like function maps the Intranet address to the IP address.


Jim Stevens







--=_alternative 00503CD886257A16_=-- From sratliff@cisco.com Thu Jun 7 07:42:54 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8C621F88E3 for ; Thu, 7 Jun 2012 07:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 Miyj9CCWVbhH for ; Thu, 7 Jun 2012 07:42:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7592F21F88D8 for ; Thu, 7 Jun 2012 07:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2946; q=dns/txt; s=iport; t=1339080167; x=1340289767; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=muWtsanEWxn/71k+vBxjWUifIPtmwIf97+GZgGmSbPA=; b=hYSx3KnyVz84H9oa9f2SR3hURLlY6dyimtUsQY/Pv+X0My+UVYUWAaAc 8+95U4oiCjc56f2hfa6QXHQiSYEGTDtK99y9TIwVD8Pvukhn/WEhRPX4i sLNTUYU+W2iGbYlf5iA7oYb5Dzcg80OFDiMiQk/JBB3EjAn64/IkxR3yz U=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="90408804" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jun 2012 14:42:47 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q57EgkNL005989; Thu, 7 Jun 2012 14:42:47 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> Date: Thu, 7 Jun 2012 10:42:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:42:54 -0000 On Jun 6, 2012, at 1:13 PM, Fred Baker wrote: > One thing I have never quite understood, and would appreciate some = insight on, is why a manet or roll network needs a different definition = of a subnet than any other subnetwork does. Help? >=20 > The IPv4/IPv6 definition of a subnet might perhaps be "a set of = interfaces that are reachable via one Internet layer hop from a router = within the subnet, at least from the perspective of a host outside the = subnet", and by extension are (at least in concept) mutually reachable = by all of the interfaces within the subnet without leaving the subnet. I = could imagine relaxing that model to support a multi-star network - = everyone in the same subnet is reachable *via*any*router* with an = interface in the subnet - but even so, the key attribute is that the = subnet is contiguous from a perspective of subnet routing. I model it, = conceptually, in a manner similar to the L1/L2 distinction in IS-IS; L2 = aggregates using subnets, but within the L1 domain uses host routing (as = in TRILL). >=20 > Within an Ethernet LAN, for example, I might have a sprawling switched = network with hundreds or even thousands of Ethernet interfaces, but = unless someone is actually aware of the switches (eg, operating at the = Ethernet layer), they can be viewed from layer 3 as if they were = physically attached to a common physical cable. In an AODV or OLSR = world, we might use the IP header to do host routing within the subnet, = but from the viewpoint of anyone outside the subnet, they send a = datagram to any connecting router, and it hands the datagram to the = IP-connected device as its at-least-conceptual next hop (modulo TTL, = which still needs to be handled). Ditto a RPL world. >=20 > When we discuss a separate subnet model for manet/roll/etc, it tells = me that we want to somehow enable discontiguous subnets - I can no = longer assume that interfaces within the same subnet know how to reach = each other without leaving the subnet, and I can no longer assume that = it is sufficient for routing in other parts of the network to get = datagrams to the subnet in order to reach an interface within the = subnet. That worries me. What am I missing? Discontiguous subnets are possible in these networks, due to mobility. = Consider a scenario where I have Group A in one subnet, and Group B in = another. Due to everyone moving around, I get in a position where Group = A is split into 2 halves, with Group B in the middle. At that point, you = either have to talk about a discontiguous subnet, or somehow cause the = "appropriate" host routes to be injected in the right places (e.g. one = half of Group A needs host routes for the other half that go via Group = B). Regards, Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Thu Jun 7 07:58:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDDBD21F86F0 for ; Thu, 7 Jun 2012 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 fLA5J7hydsl2 for ; Thu, 7 Jun 2012 07:58:17 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24A9321F86EC for ; Thu, 7 Jun 2012 07:58:17 -0700 (PDT) Received: by dacx6 with SMTP id x6so1012202dac.31 for ; Thu, 07 Jun 2012 07:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=nbHdmCHjpAehBCfaBH91gVolGWswPckCM7GHw+qbacs=; b=zT25QkcUdtDcu3s7djmnDe9HpjAIoP3ptY2nF/xhbl4AReD1DxCWXGpSOCB8j87wp/ jXD0lgW0jTgsWg3+FIsz5uYdNYxTHiVwud09ovmaEzgUXNjDaafQBchSNY9mSWPMn/J6 deK0x8nLlPlGuitikPhllIQm7s8ETLQClOfy0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=nbHdmCHjpAehBCfaBH91gVolGWswPckCM7GHw+qbacs=; b=iyBESqfPnJ/osPoDKp2WSeEeX2jF4vLgMm9jtqPIqAHnhq3Uq2APvdSFNJaWwKkgx5 MDDO6yIFyFbc5vOZKkWBdSR/MDaQmPaGV/HrohQNsoAHL0tz/LttnlWI4vRL1mIavt+A FHYTgNyNgQAOtk8iHlO1Khq/3t/NxArzVO8eZbQKXJymyU5U6xgjq0iNAf+vjDtu/ka6 Qh4/UiyRIezm61LVyTML9KGbTky89ouFI7tucbbIfp0bSTXYix4Yc39yPZkuttXw9U7x kUpMu5yxoqR/NoDlAsXFeyHmuWPrfJrwLg0UdHW/qrh/xfltDO6OaxGmluONXzsxhvHj JnAw== Received: by 10.68.222.197 with SMTP id qo5mr9618167pbc.72.1339081096920; Thu, 07 Jun 2012 07:58:16 -0700 (PDT) Received: from [192.168.1.4] (c-24-5-73-168.hsd1.ca.comcast.net. [24.5.73.168]) by mx.google.com with ESMTPS id ny10sm1508037pbb.38.2012.06.07.07.58.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 07:58:14 -0700 (PDT) References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6AED76A2-FC39-4C00-B068-ACF60510B722@herberg.name> X-Mailer: iPad Mail (9B206) From: Ulrich Herberg Date: Thu, 7 Jun 2012 07:58:12 -0700 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQlOeTFl57E715wRTuhCSp5m2GGnNGGb+Pm3SyC0vfqwo0qRBQQQ4pOKGSDlPFExO/MYts24 Cc: manet , Fred Baker Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 14:58:19 -0000 Let me clarify: Autoconf did not die because a lack of discussion. Quite to t= he contrary! We had extremely many and long discussions and several drafts t= rying to tackle the issue. Over 5 years we did that, and many of the partici= pants are the same that are also active in MANET.=20 Ulrich On Jun 7, 2012, at 1:50, Abdussalam Baryun wrot= e: > Hi Herberg, I think we should not beary our self just because autoconfig W= G had > died I think its discussions were not productive so that it was ended. In I= ETF > discussion is more important than drafting papers/documents. Knowledge > should be > distributed and open to All, not to restrict knowledge-distribution > because we MAY > NOT be able to discuss productively or to get to solution. It is the > CHAIR's job to > solve unproductive issues, and WGs advising their AD to help as well > for progress. > IMHO, it is always the WG memebrs' and the WG Chair's fault/welling if > such WG will/have die(d). From jomullen@ad.nmsu.edu Thu Jun 7 08:00:08 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE2E21F85F4 for ; Thu, 7 Jun 2012 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 UJIWDshDHi0D for ; Thu, 7 Jun 2012 08:00:05 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-01.nmsu.edu [128.123.34.211]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9C21F85BD for ; Thu, 7 Jun 2012 08:00:04 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.89]) by exchange-ht-01.ACN.ad.nmsu.edu ([128.123.34.211]) with mapi; Thu, 7 Jun 2012 08:59:55 -0600 From: Dr John P Mullen To: manet Date: Thu, 7 Jun 2012 08:59:55 -0600 Thread-Topic: [manet] Subnet definition -- why do we need one that is different than standard IP? Thread-Index: Ac1Eu9QVQWg5VQxfTayLGCrMmD9Y0gAAIFGw Message-ID: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:00:08 -0000 This discussion brings back a lot of memories. In the early days, I spent a lot of time explaining to people that MANETs a= re a different animal and things that are a good idea for other forms of ne= tworking or communication are not such good ideas for MANETs. I think subne= ts is one of those things. As I understand it, there are two possible reasons to subnet 1. To improve routing efficiency. Different subnets represent different con= tiguous portions of a larger network. Some routing can be accomplished base= d on subnet address. This leads to smaller routing tables and faster routin= g.=20 2. To reflect organizational structures or restrictions. For example, mark= eting and production. At one level, just to reduce the volume of irrelevant= traffic, at another to prevent people who should not have access from gett= ing or changing information. MANET routing protocols perform function #1. Many protocols essentially con= struct and maintain dynamic subnets and use information from nodes to manag= e the continually changing topological structure. For this function, a subn= et would be redundant. For the second, subnets can be superimposed at an appropriate layer, depend= ing on security concerns. However, as Fred points out, we would not want th= at subnet structure to create a partition, so the most efficient thing woul= d be for the MANET protocol to ignore it and let higher layers implement an= y subnetting.=20 But, I could be wrong. ^_^ John Mullen -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of S= tan Ratliff Sent: Thursday, June 07, 2012 8:43 AM To: Fred Baker Cc: manet; Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is differ= ent than standard IP? On Jun 6, 2012, at 1:13 PM, Fred Baker wrote: > One thing I have never quite understood, and would appreciate some insigh= t on, is why a manet or roll network needs a different definition of a subn= et than any other subnetwork does. Help? >=20 > The IPv4/IPv6 definition of a subnet might perhaps be "a set of interface= s that are reachable via one Internet layer hop from a router within the su= bnet, at least from the perspective of a host outside the subnet", and by e= xtension are (at least in concept) mutually reachable by all of the interfa= ces within the subnet without leaving the subnet. I could imagine relaxing = that model to support a multi-star network - everyone in the same subnet is= reachable *via*any*router* with an interface in the subnet - but even so, = the key attribute is that the subnet is contiguous from a perspective of su= bnet routing. I model it, conceptually, in a manner similar to the L1/L2 di= stinction in IS-IS; L2 aggregates using subnets, but within the L1 domain u= ses host routing (as in TRILL). >=20 > Within an Ethernet LAN, for example, I might have a sprawling switched ne= twork with hundreds or even thousands of Ethernet interfaces, but unless so= meone is actually aware of the switches (eg, operating at the Ethernet laye= r), they can be viewed from layer 3 as if they were physically attached to = a common physical cable. In an AODV or OLSR world, we might use the IP head= er to do host routing within the subnet, but from the viewpoint of anyone o= utside the subnet, they send a datagram to any connecting router, and it ha= nds the datagram to the IP-connected device as its at-least-conceptual next= hop (modulo TTL, which still needs to be handled). Ditto a RPL world. >=20 > When we discuss a separate subnet model for manet/roll/etc, it tells me t= hat we want to somehow enable discontiguous subnets - I can no longer assum= e that interfaces within the same subnet know how to reach each other witho= ut leaving the subnet, and I can no longer assume that it is sufficient for= routing in other parts of the network to get datagrams to the subnet in or= der to reach an interface within the subnet. That worries me. What am I mis= sing? Discontiguous subnets are possible in these networks, due to mobility. Cons= ider a scenario where I have Group A in one subnet, and Group B in another.= Due to everyone moving around, I get in a position where Group A is split = into 2 halves, with Group B in the middle. At that point, you either have t= o talk about a discontiguous subnet, or somehow cause the "appropriate" hos= t routes to be injected in the right places (e.g. one half of Group A needs= host routes for the other half that go via Group B). Regards, Stan > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From fred@cisco.com Thu Jun 7 08:13:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E550011E808C for ; Thu, 7 Jun 2012 08:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.48 X-Spam-Level: X-Spam-Status: No, score=-110.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 VeHChS7Lqh4z for ; Thu, 7 Jun 2012 08:13:23 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0717B11E8089 for ; Thu, 7 Jun 2012 08:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2340; q=dns/txt; s=iport; t=1339082003; x=1340291603; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=LGk2it2owYF1G23m6GV09Lpx2+GvwSIujGmlVRMopCA=; b=T9eipTZBYdGNDrFQSFkv5MxG2fcTPep0sFnTlQMcfjUq9F9Q69IJSvNf DdilIi5hGdZUri6kxBJZfoeJIQSHjeGq1tmrH70rkYdJGm9Pzxf5VeEpT IpVqpyRCEaaI6/p6z4OznW3QAEhl7Y/tWdZmi3c4yfYJqRaqlGl/G5QCE E=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="47962768" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 07 Jun 2012 15:13:22 +0000 Received: from sjc-vpn5-1824.cisco.com (sjc-vpn5-1824.cisco.com [10.21.95.32]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q57FDL8w011223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 15:13:22 GMT Received: from [127.0.0.1] by sjc-vpn5-1824.cisco.com (PGP Universal service); Thu, 07 Jun 2012 09:13:22 -0600 X-PGP-Universal: processed; by sjc-vpn5-1824.cisco.com on Thu, 07 Jun 2012 09:13:22 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 7 Jun 2012 09:12:56 -0600 Message-Id: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:13:24 -0000 On Jun 7, 2012, at 8:42 AM, Stan Ratliff wrote: > Discontiguous subnets are possible in these networks, due to mobility. = Consider a scenario where I have Group A in one subnet, and Group B in = another. Due to everyone moving around, I get in a position where Group = A is split into 2 halves, with Group B in the middle. At that point, you = either have to talk about a discontiguous subnet, or somehow cause the = "appropriate" host routes to be injected in the right places (e.g. one = half of Group A needs host routes for the other half that go via Group = B). In that case it should simply be host routing, not subnet routing, which = AFAIK is status quo in manet networks. The routers to other parts of the = world should be able to find the host routes for devices in the manet, = no? Here's my concern.=20 So I now have some truly large routing domain - BGP among serveral AS's, = perhaps going to the Internet and perhaps in some other network, within = a given AS a few hundred subnets to fixed and mobile domains, and within = a given subnet a number of vehicles wandering around. The routing = assumption that every OTHER routing protocol makes is that it is = sufficient to get a packet to the subnet, and the subnet will take care = of getting it to the host in question. The details of how that is done = are irrelevant except within the subnet. If other routing domains have to interact with a subnet that can = bifurcate, then they have to do something that they are currently = unprepared to do - not only get it to "a router in the subnet", but "the = right router in the subnet". urk. If the routing system is willing to export host routes from the subnet - = "each router in the subnet can reach 2001:0db8:0:1::/64, but = 2001:0db8:0:1::dead:beef/128 is carried outside the domain as a host = route", or the various routers in the subnet advertise host routes for = themselves and advertise host routes within the subnet among themselves, = that works. I can still follow "longest match" and get the packet = delivered to the endpoint without worrying about "the right router" = outside the subnet. But I would not want to literally bifurcate the = subnet and expect the rest of the routing system to interact with it. pictures on request if I'm not being clear.= From sratliff@cisco.com Thu Jun 7 08:23:20 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CA121F8738 for ; Thu, 7 Jun 2012 08:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 mRWeHDmihtQ0 for ; Thu, 7 Jun 2012 08:23:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id D24F121F870A for ; Thu, 7 Jun 2012 08:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=1760; q=dns/txt; s=iport; t=1339082598; x=1340292198; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=e3TMWakSqsiyWN9pny43xjgjkQtdmvGzLVJ0lymLzuE=; b=kExQ5GyMQXsdalPe/WEb+LIKSfLZ0XRfv7DZZx+K5eyONNm1Z05nYDX4 r1Mh1O4+hiyFlG6D/p0jzMOwfyMgJ0mKeONpTIMDBWJoeAAy5FwoaSCe0 foAaalq+Gq1yGkM/ikkDp1Nf87FQu9YMYMRCqRn434TpOauDaKZkMd8LC I=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="90402551" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 07 Jun 2012 15:23:14 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q57FNERm014200; Thu, 7 Jun 2012 15:23:14 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Stan Ratliff In-Reply-To: <6AED76A2-FC39-4C00-B068-ACF60510B722@herberg.name> Date: Thu, 7 Jun 2012 11:23:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5D3FD5F3-DB07-42CF-A6F6-757405BFB201@cisco.com> References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <6AED76A2-FC39-4C00-B068-ACF60510B722@herberg.name> To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) Cc: manet , Fred Baker , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:23:20 -0000 Ditto what Ulrich said. The working group not to be named died only = after many, many, MANY long, tedious discussions. Discussions that = yielded exactly 1 document.=20 At a baseline, fundamental level, discussion of a "subnet model" in an = "ad-hoc" network seems like an oxymoron to me=85 if we have a specific = "model" that the network fits into, how is that "ad-hoc"? I'll say it = again - unfortunately, the only subnet model that fits is that there = isn't a subnet model.=20 Regards, Stan On Jun 7, 2012, at 10:58 AM, Ulrich Herberg wrote: > Let me clarify: Autoconf did not die because a lack of discussion. = Quite to the contrary! We had extremely many and long discussions and = several drafts trying to tackle the issue. Over 5 years we did that, and = many of the participants are the same that are also active in MANET.=20 >=20 > Ulrich >=20 > On Jun 7, 2012, at 1:50, Abdussalam Baryun = wrote: >=20 >> Hi Herberg, I think we should not beary our self just because = autoconfig WG had >> died I think its discussions were not productive so that it was = ended. In IETF >> discussion is more important than drafting papers/documents. = Knowledge >> should be >> distributed and open to All, not to restrict knowledge-distribution >> because we MAY >> NOT be able to discuss productively or to get to solution. It is the >> CHAIR's job to >> solve unproductive issues, and WGs advising their AD to help as well >> for progress. >> IMHO, it is always the WG memebrs' and the WG Chair's fault/welling = if >> such WG will/have die(d). > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Thu Jun 7 08:27:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F358E21F87E3 for ; Thu, 7 Jun 2012 08:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 U+3NhRe811UE for ; Thu, 7 Jun 2012 08:27:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F082921F87AE for ; Thu, 7 Jun 2012 08:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2687; q=dns/txt; s=iport; t=1339082860; x=1340292460; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ZMWLSIIINvae6OoMYkDvSV480majHKFF+CkEoGAmVsc=; b=IJubFDegTnqY/pZvbgv+CV6k0WzCPnL/D8NfGk/8I4INWYDiX5nlbvqx 4hY3CCBFWODFfCmjmhz26lNfOF9zaM9Cyrc2hWfUSdhxsj0peCKKM7DXn JA8ei0yMG0mEyWae7lHUt16HsSd+E4m5KodweQwJ09I2lucqgVXDzcI1v A=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="90448917" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 07 Jun 2012 15:27:39 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q57FRdBQ016434; Thu, 7 Jun 2012 15:27:39 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Thu, 7 Jun 2012 11:27:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1278) Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:27:41 -0000 On Jun 7, 2012, at 11:12 AM, Fred Baker wrote: >=20 > On Jun 7, 2012, at 8:42 AM, Stan Ratliff wrote: >=20 >> Discontiguous subnets are possible in these networks, due to = mobility. Consider a scenario where I have Group A in one subnet, and = Group B in another. Due to everyone moving around, I get in a position = where Group A is split into 2 halves, with Group B in the middle. At = that point, you either have to talk about a discontiguous subnet, or = somehow cause the "appropriate" host routes to be injected in the right = places (e.g. one half of Group A needs host routes for the other half = that go via Group B). >=20 > In that case it should simply be host routing, not subnet routing, = which AFAIK is status quo in manet networks. The routers to other parts = of the world should be able to find the host routes for devices in the = manet, no? Yep, we're on the same page. Host routing gets around that issue.=20 >=20 > Here's my concern.=20 >=20 > So I now have some truly large routing domain - BGP among serveral = AS's, perhaps going to the Internet and perhaps in some other network, = within a given AS a few hundred subnets to fixed and mobile domains, and = within a given subnet a number of vehicles wandering around. The routing = assumption that every OTHER routing protocol makes is that it is = sufficient to get a packet to the subnet, and the subnet will take care = of getting it to the host in question. The details of how that is done = are irrelevant except within the subnet. >=20 > If other routing domains have to interact with a subnet that can = bifurcate, then they have to do something that they are currently = unprepared to do - not only get it to "a router in the subnet", but "the = right router in the subnet". urk. :-) Urk indeed.=20 >=20 > If the routing system is willing to export host routes from the subnet = - "each router in the subnet can reach 2001:0db8:0:1::/64, but = 2001:0db8:0:1::dead:beef/128 is carried outside the domain as a host = route", or the various routers in the subnet advertise host routes for = themselves and advertise host routes within the subnet among themselves, = that works. I can still follow "longest match" and get the packet = delivered to the endpoint without worrying about "the right router" = outside the subnet. But I would not want to literally bifurcate the = subnet and expect the rest of the routing system to interact with it. >=20 > pictures on request if I'm not being clear. I think I've got the picture. Sounds like you're OK with a subnet = definition in MANETs that would be "a subnet of 1"??? ;-)=20 Regards, Stan From fred@cisco.com Thu Jun 7 08:35:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661BA21F8893 for ; Thu, 7 Jun 2012 08:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.486 X-Spam-Level: X-Spam-Status: No, score=-110.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 xpKmMMfDcAyF for ; Thu, 7 Jun 2012 08:35:52 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EF9DA21F8879 for ; Thu, 7 Jun 2012 08:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=449; q=dns/txt; s=iport; t=1339083351; x=1340292951; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=MdNVHabSUH0c+DXnYXACVFWKheAZryVjP90Zdh2Oh4k=; b=ioEL/XKZ+H8Az9LzPtwo5KUC6cFKT3NJbUsROcusr03DTWwtoskxu7n3 K5BrOy4GqrAbsgguGqKKrtOfmV3yE+AeSgMlp95JGZkLhbw+UDjF66q+0 KM5bx/s+jsY8OKvJ0BytjTzH2pcWzdm8xBKsBBChc66bSsof/pbbiaERn c=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="44936925" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 07 Jun 2012 15:35:51 +0000 Received: from sjc-vpn5-1824.cisco.com (sjc-vpn5-1824.cisco.com [10.21.95.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q57FZoVh028428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 15:35:51 GMT Received: from [127.0.0.1] by sjc-vpn5-1824.cisco.com (PGP Universal service); Thu, 07 Jun 2012 09:35:51 -0600 X-PGP-Universal: processed; by sjc-vpn5-1824.cisco.com on Thu, 07 Jun 2012 09:35:51 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 7 Jun 2012 09:35:05 -0600 Message-Id: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> To: Stan Ratliff X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 15:35:52 -0000 On Jun 7, 2012, at 9:27 AM, Stan Ratliff wrote: > Sounds like you're OK with a subnet definition in MANETs that would be = "a subnet of 1"??? ;-)=20 A host route is a prefix of the full length (/32 or /128 depending on = the flavor of the month). Yes, I'm OK with host routing within a domain = that understands that it is happening and whose administration is OK = with it.=20 #include standard remarks on aggregation and scaling.= From Chris.Dearlove@baesystems.com Thu Jun 7 09:09:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6C111E80D2 for ; Thu, 7 Jun 2012 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MoskpGvXaLiy for ; Thu, 7 Jun 2012 09:09:15 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFE911E808C for ; Thu, 7 Jun 2012 09:08:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="244395350" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 07 Jun 2012 17:08:35 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q57G8ZSW013777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jun 2012 17:08:35 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 7 Jun 2012 17:08:35 +0100 From: "Dearlove, Christopher (UK)" To: Fred Baker , Stan Ratliff Thread-Topic: [manet] Subnet definition -- why do we need one that is different than standard IP? Thread-Index: AQHNRLvV1b91MlojQEu/eNmuNjDaX5bu5c0AgAAcgAA= Date: Thu, 7 Jun 2012 16:08:34 +0000 Message-ID: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:09:16 -0000 I think that a model that may apply (when you want/need scalability) is one= where there are gateway nodes between the MANET and the rest of the networ= k, the gateway nodes being both part of the MANET and outside it (very roug= hly speaking). The knowledge that there is something different about the MA= NET is limited to the gateway nodes, other network nodes just route to a ga= teway node, treating the MANET as being handled by an aggregated address pr= efix. (I'm going to avoid the s word.) Things get complicated with multiple= gateways and fragmented MANETs, especially together, and then we need inte= lligence at the gateways, which may need further work (perhaps tunnelling b= etween gateways similarly to mobile IP). But at least the other routing dom= ains are off the hook. Don't recall where I've seen this suggested in the IETF, but it's not origi= nal with me of course. Maybe in NEMO? --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of F= red Baker Sent: 07 June 2012 16:13 To: Stan Ratliff Cc: manet; Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is differ= ent than standard IP? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Jun 7, 2012, at 8:42 AM, Stan Ratliff wrote: > Discontiguous subnets are possible in these networks, due to mobility. Co= nsider a scenario where I have Group A in one subnet, and Group B in anothe= r. Due to everyone moving around, I get in a position where Group A is spli= t into 2 halves, with Group B in the middle. At that point, you either have= to talk about a discontiguous subnet, or somehow cause the "appropriate" h= ost routes to be injected in the right places (e.g. one half of Group A nee= ds host routes for the other half that go via Group B). In that case it should simply be host routing, not subnet routing, which AF= AIK is status quo in manet networks. The routers to other parts of the worl= d should be able to find the host routes for devices in the manet, no? Here's my concern.=20 So I now have some truly large routing domain - BGP among serveral AS's, pe= rhaps going to the Internet and perhaps in some other network, within a giv= en AS a few hundred subnets to fixed and mobile domains, and within a given= subnet a number of vehicles wandering around. The routing assumption that = every OTHER routing protocol makes is that it is sufficient to get a packet= to the subnet, and the subnet will take care of getting it to the host in = question. The details of how that is done are irrelevant except within the = subnet. If other routing domains have to interact with a subnet that can bifurcate,= then they have to do something that they are currently unprepared to do - = not only get it to "a router in the subnet", but "the right router in the s= ubnet". urk. If the routing system is willing to export host routes from the subnet - "e= ach router in the subnet can reach 2001:0db8:0:1::/64, but 2001:0db8:0:1::d= ead:beef/128 is carried outside the domain as a host route", or the various= routers in the subnet advertise host routes for themselves and advertise h= ost routes within the subnet among themselves, that works. I can still foll= ow "longest match" and get the packet delivered to the endpoint without wor= rying about "the right router" outside the subnet. But I would not want to = literally bifurcate the subnet and expect the rest of the routing system to= interact with it. pictures on request if I'm not being clear. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** From fred@cisco.com Thu Jun 7 09:22:10 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4017911E810F for ; Thu, 7 Jun 2012 09:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 g58fbWtghkm3 for ; Thu, 7 Jun 2012 09:22:09 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD3811E810C for ; Thu, 7 Jun 2012 09:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5587; q=dns/txt; s=iport; t=1339086129; x=1340295729; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=ho2siaOq+vaNoJIc+p09ztQkq5gQQLKiPQP1k57T2mY=; b=hluMlNpct3AUN1Zce2ccjsJNop/gC14a3ylL2uSaUpFewiIGdweTjUFu HGJcl1r57uHCrp2yCacpjpq7PQCdpjLwM8CxMTWucnoJJY5bh9cTpPPpH WwNWWbfJky7378dc6utT+GlGyABSQ7/ej2kTGFpRRLySbIdSCGeXLFgeW w=; X-IronPort-AV: E=Sophos;i="4.75,731,1330905600"; d="scan'208";a="48056316" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 07 Jun 2012 16:22:09 +0000 Received: from sjc-vpn5-1824.cisco.com (sjc-vpn5-1824.cisco.com [10.21.95.32]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q57GM8T5023045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 7 Jun 2012 16:22:08 GMT Received: from [127.0.0.1] by sjc-vpn5-1824.cisco.com (PGP Universal service); Thu, 07 Jun 2012 10:22:09 -0600 X-PGP-Universal: processed; by sjc-vpn5-1824.cisco.com on Thu, 07 Jun 2012 10:22:09 -0600 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 7 Jun 2012 10:21:42 -0600 Message-Id: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: manet , Stan Ratliff Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:22:10 -0000 On Jun 7, 2012, at 10:08 AM, Dearlove, Christopher (UK) wrote: > I think that a model that may apply (when you want/need scalability) = is one where there are gateway nodes between the MANET and the rest of = the network, the gateway nodes being both part of the MANET and outside = it (very roughly speaking). The knowledge that there is something = different about the MANET is limited to the gateway nodes, other network = nodes just route to a gateway node, treating the MANET as being handled = by an aggregated address prefix. (I'm going to avoid the s word.) Things = get complicated with multiple gateways and fragmented MANETs, especially = together, and then we need intelligence at the gateways, which may need = further work (perhaps tunnelling between gateways similarly to mobile = IP). But at least the other routing domains are off the hook. >=20 > Don't recall where I've seen this suggested in the IETF, but it's not = original with me of course. Maybe in NEMO? What you're describing is usually called a router; as defined in RFC = 2460, a system that has an interface in each of two or more subnets and = receives traffic in any given subnet with a view to forwarding it to = another. I would hope it's implicit in the IP Routing Architecture.=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > 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 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Fred Baker > Sent: 07 June 2012 16:13 > To: Stan Ratliff > Cc: manet; Abdussalam Baryun > Subject: Re: [manet] Subnet definition -- why do we need one that is = different than standard IP? >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > On Jun 7, 2012, at 8:42 AM, Stan Ratliff wrote: >=20 >> Discontiguous subnets are possible in these networks, due to = mobility. Consider a scenario where I have Group A in one subnet, and = Group B in another. Due to everyone moving around, I get in a position = where Group A is split into 2 halves, with Group B in the middle. At = that point, you either have to talk about a discontiguous subnet, or = somehow cause the "appropriate" host routes to be injected in the right = places (e.g. one half of Group A needs host routes for the other half = that go via Group B). >=20 > In that case it should simply be host routing, not subnet routing, = which AFAIK is status quo in manet networks. The routers to other parts = of the world should be able to find the host routes for devices in the = manet, no? >=20 > Here's my concern.=20 >=20 > So I now have some truly large routing domain - BGP among serveral = AS's, perhaps going to the Internet and perhaps in some other network, = within a given AS a few hundred subnets to fixed and mobile domains, and = within a given subnet a number of vehicles wandering around. The routing = assumption that every OTHER routing protocol makes is that it is = sufficient to get a packet to the subnet, and the subnet will take care = of getting it to the host in question. The details of how that is done = are irrelevant except within the subnet. >=20 > If other routing domains have to interact with a subnet that can = bifurcate, then they have to do something that they are currently = unprepared to do - not only get it to "a router in the subnet", but "the = right router in the subnet". urk. >=20 > If the routing system is willing to export host routes from the subnet = - "each router in the subnet can reach 2001:0db8:0:1::/64, but = 2001:0db8:0:1::dead:beef/128 is carried outside the domain as a host = route", or the various routers in the subnet advertise host routes for = themselves and advertise host routes within the subnet among themselves, = that works. I can still follow "longest match" and get the packet = delivered to the endpoint without worrying about "the right router" = outside the subnet. But I would not want to literally bifurcate the = subnet and expect the rest of the routing system to interact with it. >=20 > pictures on request if I'm not being clear. > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 From charliep@computer.org Thu Jun 7 09:22:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B581511E811A for ; Thu, 7 Jun 2012 09:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 RjOpBcUCbaQx for ; Thu, 7 Jun 2012 09:22:13 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 24E7B11E8119 for ; Thu, 7 Jun 2012 09:22:13 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ScfTQ-0004sJ-Bg; Thu, 07 Jun 2012 12:22:12 -0400 Message-ID: <4FD0D52C.1030907@computer.org> Date: Thu, 07 Jun 2012 09:22:04 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86897b7e25e54cdb9fec815e4493c723ab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet , Fred Baker , Stan Ratliff Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:22:13 -0000 Hello Chris, Really nothing special is needed as long as the gateway does not advertise the host routes into the Internet. For multiple gateways, if routes need to be shared, then the sharing can be done in a straightforward way. But, deciding which routes need to be shared starts to sound like policy, which doesn't sound ad hoc. And that does not have to be done until after the single-domain tasks are done. Regards, Charlie P. On 6/7/2012 9:08 AM, Dearlove, Christopher (UK) wrote: > I think that a model that may apply (when you want/need scalability) is one where there are gateway nodes between the MANET and the rest of the network, the gateway nodes being both part of the MANET and outside it (very roughly speaking). The knowledge that there is something different about the MANET is limited to the gateway nodes, other network nodes just route to a gateway node, treating the MANET as being handled by an aggregated address prefix. (I'm going to avoid the s word.) Things get complicated with multiple gateways and fragmented MANETs, especially together, and then we need intelligence at the gateways, which may need further work (perhaps tunnelling between gateways similarly to mobile IP). But at least the other routing domains are off the hook. > > Don't recall where I've seen this suggested in the IETF, but it's not original with me of course. Maybe in NEMO? > -- Regards, Charlie P. From Chris.Dearlove@baesystems.com Thu Jun 7 09:31:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41311E810A for ; Thu, 7 Jun 2012 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 o0qdZR96FtXV for ; Thu, 7 Jun 2012 09:31:17 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9665811E8085 for ; Thu, 7 Jun 2012 09:31:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="244401722" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 07 Jun 2012 17:31:17 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q57GVGSh029320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jun 2012 17:31:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 7 Jun 2012 17:31:16 +0100 From: "Dearlove, Christopher (UK)" To: "Charles E. Perkins" Thread-Topic: [manet] Subnet definition -- why do we need one that is different than standard IP? Thread-Index: AQHNRLvV1b91MlojQEu/eNmuNjDaX5bu5c0AgAAcgAD///bRAIAAER8g Date: Thu, 7 Jun 2012 16:31:15 +0000 Message-ID: References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FD0D52C.1030907@computer.org> In-Reply-To: <4FD0D52C.1030907@computer.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet , Fred Baker , Stan Ratliff Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:31:18 -0000 The special case arises when the MANET has two gateways (I see Fred's comme= nt saying this is just a router, this case is when it gets a bit more than = that) and fragments, so that part of the MANET is attached to gateway A, an= d part to gateway B. And without any addressing in the MANET that indicates= that. Now another routing domain, which knows nothing of this, just routes= to one of the gateways, let's say A. But the destination in question is in= the fragment attached to gateway B. And it gets a little more complicated = still if there is a gateway C. Of course you can avoid all that if you advertise /32 or /128 addresses int= o other routing domains. This is only if you want to avoid that, but still = handle the case above. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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:charliep@computer.org]=20 Sent: 07 June 2012 17:22 To: Dearlove, Christopher (UK) Cc: Fred Baker; Stan Ratliff; manet Subject: Re: [manet] Subnet definition -- why do we need one that is differ= ent than standard IP? ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hello Chris, Really nothing special is needed as long as the gateway does not=20 advertise the host routes into the Internet. For multiple gateways, if routes need to be shared, then the sharing can=20 be done in a straightforward way. But, deciding which routes need to be shared starts to sound like=20 policy, which doesn't sound ad hoc. And that does not have to be done until after the single-domain tasks=20 are done. Regards, Charlie P. On 6/7/2012 9:08 AM, Dearlove, Christopher (UK) wrote: > I think that a model that may apply (when you want/need scalability) is o= ne where there are gateway nodes between the MANET and the rest of the netw= ork, the gateway nodes being both part of the MANET and outside it (very ro= ughly speaking). The knowledge that there is something different about the = MANET is limited to the gateway nodes, other network nodes just route to a = gateway node, treating the MANET as being handled by an aggregated address = prefix. (I'm going to avoid the s word.) Things get complicated with multip= le gateways and fragmented MANETs, especially together, and then we need in= telligence at the gateways, which may need further work (perhaps tunnelling= between gateways similarly to mobile IP). But at least the other routing d= omains are off the hook. > > Don't recall where I've seen this suggested in the IETF, but it's not ori= ginal with me of course. Maybe in NEMO? > --=20 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. ******************************************************************** From charliep@computer.org Thu Jun 7 09:34:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9325A11E8120 for ; Thu, 7 Jun 2012 09:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 PofQQRhldx74 for ; Thu, 7 Jun 2012 09:34:13 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 023B111E8110 for ; Thu, 7 Jun 2012 09:34:13 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Scff1-0008Kz-UG; Thu, 07 Jun 2012 12:34:12 -0400 Message-ID: <4FD0D7FA.7000900@computer.org> Date: Thu, 07 Jun 2012 09:34:02 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Dr John P Mullen References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad8695fe0d60fdfd22fc5bd5eeee457407e3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:34:13 -0000 Hello John, On 6/7/2012 7:59 AM, Dr John P Mullen wrote: > This discussion brings back a lot of memories. Some might say nightmares. > In the early days, I spent a lot of time explaining to people that MANETs are a different animal and things that are a good idea for other forms of networking or communication are not such good ideas for MANETs. I think subnets is one of those things. I've always thought it was quite interesting just how the pre-existing IP protocol design works very well indeed as long as one doesn't insist on having subnets where none really exist. > MANET routing protocols perform function #1. Many protocols essentially construct and maintain dynamic subnets and use information from nodes to manage the continually changing topological structure. For this function, a subnet would be redundant. Perhaps "very expensive to maintain" instead of "redundant"...? > For the second, subnets can be superimposed at an appropriate layer, depending on security concerns. However, as Fred points out, we would not want that subnet structure to create a partition, so the most efficient thing would be for the MANET protocol to ignore it and let higher layers implement any subnetting. I really think that subnetting should be done below the level of routing protocols. Put another way, [manet] protocols should [in and of themselves] certainly ignore subnet creation because doing otherwise would amount to a serious and confusing layer violation. While one can certainly make use ad hoc protocols as part of the process of "creating" subnets, there still has to be a network layer even higher in the stack compared to where those subnets are established. The protocol stack, and this discussion, can have a seemingly arbitrary number of layers as exemplified so often in the past. I'm reminded of the "encapsulation limit" extension which was included as part of the IPv6-within-IPv6 tunneling specification. There is no analogous "recirculation limit" extension for discussions about where subnets are established in the protocol stack. -- Regards, Charlie P. From charliep@computer.org Thu Jun 7 09:43:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8CD021F8671 for ; Thu, 7 Jun 2012 09:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 Hj0Ma4WNZwmj for ; Thu, 7 Jun 2012 09:43:36 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4109721F8672 for ; Thu, 7 Jun 2012 09:43:32 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Scfo1-0004zq-Qy; Thu, 07 Jun 2012 12:43:30 -0400 Message-ID: <4FD0DA29.5040908@computer.org> Date: Thu, 07 Jun 2012 09:43:21 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stan Ratliff References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <6AED76A2-FC39-4C00-B068-ACF60510B722@herberg.name> <5D3FD5F3-DB07-42CF-A6F6-757405BFB201@cisco.com> In-Reply-To: <5D3FD5F3-DB07-42CF-A6F6-757405BFB201@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86d497925334249b2add716755e8a4a65d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet , Fred Baker , Abdussalam Baryun Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:43:37 -0000 Hello Stan, I'd like to echo what you said but just adding a bit more: On 6/7/2012 8:23 AM, Stan Ratliff wrote: > Ditto what Ulrich said. The working group not to be named died only after many, many, MANY long, tedious discussions. Discussions that yielded exactly 1 document. We had quite a few good documents. These documents did not make progress because there was a fatal insistence on producing some architectural model that included subnets. I must have stood in front of the mike dozens of times complaining that it was by no means necessary and in fact even dangerous to go there before getting the basic work done. > At a baseline, fundamental level, discussion of a "subnet model" in an "ad-hoc" network seems like an oxymoron to me… if we have a specific "model" that the network fits into, how is that "ad-hoc"? I'll say it again - unfortunately, the only subnet model that fits is that there isn't a subnet model. You make a good point: subnet organization is NOT "ad hoc". However, once a subnet is established, as mentioned before it is just fine for an ad hoc routing protocol to make use of the subnet. It's just that maintaining the subnet structure needs to be _external_ [i.e., out of scope] for the specification of the ad hoc routing protocol. So I'd restate your last sentence as follows: "the only subnet models that fit are those whose establishment and maintenence are out of scope for [manet]" -- Regards, Charlie P. From dbeach@cisco.com Thu Jun 7 10:02:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF3321F86DE for ; Thu, 7 Jun 2012 10:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UpMGYs4960jv for ; Thu, 7 Jun 2012 10:02:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB6221F86A5 for ; Thu, 7 Jun 2012 10:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dbeach@cisco.com; l=467; q=dns/txt; s=iport; t=1339088564; x=1340298164; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=ZKurZwcTZwjs0moxx06XjpblYMiile8Eroew2bhdhG8=; b=cDQfojHPVw0wZWdWrOX8m68B/Z/d9x3B1i9T/SrSRzMs3X2hvJ2hHltV 6sw86lFs7DIHhfxBDS/0Qg0a9WI+TZd1iCn3hUaeVUaFBK7/DBfcQ6Kz9 PvcOt44gxiD6g6Zcq8LvvZxmeeKp7VWENAjuSULDVwSpYlafUkg6V2yap Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAOzd0E+tJXHB/2dsb2JhbABFsX2CJIEHghoBBBIBHQpRAQgiBhgHVwEEGxqHaZdvgSiffI4QgjlgA4hAmnGBZoJ+ X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="90451400" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 07 Jun 2012 17:02:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q57H2gVN013627 for ; Thu, 7 Jun 2012 17:02:43 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 7 Jun 2012 12:02:43 -0500 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: quoted-printable Date: Thu, 7 Jun 2012 12:02:41 -0500 Message-ID: <507C43E627B1F74981DE460240FEE21707BBDFA0@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [manet] Subnet definition -- why do we need one that is Thread-Index: Ac1Ez1m4fJ7fKqkCS7OL70Yc1mtVvg== From: "Darrel Beach (dbeach)" To: X-OriginalArrivalTime: 07 Jun 2012 17:02:43.0358 (UTC) FILETIME=[5AA95BE0:01CD44CF] Subject: Re: [manet] Subnet definition -- why do we need one that is X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 17:02:46 -0000 One aspect of radio deployments is that at the broader internet connection level, the underlying radio nets would generally be aggregated. So the segregated=20 subnets, individual host route propagation, etc could be within a single administrative or at least a small group of cooperating, domains. As Jim alluded to, there will generally be multiple types of radio networks of very different characteristics and often operating in parallel. =20 /d From macintyrelp@ornl.gov Thu Jun 7 09:52:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D377D21F8804 for ; Thu, 7 Jun 2012 09:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 PYBrZwt-8Trr for ; Thu, 7 Jun 2012 09:52:12 -0700 (PDT) Received: from mta01.ornl.gov (mta01.ornl.gov [128.219.14.70]) by ietfa.amsl.com (Postfix) with ESMTP id 550F921F8808 for ; Thu, 7 Jun 2012 09:52:12 -0700 (PDT) X-SG: RELAYLIST X-IronPort-AV: E=Sophos;i="4.75,732,1330923600"; d="scan'208";a="35211601" Received: from ironport-5600-src.ens.ornl.gov (HELO [160.91.76.47]) ([10.1.86.80]) by iron1.ornl.gov with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Jun 2012 12:52:11 -0400 Message-ID: <4FD0DC3B.8010204@ornl.gov> Date: Thu, 07 Jun 2012 12:52:11 -0400 From: Lawrence MacIntyre User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: manet@ietf.org References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <4FD0D7FA.7000900@computer.org> In-Reply-To: <4FD0D7FA.7000900@computer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 07 Jun 2012 10:14:55 -0700 Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 16:52:14 -0000 Charles: I will agree with you that there are many times where subnets don't make sense. If a swarm of nodes is considered a subnet, the swarm can be separated and no longer function as a subnet, and that makes routing painful. In this case, subnets might be considered harmful. However, it is true that one of the most difficult things about MANETs is that there are SO many kinds of them. There are, indeed, instances where subnets make sense. Think of a vehicle with multiple devices contained inside (vehicles can be very tiny and also very large. For instance, the USS Enterprise is a vehicle). It is unlikely that the vehicle can be split up and still be functional:-) Therefore, a subnet for the (potentially many) devices on the vehicle aids greatly in scaling the network, since you only need one route for the entire subnet. Thanks, Lawrence On 06/07/2012 12:34 PM, Charles E. Perkins wrote: > Hello John, > > On 6/7/2012 7:59 AM, Dr John P Mullen wrote: >> This discussion brings back a lot of memories. > Some might say nightmares. > >> In the early days, I spent a lot of time explaining to people that MANETs are a different animal and things that are a good idea for other forms of networking or communication are not such good ideas for MANETs. I think subnets is one of those things. > I've always thought it was quite interesting just how the pre-existing > IP protocol > design works very well indeed as long as one doesn't insist on having > subnets where > none really exist. > >> MANET routing protocols perform function #1. Many protocols essentially construct and maintain dynamic subnets and use information from nodes to manage the continually changing topological structure. For this function, a subnet would be redundant. > Perhaps "very expensive to maintain" instead of "redundant"...? > >> For the second, subnets can be superimposed at an appropriate layer, depending on security concerns. However, as Fred points out, we would not want that subnet structure to create a partition, so the most efficient thing would be for the MANET protocol to ignore it and let higher layers implement any subnetting. > I really think that subnetting should be done below the level of routing > protocols. Put another way, [manet] protocols should [in and of > themselves] certainly ignore subnet creation because doing otherwise > would amount to a serious and confusing layer violation. > > While one can certainly make use ad hoc protocols as part of the process > of "creating" subnets, there still has to be a network layer even higher > in the stack compared to where those subnets are established. The > protocol stack, and this discussion, can have a seemingly arbitrary > number of layers as exemplified so often in the past. I'm reminded of > the "encapsulation limit" extension which was included as part of the > IPv6-within-IPv6 tunneling specification. There is no analogous > "recirculation limit" extension for discussions about where subnets are > established in the protocol stack. > -- Lawrence MacIntyre macintyrelp@ornl.gov Oak Ridge National Laboratory 865.574.7401 Cyber Space and Information Intelligence Research Group SIPRNet: macintyrelp@ornl.doe.sgov.gov ICMail: ormaclp@doe.ic.gov From hrogge@googlemail.com Thu Jun 7 11:09:31 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0FF21F86D6 for ; Thu, 7 Jun 2012 11:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 gmfAW5zx209R for ; Thu, 7 Jun 2012 11:09:30 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7DD821F862A for ; Thu, 7 Jun 2012 11:09:29 -0700 (PDT) Received: by dacx6 with SMTP id x6so1238355dac.31 for ; Thu, 07 Jun 2012 11:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=DRU4AqFQRRE5A9FGjMQdU3XowGLz9RBmC147S4eh6us=; b=IGv53owqDHPJkeG2hop0a3C83s5S1WHM/qA6ESfqKdCukSQiN1EqCEU1pNFoQ4C7WS cckFapxyN+On0k3ml645odvHcfSH62DHw4yDKc+UWovIBk6WwKfNQLK1HnHWPi6iR+oq 6T5sA7UGfo5IGKQwWXc3hYcuxyXXNgECdQLCo2a77X85Tp7w3gdPg8wxEerpfTfx3Cej b8ulhcOP9ZLjcbT/nKAqWcwitQvGFkGMVdcxH5t02Tdo/09G/NgCIOVQkk2sgXAiNQPX cPsJQHoj32pgdBv/5Jdu1S0bxbSoMO889CkbHt3Vl1726Ct1FSCDiUGZc5ZiRegn5ioP NaLA== Received: by 10.68.131.38 with SMTP id oj6mr11535747pbb.39.1339092569373; Thu, 07 Jun 2012 11:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Thu, 7 Jun 2012 11:09:09 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 7 Jun 2012 20:09:09 +0200 Message-ID: To: jasteven@rockwellcollins.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet@ietf.org Subject: Re: [manet] MANET Routing Below IP (spin off from Subnet Definition thread) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 18:09:31 -0000 On Thu, Jun 7, 2012 at 4:36 PM, wrote: > On Jun 6, 2012 at 154:45:20 (-0600), Fred Baker wrote: >>here you hark back to a debate that actually kinda-sorta made sense 20 >> years ago, but makes no sense in this context. IEEE 802.1, and specifica= lly >> >802.1d, is a routing technology. It doesn't route in the sense that OSP= F or >> BGP do, but it figures out how to get packets across a network from >poi= nt A >> to point B. > > Actually, this debate makes a lot of sense today. =A0In fact, this is the= way > that a lot of companies have been developing & fielding multihop, mobile = ad > hoc networks for over 4 decades now - going all the way back to the origi= nal > DARPA funded Packet Radio work in 1970s as part of the original Internet > project. =A0Namely multihop routing below IP, so that the multihop wirele= ss > network below IP looks like a 1 hop IP link no matter how many wireless h= ops > it takes. =A0In other words, the wireless network does routing analogous = to > ethernet switching (routing) below IP. Yes, this grow of multihop capabilities directly in the radios can be both a blessing and a pain, depending on the usecase. > And we are still going strong this way today with over a dozen different > MANET wireless technologies today that are working with multihop routing > below IP - both from my company and other companies. =A0I believe that in > total, there are over 100,000 fielded wireless nodes of one type or anoth= er > of these MANET technologies. Some of these wireless technologies with MAN= ET > routing below IP that have been described in public domain documentation > include Mil-Std-188-220, MARLIN (STANAG 4691), Link 22 (although the fina= l > fielded standard dropped support for IP at layer 3), EPLRS, and FlexNet. > =A0Some of these waveforms call this sub-layer below IP the Intranet, oth= ers > the wireless Subnet, others the Data Link. Some of them also do IP routing in their network, which can become a problem when they cannot connect to a larger routing domain as a transit network. > As an aside, you may ask why are there so many different types of wireles= s > technologies? =A0Well the answer is that there are lots of different > requirements with different RF channel conditions with different fading > conditions, frequency allocations (different freq bands and bandwidths), > data rates (from burst rates with kbps to 100s of Mbps), threats (jamming= or > not jamming), user traffic with different QOS requirements (from ETE > latencies of 10s of milliseconds to minutes, ETE message successful deliv= ery > rates (from 90% to 99.999% success), traffic mixes (unicast only, broadca= st > only, to mix of uni-, multi- & broadcast), etc. A lot of TDMA waveforms do (positive and negative) crazy things with their explicit knowledge of their timings. >>again, harking back to a discussion that is kind of irrelevant. Are you >> going to tell me that an IP address used by two layers, one of which is >> >doing subnet routing using, say, OSPF, and the other is doing host rout= ing >> through AODV, are not both in the network layer? If so, then why would a >> >network doing two layers of routing, one of which is using subnet routi= ng >> using, say, OSPF, and the other is doing host routing through 802.1d, is >> >not both in the network layer? > > The reason all of the waveforms that I mentioned do routing below IP is t= hat > they are all omnidirectional wireless and multihop networks (without base > stations or access points with out-of-band infrastructure to use for > routing). =A0Thus, MANET operation for these networks is much more than j= ust > routing. =A0It includes determining what is a good neighbor and under wha= t > conditions (e.g. predicted transmission success probability for given FEC= , > transmit power, frequency, antenna setting, etc). It includes figuring ou= t > which neighbors to address for any given transmission as well as accounti= ng > for the self-interference caused by the transmissions. It also includes > allocating more resources (e.g. time slots) to adapt to QOS and traffic > loading at different nodes in an RF neighborhood. In general, then MANET = in > these networks means cross-layer optimization of the physical modulation, > the channel access, and the Intranet routing. (For example, see my IETF > MANET 12 Jul 2002 13:18:43 email, and follow on discussion threads, on > "Interference in RF networks.") =A0In general, I claim that since this cr= oss > layer optimization cannot be performed by IP MANET routing alone, it make= s > architectural sense to do MANET Intranet routing below IP and just provid= e > an abstracted IP link cost to the IP routing for that wireless MANET netw= ork > technology. Thats why I think that the idea behind DLEP can become VERY important for future digital radios. > As an aside, IMO most work in the IETF MANET has been concerned with 802.= 11 > networks and cross-layer optimization have focused on its CTS/RTS MAC lay= er. > =A0This is why work was done to allow jitter to be inserted by the MANET > protocols as a type of cross-layer optimization for 802.11 as an Internet > Draft circa 2007 and included in RFC 6130 NHDP in 2011. Well Packet Radio > already had that optimization included back in 1970s and in Mil-Std-188-2= 20 > in 1990s. I think the existence of Jitter in IETF network protocols is older than NHD= P. > So, do I think that the IETF MANET work makes sense? Yes! For example, so= me > of the wireless Intranet technologies I mentioned above are using optimiz= ed > variants of IETF MANET protocols, namely OLSR. The most common optimizati= on > is to eliminate the use of Hellos for neighbor discovery (because it is p= art > of the MAC function) as well as using the local MAC layer information to > route to nodes that may be 1 or 2 hops away. This would also be something DLEP could help with a small extension. Lets the radio the link sensing and neighbor detection (which it already has to do for TDMA handling anyways) and export them in a well defined form into the Layer-3 routing to use it for something like OLSRv2. > However, I think that some of the IETF MANET work is not applicable to th= ese > Intranet MANETs. For example, Hello messages should be optional if the MA= C > layer can provide that information directly. In fact, trying to determine > neighbors from just hellos alone can lead to poor performance in many of > these networks because it doesn't take into account interference as an > example and doesn't help select which good nodes to use as good neighbors= . OLSRv2 normally runs on top of NHDP... but I could imagine a "mixed mode" to draw neighbor data from external sources. > Twenty years ago, I used to say that wireless MANET routing **must** be > below IP to enable such cross layer optimization. I no longer claim that > because I now see some wireless technologies where IP layer MANET routing > alone works just fine. =A0However, I am now concerned when people claim t= hat > wireless MANET routing must be at IP layer only - because they don't know= or > understand the issues involved with the cross layer optimization I discus= sed > above. =A0And, it confuses non-networking people who say "if the IETF MAN= ET > says it, then it must be true." *G* > I have seen multiple different types of addressing used in the Intranet > below the IP layer. =A0In most cases, the wireless Intranet has its own > address separate from the IP address. =A0In many cases, this Intranet add= ress > maps to an IP subnet address (say the lower octect or two) for that wirel= ess > network. =A0Hence this is why some of the above mentioned wireless MANETs= call > this layer below IP the Subnet Layer rather than the Intranet layer. =A0 = In > other cases, the wireless Intranet has its own address and a ARP or ARP-l= ike > function maps the Intranet address to the IP address. If they directly map onto IP addresses in a "one on one" way, they could be called IP addresses. Just with some special "compression" and handling scheme. I think there are (at least) two usecases for upcoming digital radios like the ones you mentioned. Some users just want to install them somewhere, just with an ethernet plug to attach the local network (like a laptop, an internal car network). Others want to integrate them into a larger heterogeneous radio network based on IP routers. In the first case, being able to do the whole "routing" in the device is a great thing and simplifies a lot. But in the second case, internal routing can become a problem for integration. I think something like DLEP could maybe help us to solve this problem, allowing a radio to run in two modes... one autonomous and another one radio and attached router working hand in hand. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From abdussalambaryun@gmail.com Thu Jun 7 20:42:14 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8547311E80B3 for ; Thu, 7 Jun 2012 20:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hztigyb4osBW for ; Thu, 7 Jun 2012 20:42:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E052A21F8627 for ; Thu, 7 Jun 2012 20:42:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so870996vbb.31 for ; Thu, 07 Jun 2012 20:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Lrp2gxmlLiivKyyr6XkDiKy3F+2kK7OYHJTJPO3y13o=; b=yWwJhKnS8oQfD01+Rbjhe9cRgcQkVTPhGIRfPwLwo6/O/JYpJ3tw/4BXOokmxak2md 5gw9ktq5BCDY/gUJfIE/+y63WR/PRgY7JmzuCU9a7RtaAWdQ5wsAaE7HMeBJPE4UKohE ufrCoCCovlY9q47q5SfIK6hW5dKEHc0nLJViomL1ygx1bEd24ZGmMvDyfSlCGxbrIEwB 50ntMg6dyIUy0/NnT7EDg/94pGSCl9UfgjUQ0KAVjpktSSXMQDyCa5+f+V12yKN5QYtA FSXYjnNTgK+5XGKd3iQIOxPszauKGfsCkiJLnX0wgu42gs+ZZsndJDVA3dZHEbMP/deF hDHg== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr4115695vdb.10.1339126933196; Thu, 07 Jun 2012 20:42:13 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 7 Jun 2012 20:42:13 -0700 (PDT) Date: Fri, 8 Jun 2012 05:42:13 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 03:42:14 -0000 Hi Folks I have read two important inputs and want to share my opinion, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D In one work in progress ietf-draft (expired): draft-ietf-manet-appl-00.txt= , Corson, (1998)mentioned in Abstract and Introduction: Abstract> The intent of this =92Applicability Section=92 is to aid readers unfamiliar with the details of each protocol=92s design in understanding the protocol=92s basic characteristics, functioning and mechanisms, as well as to provide a general description of the networking context for which the protocol was designed, and in which it is expected to perform well. Introduction> The set of applications for which the use of MANET technology envisioned is diverse, ranging from small, energy-constrained nearly static networks to large-scale, mobile, highly-dynamic networks. The combinations of network size, topology composition and dynamics, bandwidth and energy availability, physical and link-layer technologies, intended application usages, etc. are many, and it seems unlikely that a single protocol will function superiorly over this wide range of networking contexts. Thus a given protocol is likely to be well-suited for operation in those networks whose characteristics match well with the combination of mechanisms employed by the protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is important to be explicit about assumptions/conditions before talking about protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I agree with both points and approach to solve routing protocols, and would RECOMMEND either of the following: 1- MANET WG defines (in one informative-draft) intended application usage, and be explicit about applicable L2 network technologies. So that each future protocols mentions in their applicability statement section the usual use-case for such protocol, OR 2- MANET WG renews the I-D expired of Corson (1998) and adds more issues so it can become an RFC in future, Thanking you, Abdussalam Baryun =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From Chris.Dearlove@baesystems.com Fri Jun 8 01:51:23 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC27D21F8857 for ; Fri, 8 Jun 2012 01:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PwjVcjjvQ2zu for ; Fri, 8 Jun 2012 01:51:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id ED9DB21F885D for ; Fri, 8 Jun 2012 01:51:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="244560934" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Jun 2012 09:51:16 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q588pG6h000784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 09:51:16 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 09:51:15 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "jasteven@rockwellcollins.com" Thread-Topic: [manet] MANET Routing Below IP (spin off from Subnet Definition thread) Thread-Index: AQHNRLryeqjaPOe5WEiT/nUUYFWlFpbvFwuAgAEFHEA= Date: Fri, 8 Jun 2012 08:51:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "manet@ietf.org" Subject: Re: [manet] MANET Routing Below IP (spin off from Subnet Definition thread) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 08:51:23 -0000 Jitter is described in RFC 5148, which is what NHDP and OLSRv2 reference (f= or use when appropriate, but not when not). The specific model 5148 uses co= mes from OLSR (RFC 3626) but 5148 has some informative references to other = uses. Right now I don't recall if any of those informative references use t= he same [-T,0] offset as OLSR/5148 does (for at least two good reasons), so= me certainly use a [-T,T] offset. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of H= enning Rogge Sent: 07 June 2012 19:09 To: jasteven@rockwellcollins.com Cc: manet@ietf.org Subject: Re: [manet] MANET Routing Below IP (spin off from Subnet Definitio= n thread) ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- On Thu, Jun 7, 2012 at 4:36 PM, wrote: > On Jun 6, 2012 at 154:45:20 (-0600), Fred Baker wrote: >>here you hark back to a debate that actually kinda-sorta made sense 20 >> years ago, but makes no sense in this context. IEEE 802.1, and specifica= lly >> >802.1d, is a routing technology. It doesn't route in the sense that OSP= F or >> BGP do, but it figures out how to get packets across a network from >poi= nt A >> to point B. > > Actually, this debate makes a lot of sense today. =A0In fact, this is the= way > that a lot of companies have been developing & fielding multihop, mobile = ad > hoc networks for over 4 decades now - going all the way back to the origi= nal > DARPA funded Packet Radio work in 1970s as part of the original Internet > project. =A0Namely multihop routing below IP, so that the multihop wirele= ss > network below IP looks like a 1 hop IP link no matter how many wireless h= ops > it takes. =A0In other words, the wireless network does routing analogous = to > ethernet switching (routing) below IP. Yes, this grow of multihop capabilities directly in the radios can be both a blessing and a pain, depending on the usecase. > And we are still going strong this way today with over a dozen different > MANET wireless technologies today that are working with multihop routing > below IP - both from my company and other companies. =A0I believe that in > total, there are over 100,000 fielded wireless nodes of one type or anoth= er > of these MANET technologies. Some of these wireless technologies with MAN= ET > routing below IP that have been described in public domain documentation > include Mil-Std-188-220, MARLIN (STANAG 4691), Link 22 (although the fina= l > fielded standard dropped support for IP at layer 3), EPLRS, and FlexNet. > =A0Some of these waveforms call this sub-layer below IP the Intranet, oth= ers > the wireless Subnet, others the Data Link. Some of them also do IP routing in their network, which can become a problem when they cannot connect to a larger routing domain as a transit network. > As an aside, you may ask why are there so many different types of wireles= s > technologies? =A0Well the answer is that there are lots of different > requirements with different RF channel conditions with different fading > conditions, frequency allocations (different freq bands and bandwidths), > data rates (from burst rates with kbps to 100s of Mbps), threats (jamming= or > not jamming), user traffic with different QOS requirements (from ETE > latencies of 10s of milliseconds to minutes, ETE message successful deliv= ery > rates (from 90% to 99.999% success), traffic mixes (unicast only, broadca= st > only, to mix of uni-, multi- & broadcast), etc. A lot of TDMA waveforms do (positive and negative) crazy things with their explicit knowledge of their timings. >>again, harking back to a discussion that is kind of irrelevant. Are you >> going to tell me that an IP address used by two layers, one of which is >> >doing subnet routing using, say, OSPF, and the other is doing host rout= ing >> through AODV, are not both in the network layer? If so, then why would a >> >network doing two layers of routing, one of which is using subnet routi= ng >> using, say, OSPF, and the other is doing host routing through 802.1d, is >> >not both in the network layer? > > The reason all of the waveforms that I mentioned do routing below IP is t= hat > they are all omnidirectional wireless and multihop networks (without base > stations or access points with out-of-band infrastructure to use for > routing). =A0Thus, MANET operation for these networks is much more than j= ust > routing. =A0It includes determining what is a good neighbor and under wha= t > conditions (e.g. predicted transmission success probability for given FEC= , > transmit power, frequency, antenna setting, etc). It includes figuring ou= t > which neighbors to address for any given transmission as well as accounti= ng > for the self-interference caused by the transmissions. It also includes > allocating more resources (e.g. time slots) to adapt to QOS and traffic > loading at different nodes in an RF neighborhood. In general, then MANET = in > these networks means cross-layer optimization of the physical modulation, > the channel access, and the Intranet routing. (For example, see my IETF > MANET 12 Jul 2002 13:18:43 email, and follow on discussion threads, on > "Interference in RF networks.") =A0In general, I claim that since this cr= oss > layer optimization cannot be performed by IP MANET routing alone, it make= s > architectural sense to do MANET Intranet routing below IP and just provid= e > an abstracted IP link cost to the IP routing for that wireless MANET netw= ork > technology. Thats why I think that the idea behind DLEP can become VERY important for future digital radios. > As an aside, IMO most work in the IETF MANET has been concerned with 802.= 11 > networks and cross-layer optimization have focused on its CTS/RTS MAC lay= er. > =A0This is why work was done to allow jitter to be inserted by the MANET > protocols as a type of cross-layer optimization for 802.11 as an Internet > Draft circa 2007 and included in RFC 6130 NHDP in 2011. Well Packet Radio > already had that optimization included back in 1970s and in Mil-Std-188-2= 20 > in 1990s. I think the existence of Jitter in IETF network protocols is older than NHD= P. > So, do I think that the IETF MANET work makes sense? Yes! For example, so= me > of the wireless Intranet technologies I mentioned above are using optimiz= ed > variants of IETF MANET protocols, namely OLSR. The most common optimizati= on > is to eliminate the use of Hellos for neighbor discovery (because it is p= art > of the MAC function) as well as using the local MAC layer information to > route to nodes that may be 1 or 2 hops away. This would also be something DLEP could help with a small extension. Lets the radio the link sensing and neighbor detection (which it already has to do for TDMA handling anyways) and export them in a well defined form into the Layer-3 routing to use it for something like OLSRv2. > However, I think that some of the IETF MANET work is not applicable to th= ese > Intranet MANETs. For example, Hello messages should be optional if the MA= C > layer can provide that information directly. In fact, trying to determine > neighbors from just hellos alone can lead to poor performance in many of > these networks because it doesn't take into account interference as an > example and doesn't help select which good nodes to use as good neighbors= . OLSRv2 normally runs on top of NHDP... but I could imagine a "mixed mode" to draw neighbor data from external sources. > Twenty years ago, I used to say that wireless MANET routing **must** be > below IP to enable such cross layer optimization. I no longer claim that > because I now see some wireless technologies where IP layer MANET routing > alone works just fine. =A0However, I am now concerned when people claim t= hat > wireless MANET routing must be at IP layer only - because they don't know= or > understand the issues involved with the cross layer optimization I discus= sed > above. =A0And, it confuses non-networking people who say "if the IETF MAN= ET > says it, then it must be true." *G* > I have seen multiple different types of addressing used in the Intranet > below the IP layer. =A0In most cases, the wireless Intranet has its own > address separate from the IP address. =A0In many cases, this Intranet add= ress > maps to an IP subnet address (say the lower octect or two) for that wirel= ess > network. =A0Hence this is why some of the above mentioned wireless MANETs= call > this layer below IP the Subnet Layer rather than the Intranet layer. =A0 = In > other cases, the wireless Intranet has its own address and a ARP or ARP-l= ike > function maps the Intranet address to the IP address. If they directly map onto IP addresses in a "one on one" way, they could be called IP addresses. Just with some special "compression" and handling scheme. I think there are (at least) two usecases for upcoming digital radios like the ones you mentioned. Some users just want to install them somewhere, just with an ethernet plug to attach the local network (like a laptop, an internal car network). Others want to integrate them into a larger heterogeneous radio network based on IP routers. In the first case, being able to do the whole "routing" in the device is a great thing and simplifies a lot. But in the second case, internal routing can become a problem for integration. I think something like DLEP could maybe help us to solve this problem, allowing a radio to run in two modes... one autonomous and another one radio and attached router working hand in hand. Henning Rogge --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** From Chris.Dearlove@baesystems.com Fri Jun 8 01:58:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AAE21F8889 for ; Fri, 8 Jun 2012 01:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 0dogSQNivEIo for ; Fri, 8 Jun 2012 01:58:12 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8196C21F8883 for ; Fri, 8 Jun 2012 01:58:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,737,1330905600"; d="scan'208";a="244563595" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Jun 2012 09:58:08 +0100 Received: from GLKXH0004V.GREENLNK.net ([10.109.2.35]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q588w8bR005885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 09:58:08 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 09:58:07 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] MANET Protocol Applicability Thread-Index: AQHNRSi2AwHjHpgnTkaFZUo3+G0t9JbwHtHg Date: Fri, 8 Jun 2012 08:58:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 08:58:13 -0000 Being explicit about L2 technologies is exactly what MANET should not do. A= t least not in any limiting way. Of course if someone were to write an info= rmative draft about (say) using OLSRv2 over IEEE 802.11 that would be fine.= Though it would run the risk of suggesting to some that that is the only L= 2 suggested,, so I'd want the draft to make it clear that wasn't so. And an= ything that said OLSRv2 was intended for use over the following L2 protocol= s would be completely wrong. The point of routing at L3 is to be as L2 inde= pendent as possible. If I've read the draft you mention it was a long time ago. Digging up 1998 = drafts to reissue doesn't strike me as the most productive possible exercis= e. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 08 June 2012 04:42 To: manet Subject: [manet] MANET Protocol Applicability ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Folks I have read two important inputs and want to share my opinion, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D In one work in progress ietf-draft (expired): draft-ietf-manet-appl-00.txt= , Corson, (1998)mentioned in Abstract and Introduction: Abstract> The intent of this 'Applicability Section' is to aid readers unfamiliar with the details of each protocol's design in understanding the protocol's basic characteristics, functioning and mechanisms, as well as to provide a general description of the networking context for which the protocol was designed, and in which it is expected to perform well. Introduction> The set of applications for which the use of MANET technology envisioned is diverse, ranging from small, energy-constrained nearly static networks to large-scale, mobile, highly-dynamic networks. The combinations of network size, topology composition and dynamics, bandwidth and energy availability, physical and link-layer technologies, intended application usages, etc. are many, and it seems unlikely that a single protocol will function superiorly over this wide range of networking contexts. Thus a given protocol is likely to be well-suited for operation in those networks whose characteristics match well with the combination of mechanisms employed by the protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is important to be explicit about assumptions/conditions before talking about protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D I agree with both points and approach to solve routing protocols, and would RECOMMEND either of the following: 1- MANET WG defines (in one informative-draft) intended application usage, and be explicit about applicable L2 network technologies. So that each future protocols mentions in their applicability statement section the usual use-case for such protocol, OR 2- MANET WG renews the I-D expired of Corson (1998) and adds more issues so it can become an RFC in future, Thanking you, Abdussalam Baryun =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** From john.dowdell@cassidian.com Fri Jun 8 03:00:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4834921F86A0 for ; Fri, 8 Jun 2012 03:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 WWMqVvRBWmLo for ; Fri, 8 Jun 2012 03:00:02 -0700 (PDT) Received: from mail-dotnet3.eads.net (mail-dotnet3.eads.net [193.56.40.75]) by ietfa.amsl.com (Postfix) with ESMTP id 95F1821F869E for ; Fri, 8 Jun 2012 02:59:50 -0700 (PDT) Received: from unknown (HELO fr-gate2.mailhub.intra.corp) ([53.154.16.34]) by mail-dotnet3.eads.net with ESMTP; 08 Jun 2012 11:59:48 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate2.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Fri, 8 Jun 2012 11:59:48 +0200 Received: from f8561vs4.main.fr.ds.corp ([10.37.8.27]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 11:59:48 +0200 Received: from SUKNPT8108.cogent-dsn.local ([10.81.0.121]) by f8561vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Jun 2012 11:59:48 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 8 Jun 2012 11:00:00 +0100 Message-ID: <1B40484159234F4FB6FE11D4C2F408DE01455C9E@SUKNPT8108.cogent-dsn.local> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MANET Protocol Applicability Thread-Index: AQHNRSi2AwHjHpgnTkaFZUo3+G0t9JbwHtHggAANwLA= From: "John Dowdell" To: "manet" X-OriginalArrivalTime: 08 Jun 2012 09:59:48.0187 (UTC) FILETIME=[704B4AB0:01CD455D] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-6.500.1024-18954.006 X-TM-AS-Result: No--34.704400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:00:03 -0000 I must say I agree with Chris. Even in my limited experience, the point = of MANETs is that you should be able to use whatever you need as the = L1/L2 transport. IP over anything that will take it; HF using STANAG = 5506, satcom, 802.11, proprietary mesh networking, to name but a few. = Each has its own strange foibles and it's up to the integrator to decide = what is best for the task in hand. This is in the same vein as the = subnet discussion earlier; MANET WG should not (IMHO) seek to define a = policy because it will not fit every eventuality, of which there will be = many and legion. Having said that, some comments from clever people familiar with the = current state of the art of implementation of MANETs for multi-agency = disaster relief would be welcome, if any care to give them. John -----Original Message----- From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Dearlove, Christopher (UK) Sent: 08 June 2012 09:58 To: Abdussalam Baryun; manet Subject: Re: [manet] MANET Protocol Applicability Being explicit about L2 technologies is exactly what MANET should not = do. At least not in any limiting way. Of course if someone were to write = an informative draft about (say) using OLSRv2 over IEEE 802.11 that = would be fine. Though it would run the risk of suggesting to some that = that is the only L2 suggested,, so I'd want the draft to make it clear = that wasn't so. And anything that said OLSRv2 was intended for use over = the following L2 protocols would be completely wrong. The point of = routing at L3 is to be as L2 independent as possible. If I've read the draft you mention it was a long time ago. Digging up = 1998 drafts to reissue doesn't strike me as the most productive possible = exercise. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun Sent: 08 June 2012 04:42 To: manet Subject: [manet] MANET Protocol Applicability ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Folks I have read two important inputs and want to share my opinion, =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In one work in progress ietf-draft (expired): = draft-ietf-manet-appl-00.txt, Corson, (1998)mentioned in Abstract and Introduction: Abstract> The intent of this 'Applicability Section' is to aid readers unfamiliar with the details of each protocol's design in understanding the protocol's basic characteristics, functioning and mechanisms, as well as to provide a general description of the networking context for which the protocol was designed, and in which it is expected to perform well. Introduction> The set of applications for which the use of MANET technology envisioned is diverse, ranging from small, energy-constrained nearly static networks to large-scale, mobile, highly-dynamic networks. The combinations of network size, topology composition and dynamics, bandwidth and energy availability, physical and link-layer technologies, intended application usages, etc. are many, and it seems unlikely that a single protocol will function superiorly over this wide range of networking contexts. Thus a given protocol is likely to be well-suited for operation in those networks whose characteristics match well with the combination of mechanisms employed by the protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is important to be explicit about assumptions/conditions before talking about protocol. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I agree with both points and approach to solve routing protocols, and would RECOMMEND either of the following: 1- MANET WG defines (in one informative-draft) intended application usage, and be explicit about applicable L2 network technologies. So that each future protocols mentions in their applicability statement section the usual use-case for such protocol, OR 2- MANET WG renews the I-D expired of Corson (1998) and adds more issues so it can become an RFC in future, Thanking you, Abdussalam Baryun =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jun 8 03:53:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED9A21F87DF for ; Fri, 8 Jun 2012 03:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.214 X-Spam-Level: X-Spam-Status: No, score=-3.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-1] 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 uHVpXJrKr8PC for ; Fri, 8 Jun 2012 03:53:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2642521F85DD for ; Fri, 8 Jun 2012 03:53:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1039153vbb.31 for ; Fri, 08 Jun 2012 03:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uA62j4KorEyfPnQedHr1DQbEAr5BPBosbaR7ZtE2OBM=; b=FSccoRX2sgjVW7Zq8hJYXP4FEEOkpLbz8TOixC90dCBboBh10+UPgZddl1MffhDI0s LJhYG51CxDQzQJVoNuvOCei+zN8G5rqJTCZ+/0t4N8XFkiTOsuR3v1SJwv2K/dEDceRd Lt5Eigbc47zzhYyiuEZGt07Ux3IP85WpKZIs5OinS63+7XTOW1xfdPR+9B8h1EpcDTUX l1niaEtnW6K/xBKf90FB7h9VjsL1gSL1Rf0lv/afws38JmqGanhr5/g9Ugi8MlvVlNa7 NCqeBXyk7kQ+t3WwufdrQmL62X41ihSN5fW3GBlEFLN/BN/Yq1hkXpAKYDMSA7/Hf3cs WZug== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr4970397vdb.10.1339152829399; Fri, 08 Jun 2012 03:53:49 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 03:53:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 12:53:49 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Fred Baker Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:53:56 -0000 Hi Ulrich, I agree with you that there was an excellent discussions, but that does not mean we stop revive because many relating things in MANET and IP may change in future. Furthermore, I did not like to use the word die (just used what content I reply), we can say the ad-hoc-autoconfig was closed, so it MAY re-open in the willing of memebrs with reasons. We should not ignore Mr.Jari (the WG AD) input nor to ignore announcement reason of close (please read below), it was not my action-reason, but you have to admit that the reason of close was related to the discussion or the activity direction. Also, Mr.Jari mentioned some how a collide with ROLL please read his reason again. UH>I think it would be wrong to define such a multi-link subnet (for the >reasons the IAB described in in RFC4903, and that we tried to convey >at length in AUTOCONF). We had a long discussion about the reasons in >AUTOCONF (which led to RFC5889), and I don't think we should revive >this discussion in MANET. I just now finished reading RFC4903 and thank you that you brought it to my attention ( I will include in my draft), however, I see that it considers issue of L3 link models not L2 link models. There are big difference between L3 and L2. RFC4903>There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link. AB> meaning the total link that includes the path between two node-interfaces. RFC4903>Links that appear as NBMA links at layer 3 are problematic. Instead, if a link is an NBMA link at layer 2, then protocol designers should define some mechanism such that it appears as either the multi-access link model or point-to-point link model at layer 3. AB> please read above----> designers SHOULD define some mechanism such that it appears as either the multi-access....... AB> I just wanted to write a draft to define L2 network technology and follow the RFC4903, so the RFC4903 is not against but with my approach. Please note that I don't want to define the protocol to be dependent on the L2 technology, but I want the DESIGNERS to KNOW what they are looking as Mr.Clausen mentioned in the WG 77 meeting, that we define assumptions/conditions before looking at our protocols. I appreciate that you educated me regarding the RFC4903 it is very important to read I admit that I missed. Thanks, Best Regards Abdussalam Baryun University of Glamorgan, UK ========================================================= On 6/7/12, Ulrich Herberg wrote: > Let me clarify: Autoconf did not die because a lack of discussion. Quite to > the contrary! We had extremely many and long discussions and several drafts > trying to tackle the issue. Over 5 years we did that, and many of the > participants are the same that are also active in MANET. > > Ulrich > > On Jun 7, 2012, at 1:50, Abdussalam Baryun > wrote: > >> Hi Herberg, I think we should not beary our self just because autoconfig >> WG had >> died I think its discussions were not productive so that it was ended. In >> IETF >> discussion is more important than drafting papers/documents. Knowledge >> should be >> distributed and open to All, not to restrict knowledge-distribution >> because we MAY >> NOT be able to discuss productively or to get to solution. It is the >> CHAIR's job to >> solve unproductive issues, and WGs advising their AD to help as well >> for progress. >> IMHO, it is always the WG memebrs' and the WG Chair's fault/welling if >> such WG will/have die(d). > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> To: "autoconf at ietf.org" >>> Subject: [Autoconf] closing the working group? >>> From: Jari Arkko >>> Date: Tue, 29 Mar 2011 08:48:47 +0200 >>> >>> -------------------------------------------------------------------------------- >>> I have looked at the discussions on the list (or lack thereof). I also >>> cannot see too many internet drafts on the topics belonging to the >>> group's charter. I am very happy with the RFC that has been produced >>> by the working group, but we also seem to have some actual protocol >>> work happening elsewhere (e.g., in the context of the ROLL WG). >>> >>> I discussed this matter with the chairs and my co-AD, and we are >>> wondering if it would be time to close the working group. I do know >>> that there is at least one implementation team that is still in the >>> process of describing their DHCP-based solution, maybe there are >>> similar efforts on the distributed solution space. My proposal is that >>> we close the working group and I'be VERY happy to AD sponsor all such >>> solutions to Experimental RFCs as soon as we have those proposals in >>> some reasonable shape. >>> Thoughts? >>> >>> Jari From teco@inf-net.nl Fri Jun 8 03:58:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0721F8887 for ; Fri, 8 Jun 2012 03:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 6JBvMvz3+6uu for ; Fri, 8 Jun 2012 03:58:36 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 136EB21F8661 for ; Fri, 8 Jun 2012 03:58:35 -0700 (PDT) Received: by eekd4 with SMTP id d4so1311095eek.31 for ; Fri, 08 Jun 2012 03:58:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=SUJ0S7zg+zER5N9LyryJy7kBq+93E3Oo9nwdYz3iPOM=; b=GpXXwbV7CB81rFcAXme76Mnh7k0f5OK9RsvSmMCHH+41X09eeoD3l64Xq81TM3rZlr OpxIz4OhCOi3A8PyW8A4GKBLJQ7VW/SJheNTgkRynvTrtHKWkumxPbUysiO2Pya7DPP9 6E9mCbtajPfja5t1BRHTErej1bAIJSJZk4o1JNqxbfnmzUDGim00G3ItKnIDuPevUky8 kNPBsUI0NiZa9uHAhWErB2nnFdX5z2E0+mtWg6QG6GqSvAdgE+ujXDFdJ2f7+MKmoSRV s6gpgBy9THYlZetsiOGf9R0QF7P6Uy6AEz0MzrTA8AFfH1jU96AgAARVt+P4+H9OeZMr EffQ== Received: by 10.14.127.198 with SMTP id d46mr3796931eei.101.1339153114281; Fri, 08 Jun 2012 03:58:34 -0700 (PDT) Received: from [10.175.173.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id fm1sm542819wib.10.2012.06.08.03.58.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 03:58:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: <1B40484159234F4FB6FE11D4C2F408DE01455C9E@SUKNPT8108.cogent-dsn.local> Date: Fri, 8 Jun 2012 12:58:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B40484159234F4FB6FE11D4C2F408DE01455C9E@SUKNPT8108.cogent-dsn.local> To: John Dowdell X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl3FJvAasTEiwfIZ3O/tWEoSlI+X+nvJjvuV3iu/sSSJRIpjRhvHp7n8xF3toXppP2cTD44 Cc: manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:58:40 -0000 Op 8 jun. 2012, om 12:00 heeft John Dowdell het volgende geschreven: > I must say I agree with Chris. Even in my limited experience, the = point of MANETs is that you should be able to use whatever you need as = the L1/L2 transport. IP over anything that will take it; HF using STANAG = 5506, satcom, 802.11, proprietary mesh networking, to name but a few. = Each has its own strange foibles and it's up to the integrator to decide = what is best for the task in hand. This is in the same vein as the = subnet discussion earlier; MANET WG should not (IMHO) seek to define a = policy because it will not fit every eventuality, of which there will be = many and legion. >=20 > Having said that, some comments from clever people familiar with the = current state of the art of implementation of MANETs for multi-agency = disaster relief would be welcome, if any care to give them. As dummy, I didn't feel addressed. But struggling with getting things = done for multi-agency disaster relief, I can tell that I am not = interested in discussions for finding best solutions for undefined = scenario's. Improved interoperability is what I am looking for. Using IP = helps, using proprietary sub-IP technology does not. It gets worse when = security and apps get in scope. With some experience from the customer side of the table, I say it is = _not_ up to the integrator to decide what technology to use. I have to = deal with multiple, making their own decisions. This needs to be = standardized. Teco >=20 > John >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Dearlove, Christopher (UK) > Sent: 08 June 2012 09:58 > To: Abdussalam Baryun; manet > Subject: Re: [manet] MANET Protocol Applicability >=20 > Being explicit about L2 technologies is exactly what MANET should not = do. At least not in any limiting way. Of course if someone were to write = an informative draft about (say) using OLSRv2 over IEEE 802.11 that = would be fine. Though it would run the risk of suggesting to some that = that is the only L2 suggested,, so I'd want the draft to make it clear = that wasn't so. And anything that said OLSRv2 was intended for use over = the following L2 protocols would be completely wrong. The point of = routing at L3 is to be as L2 independent as possible. >=20 > If I've read the draft you mention it was a long time ago. Digging up = 1998 drafts to reissue doesn't strike me as the most productive possible = exercise. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com >=20 > 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 >=20 >=20 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Abdussalam Baryun > Sent: 08 June 2012 04:42 > To: manet > Subject: [manet] MANET Protocol Applicability >=20 > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi Folks >=20 > I have read two important inputs and want to share my opinion, >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > In one work in progress ietf-draft (expired): = draft-ietf-manet-appl-00.txt, > Corson, (1998)mentioned in Abstract and Introduction: >=20 > Abstract> The intent of this 'Applicability Section' is to > aid readers unfamiliar with the details of each protocol's design in > understanding the protocol's basic characteristics, functioning and > mechanisms, as well as to provide a general description of the > networking context for which the protocol was designed, and in which > it is expected to perform well. >=20 > Introduction> The set of applications for which the use of MANET > technology envisioned is diverse, ranging from small, > energy-constrained nearly > static networks to large-scale, mobile, highly-dynamic networks. The > combinations of network size, topology composition and dynamics, > bandwidth and energy availability, physical and link-layer > technologies, intended application usages, etc. are many, and it seems > unlikely that a single protocol will function superiorly over this > wide range of networking contexts. Thus a given protocol is likely to > be well-suited for operation in those networks whose characteristics > match well with the combination of mechanisms employed by the > protocol. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is > important to be explicit about assumptions/conditions before talking > about protocol. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion =3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > I agree with both points and approach to solve routing protocols, and > would RECOMMEND either of the following: > 1- MANET WG defines (in one informative-draft) intended application > usage, and be explicit about applicable L2 network technologies. So > that each future protocols mentions in their applicability statement > section the usual use-case for such protocol, OR > 2- MANET WG renews the I-D expired of Corson (1998) and adds more > issues so it can become an RFC in future, >=20 > Thanking you, > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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. > ******************************************************************** >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jun 8 03:59:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458CC21F8686 for ; Fri, 8 Jun 2012 03:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.51 X-Spam-Level: X-Spam-Status: No, score=-3.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qqJLyc373HqD for ; Fri, 8 Jun 2012 03:59:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9705121F8680 for ; Fri, 8 Jun 2012 03:59:51 -0700 (PDT) Received: by vcqp1 with SMTP id p1so976538vcq.31 for ; Fri, 08 Jun 2012 03:59:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HLpd5klAMaw0WOx+V86c5n1Wj0btYP/Pr/XcgmFWss8=; b=RM0yz526jGFgXKvKV0xzOPRNCQGpUipcJf7sHbra7aZ7tNu2bQ7NZI+L/Cvv7sEEH0 OexKotFSC2dES4tOT/6obXMUF/RydsbrsWS95JWxQFniJFR9xaqHXh4th71b9OHUVkdv 101WqTZKn2TY+f2HKaLvDhQZfOt6nDnKLzHph18FVt2JulEcIP7LcX049f6CRvDDm7XT +RtOUkDCyKstEKNTTIVdtGWPxr5Tjt6muGwmwahb706Kr4WyyBHQUBKuol0ypOl4niz3 8V4JpLFhUiShwvA2Xq8iWi2ujdI65CA0AkUU60oOoo1iH7td8hZ0X5OFeL1toZw5muKh hHTQ== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr4871670vdf.127.1339153191078; Fri, 08 Jun 2012 03:59:51 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 03:59:50 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 12:59:50 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: robert.cole@jhuapl.edu Subject: Re: [manet] Defining subnet models used by our protocols X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:59:52 -0000 ++++++++++++++++++ Possible Duplication Information +++++++++++++++ Hi Folks, It may be repeated input but needed for my work on the draft of : MANET possible L2 technology. This subject input was reaction to Mr.Cole input in 82-meeting of WG, and for the apearance of DLEP in the WG. please read below: UH>I think it would be wrong to define such a multi-link subnet (for the >reasons the IAB described in in RFC4903, and that we tried to convey >at length in AUTOCONF). I just now finished reading RFC4903 and thank you that you brought it to my attention ( I will include in my draft), however, I see that it considers issue of L3 link models not L2 link models. There are big difference between L3 and L2. RFC4903>There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link. AB> meaning the total link that includes the path between two node-interfac= es. RFC4903>Links that appear as NBMA links at layer 3 are problematic. Instead= , if a link is an NBMA link at layer 2, then protocol designers should define some mechanism such that it appears as either the multi-access link model or point-to-point link model at layer 3. AB> please read above----> designers SHOULD define some mechanism such that it appears as either the multi-access....... AB> I just wanted to write a draft to define L2 network technology and follow the RFC4903, so the RFC4903 is not against but with my approach. Please note that I don't want to define the protocol to be dependent on the L2 technology, but I want the DESIGNERS to KNOW what they are looking as Mr.Clausen mentioned in the WG 77 meeting, that we define assumptions/conditions before looking at our protocols. I appreciate that you educated me regarding the RFC4903 it is very important to read I admit that I missed. Thanks, Best Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D On 6/2/12, Abdussalam Baryun wrote: > Hi All > > I want to discuss this subnet definition issue that was raised in the > 82 meeting, could we discuss about it please. Will we need to put it > in a draft or include it in our active draft working in progress, > please advise, > > Abdussalam Baryun, > University of Glamorgan, UK > ++++++++++++++++++++++++++++++ > > In WG 82 meeting it was mentioned (Bob Cole and Teco discussions): > BC> that subnet-models are not defined But in DLEP it looks at two > subnet-models (different models; e.g. radio subnet-models, > sat-subnet-models). We are defining IP over a subnet, but the subnet > is not defined. Then we don=92t know how to define control protocols, > data-packet-formats, and managements-models without having a subnet > model in mind. > TB> In sat-comms the up-link and down-link can be very different. So > for different nodes on same carrier can be different data rates, SNR, > etc. so it is important that DLEP include the link metrics, even if it > is a full connected subnet. > BC> the subnet depends on the link of the subnet-underlying model, > The semantics of link up and down are determined by the underlying. > ++++++++++++++++++++++++++++++++++++++++++++++++++ > > ******************************************************************** > 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. > ******************************************************************** > From emmanuel.baccelli@gmail.com Fri Jun 8 04:20:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9121F8877 for ; Fri, 8 Jun 2012 04:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 D-orQcBd3UXH for ; Fri, 8 Jun 2012 04:20:32 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EB54621F8873 for ; Fri, 8 Jun 2012 04:20:31 -0700 (PDT) Received: by qcsq13 with SMTP id q13so942252qcs.31 for ; Fri, 08 Jun 2012 04:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=yN8Ivv4JoVwlDjAANpqRTmmVXBv0zE5VF4zbWSZQZTw=; b=BmMZcVCHJPO7og7/vd78VArEFXt6jHJ+Mtxb556ND5uO0TWx9ow66kMwVqPARXwyEg DOXT9i1YiwVxhQHUY1jIqMP33/xVTeW24tQ0jSa2kyk5oAOgubHnm4iR78BMW50ZYfVF 7heLVZLZOcSZyq4HLUw5avCqTq6ocWn8OhZkjS7534SSH1BLriQJMgZyp0VFaJXWaQFv yBaS9Qv4gaOw5lKYMLbg+EVdV/tZdoInYWat4CxsBivPDpX0AENQfnmcdc4CFAECzW4z KSkhk6/powCCRDBmgVeRN/HAZ5HDUIm7tutSBebAbTM3fR+iEkb72Q8+LprALOqF1R+d 1QTw== Received: by 10.229.105.166 with SMTP id t38mr1657362qco.136.1339154431442; Fri, 08 Jun 2012 04:20:31 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.229.218.80 with HTTP; Fri, 8 Jun 2012 04:20:10 -0700 (PDT) In-Reply-To: <4FD0DA29.5040908@computer.org> References: <4FCE6BB4.6060403@computer.org> <04219D1A-5B89-4413-B32E-079B60472996@cisco.com> <6AED76A2-FC39-4C00-B068-ACF60510B722@herberg.name> <5D3FD5F3-DB07-42CF-A6F6-757405BFB201@cisco.com> <4FD0DA29.5040908@computer.org> From: Emmanuel Baccelli Date: Fri, 8 Jun 2012 13:20:10 +0200 X-Google-Sender-Auth: z6Ifhb0OGHDP5t-r1lDhduYUbeA Message-ID: To: manet Content-Type: multipart/alternative; boundary=00235429d1902f7f0204c1f43043 Cc: Fred Baker , sratliff@cisco.com Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:20:33 -0000 --00235429d1902f7f0204c1f43043 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Fred, I am also of the opinion that we should *try* to learn from the past, and in particular, avoid repeating AUTOCONF discussions that already went (slowly) nowhere. One of the conclusions of AUTOCONF was that, if you don't know anything a priori about an interface's connectivity (i.e. the "ad hoc" aspect), then you should not configure any IP on-link subnet prefix on this interface: this is essentially what RFC5889 stipulates. Another document described mor= e in details why "ad hoc" means in reality knowing *nothing* a priori in terms of connectivity characteristics over an interface. I am thus also of the opinion that a simple "on-link subnet of 1" models reality well enough already -- no need for a new model here. But that does not mean that IP address aggregation is impossible to use in this context. In many cases, things are still simple: IP addresses configured on interfaces to an ad hoc network can still derive from a common prefix, managed by a single gateway to the outside world, which can just advertise this prefix to the outside world, and thus perpetuate useful traditions such as subnet routing, longest-prefix matching etc. Of course, there are more hairy cases, for instance when some types of mobility or multi-homing are involved. Regards, Emmanuel On Thu, Jun 7, 2012 at 6:43 PM, Charles E. Perkins w= rote: > > Hello Stan, > > I'd like to echo what you said but just adding a bit more: > > > On 6/7/2012 8:23 AM, Stan Ratliff wrote: > >> Ditto what Ulrich said. The working group not to be named died only afte= r >> many, many, MANY long, tedious discussions. Discussions that yielded >> exactly 1 document. >> > > We had quite a few good documents. These documents did not make progress > because there was > a fatal insistence on producing some architectural model that included > subnets. I must have stood > in front of the mike dozens of times complaining that it was by no means > necessary and in fact even > dangerous to go there before getting the basic work done. > > > At a baseline, fundamental level, discussion of a "subnet model" in an >> "ad-hoc" network seems like an oxymoron to me=85 if we have a specific >> "model" that the network fits into, how is that "ad-hoc"? I'll say it ag= ain >> - unfortunately, the only subnet model that fits is that there isn't a >> subnet model. >> > > > You make a good point: subnet organization is NOT "ad hoc". However, > once a subnet is established, > as mentioned before it is just fine for an ad hoc routing protocol to mak= e > use of the subnet. It's just > that maintaining the subnet structure needs to be _external_ [i.e., out o= f > scope] for the specification of > the ad hoc routing protocol. > > So I'd restate your last sentence as follows: > "the only subnet models that fit are those whose establishment and > maintenence are out of scope for [manet]" > > -- > Regards, > Charlie P. > > > ______________________________**_________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/**listinfo/manet > --00235429d1902f7f0204c1f43043 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Fred,

I am also of the opinion that we should *try* to lear= n from the past, and in particular, avoid repeating AUTOCONF discussions th= at already went (slowly) nowhere.=A0

One of the conclusions of AUTOCONF was that, if you d= on't know anything a priori about an interface's connectivity (i.e.= the "ad hoc" aspect), then you should not configure any IP on-li= nk subnet prefix on this interface: this is essentially what RFC5889 stipul= ates.=A0Another document described=A0more in details why "ad ho= c"=A0means in reality knowing *nothin= g*=A0a priori=A0in terms of connectivity characteristics over an int= erface. I am thus also of the opinion that a simple "on-link subnet of= 1" models reality well enough already -- no need for a new model here= .

But that does not mean that IP address aggregation is i= mpossible to use in this context. In many cases, things are still simple: I= P addresses configured on interfaces to an ad hoc network can still derive = from a common prefix, managed by a single gateway to the outside world, whi= ch can just advertise this prefix to the outside world, and thus perpetuate= useful traditions such as subnet routing, longest-prefix matching etc.=A0<= /div>

Of course, there are more hairy cases, for instance whe= n some types of mobility or multi-homing are involved.=A0

Regards,

Emmanuel






=




On Thu, Jun 7, 2012 at 6:43 PM, Charles E. Perkins <c= harliep@computer.org> wrote:

Hello Stan,

I'd like to echo what you said but just adding a bit more:


On 6/7/2012 8:23 AM, Stan Ratliff wrote:
Ditto what Ulrich said. The working group not to be named died only after m= any, many, MANY long, tedious discussions. Discussions that yielded exactly= 1 document.

We had quite a few good documents. =A0These documents did not make progress= because there was
a fatal insistence on producing some architectural model that included subn= ets. =A0I must have stood
in front of the mike dozens of times complaining that it was by no means ne= cessary and in fact even
dangerous to go there before getting the basic work done.
=

At a baseline, fundamental level, discussion of a "subnet model" = in an "ad-hoc" network seems like an oxymoron to me=85 if we have= a specific "model" that the network fits into, how is that "= ;ad-hoc"? I'll say it again - unfortunately, the only subnet model= that fits is that there isn't a subnet model.


You make a good point: subnet organization is NOT "ad hoc". =A0 H= owever, once a subnet is established,
as mentioned before it is just fine for an ad hoc routing protocol to make = use of the subnet. =A0It's just
that maintaining the subnet structure needs to be _external_ [i.e., out of = scope] for the specification of
the ad hoc routing protocol.

So I'd restate your last sentence as follows:
"the only subnet models that fit are those whose establishment and mai= ntenence are out of scope for [manet]"

--
Regards,
Charlie P.


_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--00235429d1902f7f0204c1f43043-- From abdussalambaryun@gmail.com Fri Jun 8 04:44:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815B221F8639 for ; Fri, 8 Jun 2012 04:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lfx6VmMQpl6n for ; Fri, 8 Jun 2012 04:44:04 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9E21F88F4 for ; Fri, 8 Jun 2012 04:44:04 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1005517vcq.31 for ; Fri, 08 Jun 2012 04:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K9gQyX0PXX+H5uXlClULQPyTZMhfI+cNN8rF6Vqm3YY=; b=0J+9Ad9SptWfsY9RF82buk8lPAAPqk0+DgNdukOiEoTLPRzdti5u0DessSJb6gTFfc 7jYhMUb8V9HYDRGwYEb0vWsKeHvfHnwD97NZgJ0x3OgDuvk2V8Ds/zggcmWndrogjyNA zYSXYJvuKueaM9J/iNSuSXBdffc/b9MxvxVlnDEFTF4y+XvxEVfuYOWz9ZaysBo6DwXP fYy0RMa+iebJ19AsBMCehXqHyMSijmQnKpqpHk8b/q6jzJljWfXi6KfGyNxOro+9p46H fV0HFq30jdd2uHzMNGD9DbFGkAquGFmcDbUmRVk2cGfSOldFpCLjcUzDRRy5EPZariEW 1JIg== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr4974417vdi.86.1339155841540; Fri, 08 Jun 2012 04:44:01 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 04:44:01 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 13:44:01 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:44:06 -0000 Hi Chris, I thank you for your comments. I agree with Teco. However, your comments look in one direction, but I want to see All directions if possible. Your comments see the protocol progress in ignoring L2 because abstract layer, which I admit I like and we still SHOULD do that now and in future because it gives better performance (the Designer-point-of-protocol). In the other direction is that the customer wants to know our assumption/conditions or L2 technologies that we use as possible-use-case or defined in the section of Protocol-Applicability-Statement, so s/he can know how to use it OR s/he can understand that the DESIGNER tested the condition or scenarios of using PROTOCOL over such technology (the customers-point-of-using-protocol). We have different users around the world with different network technologies in use. We have to admit that RFC3561 and RFC3626 were not general purpose enough to cover LLN issues which that is why we have a WG named ROLL (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2. We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting (i.e. his input regarding one protocol that only was tested by simulation scenarios), theories don't give right results. This was also spoted by Corson (1998), it seems that is why he written the draft, and that is why I think the importance of their both inputs. Please note that NOT mentioning some technology definitions in the applicability of protocol, doesn't mean that the protocol is really tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our protocols are tested in some industry technology and are not in others. Please note that MANET WG is doing OLSRv2 without updating RFC3626 which make people think why?, I want to define technologies at L2 because DLEP is important for my draft, and that for DSRv2 to be reasonable to users around the world, and to get feedback from time to time of their concerns so I can update some RFC in future (if I was successful : ), each 8 years or any reasonable requirement. Best Regards Abdussalam Baryun University of Glamorgan, UK ======================================================= < One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. IETF WGs are always right > **************************************************************************************** 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. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any purpose other than IETF procedures purposes. **************************************************************************************** On 6/8/12, Dearlove, Christopher (UK) wrote: > Being explicit about L2 technologies is exactly what MANET should not do. At > least not in any limiting way. Of course if someone were to write an > informative draft about (say) using OLSRv2 over IEEE 802.11 that would be > fine. Though it would run the risk of suggesting to some that that is the > only L2 suggested,, so I'd want the draft to make it clear that wasn't so. > And anything that said OLSRv2 was intended for use over the following L2 > protocols would be completely wrong. The point of routing at L3 is to be as > L2 independent as possible. > > If I've read the draft you mention it was a long time ago. Digging up 1998 > drafts to reissue doesn't strike me as the most productive possible > exercise. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 08 June 2012 04:42 > To: manet > Subject: [manet] MANET Protocol Applicability > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Folks > > I have read two important inputs and want to share my opinion, > > ============ point 1 ============ > > In one work in progress ietf-draft (expired): > draft-ietf-manet-appl-00.txt, > Corson, (1998)mentioned in Abstract and Introduction: > > Abstract> The intent of this 'Applicability Section' is to > aid readers unfamiliar with the details of each protocol's design in > understanding the protocol's basic characteristics, functioning and > mechanisms, as well as to provide a general description of the > networking context for which the protocol was designed, and in which > it is expected to perform well. > > Introduction> The set of applications for which the use of MANET > technology envisioned is diverse, ranging from small, > energy-constrained nearly > static networks to large-scale, mobile, highly-dynamic networks. The > combinations of network size, topology composition and dynamics, > bandwidth and energy availability, physical and link-layer > technologies, intended application usages, etc. are many, and it seems > unlikely that a single protocol will function superiorly over this > wide range of networking contexts. Thus a given protocol is likely to > be well-suited for operation in those networks whose characteristics > match well with the combination of mechanisms employed by the > protocol. > ============ point 2 ============== > In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is > important to be explicit about assumptions/conditions before talking > about protocol. > ============ opinion ============== > I agree with both points and approach to solve routing protocols, and > would RECOMMEND either of the following: > 1- MANET WG defines (in one informative-draft) intended application > usage, and be explicit about applicable L2 network technologies. So > that each future protocols mentions in their applicability statement > section the usual use-case for such protocol, OR > 2- MANET WG renews the I-D expired of Corson (1998) and adds more > issues so it can become an RFC in future, > > Thanking you, > Abdussalam Baryun > ========================= > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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. > ******************************************************************** > > From abdussalambaryun@gmail.com Fri Jun 8 04:50:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6529921F88A3 for ; Fri, 8 Jun 2012 04:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ZvlApYw822yb for ; Fri, 8 Jun 2012 04:50:41 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60921F88B2 for ; Fri, 8 Jun 2012 04:50:41 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1010028vcq.31 for ; Fri, 08 Jun 2012 04:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/JYunS6b3WbPxy8se3oDfhg2/Uvx4WSmS/M8MNC9o+8=; b=hs+O895E0uCSvdeED8bKim/GhctApFRgR9DKZPV80EqdIUrkC0m+lOUCVd2G0wgXZS AHpEvYGgZ4nZJVe/Hh/l1LjnsclljwTXN9z0gUe8pgjhAL3a/oI0IM/uJ/cdW50GFbjb e5fiWjGevNYWrvzrgPfVhLzqYlCK6GBIVVI44hJ2iFLYtbkkCCfBA/XdSTlVHcs6X04/ dWknJDhUiQckDeebzdsFDNvAHz34GdRV3e2A3tFpJUYctF/awYHRdH7TacLBdQH1uFLc cwIsGbxVgaz7ZAOlzDH7a3qLntZMGfg+mJhr7rIU8EWpt7Z7d7JAvGAfLLbp7dfTneQf 3Ddw== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr4992859vdi.86.1339156240360; Fri, 08 Jun 2012 04:50:40 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 04:50:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 13:50:40 +0200 Message-ID: From: Abdussalam Baryun To: teco@inf-net.nl Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:50:42 -0000 Hi Teco, I will need your input and assistance in the draft I am writing for submission to the WG, and hope to get Mr. Cole as well, Your input and Mr.Cole were very important from my point of view, and hope we can go in progress for this issue, thanking you, Best Regards Abdussalam Baryun University of Glamorgan, UK =========================================================== On 6/8/12, Abdussalam Baryun wrote: > Hi Chris, > > I thank you for your comments. I agree with Teco. However, your > comments look in one direction, but I want to see All directions if > possible. Your comments see the protocol progress in ignoring L2 > because abstract layer, which I admit I like and we still SHOULD do > that now and in future because it gives better performance (the > Designer-point-of-protocol). > > In the other direction is that the customer wants to know our > assumption/conditions or L2 technologies that we use as > possible-use-case or defined in the section of > Protocol-Applicability-Statement, so s/he can know how to use it OR > s/he can understand that the DESIGNER tested the condition or > scenarios of using PROTOCOL over such technology (the > customers-point-of-using-protocol). We have different users around the > world with different network technologies in use. > > We have to admit that RFC3561 and RFC3626 were not general purpose > enough to cover LLN issues which that is why we have a WG named ROLL > (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2. > > We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting > (i.e. his input regarding one protocol that only was tested by > simulation scenarios), theories don't give right results. This was > also spoted by Corson (1998), it seems that is why he written the > draft, and that is why I think the importance of their both inputs. > Please note that NOT mentioning some technology definitions in the > applicability of protocol, doesn't mean that the protocol is really > tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our > protocols are tested in some industry technology and are not in > others. > > Please note that MANET WG is doing OLSRv2 without updating RFC3626 > which make people think why?, I want to define technologies at L2 > because DLEP is important for my draft, and that for DSRv2 to be > reasonable to users around the world, and to get feedback from time to > time of their concerns so I can update some RFC in future (if I was > successful : ), each 8 years or any reasonable requirement. > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK > ======================================================= > < One may be wrong, or may be right, but it does not matter if we work > together > as a group to discuss and resolve all issues. IETF WGs are always right > > **************************************************************************************** > 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. The contents are comply > to the IETF regulations, and WG procedures. You should not copy the > email nor use it for any purpose other than IETF procedures purposes. > **************************************************************************************** > > > On 6/8/12, Dearlove, Christopher (UK) > wrote: >> Being explicit about L2 technologies is exactly what MANET should not do. >> At >> least not in any limiting way. Of course if someone were to write an >> informative draft about (say) using OLSRv2 over IEEE 802.11 that would be >> fine. Though it would run the risk of suggesting to some that that is the >> only L2 suggested,, so I'd want the draft to make it clear that wasn't >> so. >> And anything that said OLSRv2 was intended for use over the following L2 >> protocols would be completely wrong. The point of routing at L3 is to be >> as >> L2 independent as possible. >> >> If I've read the draft you mention it was a long time ago. Digging up >> 1998 >> drafts to reissue doesn't strike me as the most productive possible >> exercise. >> >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >> >> 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of >> Abdussalam Baryun >> Sent: 08 June 2012 04:42 >> To: manet >> Subject: [manet] MANET Protocol Applicability >> >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >> >> Hi Folks >> >> I have read two important inputs and want to share my opinion, >> >> ============ point 1 ============ >> >> In one work in progress ietf-draft (expired): >> draft-ietf-manet-appl-00.txt, >> Corson, (1998)mentioned in Abstract and Introduction: >> >> Abstract> The intent of this 'Applicability Section' is to >> aid readers unfamiliar with the details of each protocol's design in >> understanding the protocol's basic characteristics, functioning and >> mechanisms, as well as to provide a general description of the >> networking context for which the protocol was designed, and in which >> it is expected to perform well. >> >> Introduction> The set of applications for which the use of MANET >> technology envisioned is diverse, ranging from small, >> energy-constrained nearly >> static networks to large-scale, mobile, highly-dynamic networks. The >> combinations of network size, topology composition and dynamics, >> bandwidth and energy availability, physical and link-layer >> technologies, intended application usages, etc. are many, and it seems >> unlikely that a single protocol will function superiorly over this >> wide range of networking contexts. Thus a given protocol is likely to >> be well-suited for operation in those networks whose characteristics >> match well with the combination of mechanisms employed by the >> protocol. >> ============ point 2 ============== >> In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is >> important to be explicit about assumptions/conditions before talking >> about protocol. >> ============ opinion ============== >> I agree with both points and approach to solve routing protocols, and >> would RECOMMEND either of the following: >> 1- MANET WG defines (in one informative-draft) intended application >> usage, and be explicit about applicable L2 network technologies. So >> that each future protocols mentions in their applicability statement >> section the usual use-case for such protocol, OR >> 2- MANET WG renews the I-D expired of Corson (1998) and adds more >> issues so it can become an RFC in future, >> >> Thanking you, >> Abdussalam Baryun >> ========================= >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> ******************************************************************** >> 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. >> ******************************************************************** >> >> > From abdussalambaryun@gmail.com Fri Jun 8 04:57:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5558F21F88EC for ; Fri, 8 Jun 2012 04:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.515 X-Spam-Level: X-Spam-Status: No, score=-3.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Vt0fcbwYJ1lP for ; Fri, 8 Jun 2012 04:57:00 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C8B6121F8912 for ; Fri, 8 Jun 2012 04:57:00 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1014226vcq.31 for ; Fri, 08 Jun 2012 04:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rsaTSdyWkih0T+UqrX88nDYHaG+pNGW75BfvMZUuN2s=; b=hcSal/7sMqEAuQe6gLlw3tn9wafEpeK14XhPa94tR4mIrwCHKb71g6OvETiURIEbMV LWDCVfdQfgq4TC27UxaZswDJNenzHNOm7XdFErEK8KsdHI3NjZHPCMyI9fQBUIKoQ7mj /CUHVymDvjlSGHhWC6ILaLBuvImMbC4iQ7Mk55vcW2Uh5Oo0tRTuc7n6Rfc24uYdFrzg E2J46NUjh+3Fkayi1wTZtWYM70jMQoZajUMs3UMHiFBrK4UMERqwf+xhb76YBJu0ehZq H0dkjeq+a9ubsScCtKsK114g3+n4QRukdSFAXBniC/eGuU45cCJQ3kB7H/zlYTj6jmHS 4Smw== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr4993896vdb.103.1339156620376; Fri, 08 Jun 2012 04:57:00 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 04:57:00 -0700 (PDT) Date: Fri, 8 Jun 2012 13:57:00 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:57:01 -0000 Hi Folks, I am starting defining MANET technology used, which I see many interests in and a need for. This need was mentioned in 82-meeting and in the Discussion Linst. I just wanted to announce *interests* and that it will be a separate Information track, but if the WG wants it other we can discuss that. There was some oppose to the idea of all/any drafts including definition, so I decided to make a first PUSH to one draft for our productive discussion and WG progress, Thanking you Abdussalam Baryun University of Glamorgan, UK, ===================================================== From Chris.Dearlove@baesystems.com Fri Jun 8 05:29:25 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41B021F88D9 for ; Fri, 8 Jun 2012 05:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1JGHw6i6gDpU for ; Fri, 8 Jun 2012 05:29:24 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 24EA021F88D2 for ; Fri, 8 Jun 2012 05:29:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="244652760" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 08 Jun 2012 13:29:23 +0100 Received: from GLKXH0001V.GREENLNK.net ([10.109.2.32]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q58CTMcv024715 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 13:29:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.01.0355.002; Fri, 8 Jun 2012 13:29:22 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] MANET Protocol Applicability Thread-Index: AQHNRSi2AwHjHpgnTkaFZUo3+G0t9JbwHtHggAAeGICAABs90A== Date: Fri, 8 Jun 2012 12:29:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:29:25 -0000 I really don't understand what you mean by " is doing OLSRv2 without updati= ng RFC3626". That suggests a lack of understanding of the process. I disagree with you on the relationship of this WG to defining L2 technolog= ies. But there's no point in me repeating what I've already said. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: 08 June 2012 12:44 To: Dearlove, Christopher (UK) Cc: manet; teco@inf-net.nl; John.Dowdell@Cassidian.com Subject: Re: [manet] MANET Protocol Applicability ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi Chris, I thank you for your comments. I agree with Teco. However, your comments look in one direction, but I want to see All directions if possible. Your comments see the protocol progress in ignoring L2 because abstract layer, which I admit I like and we still SHOULD do that now and in future because it gives better performance (the Designer-point-of-protocol). In the other direction is that the customer wants to know our assumption/conditions or L2 technologies that we use as possible-use-case or defined in the section of Protocol-Applicability-Statement, so s/he can know how to use it OR s/he can understand that the DESIGNER tested the condition or scenarios of using PROTOCOL over such technology (the customers-point-of-using-protocol). We have different users around the world with different network technologies in use. We have to admit that RFC3561 and RFC3626 were not general purpose enough to cover LLN issues which that is why we have a WG named ROLL (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2. We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting (i.e. his input regarding one protocol that only was tested by simulation scenarios), theories don't give right results. This was also spoted by Corson (1998), it seems that is why he written the draft, and that is why I think the importance of their both inputs. Please note that NOT mentioning some technology definitions in the applicability of protocol, doesn't mean that the protocol is really tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our protocols are tested in some industry technology and are not in others. Please note that MANET WG is doing OLSRv2 without updating RFC3626 which make people think why?, I want to define technologies at L2 because DLEP is important for my draft, and that for DSRv2 to be reasonable to users around the world, and to get feedback from time to time of their concerns so I can update some RFC in future (if I was successful : ), each 8 years or any reasonable requirement. Best Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D < One may be wrong, or may be right, but it does not matter if we work toge= ther as a group to discuss and resolve all issues. IETF WGs are always right > ***************************************************************************= ************* 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. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any purpose other than IETF procedures purposes. ***************************************************************************= ************* On 6/8/12, Dearlove, Christopher (UK) wrote= : > Being explicit about L2 technologies is exactly what MANET should not do.= At > least not in any limiting way. Of course if someone were to write an > informative draft about (say) using OLSRv2 over IEEE 802.11 that would be > fine. Though it would run the risk of suggesting to some that that is the > only L2 suggested,, so I'd want the draft to make it clear that wasn't so= . > And anything that said OLSRv2 was intended for use over the following L2 > protocols would be completely wrong. The point of routing at L3 is to be = as > L2 independent as possible. > > If I've read the draft you mention it was a long time ago. Digging up 199= 8 > drafts to reissue doesn't strike me as the most productive possible > exercise. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 08 June 2012 04:42 > To: manet > Subject: [manet] MANET Protocol Applicability > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi Folks > > I have read two important inputs and want to share my opinion, > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > In one work in progress ietf-draft (expired): > draft-ietf-manet-appl-00.txt, > Corson, (1998)mentioned in Abstract and Introduction: > > Abstract> The intent of this 'Applicability Section' is to > aid readers unfamiliar with the details of each protocol's design in > understanding the protocol's basic characteristics, functioning and > mechanisms, as well as to provide a general description of the > networking context for which the protocol was designed, and in which > it is expected to perform well. > > Introduction> The set of applications for which the use of MANET > technology envisioned is diverse, ranging from small, > energy-constrained nearly > static networks to large-scale, mobile, highly-dynamic networks. The > combinations of network size, topology composition and dynamics, > bandwidth and energy availability, physical and link-layer > technologies, intended application usages, etc. are many, and it seems > unlikely that a single protocol will function superiorly over this > wide range of networking contexts. Thus a given protocol is likely to > be well-suited for operation in those networks whose characteristics > match well with the combination of mechanisms employed by the > protocol. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is > important to be explicit about assumptions/conditions before talking > about protocol. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > I agree with both points and approach to solve routing protocols, and > would RECOMMEND either of the following: > 1- MANET WG defines (in one informative-draft) intended application > usage, and be explicit about applicable L2 network technologies. So > that each future protocols mentions in their applicability statement > section the usual use-case for such protocol, OR > 2- MANET WG renews the I-D expired of Corson (1998) and adds more > issues so it can become an RFC in future, > > Thanking you, > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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. > ******************************************************************** > > From hrogge@googlemail.com Fri Jun 8 05:31:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2E321F86F5 for ; Fri, 8 Jun 2012 05:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 sVWcIXlk5NTj for ; Fri, 8 Jun 2012 05:31:38 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 80B9121F86AD for ; Fri, 8 Jun 2012 05:31:38 -0700 (PDT) Received: by dacx6 with SMTP id x6so2335314dac.31 for ; Fri, 08 Jun 2012 05:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=b7YazAyk8V3+ihgV3+TqHJpMBLzzjM4ae6zIDIxCVAY=; b=TLbu+6/qepk/H/XiZmDI7CuXX0u/Q3GZax06czcxnz3pNKHNGZ1tVXZYlDBysasesx QZjdCZMUdVK+MMZErXual81jpTz8B5n0AmzqrGb5n+fTPqMCdP60BRQvWkQgthbPvHkw MorPVMvljxt345rWNiqFGw60evNmIw1FIkSHKSEZJOeQEGHe7HSrYnsCvDrK79/6di3M ayjQEkdPao1a2ARvaXbUk6fnbOiT1uPpq1z5UG4/FmH2Gqhd/sIIsCrzhkjDU1NgT2LX 8T0/1ASgp+oShvmqc6vCGEBJ7T8p6/H+HJCTSFBn2tr/41lr/FhRSqxRvstZa+T1FaKk GbtA== Received: by 10.68.190.40 with SMTP id gn8mr19896291pbc.118.1339158698314; Fri, 08 Jun 2012 05:31:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Fri, 8 Jun 2012 05:31:18 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Fri, 8 Jun 2012 14:31:18 +0200 Message-ID: To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:31:39 -0000 On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun wrote: > Hi Chris, > > Please note that MANET WG is doing OLSRv2 without updating RFC3626 > which make people think why? This sentence doesn't make sense. OLSRv2 IS the update of RFC 3626. Are you sure you understand how the IETF works to update existing protocols? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Fri Jun 8 07:08:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E585521F891C for ; Fri, 8 Jun 2012 07:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ex22OOceCmpB for ; Fri, 8 Jun 2012 07:08:35 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1321F8888 for ; Fri, 8 Jun 2012 07:08:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so621414wgb.13 for ; Fri, 08 Jun 2012 07:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Kqp/KAPazKsIvsRCVvAgBIMP0rObMt6u+mGKc4QyecM=; b=EHCCUd+FJ+PawyRR9HtlnM08s+dEGhcPnLDSC1d+HAvBZaCFkIlDxAu8SfRNqakuTD 3DMi1tOqM6fT1bU9f8tTdnb2+ja1VBOQWjECn/Oj6EF+nQbajJQjihehn4ZCmWrnDY2b LfX1LZ6wSmyQYBrWFsEfdarZveOm2y/IMgcTxtCFfsVoAYgWUfzIFSM0xKGLPRgQiqVb 9mbc7wGLgtepMNLN6WnPUjCx4xNODKOT849NI+aiQnh1dHpce63f6E/PdwVPfZNyZUhQ IEsKx7Is6PVpfdd75MVd6MxbuMeJVNR+Onz/NO5/IRjp67Sb+1rMpOTphKmo5kaZ3cUh 8Zog== Received: by 10.180.7.133 with SMTP id j5mr695639wia.14.1339164513886; Fri, 08 Jun 2012 07:08:33 -0700 (PDT) Received: from [10.175.173.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id hv7sm2406084wib.0.2012.06.08.07.08.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 07:08:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 8 Jun 2012 16:08:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <087382AA-47C5-4226-9CE2-EDD08A63D24D@inf-net.nl> References: To: Henning Rogge X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmF+4c2ziKokMxrPFfEeGgdLXzIPZ9xQyBn+XqZreM77vV+3r3eqvtue3Qc2CSFi6HPp37u Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:08:36 -0000 Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: > On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > wrote: >> Hi Chris, >>=20 >> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >> which make people think why? >=20 > This sentence doesn't make sense. >=20 > OLSRv2 IS the update of RFC 3626. More precisely, we work on a replacement for the initial experimental = version. RFC 3626 is not updated. It could get historic one day. Teco >=20 > Are you sure you understand how the IETF works to update existing = protocols? >=20 > Henning Rogge >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From sratliff@cisco.com Fri Jun 8 07:09:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DDA21F87D8 for ; Fri, 8 Jun 2012 07:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 fZkz1DAyMRCg for ; Fri, 8 Jun 2012 07:09:50 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE5721F87B4 for ; Fri, 8 Jun 2012 07:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=9647; q=dns/txt; s=iport; t=1339164590; x=1340374190; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=C8oksATmlZKeHdmXf6ywPSoQDgg0SX212Icxvro6g4s=; b=C0rYqCgs4U2HJomeLyR9EKDIzl/kV+Q3KCdVNRoG05lWPfOHdjglf8eF LRasNAEmPLc+dwyIyZAr3tlLoJKVGR3AGiC7QT4BmzB90VN8Bvnk/qewH 73dTjFpfETDvAD/wQSeaw8/WxOwH3oU1X8IU/vS/luJHO32xX0SwKpy5m 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKYG0k+tJXG8/2dsb2JhbABFtE6BB4IYAQEBAwEBAQEPAScbGQMIBQcECxEEAQEBJwcnHwkIBhMih2QFC5kvn2uLJhQOhH5gA5UejhWBZoJ8gToJ X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90730751" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jun 2012 14:09:49 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q58E9nM9029087; Fri, 8 Jun 2012 14:09:49 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Fri, 8 Jun 2012 10:09:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7CC485E7-3973-485F-ADD0-107B0EAE6669@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:09:52 -0000 It's been said by others on this mailing list, but I'll add my opinion = in as well: Any attempt to specifically define L2 technologies for = MANET networks is, IMO, misguided at best, dangerous at worst.=20 In my experiences, we have deployed mobile networks over a variety of L2 = technologies; that is *exactly* what the layered model (what you are = referring to as the abstraction) was intended to facilitate. The L1/L2 = characteristics of the networks I've worked on varies wildly - again, a = benefit of the layered approach. Part of the DLEP work is trying to find = ways for radios and routers to tell each other more information (thus, = to some extent, DLEP codifies a small subset of "layer violations", if = you will), but to do so in a manner that is applicable for all types of = devices. Hence, the generalized DLEP abstractions for "bandwidth" and = "latency". So this email can be registered as my vote as a Working Group member = that this (a) is a *really bad* idea, and (b) should not be accepted as = a working group item, if it is presented to the WG.=20 Regards, Stan > Hi Chris, >=20 > I thank you for your comments. I agree with Teco. However, your > comments look in one direction, but I want to see All directions if > possible. Your comments see the protocol progress in ignoring L2 > because abstract layer, which I admit I like and we still SHOULD do > that now and in future because it gives better performance (the > Designer-point-of-protocol). >=20 > In the other direction is that the customer wants to know our > assumption/conditions or L2 technologies that we use as > possible-use-case or defined in the section of > Protocol-Applicability-Statement, so s/he can know how to use it OR > s/he can understand that the DESIGNER tested the condition or > scenarios of using PROTOCOL over such technology (the > customers-point-of-using-protocol). We have different users around the > world with different network technologies in use. >=20 > We have to admit that RFC3561 and RFC3626 were not general purpose > enough to cover LLN issues which that is why we have a WG named ROLL > (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2. >=20 > We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting > (i.e. his input regarding one protocol that only was tested by > simulation scenarios), theories don't give right results. This was > also spoted by Corson (1998), it seems that is why he written the > draft, and that is why I think the importance of their both inputs. > Please note that NOT mentioning some technology definitions in the > applicability of protocol, doesn't mean that the protocol is really > tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our > protocols are tested in some industry technology and are not in > others. >=20 > Please note that MANET WG is doing OLSRv2 without updating RFC3626 > which make people think why?, I want to define technologies at L2 > because DLEP is important for my draft, and that for DSRv2 to be > reasonable to users around the world, and to get feedback from time to > time of their concerns so I can update some RFC in future (if I was > successful : ), each 8 years or any reasonable requirement. >=20 > Best Regards >=20 > Abdussalam Baryun > University of Glamorgan, UK > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > < One may be wrong, or may be right, but it does not matter if we work = together > as a group to discuss and resolve all issues. IETF WGs are always = right > > = **************************************************************************= ************** > 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. The contents are = comply > to the IETF regulations, and WG procedures. You should not copy the > email nor use it for any purpose other than IETF procedures purposes. > = **************************************************************************= ************** >=20 >=20 > On 6/8/12, Dearlove, Christopher (UK) = wrote: >> Being explicit about L2 technologies is exactly what MANET should not = do. At >> least not in any limiting way. Of course if someone were to write an >> informative draft about (say) using OLSRv2 over IEEE 802.11 that = would be >> fine. Though it would run the risk of suggesting to some that that is = the >> only L2 suggested,, so I'd want the draft to make it clear that = wasn't so. >> And anything that said OLSRv2 was intended for use over the following = L2 >> protocols would be completely wrong. The point of routing at L3 is to = be as >> L2 independent as possible. >>=20 >> If I've read the draft you mention it was a long time ago. Digging up = 1998 >> drafts to reissue doesn't strike me as the most productive possible >> exercise. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> 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 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Abdussalam Baryun >> Sent: 08 June 2012 04:42 >> To: manet >> Subject: [manet] MANET Protocol Applicability >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Hi Folks >>=20 >> I have read two important inputs and want to share my opinion, >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 1 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >>=20 >> In one work in progress ietf-draft (expired): >> draft-ietf-manet-appl-00.txt, >> Corson, (1998)mentioned in Abstract and Introduction: >>=20 >> Abstract> The intent of this 'Applicability Section' is to >> aid readers unfamiliar with the details of each protocol's design in >> understanding the protocol's basic characteristics, functioning and >> mechanisms, as well as to provide a general description of the >> networking context for which the protocol was designed, and in which >> it is expected to perform well. >>=20 >> Introduction> The set of applications for which the use of MANET >> technology envisioned is diverse, ranging from small, >> energy-constrained nearly >> static networks to large-scale, mobile, highly-dynamic networks. The >> combinations of network size, topology composition and dynamics, >> bandwidth and energy availability, physical and link-layer >> technologies, intended application usages, etc. are many, and it = seems >> unlikely that a single protocol will function superiorly over this >> wide range of networking contexts. Thus a given protocol is likely to >> be well-suited for operation in those networks whose characteristics >> match well with the combination of mechanisms employed by the >> protocol. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D point 2 =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is >> important to be explicit about assumptions/conditions before talking >> about protocol. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D opinion =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> I agree with both points and approach to solve routing protocols, and >> would RECOMMEND either of the following: >> 1- MANET WG defines (in one informative-draft) intended application >> usage, and be explicit about applicable L2 network technologies. So >> that each future protocols mentions in their applicability statement >> section the usual use-case for such protocol, OR >> 2- MANET WG renews the I-D expired of Corson (1998) and adds more >> issues so it can become an RFC in future, >>=20 >> Thanking you, >> Abdussalam Baryun >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jun 8 08:20:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E18321F884A for ; Fri, 8 Jun 2012 08:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.517 X-Spam-Level: X-Spam-Status: No, score=-3.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Sn93Z6nox0AZ for ; Fri, 8 Jun 2012 08:20:08 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B57F521F8847 for ; Fri, 8 Jun 2012 08:20:05 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1196843vcq.31 for ; Fri, 08 Jun 2012 08:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2T12REUPZ4Rwee7P31qV2/WMaM8DIxtu5/XWbJBVRwc=; b=yuO1jELnGK7T5p7M3VJmHNBcgACwbrM3OOXqor4LB346a+obL/PDK+HHhX0IbNRzHx Wi3ozm5ROzyysfNUxYvzInUDdJNpCtFuPa/JdUfBNUi4wiPT/TBhU2P6cXZG9kPzPxl5 zqvsXPGpnGs3CcDt9iksYtPUlSDxfei+sz+QW2ysxBJj0z0+PFDlVsVAn5aDE4VEU1Fo T+bN4PmXOtYPepx2Yw1tw4uWrMhgK9OztzmrFPr4ozlsD551WR6r2OgQLVWOxnQvNSCt TlBPNYty5IjFBbMrcHkC0pSiVreWh8UlrFoH7VDxKzKTu8TGMpfELSX6y2R75PLmjgo9 BZEw== MIME-Version: 1.0 Received: by 10.220.140.193 with SMTP id j1mr6684677vcu.4.1339168804941; Fri, 08 Jun 2012 08:20:04 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 08:20:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jun 2012 17:20:04 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:20:09 -0000 Hi Henning, I may sometimes don't understand but it is not mandatory to know every procedure or process, I know I am new and need the help from a welcoming WG. We are in a community of Internet society and IETF contains volunteers, not in an organisation that request every one to follow management procedure. Please note that IETF procedures MAY be changed by the community requests, which is not like many other organisations. Regarding OLSRv2 I have not seen any mention that RFC3626 will be obsleted when the RFC of the OLSRv2 is published, the RFC3626 is an Experimental and OLSRv2 is a Standard. There is nothing in OLSRv2 draft mentioning that it obsletes the RFC3626, so I understand it is not updating the RFC document but it MAY update the protocol specification. However, it is good now I understand from you that you beleive that OLSRv2 updates the RFC3626, I hope every one beleives the same in WG, because I am not sure yet until the WG chair advises, Best Regards Abdussalam Baryun, On 6/8/12, Henning Rogge wrote: > On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > wrote: >> Hi Chris, >> >> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >> which make people think why? > > This sentence doesn't make sense. > > OLSRv2 IS the update of RFC 3626. > > Are you sure you understand how the IETF works to update existing > protocols? > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > From abdussalambaryun@gmail.com Fri Jun 8 08:33:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8234021F8569 for ; Fri, 8 Jun 2012 08:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 e9OeWdQli5k9 for ; Fri, 8 Jun 2012 08:33:43 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F139F21F8516 for ; Fri, 8 Jun 2012 08:33:38 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1208686vcq.31 for ; Fri, 08 Jun 2012 08:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xu5GkuYJAl8y7tjNq6D/oJtNFMwlUgb16412fSQsUDw=; b=oyXIoC2WnB+zMK1g/au0G+NK1NuRfZVTlAU5gWi4n6LJLxxnAf8Ud7wVFjZgkIhk/M YUCjkcFqkwpWyr3Z2wdk4bKKQh6cQ2KpTMD/RwxB9mKzpxOxoqeb3B4GAyhgtfaHT+Sk oi4iefr2jFuo4BD/BHO2n9EKexi5AXsPx/Z6uASqtaoKXvw9ImfiCOYqAfLJ6IyschKD SSsfkj8yQR1iKJ1IqCvL9ZIvw2c+WbWex84wg6YOLEaoj75SFG4A6QVKXZjnxqYtZpLC jepbw00//at50UYobD4499EVY06vaxln5qL9T0iJjWZ3bNzRk6Xa9vkKkwtjO+ZvjWjV iJOw== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr5744439vdi.86.1339169615537; Fri, 08 Jun 2012 08:33:35 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 08:33:35 -0700 (PDT) In-Reply-To: <7CC485E7-3973-485F-ADD0-107B0EAE6669@cisco.com> References: <7CC485E7-3973-485F-ADD0-107B0EAE6669@cisco.com> Date: Fri, 8 Jun 2012 17:33:35 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] MANET Protocol Applicability X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 15:33:44 -0000 Hi Stan, Please note that I needed to discuss this issue because it was not understood and left open by the chair at WG 82 meeting to be discussed at the list, which was not much discussed. I have noticed Mr.Perkins mention the word dangerous in 82 meeting, and now you mention it again. I need to know how kind or what type of dangerous you mean please define it and what will be result of the work proposed by Mr.Cole, Please see in lines comments: On 6/8/12, Stan Ratliff wrote: > It's been said by others on this mailing list, but I'll add my opinion in as > well: Any attempt to specifically define L2 technologies for MANET networks > is, IMO, misguided at best, dangerous at worst. > AB> traveling by airplane may be dangerous but still many people travel this way, driving a car may be dangerous but still most of people use it. Therefore, what kind of dangerous you are seeing that I can't see. > In my experiences, we have deployed mobile networks over a variety of L2 > technologies; that is *exactly* what the layered model (what you are > referring to as the abstraction) was intended to facilitate. The L1/L2 > characteristics of the networks I've worked on varies wildly - again, a > benefit of the layered approach. Part of the DLEP work is trying to find > ways for radios and routers to tell each other more information (thus, to > some extent, DLEP codifies a small subset of "layer violations", if you > will), but to do so in a manner that is applicable for all types of devices. > Hence, the generalized DLEP abstractions for "bandwidth" and "latency". > Do you admit now that DLEP is a L2 technology or you think it is not. I think we thought of the proposal of Mr.Cole only because of the new DLEP ideas and/or other R2RI ideas bring to MANET. > So this email can be registered as my vote as a Working Group member that > this (a) is a *really bad* idea, and (b) should not be accepted as a working > group item, if it is presented to the WG. > I thank you for your vote and opinion and really that is why I am writing my posts to see if it is worth it or not by the community feedback :), Please all WG give me your feedback before and then if I feel there is a need I will take my chances Best Regards Abdussalam ================================================== >> Hi Chris, >> >> I thank you for your comments. I agree with Teco. However, your >> comments look in one direction, but I want to see All directions if >> possible. Your comments see the protocol progress in ignoring L2 >> because abstract layer, which I admit I like and we still SHOULD do >> that now and in future because it gives better performance (the >> Designer-point-of-protocol). >> >> In the other direction is that the customer wants to know our >> assumption/conditions or L2 technologies that we use as >> possible-use-case or defined in the section of >> Protocol-Applicability-Statement, so s/he can know how to use it OR >> s/he can understand that the DESIGNER tested the condition or >> scenarios of using PROTOCOL over such technology (the >> customers-point-of-using-protocol). We have different users around the >> world with different network technologies in use. >> >> We have to admit that RFC3561 and RFC3626 were not general purpose >> enough to cover LLN issues which that is why we have a WG named ROLL >> (i.e. 4 years old) and that is why we have AODVv2 and OLSRv2. >> >> We SHOULD be more practical as Mr.Clausen mentioned in WG-77-meeting >> (i.e. his input regarding one protocol that only was tested by >> simulation scenarios), theories don't give right results. This was >> also spoted by Corson (1998), it seems that is why he written the >> draft, and that is why I think the importance of their both inputs. >> Please note that NOT mentioning some technology definitions in the >> applicability of protocol, doesn't mean that the protocol is really >> tested as a GENERAL purpuse protocol (e.g. OLSRv2, AODVv2). Our >> protocols are tested in some industry technology and are not in >> others. >> >> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >> which make people think why?, I want to define technologies at L2 >> because DLEP is important for my draft, and that for DSRv2 to be >> reasonable to users around the world, and to get feedback from time to >> time of their concerns so I can update some RFC in future (if I was >> successful : ), each 8 years or any reasonable requirement. >> >> Best Regards >> >> Abdussalam Baryun >> University of Glamorgan, UK >> ======================================================= >> < One may be wrong, or may be right, but it does not matter if we work >> together >> as a group to discuss and resolve all issues. IETF WGs are always right > >> **************************************************************************************** >> 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. The contents are comply >> to the IETF regulations, and WG procedures. You should not copy the >> email nor use it for any purpose other than IETF procedures purposes. >> **************************************************************************************** >> >> >> On 6/8/12, Dearlove, Christopher (UK) >> wrote: >>> Being explicit about L2 technologies is exactly what MANET should not do. >>> At >>> least not in any limiting way. Of course if someone were to write an >>> informative draft about (say) using OLSRv2 over IEEE 802.11 that would >>> be >>> fine. Though it would run the risk of suggesting to some that that is >>> the >>> only L2 suggested,, so I'd want the draft to make it clear that wasn't >>> so. >>> And anything that said OLSRv2 was intended for use over the following L2 >>> protocols would be completely wrong. The point of routing at L3 is to be >>> as >>> L2 independent as possible. >>> >>> If I've read the draft you mention it was a long time ago. Digging up >>> 1998 >>> drafts to reissue doesn't strike me as the most productive possible >>> exercise. >>> >>> -- >>> Christopher Dearlove >>> Senior Principal Engineer, Communications Group >>> Communications, Networks and Image Analysis Capability >>> BAE Systems Advanced Technology Centre >>> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >>> Tel: +44 1245 242194 | Fax: +44 1245 242124 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>> >>> 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>> Of >>> Abdussalam Baryun >>> Sent: 08 June 2012 04:42 >>> To: manet >>> Subject: [manet] MANET Protocol Applicability >>> >>> ----------------------! WARNING ! ---------------------- >>> This message originates from outside our organisation, >>> either from an external partner or from the internet. >>> Keep this in mind if you answer this message. >>> Follow the 'Report Suspicious Emails' link on IT matters >>> for instructions on reporting suspicious email messages. >>> -------------------------------------------------------- >>> >>> Hi Folks >>> >>> I have read two important inputs and want to share my opinion, >>> >>> ============ point 1 ============ >>> >>> In one work in progress ietf-draft (expired): >>> draft-ietf-manet-appl-00.txt, >>> Corson, (1998)mentioned in Abstract and Introduction: >>> >>> Abstract> The intent of this 'Applicability Section' is to >>> aid readers unfamiliar with the details of each protocol's design in >>> understanding the protocol's basic characteristics, functioning and >>> mechanisms, as well as to provide a general description of the >>> networking context for which the protocol was designed, and in which >>> it is expected to perform well. >>> >>> Introduction> The set of applications for which the use of MANET >>> technology envisioned is diverse, ranging from small, >>> energy-constrained nearly >>> static networks to large-scale, mobile, highly-dynamic networks. The >>> combinations of network size, topology composition and dynamics, >>> bandwidth and energy availability, physical and link-layer >>> technologies, intended application usages, etc. are many, and it seems >>> unlikely that a single protocol will function superiorly over this >>> wide range of networking contexts. Thus a given protocol is likely to >>> be well-suited for operation in those networks whose characteristics >>> match well with the combination of mechanisms employed by the >>> protocol. >>> ============ point 2 ============== >>> In the MANET WG 77 meeting minutes, Mr.Clausen mentioned that it is >>> important to be explicit about assumptions/conditions before talking >>> about protocol. >>> ============ opinion ============== >>> I agree with both points and approach to solve routing protocols, and >>> would RECOMMEND either of the following: >>> 1- MANET WG defines (in one informative-draft) intended application >>> usage, and be explicit about applicable L2 network technologies. So >>> that each future protocols mentions in their applicability statement >>> section the usual use-case for such protocol, OR >>> 2- MANET WG renews the I-D expired of Corson (1998) and adds more >>> issues so it can become an RFC in future, >>> >>> Thanking you, >>> Abdussalam Baryun >>> ========================= >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >>> >>> ******************************************************************** >>> 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. >>> ******************************************************************** >>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From abdussalambaryun@gmail.com Fri Jun 8 10:25:09 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5734721F84C8 for ; Fri, 8 Jun 2012 10:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 gDZRmCqlWFER for ; Fri, 8 Jun 2012 10:25:08 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F321F8475 for ; Fri, 8 Jun 2012 10:25:08 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1299875vcq.31 for ; Fri, 08 Jun 2012 10:25:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Kmzq3030xqr/+l3ZiAnSraIQHHYziLSfzGJKEkx/yF4=; b=bFcEG8nqQH3AEo+nY1hqVWt3F1Vqz0opPr0cnsr9ku994f+2xKlPliUmFf0nUTXG2x P4WlmoOGTaiNWq9/barIobiMY3poNYrcTDbSNKAPZW1rRGqZ8ScMJEiP47yaejOYe839 ah649nE7V9rUI7OUC+0mufrWjiweP9oaIe4CEZ7GHaTAiHYiaNl8wH0Fr3xJ6CJCB4oo u7JfLRf09b8gP+kUZWAV8HOON9iJ5ad9vG7LMf+NtTPAd0MziIHXtYBS+7zL75pksR1W 1lSQtT9VgAchTpJjGUCfOZbG5KIjOvssuRGeR+zIZ4OfHS7cxio9XaEbk0tSejJc0a/c /vzA== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr7024586vcw.55.1339176308176; Fri, 08 Jun 2012 10:25:08 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 10:25:08 -0700 (PDT) Date: Fri, 8 Jun 2012 19:25:08 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" , manet Subject: [manet] There is no document submitted so far to WG stating an update request for RFC3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:25:09 -0000 Hi Teco, > More precisely, we work on a replacement for the initial experimental > version. you mean that there is a work for replacement, I don't see any discussion befor about that, please advise, > RFC 3626 is not updated. It could get historic one day. > same what I thought, but one author of OLSRv2 mentioned that I may misunderstood the process of OLSRv2, even though the authors don't specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen other I-D when submitted for IESG they put inside the draft what the draft authors intention if they obslete another documents or if their new draft is updating any thing, OLSRv2 does not mention the process of update, which IMHO it should if authors want to update RFC3626, I may be wrong, but I hope the chair updates me with the status, may be he received a private request of update out of the discussion list, please advise, Regards AB +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/8/12, Teco Boot wrote: > > Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: > >> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >> wrote: >>> Hi Chris, >>> >>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>> which make people think why? >> >> This sentence doesn't make sense. >> >> OLSRv2 IS the update of RFC 3626. > More precisely, we work on a replacement for the initial experimental > version. > RFC 3626 is not updated. It could get historic one day. > > Teco > >> >> Are you sure you understand how the IETF works to update existing >> protocols? >> >> Henning Rogge >> >> -- >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From teco@inf-net.nl Fri Jun 8 11:13:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C4411E80B1 for ; Fri, 8 Jun 2012 11:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] 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 7VMCpIj5SKhe for ; Fri, 8 Jun 2012 11:13:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3361411E8072 for ; Fri, 8 Jun 2012 11:13:32 -0700 (PDT) Received: by werb13 with SMTP id b13so999648wer.31 for ; Fri, 08 Jun 2012 11:13:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=9bpoDDjhAYNTUvDLbuRDAkmnPd84iCGLgnPhLfvB5b8=; b=gYhKx1YT5cnxH63F2R2oMc8yp+hcaGRyjWt2CwaGo7zNO2wTLG9yjKcMvxUMFsMe5k q9YvWIG9RmMd3MFF9C9AZRu0jgbQGKse1rzUXTPBmyQtvcBidwA+fLYFhDE+LUzmMAej L3/8LRGkNseggVDfX8pFIYv+YVQy6U/jws9e+BjBpb/dW6EY6QXsFx0xEzBhqPMGEvHG 7yAGZgo0L6meZLPhb/lpW7mbYWm28uoMeSJ8Zh44noK7PA/uOjBrVC1d1nIAizZ0wfUK i6n/lnFmycP3b8h2vLcKT3jZUGEfEaYUu3M6J4Xky0AmuguFoEmQmtEQdPswlY1tVbzF /U5A== Received: by 10.216.198.1 with SMTP id u1mr1843262wen.92.1339179210587; Fri, 08 Jun 2012 11:13:30 -0700 (PDT) Received: from [10.24.184.74] ([84.241.196.213]) by mx.google.com with ESMTPS id fm1sm2679620wib.10.2012.06.08.11.13.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 11:13:29 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <834D8EEF-2AA0-453A-8666-CA3A675A7D3F@inf-net.nl> X-Mailer: iPhone Mail (9B206) From: Teco Boot Date: Fri, 8 Jun 2012 20:13:04 +0200 To: Abdussalam Baryun X-Gm-Message-State: ALoCoQkXUlOjbdPjEY07dI142n3pEtY9WeHWN8Zdc78Q4ySv1gCqL7UzwitkZeUGTAwl9exgdtnf Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] There is no document submitted so far to WG stating an update request for RFC3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:13:33 -0000 Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = het volgende geschreven: > Hi Teco, >=20 >> More precisely, we work on a replacement for the initial experimental >> version. >=20 > you mean that there is a work for replacement, I don't see any > discussion befor about that, please advise, I guess you can find it in the archives.=20 >=20 >> RFC 3626 is not updated. It could get historic one day. >>=20 >=20 > same what I thought, but one author of OLSRv2 mentioned that I may > misunderstood the process of OLSRv2, even though the authors don't > specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen > other I-D when submitted for IESG they put inside the draft what the > draft authors intention if they obslete another documents or if their > new draft is updating any thing, >=20 I have confidence in authors' knowledge on the proces. Dito for chairs.=20 > OLSRv2 does not mention the process of update, which IMHO it should if > authors want to update RFC3626, I believe they don't.=20 Same for workgroup.=20 >=20 > I may be wrong, but I hope the chair updates me with the status, may > be he received a private request of update out of the discussion list, > please advise, I guess you misunderstood him.=20 Enjoy your weekend.=20 Teco >=20 > Regards >=20 > AB > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 > On 6/8/12, Teco Boot wrote: >>=20 >> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: >>=20 >>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>> wrote: >>>> Hi Chris, >>>>=20 >>>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>>> which make people think why? >>>=20 >>> This sentence doesn't make sense. >>>=20 >>> OLSRv2 IS the update of RFC 3626. >> More precisely, we work on a replacement for the initial experimental >> version. >> RFC 3626 is not updated. It could get historic one day. >>=20 >> Teco >>=20 >>>=20 >>> Are you sure you understand how the IETF works to update existing >>> protocols? >>>=20 >>> Henning Rogge >>>=20 >>> -- >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 From sratliff@cisco.com Fri Jun 8 11:33:36 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5598A21F87E3 for ; Fri, 8 Jun 2012 11:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 G8r6jeL3LmiL for ; Fri, 8 Jun 2012 11:33:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 37E5321F87DE for ; Fri, 8 Jun 2012 11:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=13935; q=dns/txt; s=iport; t=1339180415; x=1340390015; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=kg4xWeyrQuVWp9MkRh3l2GB5J3wIbbD19gqpm5erkMg=; b=WdU0bZUXSaoPr8it7iUZHuDqlxXZb0RhPXVyzMhpIlGJnOmctwoX6Mk/ iTOFpJD+4yz5kNzt4WO1I5wmghZP2msq6z5/G1ULoryJjF6Ur/c+FdgCI JPwQmBm5sRQu2q11owpzr8ePTPE2xyeGGa850yVQ4xc7WI0b48/4aRcIh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAMRE0k+tJV2d/2dsb2JhbABFsjGCJoEHghgBAQEDAQEBAQ8BWwsQCxguIQYwBhMih1sDBgULmSSWCw2JSgSKRWGFIGADlR6KfoMXgWaCfA X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208,217";a="90809847" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 08 Jun 2012 18:33:34 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q58IXY74023148; Fri, 8 Jun 2012 18:33:34 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_AD24258B-361E-4513-AF84-4371B4752073" From: Stan Ratliff In-Reply-To: <834D8EEF-2AA0-453A-8666-CA3A675A7D3F@inf-net.nl> Date: Fri, 8 Jun 2012 14:33:33 -0400 Message-Id: References: <834D8EEF-2AA0-453A-8666-CA3A675A7D3F@inf-net.nl> To: Teco Boot X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , manet , Abdussalam Baryun Subject: Re: [manet] There is no document submitted so far to WG stating an update request for RFC3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:33:36 -0000 --Apple-Mail=_AD24258B-361E-4513-AF84-4371B4752073 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Abdussalam, The first paragraph of the "Introduction" section of OSLRv2 states:=20 "The Optimized Link State Routing protocol version 2 (OLSRv2) is the successor to OLSR (version 1) as published in [RFC3626]." As such, I'm assuming that no additional work to RFC 3626 is expressed = or implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all = intents and purposes, a new protocol documented by this new RFC.=20 Regards, Stan On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >=20 > Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = het volgende geschreven: >=20 >> Hi Teco, >>=20 >>> More precisely, we work on a replacement for the initial = experimental >>> version. >>=20 >> you mean that there is a work for replacement, I don't see any >> discussion befor about that, please advise, >=20 > I guess you can find it in the archives.=20 >=20 >>=20 >>> RFC 3626 is not updated. It could get historic one day. >>>=20 >>=20 >> same what I thought, but one author of OLSRv2 mentioned that I may >> misunderstood the process of OLSRv2, even though the authors don't >> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >> other I-D when submitted for IESG they put inside the draft what the >> draft authors intention if they obslete another documents or if their >> new draft is updating any thing, >>=20 > I have confidence in authors' knowledge on the proces. Dito for = chairs.=20 >=20 >=20 >> OLSRv2 does not mention the process of update, which IMHO it should = if >> authors want to update RFC3626, >=20 > I believe they don't.=20 > Same for workgroup.=20 >=20 >>=20 >> I may be wrong, but I hope the chair updates me with the status, may >> be he received a private request of update out of the discussion = list, >> please advise, >=20 > I guess you misunderstood him.=20 >=20 > Enjoy your weekend.=20 > Teco >=20 >>=20 >> Regards >>=20 >> AB >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>=20 >> On 6/8/12, Teco Boot wrote: >>>=20 >>> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende = geschreven: >>>=20 >>>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>>> wrote: >>>>> Hi Chris, >>>>>=20 >>>>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>>>> which make people think why? >>>>=20 >>>> This sentence doesn't make sense. >>>>=20 >>>> OLSRv2 IS the update of RFC 3626. >>> More precisely, we work on a replacement for the initial = experimental >>> version. >>> RFC 3626 is not updated. It could get historic one day. >>>=20 >>> Teco >>>=20 >>>>=20 >>>> Are you sure you understand how the IETF works to update existing >>>> protocols? >>>>=20 >>>> Henning Rogge >>>>=20 >>>> -- >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_AD24258B-361E-4513-AF84-4371B4752073 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
"The Optimized Link State Routing protocol version 2 (OLSRv2) = is the
successor to = OLSR (version 1) as published in = [RFC3626]."

Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = <abdussalambaryun@gmail.com&= gt; het volgende geschreven:

Hi = Teco,

More precisely, we work on a replacement for the initial = experimental
version.

you mean that = there is a work for replacement, I don't see = any
discussion befor about = that, please advise,

I guess you can find it in the = archives.


RFC 3626 is not updated. It = could get historic one day.


same what I = thought, but one author of OLSRv2 mentioned that I = may
misunderstood the process = of OLSRv2, even though the authors don't
specify what will happen to RFC3626 when OLSRv2 is an RFC. = I seen
other I-D when = submitted for IESG they put inside the draft what = the
draft authors intention if = they obslete another documents or if their
new draft is updating any = thing,

I have = confidence in authors' knowledge on the proces. Dito for chairs. =


OLSRv2 does not mention the = process of update, which IMHO it should if
authors want to update RFC3626,

I = believe they don't.
Same for workgroup.


I may be wrong, = but I hope the chair updates me with the status, = may
be he received a private = request of update out of the discussion = list,
please = advise,

I guess you misunderstood him.

Enjoy = your weekend.
Teco


Regards

AB
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<= br>

On 6/8/12, Teco Boot <teco@inf-net.nl> = wrote:

Op 8 jun. 2012, om 14:31 heeft = Henning Rogge het volgende = geschreven:

On = Fri, Jun 8, 2012 at 1:44 PM, Abdussalam = Baryun
<abdussalambaryun@gmail.com&= gt; wrote:
Hi = Chris,

Please note that MANET WG is = doing OLSRv2 without updating = RFC3626
which make people think = why?

This = sentence doesn't make = sense.

OLSRv2 = IS the update of RFC = 3626.
More precisely, we work on a = replacement for the initial = experimental
version.
RFC 3626 is not updated. It = could get historic one day.

Teco


Are = you sure you understand how the IETF works to update = existing
protocols?

Henning = Rogge

--
Steven = Hawkings about cosmic inflation: "An increase of billions = of
billions= of percent in a tiny fraction of a second. Of course, = that
was = before the present = government."
_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet


______________________________= _________________
manet mailing list
manet@ietf.org
https://www.ietf.org/= mailman/listinfo/manet

= --Apple-Mail=_AD24258B-361E-4513-AF84-4371B4752073-- From adrian@olddog.co.uk Fri Jun 8 12:57:39 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BDD11E80EF for ; Fri, 8 Jun 2012 12:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vZR5lkGpQe-Q for ; Fri, 8 Jun 2012 12:57:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id B776611E80B0 for ; Fri, 8 Jun 2012 12:57:26 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q58JvP4e024816 for ; Fri, 8 Jun 2012 20:57:25 +0100 Received: from 950129200 (ns-visitor-nsrp.juniper.net [208.223.208.242]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q58JvKYk024789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 8 Jun 2012 20:57:22 +0100 From: "Adrian Farrel" To: "'manet'" Date: Fri, 8 Jun 2012 20:57:18 +0100 Message-ID: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CD45B9.4C7BA3D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1FsOesZUVwhxvISFuDzvMTppSUlg== Content-Language: en-gb Subject: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:57:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001A_01CD45B9.4C7BA3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit PMFJI This thread has brought up a question that I need to ask as I review OLSRv2 which you have requested goes for publication. In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv1? There is a whole range of options, and what you choose depends largely on what future exposure you think OLSRv1 should have. You could: - Move RFC 3626 to Historic - Obsolete RFC 3626 with OLSRv2 - Leave RFC 3626 in place for further experimentation - Update RFC 3626 as a separate activity to advance the experiment What I don't think you are doing with OLSRv2 is Updating RFC 3626. Thanks, Adrian From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff Sent: 08 June 2012 19:34 To: Teco Boot Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun Subject: Re: [manet] There is no document submitted so far to WG stating an update request for RFC3626 Abdussalam, The first paragraph of the "Introduction" section of OSLRv2 states: "The Optimized Link State Routing protocol version 2 (OLSRv2) is the successor to OLSR (version 1) as published in [RFC3626]." As such, I'm assuming that no additional work to RFC 3626 is expressed or implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and purposes, a new protocol documented by this new RFC. Regards, Stan On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun het volgende geschreven: Hi Teco, More precisely, we work on a replacement for the initial experimental version. you mean that there is a work for replacement, I don't see any discussion befor about that, please advise, I guess you can find it in the archives. RFC 3626 is not updated. It could get historic one day. same what I thought, but one author of OLSRv2 mentioned that I may misunderstood the process of OLSRv2, even though the authors don't specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen other I-D when submitted for IESG they put inside the draft what the draft authors intention if they obslete another documents or if their new draft is updating any thing, I have confidence in authors' knowledge on the proces. Dito for chairs. OLSRv2 does not mention the process of update, which IMHO it should if authors want to update RFC3626, I believe they don't. Same for workgroup. I may be wrong, but I hope the chair updates me with the status, may be he received a private request of update out of the discussion list, please advise, I guess you misunderstood him. Enjoy your weekend. Teco Regards AB +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/8/12, Teco Boot wrote: Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun wrote: Hi Chris, Please note that MANET WG is doing OLSRv2 without updating RFC3626 which make people think why? This sentence doesn't make sense. OLSRv2 IS the update of RFC 3626. More precisely, we work on a replacement for the initial experimental version. RFC 3626 is not updated. It could get historic one day. Teco Are you sure you understand how the IETF works to update existing protocols? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ------=_NextPart_000_001A_01CD45B9.4C7BA3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

PMFJI

 

This thread has brought up a = question that I need to ask as I review OLSRv2 which you have requested = goes for publication.

 

In what way does the WG intend = OLSRv2 to replace/update/deprecate OSLRv1?

 

There is a whole range of = options, and what you choose depends largely on what future exposure you = think OLSRv1 should have. You could:

 

- Move RFC 3626 to = Historic

- Obsolete RFC 3626 with = OLSRv2

- Leave RFC 3626 in place for = further experimentation

- Update RFC 3626 as a = separate activity to advance the experiment

 

What I don't think you are = doing with OLSRv2 is Updating RFC 3626.

 

Thanks,

Adrian

 

From: = manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of = Stan Ratliff
Sent: 08 June 2012 19:34
To: Teco = Boot
Cc: Dearlove, Christopher (UK); manet; Abdussalam = Baryun
Subject: Re: [manet] There is no document submitted so = far to WG stating an update request for = RFC3626

 

Abdussalam,

 

The first paragraph = of the "Introduction" section of OSLRv2 = states: 

 

"The Optimized Link State Routing protocol version 2 (OLSRv2) is = the

successor to OLSR = (version 1) as published in [RFC3626]."





As such, I'm = assuming that no additional work to RFC 3626 is expressed or implied - = OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and = purposes, a new protocol documented by this new = RFC. 

 

Regards,

Stan

 

 

On Jun 8, 2012, at 2:13 PM, Teco Boot = wrote:




Op 8 jun. 2012 = om 19:25 heeft Abdussalam Baryun <abdussalambaryun@gmail.com= > het volgende geschreven:


Hi Teco,

 

More precisely, we work on a replacement for the initial = experimental

version.

 

you mean that there is a work for replacement, I don't see = any

discussion befor about that, please = advise,


I guess you can = find it in the archives.


 

RFC 3626 is not updated. It could get historic one = day.

 

 

same what I thought, but one author of OLSRv2 mentioned that I = may

misunderstood the process of OLSRv2, even though the authors = don't

specify what will happen to RFC3626 when OLSRv2 is an RFC. I = seen

other I-D when submitted for IESG they put inside the draft what = the

draft authors intention if they obslete another documents or if = their

new draft is updating any = thing,

 

I have confidence in authors' knowledge on the proces. Dito for = chairs.



OLSRv2 does not mention the process of update, which IMHO it = should if

authors want to update = RFC3626,


I believe they = don't.
Same for workgroup.


 

I may be wrong, but I hope the chair updates me with the status, = may

be he received a private request of update out of the discussion = list,

please advise,


I guess you misunderstood him.

Enjoy your weekend. =
Teco


 

Regards

 

AB

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<= /o:p>

 

On 6/8/12, Teco Boot <teco@inf-net.nl> = wrote:

 

Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende = geschreven:

 

On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam = Baryun

<abdussalambaryun@gmail.com= > = wrote:

Hi = Chris,

 

Please note that MANET WG is doing OLSRv2 without updating = RFC3626

which make people think = why?

 

This sentence doesn't make = sense.

 

OLSRv2 IS the update of RFC = 3626.

More precisely, we work on a replacement for the initial = experimental

version.

RFC 3626 is not updated. It could get historic one = day.

 

Teco

 

 

Are you sure you understand how the IETF works to update = existing

protocols?

 

Henning = Rogge

 

--

Steven Hawkings about cosmic inflation: "An increase of = billions = of

billions of percent in a tiny fraction of a second. Of course, = that

was before the present = government."

_______________________________________________=

manet mailing = list

manet@ietf.org

https://www.ietf.org= /mailman/listinfo/manet

 

 

_______________________________________________
manet mailing = list
manet@ietf.org
https://www.ietf.org= /mailman/listinfo/manet

 

------=_NextPart_000_001A_01CD45B9.4C7BA3D0-- From sratliff@cisco.com Fri Jun 8 13:34:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609C411E816B for ; Fri, 8 Jun 2012 13:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TmD33Ik2fgqg for ; Fri, 8 Jun 2012 13:34:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DB76211E8165 for ; Fri, 8 Jun 2012 13:34:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=45860; q=dns/txt; s=iport; t=1339187667; x=1340397267; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=aRhACw6uu9REKFkp1HbobeblC3CpFusSkequJaqMPl0=; b=LpYLjFKjgLWNrCBEA0FYLFzSQezRrJDbTvg9aBIggR0lVbglWvJA2zFo 9KuLDcMdx2xobWt03F4bOofuZrUvR4xnh4zR52RiF/WrJ97Fzcymra+Kq Qys5eycZnGlctt9xDb21MQN/WpnL86EEPexXbiBrp688uYnN2+2TfhW5d I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicNAJ9g0k+tJXG9/2dsb2JhbABFgXhNshKBB4IYAQEBAwEBAQEPAVsLBQsLEQQBAQEgAQYHIQYfCQgZIodbAwYFC5kVlgYNiUoEikVhhSBgA5Uein6DF4Fmgnw X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208,217";a="90863484" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jun 2012 20:34:26 +0000 Received: from rtp-sratliff-8716.cisco.com (rtp-sratliff-8716.cisco.com [10.116.179.215]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q58KYOkH025235; Fri, 8 Jun 2012 20:34:24 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_34132A6A-8615-4921-B8E2-9EFA908A5D6E" From: Stan Ratliff In-Reply-To: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> Date: Fri, 8 Jun 2012 16:34:24 -0400 Message-Id: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> To: adrian@olddog.co.uk X-Mailer: Apple Mail (2.1278) Cc: 'manet' Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:34:28 -0000 --Apple-Mail=_34132A6A-8615-4921-B8E2-9EFA908A5D6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Adrian,=20 In that case, my vote as a WG member would be to obsolete RFC 3626. Other WG members? Please jump in.=20 Regards, Stan On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: > PMFJI > =20 > This thread has brought up a question that I need to ask as I review = OLSRv2 which you have requested goes for publication. > =20 > In what way does the WG intend OLSRv2 to replace/update/deprecate = OSLRv1? > =20 > There is a whole range of options, and what you choose depends largely = on what future exposure you think OLSRv1 should have. You could: > =20 > - Move RFC 3626 to Historic > - Obsolete RFC 3626 with OLSRv2 > - Leave RFC 3626 in place for further experimentation > - Update RFC 3626 as a separate activity to advance the experiment > =20 > What I don't think you are doing with OLSRv2 is Updating RFC 3626. > =20 > Thanks, > Adrian > =20 > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Stan Ratliff > Sent: 08 June 2012 19:34 > To: Teco Boot > Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun > Subject: Re: [manet] There is no document submitted so far to WG = stating an update request for RFC3626 > =20 > Abdussalam, > =20 > The first paragraph of the "Introduction" section of OSLRv2 states:=20 > =20 > "The Optimized Link State Routing protocol version 2 (OLSRv2) is the > successor to OLSR (version 1) as published in [RFC3626]." >=20 >=20 >=20 >=20 > As such, I'm assuming that no additional work to RFC 3626 is expressed = or implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all = intents and purposes, a new protocol documented by this new RFC.=20 > =20 > Regards, > Stan > =20 > =20 > On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >=20 >=20 >=20 > Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = het volgende geschreven: >=20 >=20 > Hi Teco, > =20 > More precisely, we work on a replacement for the initial experimental > version. > =20 > you mean that there is a work for replacement, I don't see any > discussion befor about that, please advise, >=20 > I guess you can find it in the archives.=20 >=20 >=20 > =20 > RFC 3626 is not updated. It could get historic one day. > =20 > =20 > same what I thought, but one author of OLSRv2 mentioned that I may > misunderstood the process of OLSRv2, even though the authors don't > specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen > other I-D when submitted for IESG they put inside the draft what the > draft authors intention if they obslete another documents or if their > new draft is updating any thing, > =20 > I have confidence in authors' knowledge on the proces. Dito for = chairs.=20 >=20 >=20 >=20 > OLSRv2 does not mention the process of update, which IMHO it should if > authors want to update RFC3626, >=20 > I believe they don't.=20 > Same for workgroup.=20 >=20 >=20 > =20 > I may be wrong, but I hope the chair updates me with the status, may > be he received a private request of update out of the discussion list, > please advise, >=20 > I guess you misunderstood him.=20 >=20 > Enjoy your weekend.=20 > Teco >=20 >=20 > =20 > Regards > =20 > AB > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > =20 > On 6/8/12, Teco Boot wrote: > =20 > Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: > =20 > On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > wrote: > Hi Chris, > =20 > Please note that MANET WG is doing OLSRv2 without updating RFC3626 > which make people think why? > =20 > This sentence doesn't make sense. > =20 > OLSRv2 IS the update of RFC 3626. > More precisely, we work on a replacement for the initial experimental > version. > RFC 3626 is not updated. It could get historic one day. > =20 > Teco > =20 > =20 > Are you sure you understand how the IETF works to update existing > protocols? > =20 > Henning Rogge > =20 > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > =20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_34132A6A-8615-4921-B8E2-9EFA908A5D6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Adrian, 

In that case, my = vote as a WG member would be to obsolete RFC = 3626.

Other WG members? Please jump = in. 

Regards,
Stan

<= div>
On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote:

This = thread has brought up a question that I need to ask as I review OLSRv2 = which you have requested goes for = publication.
In = what way does the WG intend OLSRv2 to replace/update/deprecate = OSLRv1?
There = is a whole range of options, and what you choose depends largely on what = future exposure you think OLSRv1 should have. You = could:
- = Move RFC 3626 to Historic
- Obsolete RFC 3626 with = OLSRv2
- = Leave RFC 3626 in place for further = experimentation
- = Update RFC 3626 as a separate activity to advance the = experiment
What = I don't think you are doing with OLSRv2 is Updating RFC = 3626.
 manet-bounces@ietf.org [mailto:manet-bounces@ietf.or= g] On Behalf = Of Stan = Ratliff
Sent: 08 June 2012 = 19:34
To: Teco= Boot
Cc: Dearlove, Christopher (UK); = manet; Abdussalam Baryun
Subject: Re: [manet] There is no = document submitted so far to WG stating an update request for = RFC3626
 
The first paragraph of the "Introduction" section = of OSLRv2 states: 
 
"The Optimized Link State Routing = protocol version 2 (OLSRv2) is = the
successor to OLSR (version 1) as = published in = [RFC3626]."
As such, I'm assuming that no additional work to = RFC 3626 is expressed or implied - OLSRv1 is documented in RFC 3626; = OLSRv2 is, for all intents and purposes, a new protocol documented by = this new RFC. 
 
Regards,
Stan
On Jun = 8, 2012, at 2:13 PM, Teco Boot wrote:



Op 8 jun. 2012 om 19:25 heeft Abdussalam = Baryun <abdussalambaryun@gmail.com> = het volgende geschreven:


Hi Teco,
More = precisely, we work on a replacement for the initial = experimental
you mean = that there is a work for replacement, I don't see = any
discussion befor about = that, please advise,

I guess you can find it in the archives. 


 
RFC 3626 = is not updated. It could get historic one = day.
same = what I thought, but one author of OLSRv2 mentioned that I = may
misunderstood the process = of OLSRv2, even though the authors = don't
specify what will happen = to RFC3626 when OLSRv2 is an RFC. I = seen
other I-D when submitted = for IESG they put inside the draft what = the
draft authors intention = if they obslete another documents or if = their
new draft is updating any = thing,
I have confidence in authors' knowledge on the = proces. Dito for chairs. 



OLSRv2 does not mention the process of = update, which IMHO it should if
authors = want to update RFC3626,

I believe they don't. 
Same for = workgroup. 


 
I may be = wrong, but I hope the chair updates me with the status, = may
be he received a private = request of update out of the discussion = list,
please = advise,

I = guess you misunderstood him. 

Enjoy your = weekend. 
Teco


On = 6/8/12, Teco Boot <teco@inf-net.nl> = wrote:
Op 8 = jun. 2012, om 14:31 heeft Henning Rogge het volgende = geschreven:
On Fri, = Jun 8, 2012 at 1:44 PM, Abdussalam = Baryun
Hi = Chris,
Please note that MANET WG is doing OLSRv2 without = updating = RFC3626
which make people think = why?
This sentence doesn't make = sense.
OLSRv2 IS the update of RFC = 3626.
More = precisely, we work on a replacement for the initial = experimental
RFC 3626 = is not updated. It could get historic one = day.
Are you sure you understand how the IETF works to = update = existing
Henning = Rogge
Steven = Hawkings about cosmic inflation: "An increase of billions = of
billions = of percent in a tiny fraction of a second. Of course, = that
was = before the present = government."
manet = mailing = list
manet@ietf.org
manet@ietf.org
> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the > successor to OLSR (version 1) as published in [RFC3626]." > > > > > As such, I'm assuming that no additional work to RFC 3626 is expressed or > implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents an= d > purposes, a new protocol documented by this new RFC. > > Regards, > Stan > > > On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: > > > > Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun > het volgende geschreven: > > > Hi Teco, > > > > More precisely, we work on a replacement for the initial experimental > > version. > > > > you mean that there is a work for replacement, I don't see any > > discussion befor about that, please advise, > > > I guess you can find it in the archives. > > > > > RFC 3626 is not updated. It could get historic one day. > > > > > > same what I thought, but one author of OLSRv2 mentioned that I may > > misunderstood the process of OLSRv2, even though the authors don't > > specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen > > other I-D when submitted for IESG they put inside the draft what the > > draft authors intention if they obslete another documents or if their > > new draft is updating any thing, > > > > I have confidence in authors' knowledge on the proces. Dito for chairs. > > > > OLSRv2 does not mention the process of update, which IMHO it should if > > authors want to update RFC3626, > > > I believe they don't. > Same for workgroup. > > > > > I may be wrong, but I hope the chair updates me with the status, may > > be he received a private request of update out of the discussion list, > > please advise, > > > I guess you misunderstood him. > > Enjoy your weekend. > Teco > > > > > Regards > > > > AB > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > > On 6/8/12, Teco Boot wrote: > > > > Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: > > > > On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > > wrote: > > Hi Chris, > > > > Please note that MANET WG is doing OLSRv2 without updating RFC3626 > > which make people think why? > > > > This sentence doesn't make sense. > > > > OLSRv2 IS the update of RFC 3626. > > More precisely, we work on a replacement for the initial experimental > > version. > > RFC 3626 is not updated. It could get historic one day. > > > > Teco > > > > > > Are you sure you understand how the IETF works to update existing > > protocols? > > > > Henning Rogge > > > > -- > > Steven Hawkings about cosmic inflation: "An increase of billions of > > billions of percent in a tiny fraction of a second. Of course, that > > was before the present government." > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --=20 Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From ietf@thomasclausen.org Fri Jun 8 14:21:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CFA21F8627 for ; Fri, 8 Jun 2012 14:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] 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 xaEqgv8UtC1z for ; Fri, 8 Jun 2012 14:21:34 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A0C3E21F85AF for ; Fri, 8 Jun 2012 14:21:34 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 307FC55811C for ; Fri, 8 Jun 2012 14:21:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AF0D11C0056; Fri, 8 Jun 2012 14:21:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.250] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 0ADB01C049C; Fri, 8 Jun 2012 14:21:28 -0700 (PDT) References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 8 Jun 2012 23:21:28 +0200 To: Henning Rogge Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:21:35 -0000 On 8 Jun 2012, at 23:05, Henning Rogge wrote: > Obsoleting RFC 3626 would make sense. >=20 > There will be quite a few deployments with OLSR (v1) for a long time, > but OLSRv2 (because of RFC 5444) is a much better base for > experiments. The existence of "quite a few deployments with OLSR (v1)" is, to me, a very g= ood reason for not obsoleting OLSRv1 with the publication of OLSRv2 - I woul= d be very much against that, especially as OLSRv2 isn't "broken" per se. I would vote for "Leave RFC 3626 in place for further experimentation", for t= he time being; eventually, it may make sense to mark it as "Historic", but I= do not think that we are there yet. [We've got a proud history of co-existence when protocol versions are still i= n use: OPSFv2/OSPFv3; IPv4/IPv6, ....] Best, Thomas > Henning Rogge >=20 > On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff wrote: >> Adrian, >>=20 >> In that case, my vote as a WG member would be to obsolete RFC 3626. >>=20 >> Other WG members? Please jump in. >>=20 >> Regards, >> Stan >>=20 >> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >>=20 >> PMFJI >>=20 >> This thread has brought up a question that I need to ask as I review OLSR= v2 >> which you have requested goes for publication. >>=20 >> In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv1?= >>=20 >> There is a whole range of options, and what you choose depends largely on= >> what future exposure you think OLSRv1 should have. You could: >>=20 >> - Move RFC 3626 to Historic >> - Obsolete RFC 3626 with OLSRv2 >> - Leave RFC 3626 in place for further experimentation >> - Update RFC 3626 as a separate activity to advance the experiment >>=20 >> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >>=20 >> Thanks, >> Adrian >>=20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >> Of Stan Ratliff >> Sent: 08 June 2012 19:34 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >> Subject: Re: [manet] There is no document submitted so far to WG stating a= n >> update request for RFC3626 >>=20 >> Abdussalam, >>=20 >> The first paragraph of the "Introduction" section of OSLRv2 states: >>=20 >> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the >> successor to OLSR (version 1) as published in [RFC3626]." >>=20 >>=20 >>=20 >>=20 >> As such, I'm assuming that no additional work to RFC 3626 is expressed or= >> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents an= d >> purposes, a new protocol documented by this new RFC. >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >>=20 >>=20 >>=20 >> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun >> het volgende geschreven: >>=20 >>=20 >> Hi Teco, >>=20 >>=20 >>=20 >> More precisely, we work on a replacement for the initial experimental >>=20 >> version. >>=20 >>=20 >>=20 >> you mean that there is a work for replacement, I don't see any >>=20 >> discussion befor about that, please advise, >>=20 >>=20 >> I guess you can find it in the archives. >>=20 >>=20 >>=20 >>=20 >> RFC 3626 is not updated. It could get historic one day. >>=20 >>=20 >>=20 >>=20 >>=20 >> same what I thought, but one author of OLSRv2 mentioned that I may >>=20 >> misunderstood the process of OLSRv2, even though the authors don't >>=20 >> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >>=20 >> other I-D when submitted for IESG they put inside the draft what the >>=20 >> draft authors intention if they obslete another documents or if their >>=20 >> new draft is updating any thing, >>=20 >>=20 >>=20 >> I have confidence in authors' knowledge on the proces. Dito for chairs. >>=20 >>=20 >>=20 >> OLSRv2 does not mention the process of update, which IMHO it should if >>=20 >> authors want to update RFC3626, >>=20 >>=20 >> I believe they don't. >> Same for workgroup. >>=20 >>=20 >>=20 >>=20 >> I may be wrong, but I hope the chair updates me with the status, may >>=20 >> be he received a private request of update out of the discussion list, >>=20 >> please advise, >>=20 >>=20 >> I guess you misunderstood him. >>=20 >> Enjoy your weekend. >> Teco >>=20 >>=20 >>=20 >>=20 >> Regards >>=20 >>=20 >>=20 >> AB >>=20 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>=20 >>=20 >>=20 >> On 6/8/12, Teco Boot wrote: >>=20 >>=20 >>=20 >> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: >>=20 >>=20 >>=20 >> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>=20 >> wrote: >>=20 >> Hi Chris, >>=20 >>=20 >>=20 >> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>=20 >> which make people think why? >>=20 >>=20 >>=20 >> This sentence doesn't make sense. >>=20 >>=20 >>=20 >> OLSRv2 IS the update of RFC 3626. >>=20 >> More precisely, we work on a replacement for the initial experimental >>=20 >> version. >>=20 >> RFC 3626 is not updated. It could get historic one day. >>=20 >>=20 >>=20 >> Teco >>=20 >>=20 >>=20 >>=20 >>=20 >> Are you sure you understand how the IETF works to update existing >>=20 >> protocols? >>=20 >>=20 >>=20 >> Henning Rogge >>=20 >>=20 >>=20 >> -- >>=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >>=20 >> billions of percent in a tiny fraction of a second. Of course, that >>=20 >> was before the present government." >>=20 >> _______________________________________________ >>=20 >> manet mailing list >>=20 >> manet@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Fri Jun 8 14:32:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780E211E8142 for ; Fri, 8 Jun 2012 14:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 3KjyvcuLgS3w for ; Fri, 8 Jun 2012 14:32:32 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9EFF11E813C for ; Fri, 8 Jun 2012 14:32:31 -0700 (PDT) Received: by yenq13 with SMTP id q13so1899319yen.31 for ; Fri, 08 Jun 2012 14:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BVmenjWmHQsteKQPsalwOe3/ks7lbELVRpqUZCdS25c=; b=rDBtbZ1lvyXU0X0kLenwBY2IFNLS30b8caBGXY8ACIlD7NwjoNFcQo33loRlZchwbV Oelh/Dk1zQQ+Drdmn29vombK2a/nXJuerwMnUrK7peipht/Bly7D0Po8QJy12PPDgzxe 8Z59f/vj1EpcctBs1n8OE7Jpuu5UpD+h+7EaM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BVmenjWmHQsteKQPsalwOe3/ks7lbELVRpqUZCdS25c=; b=KinBTFhD0VwXRfv038PS7vpgAn5ufb/Oxu3jvPBA38wZKzSoyFhy/mMueu39/dC4cK SNZmahjBz42TOa3S15bxDQr2EbQ+TwUpyV1uDnXaqADuY85fuppRU1BBjLRo1x6pKMC8 83l6MbeskNiTVS1ZWRh+CGd+XDRIaPNpxeRxfnX7v8RF/7Qq6t8qeGj9f3vlc8TuXPla n1BRRSjV/BQr/+lyXOyA34lP3kXixNBjhM4Wj606QfK9ayFUfMO8qaNcKaZ4wemMIiP5 MxQIGz7iRAQs6L9eotOc98aDKLs+eiyw7smMwOJKxGCgUD4wZxF/4nS+1CE8pxkqoOG9 iQYA== MIME-Version: 1.0 Received: by 10.236.165.74 with SMTP id d50mr9290372yhl.48.1339191151481; Fri, 08 Jun 2012 14:32:31 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Fri, 8 Jun 2012 14:32:31 -0700 (PDT) In-Reply-To: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> Date: Fri, 8 Jun 2012 14:32:31 -0700 Message-ID: From: Ulrich Herberg To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnGve9SHV/DIUsztVbmgCvpU4a0QeDhjL5I//Mvmu8PEq5Nehw0Y2kDZIfM1mYfOZJFmWt6 Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 21:32:32 -0000 On Fri, Jun 8, 2012 at 2:21 PM, Thomas Heide Clausen wrote: > The existence of "quite a few deployments with OLSR (v1)" is, to me, a very good reason for not obsoleting OLSRv1 with the publication of OLSRv2 - I would be very much against that, especially as OLSRv2 isn't "broken" per se. > > I would vote for "Leave RFC 3626 in place for further experimentation", for the time being; eventually, it may make sense to mark it as "Historic", but I do not think that we are there yet. +1 Ulrich From abdussalambaryun@gmail.com Fri Jun 8 23:11:18 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4447A21F8547 for ; Fri, 8 Jun 2012 23:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.521 X-Spam-Level: X-Spam-Status: No, score=-3.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iccy4V-S4qHP for ; Fri, 8 Jun 2012 23:11:17 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 48C4121F8542 for ; Fri, 8 Jun 2012 23:11:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1676045vbb.31 for ; Fri, 08 Jun 2012 23:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=RRCxtgltK9XhX2Rp9+efhKjRuHJd+gjNscEaXJ7cSrs=; b=pSD23RxolKLxhvKQcFQXKxvlv4pWaIP5jiQFcOTQE9uqFIs6ysPk+aioJuyB/wpzOo 782UtVFU49cCKJg/FEdrdicaMDtZZVchE32sGSU7eT0Mc2AZGU4bxpddV0GKBzj8Oyor tG/mQZpipFKga4kttEdnQvNx26jbIZXh/78C117waJbznn+CssalHGpvSuqQWK2A8Hqh Q53QY4Ve1WoziFq9raRCVkrr7g/gUip4TqLmfmz/yxREdP6jvCYWearNYtZEgJnkwNo+ jfS7XEYQlEvquk5lCOTw0NOlKtbjgImeosifxRBy0heAjk323RoDvAtVuNBnpZ88YbvF Wa5g== MIME-Version: 1.0 Received: by 10.220.140.193 with SMTP id j1mr8431744vcu.4.1339222276676; Fri, 08 Jun 2012 23:11:16 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 23:11:16 -0700 (PDT) Date: Sat, 9 Jun 2012 08:11:16 +0200 Message-ID: From: Abdussalam Baryun To: adrian@olddog.co.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: "jpmacker@gmail.com" , manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 06:11:18 -0000 Hi Adrian, I understood that there was no replace/update/obsolete, but some author thought that I didn't know the system/process, I hope that Chairs and author get to know the system, Comments in Line: >There is a whole range of options, and what you choose depends largely on what >future exposure you think OLSRv1 should have. You could: - Move RFC 3626 to Historic - Obsolete RFC 3626 with OLSRv2 - Leave RFC 3626 in place for further experimentation - Update RFC 3626 as a separate activity to advance the experiment >What I don't think you are doing with OLSRv2 is Updating RFC 3626. If WG undertaking one of options excluding the third, I think a document needs to be produced and submitted to the WG, IMHO we cannot do such thing until the submission is announced, and consesus collected. It has not been announce yet, Best Wishes, Abdussalam Baryun Univeristy of Glamorgan, UK. Regarding the From abdussalambaryun@gmail.com Fri Jun 8 23:16:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4442F21F884B for ; Fri, 8 Jun 2012 23:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 wLfF8oxJDfuD for ; Fri, 8 Jun 2012 23:16:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 865CA21F8879 for ; Fri, 8 Jun 2012 23:16:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1677042vbb.31 for ; Fri, 08 Jun 2012 23:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=0C0pnE0RELgiISf4caqy9GjCoYfFBfNkH+V9k+jeRf0=; b=DRrRL8LKo/yT7o/fKPhsWRWpox2McTZ1dC4RK3AXyaPWVfPNkSWVQQoGIphhAMU/qE mFzhoZqjc/cWCnU2KJ6YUTstEUTMXU7NecCK+WQ1NwttmF77HcZo2uN/SMxi446d8kUz NdupWO8zPKWv1hAlAKnrfvCe66T1IsvG4d1CfkrR9cbqyxwKjOqemrgdik/mdFVvpJFB PDfz6gZ2jywFl9tlbwcRPb76k7Mw0K415jzNhWXBbmE9oCUKMRiLcA8BGTHEHW8TrWZ3 fqunwG5xK5YDn6HXPyuq7MtL7q7lT8O5eAQQtuP3+9OFxxpQJ1yk1Dlpg5PU1XhwAGxt fq3g== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr7313675vdb.10.1339222568478; Fri, 08 Jun 2012 23:16:08 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Fri, 8 Jun 2012 23:16:08 -0700 (PDT) Date: Sat, 9 Jun 2012 08:16:08 +0200 Message-ID: From: Abdussalam Baryun To: ietf@thomasclausen.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 06:16:11 -0000 +1 with Thomas, also we should also define network technologies to know how to use OLSRv1 and OLSRv2, which I RECOMMEND to make a draft for definition L2 technology, AB ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 8 Jun 2012, at 23:05, Henning Rogge wrote: > Obsoleting RFC 3626 would make sense. > > There will be quite a few deployments with OLSR (v1) for a long time, > but OLSRv2 (because of RFC 5444) is a much better base for > experiments. The existence of "quite a few deployments with OLSR (v1)" is, to me, a very good reason for not obsoleting OLSRv1 with the publication of OLSRv2 - I would be very much against that, especially as OLSRv2 isn't "broken" per se. I would vote for "Leave RFC 3626 in place for further experimentation", for the time being; eventually, it may make sense to mark it as "Historic", but I do not think that we are there yet. [We've got a proud history of co-existence when protocol versions are still in use: OPSFv2/OSPFv3; IPv4/IPv6, ....] Best, Thomas > Henning Rogge > > On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff wrote: >> Adrian, >> >> In that case, my vote as a WG member would be to obsolete RFC 3626. >> >> Other WG members? Please jump in. >> >> Regards, >> Stan >> >> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >> >> PMFJI >> >> This thread has brought up a question that I need to ask as I review OLSRv2 >> which you have requested goes for publication. >> >> In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv1? >> >> There is a whole range of options, and what you choose depends largely on >> what future exposure you think OLSRv1 should have. You could: >> >> - Move RFC 3626 to Historic >> - Obsolete RFC 3626 with OLSRv2 >> - Leave RFC 3626 in place for further experimentation >> - Update RFC 3626 as a separate activity to advance the experiment >> >> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >> >> Thanks, >> Adrian >> >> From: manet-bounces at ietf.org [mailto:manet-bounces at ietf.org] On Behalf >> Of Stan Ratliff >> Sent: 08 June 2012 19:34 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >> Subject: Re: [manet] There is no document submitted so far to WG stating an >> update request for RFC3626 >> >> Abdussalam, >> >> The first paragraph of the "Introduction" section of OSLRv2 states: >> >> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the >> successor to OLSR (version 1) as published in [RFC3626]." >> >> >> >> >> As such, I'm assuming that no additional work to RFC 3626 is expressed or >> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and >> purposes, a new protocol documented by this new RFC. >> >> Regards, >> Stan >> >> >> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >> >> >> >> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun >> het volgende geschreven: >> >> >> Hi Teco, >> >> >> >> More precisely, we work on a replacement for the initial experimental >> >> version. >> >> >> >> you mean that there is a work for replacement, I don't see any >> >> discussion befor about that, please advise, >> >> >> I guess you can find it in the archives. >> >> >> >> >> RFC 3626 is not updated. It could get historic one day. >> >> >> >> >> >> same what I thought, but one author of OLSRv2 mentioned that I may >> >> misunderstood the process of OLSRv2, even though the authors don't >> >> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >> >> other I-D when submitted for IESG they put inside the draft what the >> >> draft authors intention if they obslete another documents or if their >> >> new draft is updating any thing, >> >> >> >> I have confidence in authors' knowledge on the proces. Dito for chairs. >> >> >> >> OLSRv2 does not mention the process of update, which IMHO it should if >> >> authors want to update RFC3626, >> >> >> I believe they don't. >> Same for workgroup. >> >> >> >> >> I may be wrong, but I hope the chair updates me with the status, may >> >> be he received a private request of update out of the discussion list, >> >> please advise, >> >> >> I guess you misunderstood him. >> >> Enjoy your weekend. >> Teco >> >> >> >> >> Regards >> >> >> >> AB >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> From abdussalambaryun@gmail.com Sat Jun 9 01:27:44 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046BD21F89E5 for ; Sat, 9 Jun 2012 01:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 ztaCoTqg1FBq for ; Sat, 9 Jun 2012 01:27:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41A8021F89E2 for ; Sat, 9 Jun 2012 01:27:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1709030vbb.31 for ; Sat, 09 Jun 2012 01:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=hhflRDO7cVNJlUZjlWo/JnqrxY9trbjNN8qefSSMfHo=; b=Trecmkd4i2Tb7dGVt1s+rKrquAXk0Gqt2w/mrKiWTsgp2SQc91YmmbfTZgGG3CHgRu 55qDsWy/f386j394fnnwsqCVfcvSovLPmIYhEYXOGSY8OmIMP7qUz6OxGF9NAxqQu/HQ OOcq4+VKZQrgG4qsxsGFVp/FQpWzi+FIfGSg+k7c3+BbHwwOlMBSUZNdamVdNWMew4dV Y3i7YKHTtS2oxcPMHdwpOU53kjkozMwyjkfg8+lweiyp0yj/ScTL+0B4+d7GgB8BoVkB kZgLLMj2r6TSphth+OlCkbyuLK3rDb8CvgHKR4osV2fCCMi0SUXa6RGVx+4DgsMUkLVS Kbtw== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr7315705vdb.103.1339230459472; Sat, 09 Jun 2012 01:27:39 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 9 Jun 2012 01:27:39 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 10:27:39 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:27:44 -0000 Hi Folks, As mentioned before some reasons for starting defining a) MANET use-cases and b) the L2 technologies used by MANET WG or MANET-protocols. However, I will now try to be explicit, so my proposal below is in two parts one to mention the reason of the I-D, and the other part to mention the I-D content conditions of the draft, ==================== Part One ========================== Firstly, in the proposed draft it *will not* discuss IP-Models nor L3 models of MANET [this will be done by I-D authored by Emmanuel, and Perkins (2012)]. The proposed draft will be focused on L2 technologies that MAY provide services to upper layer of MANET (i.e. L3 or above),including productive discussion and research papers. Secondly, in the proposed draft it *will* define MANET assumptions and conditions at L2 ,and discussed in the draft document for each L2 MANET protocol. Thirdly, optionally (i.e. we can take out) the proposed draft MAY mention (i.e. not define but mention as examples) a possible L1 technology used by such L2 protocol only as input to drive the reasons of L2-conditions and L2-assumptions but NOT to define L1, nor to define L1 wireless-conditions of MANET. ===================== Part two ======================== So to be progressing I mention the main reasons of the subject title also as follows: 1- The presentation concerns of Robert Cole in the MANET WG 82 meeting, with the discussion of Teco and input of Mrs.Sue (mentioning a paper in MILCOM 07 or 08). 2- The apearance of DLEP accepted by the MANET WG as a I-D for the WG, which this DLEP protocol is a Layer 2 (L2) technology serving routers. The additional optional reasons that WG may ignore : 1- There MAY be intention of internet-community and users around the world to use RFC3561 and RFC3626 in some cases, and in addition the use also of AODVv2 and OLSRv2 in other cases. Specifically, they need to know the applicability of using such general purpose protocol, because thoes RFCs may not mentioned the full use-case (they are general purpose). 2- There are misunderstanding in the community of MANET protocols use-cases, which MAY cause of; creating new WGs like ROLL and 6LoWPAN, and closing the Ad-hoc Autoconfig WG. A definition will probably stop this misunderstanding and stop creating new WGs that separate from MANET WG and that take L2 technologies but they still use MANET protocols (e.g. ROLL are using AODV, and OLSR ideas). 3- I am writing an I-D for DSRv2 which I am already defining the technologies used by DSRv2, ===================================================== Please note this thread is in the purpose to get feedback of interests or objections so that the author of the proposed draft know if he will continue making effort or he should leave it for the future need/interest. Best Regards Abdussalam Baryun University of Glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/8/12, Abdussalam Baryun wrote: > Hi Folks, > > I am starting defining MANET technology used, which I see many > interests in and a need for. This need was mentioned in 82-meeting and > in the Discussion Linst. I just wanted to announce *interests* and > that it will be a separate Information track, but if the WG wants it > other we can discuss that. > > There was some oppose to the idea of all/any drafts including > definition, so I decided to make a first PUSH to one draft for our > productive discussion and WG progress, > > Thanking you > > Abdussalam Baryun > University of Glamorgan, UK, > ===================================================== > From abdussalambaryun@gmail.com Sat Jun 9 01:41:59 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980D721F8995 for ; Sat, 9 Jun 2012 01:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.525 X-Spam-Level: X-Spam-Status: No, score=-3.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6tSHgCDx89gg for ; Sat, 9 Jun 2012 01:41:59 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0035D21F8997 for ; Sat, 9 Jun 2012 01:41:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1712731vbb.31 for ; Sat, 09 Jun 2012 01:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7NlEklBHOdmJTzaI9+JNaC8T+dcg8XIuUMR9devWO3w=; b=fiJqSbPDj8Unuohm+hpMliIiVn4j6MY+AM6YhYIsPb86WeMolqHaAoSxE+JajzkZze Ro/LlShUQpippRCAK7FI3fNzZDvoujbb1J++lPm/aAKAc0LncKpl589Pt6Aluvm26Ikv xaQm9VidSxPWxcWsqGMW/3akXjgK7TEEwSINpqAON1k88wmqlLwgqMBhPLOczAJG20ke nxnZEE7xFUUao2cdQTAJD2gJEhNxtx0SzGLZkjH/ayq7JNNWLLfwubjTvyrfEteLl5C5 vqJrrM6b5AKbFnRI1AUJLxOK4eo9+nDs1FnlSWaTeMUMmN+XAnxJD6A1VSgIIshPMAvN tTZg== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr7362158vdb.66.1339231318358; Sat, 09 Jun 2012 01:41:58 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 9 Jun 2012 01:41:58 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 10:41:58 +0200 Message-ID: From: Abdussalam Baryun To: Emmanuel.Baccelli@inria.fr, "charliep@computer.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] draft-baccelli-manet-multihop-communication-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 08:41:59 -0000 Hi Emmanuel and Charlie, Please take RFC4903 into the work body, because IMO it is important for the subject I-D and it is nice to reference RFC4903 in the I-D because it does not reference it (i.e. the RFC4903 is in the reference section but nothing in the body refers to it). Please also read below discussion. I will add that RFC4903 focused more on L3 models and not L2 models, however, there are some interesting information for L2 models which I will include and reference in the draft I am working on. ============ Possible Duplication =================== UH>I think it would be wrong to define such a multi-link subnet (for the >reasons the IAB described in in RFC4903, and that we tried to convey >at length in AUTOCONF). I just now finished reading RFC4903 and thank you that you brought it to my attention ( I will include in my draft), however, I see that it considers issue of L3 link models not L2 link models. There are big difference between L3 and L2. RFC4903>There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link. AB> meaning the total link that includes the path between two node-interfaces. RFC4903>Links that appear as NBMA links at layer 3 are problematic. Instead, if a link is an NBMA link at layer 2, then protocol designers should define some mechanism such that it appears as either the multi-access link model or point-to-point link model at layer 3. AB> please read above----> designers SHOULD define some mechanism such that it appears as either the multi-access....... AB> I just wanted to write a draft to define L2 network technology and follow the RFC4903, so the RFC4903 is not against but with my approach. Please note that I don't want to define the protocol to be dependent on the L2 technology, but I want the DESIGNERS to KNOW what they are looking as Mr.Clausen mentioned in the WG 77 meeting, that we define assumptions/conditions before looking at our protocols. I appreciate that you educated me regarding the RFC4903 it is very important to read I admit that I missed. Thanks, ================================================== Thanking you, Best Regards Abdussalam Baryun University of Glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++ From teco@inf-net.nl Sat Jun 9 03:03:52 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278BA21F89CB for ; Sat, 9 Jun 2012 03:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.25 X-Spam-Level: X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FaPZOSXhL+tr for ; Sat, 9 Jun 2012 03:03:51 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE021F89E8 for ; Sat, 9 Jun 2012 03:03:49 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1955152eaa.31 for ; Sat, 09 Jun 2012 03:03:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=wIxxf4qTbqYJRrw3y6Fxlk1iTVJDm7lJNx1LW614mXE=; b=CYJd/aUc3X4kdDPTEWNch+Jt7xwAaV3x8tjKayW+Khwoqp9jXvT8XLGhwDik3+dTUZ Fnx5cJadwRNIdBJFmD/eGIoBOjbEAMWVtd211cbVLxwmKhuq/L22vLFjbYHJ3Tc0pFjc aPBbeIx9r/S/q7ZGESi19ydpyu9jKDLvGAN1FqaoRHDdNhx9TTYqCGOlc2wqnmLJb2PT S8iHqWD5opsobmQvWB5weLV0Aql6ILiRX0ruP1+H3cMPtDWrcQzWH0+3+5StnkKm5Hqd ErYhHGh+xqIw5YLeCTWQR4yigq1W1PQCHlPf3qNe6mogrvbI6znr2vMO5pHmPY3wmcF7 9V1w== Received: by 10.14.99.10 with SMTP id w10mr4889376eef.175.1339236228808; Sat, 09 Jun 2012 03:03:48 -0700 (PDT) Received: from [10.175.173.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id t3sm31005309eeb.15.2012.06.09.03.03.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 03:03:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Sat, 9 Jun 2012 12:03:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkVXjKV9yT5g4U0k6RMDouRpXQGlLhk2+3I9MqRdwBjpfb7qTqVhGy2XAf5p7DAamrLSSGj Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 10:03:52 -0000 Op 8 jun. 2012, om 23:21 heeft Thomas Heide Clausen het volgende = geschreven: >=20 > On 8 Jun 2012, at 23:05, Henning Rogge wrote: >=20 >> Obsoleting RFC 3626 would make sense. >>=20 >> There will be quite a few deployments with OLSR (v1) for a long time, >> but OLSRv2 (because of RFC 5444) is a much better base for >> experiments. >=20 > The existence of "quite a few deployments with OLSR (v1)" is, to me, a = very good reason for not obsoleting OLSRv1 with the publication of = OLSRv2 - I would be very much against that, especially as OLSRv2 isn't = "broken" per se. Did you mean "OLSR (v1) isn't "broken" per se"? >=20 > I would vote for "Leave RFC 3626 in place for further = experimentation", for the time being; eventually, it may make sense to = mark it as "Historic", but I do not think that we are there yet. +1 Historic means we do not take efforts to enhance it. It doesn't mean it = is not used anymore.=20 Let us save our energy, RFC 3626's Experimental status is fine and = OLSRv2 doesn't update it. Teco >=20 > [We've got a proud history of co-existence when protocol versions are = still in use: OPSFv2/OSPFv3; IPv4/IPv6, ....] >=20 > Best, >=20 > Thomas >=20 >> Henning Rogge >>=20 >> On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff = wrote: >>> Adrian, >>>=20 >>> In that case, my vote as a WG member would be to obsolete RFC 3626. >>>=20 >>> Other WG members? Please jump in. >>>=20 >>> Regards, >>> Stan >>>=20 >>> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >>>=20 >>> PMFJI >>>=20 >>> This thread has brought up a question that I need to ask as I review = OLSRv2 >>> which you have requested goes for publication. >>>=20 >>> In what way does the WG intend OLSRv2 to replace/update/deprecate = OSLRv1? >>>=20 >>> There is a whole range of options, and what you choose depends = largely on >>> what future exposure you think OLSRv1 should have. You could: >>>=20 >>> - Move RFC 3626 to Historic >>> - Obsolete RFC 3626 with OLSRv2 >>> - Leave RFC 3626 in place for further experimentation >>> - Update RFC 3626 as a separate activity to advance the experiment >>>=20 >>> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >>>=20 >>> Thanks, >>> Adrian >>>=20 >>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >>> Of Stan Ratliff >>> Sent: 08 June 2012 19:34 >>> To: Teco Boot >>> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >>> Subject: Re: [manet] There is no document submitted so far to WG = stating an >>> update request for RFC3626 >>>=20 >>> Abdussalam, >>>=20 >>> The first paragraph of the "Introduction" section of OSLRv2 states: >>>=20 >>> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the >>> successor to OLSR (version 1) as published in [RFC3626]." >>>=20 >>>=20 >>>=20 >>>=20 >>> As such, I'm assuming that no additional work to RFC 3626 is = expressed or >>> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all = intents and >>> purposes, a new protocol documented by this new RFC. >>>=20 >>> Regards, >>> Stan >>>=20 >>>=20 >>> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >>>=20 >>>=20 >>>=20 >>> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = >>> het volgende geschreven: >>>=20 >>>=20 >>> Hi Teco, >>>=20 >>>=20 >>>=20 >>> More precisely, we work on a replacement for the initial = experimental >>>=20 >>> version. >>>=20 >>>=20 >>>=20 >>> you mean that there is a work for replacement, I don't see any >>>=20 >>> discussion befor about that, please advise, >>>=20 >>>=20 >>> I guess you can find it in the archives. >>>=20 >>>=20 >>>=20 >>>=20 >>> RFC 3626 is not updated. It could get historic one day. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> same what I thought, but one author of OLSRv2 mentioned that I may >>>=20 >>> misunderstood the process of OLSRv2, even though the authors don't >>>=20 >>> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >>>=20 >>> other I-D when submitted for IESG they put inside the draft what the >>>=20 >>> draft authors intention if they obslete another documents or if = their >>>=20 >>> new draft is updating any thing, >>>=20 >>>=20 >>>=20 >>> I have confidence in authors' knowledge on the proces. Dito for = chairs. >>>=20 >>>=20 >>>=20 >>> OLSRv2 does not mention the process of update, which IMHO it should = if >>>=20 >>> authors want to update RFC3626, >>>=20 >>>=20 >>> I believe they don't. >>> Same for workgroup. >>>=20 >>>=20 >>>=20 >>>=20 >>> I may be wrong, but I hope the chair updates me with the status, may >>>=20 >>> be he received a private request of update out of the discussion = list, >>>=20 >>> please advise, >>>=20 >>>=20 >>> I guess you misunderstood him. >>>=20 >>> Enjoy your weekend. >>> Teco >>>=20 >>>=20 >>>=20 >>>=20 >>> Regards >>>=20 >>>=20 >>>=20 >>> AB >>>=20 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>>=20 >>>=20 >>> On 6/8/12, Teco Boot wrote: >>>=20 >>>=20 >>>=20 >>> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende = geschreven: >>>=20 >>>=20 >>>=20 >>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>>=20 >>> wrote: >>>=20 >>> Hi Chris, >>>=20 >>>=20 >>>=20 >>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>>=20 >>> which make people think why? >>>=20 >>>=20 >>>=20 >>> This sentence doesn't make sense. >>>=20 >>>=20 >>>=20 >>> OLSRv2 IS the update of RFC 3626. >>>=20 >>> More precisely, we work on a replacement for the initial = experimental >>>=20 >>> version. >>>=20 >>> RFC 3626 is not updated. It could get historic one day. >>>=20 >>>=20 >>>=20 >>> Teco >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Are you sure you understand how the IETF works to update existing >>>=20 >>> protocols? >>>=20 >>>=20 >>>=20 >>> Henning Rogge >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>=20 >>> billions of percent in a tiny fraction of a second. Of course, that >>>=20 >>> was before the present government." >>>=20 >>> _______________________________________________ >>>=20 >>> manet mailing list >>>=20 >>> manet@ietf.org >>>=20 >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >>=20 >> --=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >> billions of percent in a tiny fraction of a second. Of course, that >> was before the present government." >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Sat Jun 9 03:09:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5408621F8543 for ; Sat, 9 Jun 2012 03:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 9tZH+s+qZO4r for ; Sat, 9 Jun 2012 03:09:52 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9584221F853F for ; Sat, 9 Jun 2012 03:09:52 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1737099vbb.31 for ; Sat, 09 Jun 2012 03:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=fU+QL4Et8H6JaOCux2VtFXqW6PuspS0P90fad/a7MR4=; b=uMwgSO7TqhvoBz7e09hGhN+w37QOAv+Nbq4fmaI11QiGczNbV9Gy3H/rsKw3b/3VeM R+Hg9vd0j40e3H3Ce868pzZceVqEUSZx5mB0mlC7784iHIOOnKKuEswpYp9zoyKSDOsu 2lrBJdfj/NrZ0isOXsQFCofFVQhnjf7gNUlJNKQPcg6TrH/Srq3s+25Kmnxd2zlSAsmP vStk+gJuDrLBEDlno73SHAtm0z5W/5n1rP3rXEJ0NvpGE0fEGhV1iQ9MsNIjBQ7+f8DI IbMo/BtEAO5gJaAEopOLWVI+t1vmP0nPvW2CWPwey5PKzfu1KptVbn3zjkprRHEpiScB T3gQ== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr7568874vdf.127.1339236591914; Sat, 09 Jun 2012 03:09:51 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 9 Jun 2012 03:09:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Jun 2012 12:09:51 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 10:09:53 -0000 Hi Folks, IMHO, there are difference between discussion that MAY become argumentable and/or debatable. In a healthy-discussion you produce new ideas and educate yourself and others, but in unproductive-discussion you MAY block any progress and waste time. I define productive discussion as the posting/speaking of a point of view referenced by scientific facts or RFCs. I define debates as the posting/speaking of points without good-referencing or without good-reasoning. IMHO these debating inputs with no good reference will not provide progress in discussions, even though it may (in low probability) start indirectly an interest/input to a work-in-progress. For example, in one of the WG discussion on list, two members of WG have referenced a history-discussion and informed me to read them regarding some subject, I did do that but was *lost in translation*. I now think that the memebrs' advise was to a wrong direction. We SHOULD NOT refer in our current discussions to any other history-subjected-discussions (thoes discussion had no approve by WG consensus nor IESG review) in any WGs. Also referring to old discussions in the list result to waste time and MAY make current arguments long (i.e. long means more than 5 working days), or even makes the current argument unproductive.Old-discussions MAY be misleading/incorrect/invalid, even if they are helpful to gain some knowledge. We should *reference* mostly RFCs in our discussion, because RFCs are correct resource. The reason is because only RFCs are productions of healthy discussions and reviewed by experts in IESG. IMHO the IETF sees that RFCs are the correct-progress-reference. All Discussions are important for the IETF processes and to produce RFCs. Memebers of the WG should try to direct their discussions in the direction of progress without discouraging debate-input. Discussions that produce I-D that in the end submits are the most productive discussions. IMO it is accepted in discussions to reference scientific research papers, reviewed publications, industry experience, or RFCs, but please don=92t accept in discussion the validity of ; a) a reference to a specific historic discussion that possibly were with wrong arguments, or b) a reference to unproductive discussions. In conclusion, we should try with the help of the WGs chairs to direct our discussions to become more productive, and within a reasonable time, and if we see any good-correct ideas, we SHOULD react quickly and input in a informational I-D and submit to WG for approval so we don't repeat refering to wrong-argumental-discussion. If you feel differently please advise, thanking you :) Best regards Abdussalam Baryun University of Glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++++ < In discussions one may be wrong, or may be right, but it does not matter if we work together as a group to progress and resolve all issues. IETF WGs are always right > ***************************************************************************= ************* From teco@inf-net.nl Sat Jun 9 03:17:53 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535FC21F8A10 for ; Sat, 9 Jun 2012 03:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 7Zgp632Vs-H1 for ; Sat, 9 Jun 2012 03:17:52 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 363EB21F8608 for ; Sat, 9 Jun 2012 03:17:48 -0700 (PDT) Received: by eekd4 with SMTP id d4so1983080eek.31 for ; Sat, 09 Jun 2012 03:17:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=/4lndzISQoQ39s0z0z0cqEIToeqt5/f+EzwGQk6pFsA=; b=EmIt9V470XORJD1qg83rujBH7z4bdNVRVQHj85FvUDgA6lQNAbpq2+4nb93n0fVUYv k3xJbzRNnwtNnCnmaOy0JKcAdKrTSfGs0ANK8ju1SOxVY8+jeNyCOR3PZqCNs/2DiynM 2TudKvtcnrUA186Yk3jhrxyxzblYpiqjk61k4T0XpTNMSbSgyGlfCiB4CPOdziHWNYNZ iC3SwkgGZRISS8G5PlOP2oe/JsYtO4kEjDSWWGB1e+UEmNWefMS5QZxzRqzwiU5R1nNj mTVTcarlJYzhK3fD+FRHVmWpkwLdEXOgttKxAwDe2hhexIhuN+2rVp/N6LEzIIOSa33s 2Cfw== Received: by 10.14.127.130 with SMTP id d2mr4467500eei.216.1339237067122; Sat, 09 Jun 2012 03:17:47 -0700 (PDT) Received: from [10.175.173.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id f16sm31190113eec.2.2012.06.09.03.17.45 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 03:17:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sat, 9 Jun 2012 12:17:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> To: Henning Rogge X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmmZbHUcFT4+q8Khi5LJaDxZQAwgcknLRETe1QU1Mt1ML+ZnOF51lvGFSCpMRhu1kncaUt9 Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 10:17:53 -0000 Op 8 jun. 2012, om 23:05 heeft Henning Rogge het volgende geschreven: > Obsoleting RFC 3626 would make sense. As protocol designers, we can just ignore it.=20 >=20 > There will be quite a few deployments with OLSR (v1) for a long time, > but OLSRv2 (because of RFC 5444) is a much better base for > experiments. OK. But OLSRv2 is Standards Track. Let's _use_ it in the Internet. _experimental_ enhancements on OLSRv2 / RFC 5444 are fine, but this is = not=20 our primary goal. OK, paying attention to IRTF work related to MANET is = in our charter. Teco >=20 > Henning Rogge >=20 > On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff = wrote: >> Adrian, >>=20 >> In that case, my vote as a WG member would be to obsolete RFC 3626. >>=20 >> Other WG members? Please jump in. >>=20 >> Regards, >> Stan >>=20 >> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >>=20 >> PMFJI >>=20 >> This thread has brought up a question that I need to ask as I review = OLSRv2 >> which you have requested goes for publication. >>=20 >> In what way does the WG intend OLSRv2 to replace/update/deprecate = OSLRv1? >>=20 >> There is a whole range of options, and what you choose depends = largely on >> what future exposure you think OLSRv1 should have. You could: >>=20 >> - Move RFC 3626 to Historic >> - Obsolete RFC 3626 with OLSRv2 >> - Leave RFC 3626 in place for further experimentation >> - Update RFC 3626 as a separate activity to advance the experiment >>=20 >> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >>=20 >> Thanks, >> Adrian >>=20 >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >> Of Stan Ratliff >> Sent: 08 June 2012 19:34 >> To: Teco Boot >> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >> Subject: Re: [manet] There is no document submitted so far to WG = stating an >> update request for RFC3626 >>=20 >> Abdussalam, >>=20 >> The first paragraph of the "Introduction" section of OSLRv2 states: >>=20 >> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the >> successor to OLSR (version 1) as published in [RFC3626]." >>=20 >>=20 >>=20 >>=20 >> As such, I'm assuming that no additional work to RFC 3626 is = expressed or >> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all = intents and >> purposes, a new protocol documented by this new RFC. >>=20 >> Regards, >> Stan >>=20 >>=20 >> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >>=20 >>=20 >>=20 >> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = >> het volgende geschreven: >>=20 >>=20 >> Hi Teco, >>=20 >>=20 >>=20 >> More precisely, we work on a replacement for the initial experimental >>=20 >> version. >>=20 >>=20 >>=20 >> you mean that there is a work for replacement, I don't see any >>=20 >> discussion befor about that, please advise, >>=20 >>=20 >> I guess you can find it in the archives. >>=20 >>=20 >>=20 >>=20 >> RFC 3626 is not updated. It could get historic one day. >>=20 >>=20 >>=20 >>=20 >>=20 >> same what I thought, but one author of OLSRv2 mentioned that I may >>=20 >> misunderstood the process of OLSRv2, even though the authors don't >>=20 >> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >>=20 >> other I-D when submitted for IESG they put inside the draft what the >>=20 >> draft authors intention if they obslete another documents or if their >>=20 >> new draft is updating any thing, >>=20 >>=20 >>=20 >> I have confidence in authors' knowledge on the proces. Dito for = chairs. >>=20 >>=20 >>=20 >> OLSRv2 does not mention the process of update, which IMHO it should = if >>=20 >> authors want to update RFC3626, >>=20 >>=20 >> I believe they don't. >> Same for workgroup. >>=20 >>=20 >>=20 >>=20 >> I may be wrong, but I hope the chair updates me with the status, may >>=20 >> be he received a private request of update out of the discussion = list, >>=20 >> please advise, >>=20 >>=20 >> I guess you misunderstood him. >>=20 >> Enjoy your weekend. >> Teco >>=20 >>=20 >>=20 >>=20 >> Regards >>=20 >>=20 >>=20 >> AB >>=20 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>=20 >>=20 >>=20 >> On 6/8/12, Teco Boot wrote: >>=20 >>=20 >>=20 >> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: >>=20 >>=20 >>=20 >> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>=20 >> wrote: >>=20 >> Hi Chris, >>=20 >>=20 >>=20 >> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>=20 >> which make people think why? >>=20 >>=20 >>=20 >> This sentence doesn't make sense. >>=20 >>=20 >>=20 >> OLSRv2 IS the update of RFC 3626. >>=20 >> More precisely, we work on a replacement for the initial experimental >>=20 >> version. >>=20 >> RFC 3626 is not updated. It could get historic one day. >>=20 >>=20 >>=20 >> Teco >>=20 >>=20 >>=20 >>=20 >>=20 >> Are you sure you understand how the IETF works to update existing >>=20 >> protocols? >>=20 >>=20 >>=20 >> Henning Rogge >>=20 >>=20 >>=20 >> -- >>=20 >> Steven Hawkings about cosmic inflation: "An increase of billions of >>=20 >> billions of percent in a tiny fraction of a second. Of course, that >>=20 >> was before the present government." >>=20 >> _______________________________________________ >>=20 >> manet mailing list >>=20 >> manet@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 >=20 >=20 > --=20 > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From hrogge@googlemail.com Sat Jun 9 04:31:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1B121F899F for ; Sat, 9 Jun 2012 04:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 D5UXGTQqPNVc for ; Sat, 9 Jun 2012 04:31:33 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 086B021F8812 for ; Sat, 9 Jun 2012 04:31:32 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so3604521pbc.31 for ; Sat, 09 Jun 2012 04:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NtpHTl+M0ixRukGFdm3XE7D56QQ+1ZxLNenyGGwAAMU=; b=hNzZ8i30zcYKNpJFkoAMptS0N71pblgdeZqcPGfBax6FHa7zJchpWWGxmDKvpZufYg kncBBSRu91jaMEtO/ftsV4DFx0ltd9E7EdGHEmIyqJ+DAsc0d6dluK/0U4vK8v9cbVQ+ kvtcesg+O1nME8j46Xw3oY3trIZZKeJF2BgCir2V67S/odeON3WIjnX5Vi75Iy0TFcjG 02uqHJP3MsOTBsZ59yApLQ7mqO1vaBpZamQlfHMVH1WICMr++97m3K+keJN6XXhC5xPq K5q2gIULruilBra+/ZDVvFBSWQW0w2gdp0f6Dibiqhzk85zSOz36lfKSzIQ6DYWiVqHj OH3w== Received: by 10.68.232.232 with SMTP id tr8mr5382343pbc.73.1339241492417; Sat, 09 Jun 2012 04:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.100.212 with HTTP; Sat, 9 Jun 2012 04:31:12 -0700 (PDT) In-Reply-To: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> From: Henning Rogge Date: Sat, 9 Jun 2012 13:31:12 +0200 Message-ID: To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:31:33 -0000 On Sat, Jun 9, 2012 at 12:17 PM, Teco Boot wrote: > Op 8 jun. 2012, om 23:05 heeft Henning Rogge het volgende geschreven: >> Obsoleting RFC 3626 would make sense. > As protocol designers, we can just ignore it. > >> >> There will be quite a few deployments with OLSR (v1) for a long time, >> but OLSRv2 (because of RFC 5444) is a much better base for >> experiments. > OK. But OLSRv2 is Standards Track. Let's _use_ it in the Internet. > > _experimental_ enhancements on OLSRv2 / RFC 5444 are fine, but this is not > our primary goal. OK, paying attention to IRTF work related to MANET is in > our charter. I was thinking about experiments like different routing metrics and multi-topology routing, which should work well with the OLSRv2 standard. Or maybe testing some deeper connections between OLSRv2 mesh routing and DLEP. Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." From teco@inf-net.nl Sat Jun 9 04:57:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5838E21F886A for ; Sat, 9 Jun 2012 04:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.425 X-Spam-Level: X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zbQNUGDGmvCT for ; Sat, 9 Jun 2012 04:57:40 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2E221F86B8 for ; Sat, 9 Jun 2012 04:57:40 -0700 (PDT) Received: by eekd4 with SMTP id d4so2017008eek.31 for ; Sat, 09 Jun 2012 04:57:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=6j5sKdzgGrIORQovMEsC2axDu6fKQQx8qOd1MwQEHVU=; b=SewUB13nv+ww93lO6A/oglYIh+yqwFNY7XRyjlaisGgxJMQvMghTaS2KiIAlelkryJ 1hE9jK3kQ8KZBjbjiiAh4NJaBlDYu9MJYRdNE6X31pLD2zxAC5EhSc9FwYetTekl9Kjo 58PUzNLr//3wkSQRE8aOJaorrSrUUc9HUpgKcyrzvMLumA7zwMBsaxnWtLjbIxtVEkQE bnL2Uy61y9eg+kGUIR1xRsunQGIYBb/+inNDkulcvwpJ5RD5SJsbFdnPBnL2gy/W5eGH xkhYKGCCfcvj8BXzpNPTKJkPJ3/EPW+pIYBO7soBNFcOiQmrYN7DLl4cw/UG/H5RjmqO 16GQ== Received: by 10.14.95.72 with SMTP id o48mr4563188eef.230.1339243059313; Sat, 09 Jun 2012 04:57:39 -0700 (PDT) Received: from [10.175.173.95] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id h53sm31882837eea.1.2012.06.09.04.57.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 09 Jun 2012 04:57:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Sat, 9 Jun 2012 13:57:31 +0200 Content-Transfer-Encoding: 7bit Message-Id: <65A37CB5-F200-4846-ADCA-AAFFCE2DF686@inf-net.nl> References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> To: Henning Rogge X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQk0/kQHgFMJHYAvyK7LQW8mNMM00G2NprwtKLJXCijjJwqtUE2ZrgqZ/yFz+XCR/NRdWgg6 Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 11:57:41 -0000 Op 9 jun. 2012, om 13:31 heeft Henning Rogge het volgende geschreven: > On Sat, Jun 9, 2012 at 12:17 PM, Teco Boot wrote: >> Op 8 jun. 2012, om 23:05 heeft Henning Rogge het volgende geschreven: >>> Obsoleting RFC 3626 would make sense. >> As protocol designers, we can just ignore it. >> >>> >>> There will be quite a few deployments with OLSR (v1) for a long time, >>> but OLSRv2 (because of RFC 5444) is a much better base for >>> experiments. >> OK. But OLSRv2 is Standards Track. Let's _use_ it in the Internet. >> >> _experimental_ enhancements on OLSRv2 / RFC 5444 are fine, but this is not >> our primary goal. OK, paying attention to IRTF work related to MANET is in >> our charter. > > I was thinking about experiments like different routing metrics and > multi-topology routing, which should work well with the OLSRv2 > standard. Or maybe testing some deeper connections between OLSRv2 mesh > routing and DLEP. OK, getting experience is great !! Teco > > Henning Rogge > > -- > Steven Hawkings about cosmic inflation: "An increase of billions of > billions of percent in a tiny fraction of a second. Of course, that > was before the present government." From ietf@thomasclausen.org Sat Jun 9 06:27:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A7421F87D6 for ; Sat, 9 Jun 2012 06:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] 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 U9V7teI3107w for ; Sat, 9 Jun 2012 06:27:44 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 40ADD21F87D5 for ; Sat, 9 Jun 2012 06:27:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id ADC13A36B2 for ; Sat, 9 Jun 2012 06:27:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7303D1C07AF; Sat, 9 Jun 2012 06:27:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.250] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id BAB7C1C078B; Sat, 9 Jun 2012 06:27:41 -0700 (PDT) References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Sat, 9 Jun 2012 15:27:42 +0200 To: Teco Boot Cc: manet , Stan Ratliff Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 13:27:45 -0000 On 9 Jun 2012, at 12:03, Teco Boot wrote: >=20 > Op 8 jun. 2012, om 23:21 heeft Thomas Heide Clausen het volgende geschreve= n: >=20 >>=20 >> On 8 Jun 2012, at 23:05, Henning Rogge wrote: >>=20 >>> Obsoleting RFC 3626 would make sense. >>>=20 >>> There will be quite a few deployments with OLSR (v1) for a long time, >>> but OLSRv2 (because of RFC 5444) is a much better base for >>> experiments. >>=20 >> The existence of "quite a few deployments with OLSR (v1)" is, to me, a ve= ry good reason for not obsoleting OLSRv1 with the publication of OLSRv2 - I w= ould be very much against that, especially as OLSRv2 isn't "broken" per se. > Did you mean "OLSR (v1) isn't "broken" per se"? >=20 Yes - good catch. Sorry. >>=20 >> I would vote for "Leave RFC 3626 in place for further experimentation", f= or the time being; eventually, it may make sense to mark it as "Historic", b= ut I do not think that we are there yet. > +1 > Historic means we do not take efforts to enhance it. It doesn't mean it is= not used anymore.=20 >=20 > Let us save our energy, RFC 3626's Experimental status is fine and OLSRv2 d= oesn't update it. >=20 +1 Thomas > Teco >=20 >=20 >>=20 >> [We've got a proud history of co-existence when protocol versions are sti= ll in use: OPSFv2/OSPFv3; IPv4/IPv6, ....] >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Henning Rogge >>>=20 >>> On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff wrote= : >>>> Adrian, >>>>=20 >>>> In that case, my vote as a WG member would be to obsolete RFC 3626. >>>>=20 >>>> Other WG members? Please jump in. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >>>>=20 >>>> PMFJI >>>>=20 >>>> This thread has brought up a question that I need to ask as I review OL= SRv2 >>>> which you have requested goes for publication. >>>>=20 >>>> In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv= 1? >>>>=20 >>>> There is a whole range of options, and what you choose depends largely o= n >>>> what future exposure you think OLSRv1 should have. You could: >>>>=20 >>>> - Move RFC 3626 to Historic >>>> - Obsolete RFC 3626 with OLSRv2 >>>> - Leave RFC 3626 in place for further experimentation >>>> - Update RFC 3626 as a separate activity to advance the experiment >>>>=20 >>>> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >>>>=20 >>>> Thanks, >>>> Adrian >>>>=20 >>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf >>>> Of Stan Ratliff >>>> Sent: 08 June 2012 19:34 >>>> To: Teco Boot >>>> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >>>> Subject: Re: [manet] There is no document submitted so far to WG statin= g an >>>> update request for RFC3626 >>>>=20 >>>> Abdussalam, >>>>=20 >>>> The first paragraph of the "Introduction" section of OSLRv2 states: >>>>=20 >>>> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the >>>> successor to OLSR (version 1) as published in [RFC3626]." >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> As such, I'm assuming that no additional work to RFC 3626 is expressed o= r >>>> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents a= nd >>>> purposes, a new protocol documented by this new RFC. >>>>=20 >>>> Regards, >>>> Stan >>>>=20 >>>>=20 >>>> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun >>>> het volgende geschreven: >>>>=20 >>>>=20 >>>> Hi Teco, >>>>=20 >>>>=20 >>>>=20 >>>> More precisely, we work on a replacement for the initial experimental >>>>=20 >>>> version. >>>>=20 >>>>=20 >>>>=20 >>>> you mean that there is a work for replacement, I don't see any >>>>=20 >>>> discussion befor about that, please advise, >>>>=20 >>>>=20 >>>> I guess you can find it in the archives. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> RFC 3626 is not updated. It could get historic one day. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> same what I thought, but one author of OLSRv2 mentioned that I may >>>>=20 >>>> misunderstood the process of OLSRv2, even though the authors don't >>>>=20 >>>> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >>>>=20 >>>> other I-D when submitted for IESG they put inside the draft what the >>>>=20 >>>> draft authors intention if they obslete another documents or if their >>>>=20 >>>> new draft is updating any thing, >>>>=20 >>>>=20 >>>>=20 >>>> I have confidence in authors' knowledge on the proces. Dito for chairs.= >>>>=20 >>>>=20 >>>>=20 >>>> OLSRv2 does not mention the process of update, which IMHO it should if >>>>=20 >>>> authors want to update RFC3626, >>>>=20 >>>>=20 >>>> I believe they don't. >>>> Same for workgroup. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> I may be wrong, but I hope the chair updates me with the status, may >>>>=20 >>>> be he received a private request of update out of the discussion list, >>>>=20 >>>> please advise, >>>>=20 >>>>=20 >>>> I guess you misunderstood him. >>>>=20 >>>> Enjoy your weekend. >>>> Teco >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Regards >>>>=20 >>>>=20 >>>>=20 >>>> AB >>>>=20 >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>=20 >>>>=20 >>>>=20 >>>> On 6/8/12, Teco Boot wrote: >>>>=20 >>>>=20 >>>>=20 >>>> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: >>>>=20 >>>>=20 >>>>=20 >>>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>>>=20 >>>> wrote: >>>>=20 >>>> Hi Chris, >>>>=20 >>>>=20 >>>>=20 >>>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>>>=20 >>>> which make people think why? >>>>=20 >>>>=20 >>>>=20 >>>> This sentence doesn't make sense. >>>>=20 >>>>=20 >>>>=20 >>>> OLSRv2 IS the update of RFC 3626. >>>>=20 >>>> More precisely, we work on a replacement for the initial experimental >>>>=20 >>>> version. >>>>=20 >>>> RFC 3626 is not updated. It could get historic one day. >>>>=20 >>>>=20 >>>>=20 >>>> Teco >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Are you sure you understand how the IETF works to update existing >>>>=20 >>>> protocols? >>>>=20 >>>>=20 >>>>=20 >>>> Henning Rogge >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>>=20 >>>> billions of percent in a tiny fraction of a second. Of course, that >>>>=20 >>>> was before the present government." >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> manet mailing list >>>>=20 >>>> manet@ietf.org >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Steven Hawkings about cosmic inflation: "An increase of billions of >>> billions of percent in a tiny fraction of a second. Of course, that >>> was before the present government." >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >=20 From sratliff@cisco.com Sat Jun 9 12:50:05 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D5921F8559 for ; Sat, 9 Jun 2012 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 qJyWFCj8o2-2 for ; Sat, 9 Jun 2012 12:50:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3521F854B for ; Sat, 9 Jun 2012 12:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=8659; q=dns/txt; s=iport; t=1339271404; x=1340481004; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=gnWJbVr0w5kTO3tJ99tM2x3Q1g96z4zARvIQVHE6M0g=; b=ca+w+Po2yJz0+I7vyiQrJploThXHtF4P/Phy/+9NsaSUdPE9EsbF3SPm Q9BBQbW/F+7h63G0u+0QXyzfA7BKhFkMJqFurlk0hnDQkz127lOEQjj+7 LxHAH2Unix5A0hDO2yvm2m3BlHR4LELDSLwnQ0q/6qef8n5F+J6ocGS0O k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKyn00+tJV2a/2dsb2JhbABFtFqBB4IYAQEBAwEBAQEPASc0CxALEQQBAQEnByEGHwkIBgESIodbAwYFC5hTlTENiUoEikZhhQlgA5Uein6DF4Fmgnw X-IronPort-AV: E=Sophos;i="4.75,743,1330905600"; d="scan'208";a="91012439" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jun 2012 19:50:03 +0000 Received: from rtp-sratliff-8716.cisco.com (rtp-sratliff-8716.cisco.com [10.116.179.215]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q59Jo2uY014902; Sat, 9 Jun 2012 19:50:02 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Sat, 9 Jun 2012 15:50:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4B441163-F58E-419C-B79D-D37EBF86BA11@cisco.com> References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> To: Thomas Heide Clausen , Adrian Farrel X-Mailer: Apple Mail (2.1278) Cc: manet Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2012 19:50:05 -0000 So, I'm seeing consensus around Thomas' approach; namely,=20 >>>=20 >>> I would vote for "Leave RFC 3626 in place for further = experimentation", for the time being >>=20 Adrian, is that an acceptable approach from the AD perspective?=20 Regards, Stan On Jun 9, 2012, at 9:27 AM, Thomas Heide Clausen wrote: >=20 >=20 > On 9 Jun 2012, at 12:03, Teco Boot wrote: >=20 >>=20 >> Op 8 jun. 2012, om 23:21 heeft Thomas Heide Clausen het volgende = geschreven: >>=20 >>>=20 >>> On 8 Jun 2012, at 23:05, Henning Rogge = wrote: >>>=20 >>>> Obsoleting RFC 3626 would make sense. >>>>=20 >>>> There will be quite a few deployments with OLSR (v1) for a long = time, >>>> but OLSRv2 (because of RFC 5444) is a much better base for >>>> experiments. >>>=20 >>> The existence of "quite a few deployments with OLSR (v1)" is, to me, = a very good reason for not obsoleting OLSRv1 with the publication of = OLSRv2 - I would be very much against that, especially as OLSRv2 isn't = "broken" per se. >> Did you mean "OLSR (v1) isn't "broken" per se"? >>=20 >=20 > Yes - good catch. Sorry. >=20 >>>=20 >>> I would vote for "Leave RFC 3626 in place for further = experimentation", for the time being; eventually, it may make sense to = mark it as "Historic", but I do not think that we are there yet. >> +1 >> Historic means we do not take efforts to enhance it. It doesn't mean = it is not used anymore.=20 >>=20 >> Let us save our energy, RFC 3626's Experimental status is fine and = OLSRv2 doesn't update it. >>=20 >=20 > +1 >=20 > Thomas >=20 >> Teco >>=20 >>=20 >>>=20 >>> [We've got a proud history of co-existence when protocol versions = are still in use: OPSFv2/OSPFv3; IPv4/IPv6, ....] >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>> Henning Rogge >>>>=20 >>>> On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff = wrote: >>>>> Adrian, >>>>>=20 >>>>> In that case, my vote as a WG member would be to obsolete RFC = 3626. >>>>>=20 >>>>> Other WG members? Please jump in. >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: >>>>>=20 >>>>> PMFJI >>>>>=20 >>>>> This thread has brought up a question that I need to ask as I = review OLSRv2 >>>>> which you have requested goes for publication. >>>>>=20 >>>>> In what way does the WG intend OLSRv2 to replace/update/deprecate = OSLRv1? >>>>>=20 >>>>> There is a whole range of options, and what you choose depends = largely on >>>>> what future exposure you think OLSRv1 should have. You could: >>>>>=20 >>>>> - Move RFC 3626 to Historic >>>>> - Obsolete RFC 3626 with OLSRv2 >>>>> - Leave RFC 3626 in place for further experimentation >>>>> - Update RFC 3626 as a separate activity to advance the experiment >>>>>=20 >>>>> What I don't think you are doing with OLSRv2 is Updating RFC 3626. >>>>>=20 >>>>> Thanks, >>>>> Adrian >>>>>=20 >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf >>>>> Of Stan Ratliff >>>>> Sent: 08 June 2012 19:34 >>>>> To: Teco Boot >>>>> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun >>>>> Subject: Re: [manet] There is no document submitted so far to WG = stating an >>>>> update request for RFC3626 >>>>>=20 >>>>> Abdussalam, >>>>>=20 >>>>> The first paragraph of the "Introduction" section of OSLRv2 = states: >>>>>=20 >>>>> "The Optimized Link State Routing protocol version 2 (OLSRv2) is = the >>>>> successor to OLSR (version 1) as published in [RFC3626]." >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> As such, I'm assuming that no additional work to RFC 3626 is = expressed or >>>>> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all = intents and >>>>> purposes, a new protocol documented by this new RFC. >>>>>=20 >>>>> Regards, >>>>> Stan >>>>>=20 >>>>>=20 >>>>> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun = >>>>> het volgende geschreven: >>>>>=20 >>>>>=20 >>>>> Hi Teco, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> More precisely, we work on a replacement for the initial = experimental >>>>>=20 >>>>> version. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> you mean that there is a work for replacement, I don't see any >>>>>=20 >>>>> discussion befor about that, please advise, >>>>>=20 >>>>>=20 >>>>> I guess you can find it in the archives. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> RFC 3626 is not updated. It could get historic one day. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> same what I thought, but one author of OLSRv2 mentioned that I may >>>>>=20 >>>>> misunderstood the process of OLSRv2, even though the authors don't >>>>>=20 >>>>> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen >>>>>=20 >>>>> other I-D when submitted for IESG they put inside the draft what = the >>>>>=20 >>>>> draft authors intention if they obslete another documents or if = their >>>>>=20 >>>>> new draft is updating any thing, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I have confidence in authors' knowledge on the proces. Dito for = chairs. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> OLSRv2 does not mention the process of update, which IMHO it = should if >>>>>=20 >>>>> authors want to update RFC3626, >>>>>=20 >>>>>=20 >>>>> I believe they don't. >>>>> Same for workgroup. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I may be wrong, but I hope the chair updates me with the status, = may >>>>>=20 >>>>> be he received a private request of update out of the discussion = list, >>>>>=20 >>>>> please advise, >>>>>=20 >>>>>=20 >>>>> I guess you misunderstood him. >>>>>=20 >>>>> Enjoy your weekend. >>>>> Teco >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Regards >>>>>=20 >>>>>=20 >>>>>=20 >>>>> AB >>>>>=20 >>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 6/8/12, Teco Boot wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende = geschreven: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun >>>>>=20 >>>>> wrote: >>>>>=20 >>>>> Hi Chris, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 >>>>>=20 >>>>> which make people think why? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This sentence doesn't make sense. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> OLSRv2 IS the update of RFC 3626. >>>>>=20 >>>>> More precisely, we work on a replacement for the initial = experimental >>>>>=20 >>>>> version. >>>>>=20 >>>>> RFC 3626 is not updated. It could get historic one day. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Teco >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Are you sure you understand how the IETF works to update existing >>>>>=20 >>>>> protocols? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Henning Rogge >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Steven Hawkings about cosmic inflation: "An increase of billions = of >>>>>=20 >>>>> billions of percent in a tiny fraction of a second. Of course, = that >>>>>=20 >>>>> was before the present government." >>>>>=20 >>>>> _______________________________________________ >>>>>=20 >>>>> manet mailing list >>>>>=20 >>>>> manet@ietf.org >>>>>=20 >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Steven Hawkings about cosmic inflation: "An increase of billions of >>>> billions of percent in a tiny fraction of a second. Of course, that >>>> was before the present government." >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 From Chris.Dearlove@baesystems.com Mon Jun 11 01:49:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBE021F84FB for ; Mon, 11 Jun 2012 01:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 cae9tPeAEoUt for ; Mon, 11 Jun 2012 01:49:56 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF6B21F84A7 for ; Mon, 11 Jun 2012 01:49:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,748,1330905600"; d="scan'208,217";a="245119434" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 11 Jun 2012 09:49:54 +0100 Received: from GLKXH0005V.GREENLNK.net ([10.109.2.36]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q5B8nr54009620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Jun 2012 09:49:53 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Mon, 11 Jun 2012 09:49:53 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , "'manet'" Thread-Topic: [manet] Updating or replacing RFC 3626 Thread-Index: Ac1FsOesZUVwhxvISFuDzvMTppSUlgB/cT9Q Date: Mon, 11 Jun 2012 08:49:52 +0000 Message-ID: References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> In-Reply-To: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D12EE57GLKXM0002VGREENLN_" MIME-Version: 1.0 Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 08:49:57 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D12EE57GLKXM0002VGREENLN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There are existing systems using OLSR (RFC 3626) such as Freifunk, so I think OLSR is clearly not yet historic nor should be considered obsoleted. I don't see anyone offering to update it (nor do I think they should). That leaves the third option of leaving RFC 3626 in place for further experimentation. That seems right to me. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 | Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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 From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: 08 June 2012 20:57 To: 'manet' Subject: [manet] Updating or replacing RFC 3626 *** WARNING *** This message originates from outside our organisation, either from an external partner or the internet. Keep this in mind if you answer this message. Please see this process on how to deal with suspicious emails. PMFJI This thread has brought up a question that I need to ask as I review OLSRv2 which you have requested goes for publication. In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv1? There is a whole range of options, and what you choose depends largely on what future exposure you think OLSRv1 should have. You could: - Move RFC 3626 to Historic - Obsolete RFC 3626 with OLSRv2 - Leave RFC 3626 in place for further experimentation - Update RFC 3626 as a separate activity to advance the experiment What I don't think you are doing with OLSRv2 is Updating RFC 3626. Thanks, Adrian From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff Sent: 08 June 2012 19:34 To: Teco Boot Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun Subject: Re: [manet] There is no document submitted so far to WG stating an update request for RFC3626 Abdussalam, The first paragraph of the "Introduction" section of OSLRv2 states: "The Optimized Link State Routing protocol version 2 (OLSRv2) is the successor to OLSR (version 1) as published in [RFC3626]." As such, I'm assuming that no additional work to RFC 3626 is expressed or implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and purposes, a new protocol documented by this new RFC. Regards, Stan On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun > het volgende geschreven: Hi Teco, More precisely, we work on a replacement for the initial experimental version. you mean that there is a work for replacement, I don't see any discussion befor about that, please advise, I guess you can find it in the archives. RFC 3626 is not updated. It could get historic one day. same what I thought, but one author of OLSRv2 mentioned that I may misunderstood the process of OLSRv2, even though the authors don't specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen other I-D when submitted for IESG they put inside the draft what the draft authors intention if they obslete another documents or if their new draft is updating any thing, I have confidence in authors' knowledge on the proces. Dito for chairs. OLSRv2 does not mention the process of update, which IMHO it should if authors want to update RFC3626, I believe they don't. Same for workgroup. I may be wrong, but I hope the chair updates me with the status, may be he received a private request of update out of the discussion list, please advise, I guess you misunderstood him. Enjoy your weekend. Teco Regards AB +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/8/12, Teco Boot > wrote: Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > wrote: Hi Chris, Please note that MANET WG is doing OLSRv2 without updating RFC3626 which make people think why? This sentence doesn't make sense. OLSRv2 IS the update of RFC 3626. More precisely, we work on a replacement for the initial experimental version. RFC 3626 is not updated. It could get historic one day. Teco Are you sure you understand how the IETF works to update existing protocols? Henning Rogge -- Steven Hawkings about cosmic inflation: "An increase of billions of billions of percent in a tiny fraction of a second. Of course, that was before the present government." _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D12EE57GLKXM0002VGREENLN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

There are existing systems using OLSR (RFC 3626) such as Freifunk, so I think OLSR is clearly not yet historic nor should be considered obsoleted. I don't see anyone offering to update it (nor do I think they should). That leaves the third option of leaving RFC 3626 in place for further experimentation. That seems right to me.

 

--

Christopher Dearlove

Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124

chris.dearlove@baesystems.com | http://www.baesystems.com

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

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: 08 June 2012 20:57
To: 'manet'
Subject: [manet] Updating or replacing RFC 3626

 

 

*** WARNING ***

This message originates from outside our organisation, either from an external partner or the internet.
Keep this in mind if you answer this message.
Please see this process on how to deal with suspicious emails.

PMFJI

 

This thread has brought up a question that I need to ask as I review OLSRv2 which you have requested goes for publication.

 

In what way does the WG intend OLSRv2 to replace/update/deprecate OSLRv1?

 

There is a whole range of options, and what you choose depends largely on what future exposure you think OLSRv1 should have. You could:

 

- Move RFC 3626 to Historic

- Obsolete RFC 3626 with OLSRv2

- Leave RFC 3626 in place for further experimentation

- Update RFC 3626 as a separate activity to advance the experiment

 

What I don't think you are doing with OLSRv2 is Updating RFC 3626.

 

Thanks,

Adrian

 

From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of Stan Ratliff
Sent: 08 June 2012 19:34
To: Teco Boot
Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun
Subject: Re: [manet] There is no document submitted so far to WG stating an update request for RFC3626

 

Abdussalam,

 

The first paragraph of the "Introduction" section of OSLRv2 states: 

 

"The Optimized Link State Routing protocol version 2 (OLSRv2) is the

successor to OLSR (version 1) as published in [RFC3626]."





As such, I'm assuming that no additional work to RFC 3626 is expressed or implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and purposes, a new protocol documented by this new RFC. 

 

Regards,

Stan

 

 

On Jun 8, 2012, at 2:13 PM, Teco Boot wrote:




Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun <abdussalambaryun@gmail.com> het volgende geschreven:


Hi Teco,

 

More precisely, we work on a replacement for the initial experimental

version.

 

you mean that there is a work for replacement, I don't see any

discussion befor about that, please advise,


I guess you can find it in the archives.


 

RFC 3626 is not updated. It could get historic one day.

 

 

same what I thought, but one author of OLSRv2 mentioned that I may

misunderstood the process of OLSRv2, even though the authors don't

specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen

other I-D when submitted for IESG they put inside the draft what the

draft authors intention if they obslete another documents or if their

new draft is updating any thing,

 

I have confidence in authors' knowledge on the proces. Dito for chairs.



OLSRv2 does not mention the process of update, which IMHO it should if

authors want to update RFC3626,


I believe they don't.
Same for workgroup.


 

I may be wrong, but I hope the chair updates me with the status, may

be he received a private request of update out of the discussion list,

please advise,


I guess you misunderstood him.

Enjoy your weekend.
Teco


 

Regards

 

AB

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 

On 6/8/12, Teco Boot <teco@inf-net.nl> wrote:

 

Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven:

 

On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun

<abdussalambaryun@gmail.com> wrote:

Hi Chris,

 

Please note that MANET WG is doing OLSRv2 without updating RFC3626

which make people think why?

 

This sentence doesn't make sense.

 

OLSRv2 IS the update of RFC 3626.

More precisely, we work on a replacement for the initial experimental

version.

RFC 3626 is not updated. It could get historic one day.

 

Teco

 

 

Are you sure you understand how the IETF works to update existing

protocols?

 

Henning Rogge

 

--

Steven Hawkings about cosmic inflation: "An increase of billions of

billions of percent in a tiny fraction of a second. Of course, that

was before the present government."

_______________________________________________

manet mailing list

manet@ietf.org

https://www.ietf.org/mailman/listinfo/manet

 

 

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

 


********************************************************************
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.
********************************************************************

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D12EE57GLKXM0002VGREENLN_-- From philippe.jacquet@inria.fr Mon Jun 11 02:18:37 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C680721F854C for ; Mon, 11 Jun 2012 02:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.649 X-Spam-Level: X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 gbKhPTPfo+Nx for ; Mon, 11 Jun 2012 02:18:37 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 12FE121F8513 for ; Mon, 11 Jun 2012 02:18:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,748,1330902000"; d="scan'208";a="162203776" Received: from zmbs5.inria.fr ([128.93.142.18]) by mail1-relais-roc.national.inria.fr with ESMTP; 11 Jun 2012 11:18:34 +0200 Date: Mon, 11 Jun 2012 11:18:34 +0200 (CEST) From: Philippe Jacquet To: manet@ietf.org Message-ID: <1144565727.2028543.1339406314931.JavaMail.root@inria.fr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Originating-IP: [64.208.49.214] X-Mailer: Zimbra 7.2.0_GA_2669 (ZimbraWebClient - IE6 (Win)/7.2.0_GA_2669) Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:18:37 -0000 Dear all, Considering the time ellapsed between RFC 3626 and olsrv2 RFC (nine years and after more than 3000 RFC index units) and since many existing implementations, including commercial ones, are refering to RFC 3626, considering olsrv2 have distinct packet formats and supports addditional pieces of protocols, I would also recommand to keep RFC 3626 as active experimental, for at least some times (maybe less than nine years;-)?) Best, Philippe From jomullen@ad.nmsu.edu Mon Jun 11 04:51:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6109C21F85A4 for ; Mon, 11 Jun 2012 04:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 74EMB+y9Mq4T for ; Mon, 11 Jun 2012 04:51:40 -0700 (PDT) Received: from exchange.nmsu.edu (exchange-ht-01.nmsu.edu [128.123.34.211]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E821F85A3 for ; Mon, 11 Jun 2012 04:51:40 -0700 (PDT) Received: from EXCHANGE-MBX-01.ACN.ad.nmsu.edu ([128.123.34.88]) by exchange-ht-01.ACN.ad.nmsu.edu ([128.123.34.211]) with mapi; Mon, 11 Jun 2012 05:51:36 -0600 From: Dr John P Mullen To: MANET List Date: Mon, 11 Jun 2012 05:51:35 -0600 Thread-Topic: [manet] Updating or replacing RFC 3626 Thread-Index: Ac1HszZyAfnOD5SzTEWQ54OS5ucFBwAFVdM/ Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] FW: Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 11:51:41 -0000 Hi, Many years ago, the z-80 microprocessor chip "replaced" the 8080 chip. I sa= y "replaced" because in almost all the instances I was familiar with, 8080 = code was used, even though the processor was z-80. I think RFC 3626 is used because it works and is something people are famil= iar with. For that reason, any changes are likely to be ignored. I'd say "historical" is more practical. John Mullen -----Original Message----- From: Philippe Jacquet Sent: Monday, June 11, 2012 3:18 AM To: manet@ietf.org Subject: Re: [manet] Updating or replacing RFC 3626 Dear all, Considering the time ellapsed between RFC 3626 and olsrv2 RFC (nine years a= nd after more than 3000 RFC index units) and since many existing implementa= tions, including commercial ones, are refering to RFC 3626, considering ols= rv2 have distinct packet formats and supports addditional pieces of protoco= ls, I would also recommand to keep RFC 3626 as active experimental, for at = least some times (maybe less than nine years;-)?) Best, Philippe _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From teco@inf-net.nl Mon Jun 11 05:01:01 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23C621F8564 for ; Mon, 11 Jun 2012 05:01:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgw3Sxw0QDRN for ; Mon, 11 Jun 2012 05:01:01 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFD21F851A for ; Mon, 11 Jun 2012 05:01:00 -0700 (PDT) Received: by eaaq13 with SMTP id q13so2571763eaa.31 for ; Mon, 11 Jun 2012 05:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=iS4xaZxwrRGxC1W/pkAozXGUIRVDImcaIK7bES4C830=; b=Fl/Y0vigaZZPKvE8t2dyn4o4qFdV3u4z7O9fzAEwQdF9OhsNpTF4GcCGiZ7lyAeYuq zpGT85Q6lB8RKCJ+3H2Poa8XiSeP4ciz+pkoRO8FNfoxL7j5nMuCQk4wkaPnF1xj/iIY HPpiKFPWurlo7l4T5O7F4BkdukYIBb9i81Plqe29ouHJguEeCeUxMdF2qwOg47OAfg8y mBOdwQtzTQ6ITuZ/KGxm43XfxFnx6aElmRad8SojkUqF7tpfKOc+JE0KhqsyLqu9GSih cJKriRsMc32vOfk0DFBqc/BVxXdF+HTUDyL1wQqih+QVl9prX993s75nHbaaI2i3dnm6 unsA== Received: by 10.14.127.12 with SMTP id c12mr6335472eei.90.1339416059856; Mon, 11 Jun 2012 05:00:59 -0700 (PDT) Received: from [172.16.4.184] ([188.205.88.52]) by mx.google.com with ESMTPS id y54sm51863784eef.10.2012.06.11.05.00.58 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 11 Jun 2012 05:00:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Mon, 11 Jun 2012 14:00:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37F5077F-A1AF-47F9-8491-42E9AE21FDAB@inf-net.nl> References: To: Dr John P Mullen X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQlRZ2PBfhoss+G96FC2NTOQnfMyzpPQOi2b3XqAzHCm/Pfx+fb2aR0PPDUVZcN+1FyckjSf Cc: MANET List Subject: Re: [manet] FW: Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:01:01 -0000 Op 11 jun. 2012, om 13:51 heeft Dr John P Mullen het volgende = geschreven: > Hi, >=20 > Many years ago, the z-80 microprocessor chip "replaced" the 8080 chip. = I say "replaced" because in almost all the instances I was familiar = with, 8080 code was used, even though the processor was z-80. >=20 > I think RFC 3626 is used because it works and is something people are = familiar with. For that reason, any changes are likely to be ignored. >=20 > I'd say "historical" is more practical. Why such a hurry? There is no OLSRv2 RFC yet. And there are a lot of = _active_ experimental deployments. Let's take this discussion a couple of years after we have our new RFC. = And after the transition to OLSRv2, when interest in RFC 3626 faded = away. Teco >=20 > John Mullen >=20 > -----Original Message----- > From: Philippe Jacquet > Sent: Monday, June 11, 2012 3:18 AM > To: manet@ietf.org > Subject: Re: [manet] Updating or replacing RFC 3626 >=20 >=20 > Dear all, >=20 > Considering the time ellapsed between RFC 3626 and olsrv2 RFC (nine = years and after more than 3000 RFC index units) and since many existing = implementations, including commercial ones, are refering to RFC 3626, = considering olsrv2 have distinct packet formats and supports addditional = pieces of protocols, I would also recommand to keep RFC 3626 as active = experimental, for at least some times (maybe less than nine years;-)?) >=20 > Best, > Philippe > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ietf@thomasclausen.org Mon Jun 11 08:21:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176221F863B for ; Mon, 11 Jun 2012 08:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 DA6XU9W0TESp for ; Mon, 11 Jun 2012 08:21:14 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9421F84B3 for ; Mon, 11 Jun 2012 08:21:14 -0700 (PDT) Received: from sphinx.lix.polytechnique.fr ([129.104.11.1] helo=[10.0.1.2]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1Se6Qb-0000h8-KV; Mon, 11 Jun 2012 15:21:13 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 129.104.11.1 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+rpKDWLyDBqBagSNjYDOAG Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: Date: Mon, 11 Jun 2012 17:21:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1257) Cc: manet Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:21:15 -0000 Dear Abdussalam, First of all, it is always encouraging when new people become interested = a domain we've been working on for the past 15 or so years in the IETF. Also, over the past 15 years, a great many things have been brought = forth, discussed, experimented, consensus reached (sometimes rough = consensus - but that's the game), and decisions made - leading to the = work-items that are currently active in the working group, and the = designs that are currently the fundament of those work-items (roughly: = the currently active I-Ds in the group).=20 The working group chairs have the thankless job of getting progress on = those work-items. That's actually quite bit more complex than what may = meet the eye: constraints and requirements from elsewhere in the IETF, = such as security and MIBs and ...., as well as whipping (not too hard ;) = ) various authors to produce updated documents, getting timely = cross-area reviews, ...... and of course, ensure that the mailing list = is available for discussions of related topics. I for one think that the MANET wg chairs are striking a fairly good = balance and are doing a good, no great, job at seeing things progress = through the process to completion. It is honorable to be curious as to the history, and wanting to = understand how decisions were made and how consensus was reached. That = is why - I guess - that some have pointed you to some of the mailing = list archives (for manet@ietf as well as other lists) so that you may be = able to acquire such understanding. I am sure that you understand that = we can't rehash every discussion that's happened in the past 15 years " = on a whim" if, at the same time, we want to get progress on the = work-items that are before us. I do not think that it's particularly helpful or productive to suggest = that the WG chairs are not doing their job (they definitely are), that = the ADs are not doing their job (they definitely are too!) or that = references to mailing list archives are inappropriate: I allow myself to = remind you that working group mailing lists are where official working = group business is conducted, arguments advanced and (rough) consensus = established and confirmed - so, if anything, those archives are the = right place to point you for further information. Rough consensus and running code ;) Thomas On Jun 9, 2012, at 12:09 , Abdussalam Baryun wrote: > Hi Folks, >=20 > IMHO, there are difference between discussion that MAY become > argumentable and/or debatable. In a healthy-discussion you produce new > ideas and educate yourself and others, but in unproductive-discussion > you MAY block any progress and waste time. I define productive > discussion as the posting/speaking of a point of view referenced by > scientific facts or RFCs. I define debates as the posting/speaking of > points without good-referencing or without good-reasoning. IMHO these > debating inputs with no good reference will not provide progress in > discussions, even though it may (in low probability) start indirectly > an interest/input to a work-in-progress. >=20 > For example, in one of the WG discussion on list, two members of WG > have referenced a history-discussion and informed me to read them > regarding some subject, I did do that but was *lost in translation*. I > now think that the memebrs' advise was to a wrong direction. We SHOULD > NOT refer in our current discussions to any other > history-subjected-discussions (thoes discussion had no approve by WG > consensus nor IESG review) in any WGs. Also referring to old > discussions in the list result to waste time and MAY make current > arguments long (i.e. long means more than 5 working days), or even > makes the current argument unproductive.Old-discussions MAY be > misleading/incorrect/invalid, even if they are helpful to gain some > knowledge. >=20 > We should *reference* mostly RFCs in our discussion, because RFCs are > correct resource. The reason is because only RFCs are productions of > healthy discussions and reviewed by experts in IESG. IMHO the IETF > sees that RFCs are the correct-progress-reference. All Discussions are > important for the IETF processes and to produce RFCs. Memebers of the > WG should try to direct their discussions in the direction of progress > without discouraging debate-input. Discussions that produce I-D that > in the end submits are the most productive > discussions. IMO it is accepted in discussions to reference scientific > research papers, reviewed publications, industry experience, or RFCs, > but please don=92t accept in discussion the validity of ; a) a = reference > to a specific historic discussion that possibly were with wrong > arguments, or b) a reference to unproductive discussions. >=20 > In conclusion, we should try with the help of the WGs chairs to direct > our discussions to become more productive, and within a reasonable > time, and if we see any good-correct ideas, we SHOULD react quickly > and input in a informational I-D and submit to WG for approval so we > don't repeat refering to wrong-argumental-discussion. >=20 > If you feel differently please advise, thanking you :) >=20 > Best regards >=20 > Abdussalam Baryun > University of Glamorgan, UK. >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++ > < In discussions one may be wrong, or may be right, but it does not > matter if we work together as a group to progress and resolve all > issues. IETF WGs are always right > > = **************************************************************************= ************** > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From adrian@olddog.co.uk Mon Jun 11 09:52:35 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA0621F8573 for ; Mon, 11 Jun 2012 09:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.763 X-Spam-Level: X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599] 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 N9cvKGD7FfVE for ; Mon, 11 Jun 2012 09:52:34 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C750121F8565 for ; Mon, 11 Jun 2012 09:52:33 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5BGqUL8029124; Mon, 11 Jun 2012 17:52:30 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5BGqTEC029112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 17:52:29 +0100 From: "Adrian Farrel" To: "'Stan Ratliff'" References: <001901cd45b0$ea911630$bfb34290$@olddog.co.uk> <4B441163-F58E-419C-B79D-D37EBF86BA11@cisco.com> In-Reply-To: <4B441163-F58E-419C-B79D-D37EBF86BA11@cisco.com> Date: Mon, 11 Jun 2012 17:52:27 +0100 Message-ID: <02f801cd47f2$96017cb0$c2047610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJopnWn98bqpEeQgUsY6OhmW1uriAHbJqLvAjb6aGEB5GKP/QHx84W/ASBvQl0CfBrbiJVibfVg Content-Language: en-gb Cc: 'manet' Subject: Re: [manet] Updating or replacing RFC 3626 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:52:35 -0000 Hi Stan, So, modulo some clarification of Obsoleted and Historical, I hear the WG and will adopt the proposal. I will suggest some text, during my AD review, for addition to the OLSRv2 spec to make the status of OLSRv1 (or rather the non-impact of OLSRv2 on the status of OLSRv1) completely clear. Cheers, Adrian For the record: The process described in RFC 2026 tends to suggest that "Historic" is coincident with "Obsoleted", but in practice these have been used differently for a considerable number of years. In fact, someone as young as myself has trouble recalling when they were ever handled the same. Current usage suggests that an RFC is made Historic when it is unlikely to be seen in the field, and when new implementations and deployments are considered a Bad Idea (TM). One RFC obsoletes another when the new one contains the best statement of the protocol for new implementations and deployments. Thus it is clear that an obsoleted RFC will (should) often be moved to Historic status, but that it will not always be the case. What I hear in this case is that, while OLSRv2 is the protocol recommended by the working group for implementation and wide-scale deployment, the WG also considers that there is continued value in implementation and experimental deployment of RFC 3626. > -----Original Message----- > From: Stan Ratliff [mailto:sratliff@cisco.com] > Sent: 09 June 2012 20:50 > To: Thomas Heide Clausen; Adrian Farrel > Cc: Teco Boot; Henning Rogge; manet > Subject: Re: [manet] Updating or replacing RFC 3626 > > So, I'm seeing consensus around Thomas' approach; namely, > > >>> > >>> I would vote for "Leave RFC 3626 in place for further experimentation", for > the time being > >> > > Adrian, is that an acceptable approach from the AD perspective? > > Regards, > Stan > > On Jun 9, 2012, at 9:27 AM, Thomas Heide Clausen wrote: > > > > > > > On 9 Jun 2012, at 12:03, Teco Boot wrote: > > > >> > >> Op 8 jun. 2012, om 23:21 heeft Thomas Heide Clausen het volgende > geschreven: > >> > >>> > >>> On 8 Jun 2012, at 23:05, Henning Rogge wrote: > >>> > >>>> Obsoleting RFC 3626 would make sense. > >>>> > >>>> There will be quite a few deployments with OLSR (v1) for a long time, > >>>> but OLSRv2 (because of RFC 5444) is a much better base for > >>>> experiments. > >>> > >>> The existence of "quite a few deployments with OLSR (v1)" is, to me, a very > good reason for not obsoleting OLSRv1 with the publication of OLSRv2 - I would > be very much against that, especially as OLSRv2 isn't "broken" per se. > >> Did you mean "OLSR (v1) isn't "broken" per se"? > >> > > > > Yes - good catch. Sorry. > > > >>> > >>> I would vote for "Leave RFC 3626 in place for further experimentation", for > the time being; eventually, it may make sense to mark it as "Historic", but I do not > think that we are there yet. > >> +1 > >> Historic means we do not take efforts to enhance it. It doesn't mean it is not > used anymore. > >> > >> Let us save our energy, RFC 3626's Experimental status is fine and OLSRv2 > doesn't update it. > >> > > > > +1 > > > > Thomas > > > >> Teco > >> > >> > >>> > >>> [We've got a proud history of co-existence when protocol versions are still in > use: OPSFv2/OSPFv3; IPv4/IPv6, ....] > >>> > >>> Best, > >>> > >>> Thomas > >>> > >>>> Henning Rogge > >>>> > >>>> On Fri, Jun 8, 2012 at 10:34 PM, Stan Ratliff wrote: > >>>>> Adrian, > >>>>> > >>>>> In that case, my vote as a WG member would be to obsolete RFC 3626. > >>>>> > >>>>> Other WG members? Please jump in. > >>>>> > >>>>> Regards, > >>>>> Stan > >>>>> > >>>>> On Jun 8, 2012, at 3:57 PM, Adrian Farrel wrote: > >>>>> > >>>>> PMFJI > >>>>> > >>>>> This thread has brought up a question that I need to ask as I review > OLSRv2 > >>>>> which you have requested goes for publication. > >>>>> > >>>>> In what way does the WG intend OLSRv2 to replace/update/deprecate > OSLRv1? > >>>>> > >>>>> There is a whole range of options, and what you choose depends largely > on > >>>>> what future exposure you think OLSRv1 should have. You could: > >>>>> > >>>>> - Move RFC 3626 to Historic > >>>>> - Obsolete RFC 3626 with OLSRv2 > >>>>> - Leave RFC 3626 in place for further experimentation > >>>>> - Update RFC 3626 as a separate activity to advance the experiment > >>>>> > >>>>> What I don't think you are doing with OLSRv2 is Updating RFC 3626. > >>>>> > >>>>> Thanks, > >>>>> Adrian > >>>>> > >>>>> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On > Behalf > >>>>> Of Stan Ratliff > >>>>> Sent: 08 June 2012 19:34 > >>>>> To: Teco Boot > >>>>> Cc: Dearlove, Christopher (UK); manet; Abdussalam Baryun > >>>>> Subject: Re: [manet] There is no document submitted so far to WG stating > an > >>>>> update request for RFC3626 > >>>>> > >>>>> Abdussalam, > >>>>> > >>>>> The first paragraph of the "Introduction" section of OSLRv2 states: > >>>>> > >>>>> "The Optimized Link State Routing protocol version 2 (OLSRv2) is the > >>>>> successor to OLSR (version 1) as published in [RFC3626]." > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> As such, I'm assuming that no additional work to RFC 3626 is expressed or > >>>>> implied - OLSRv1 is documented in RFC 3626; OLSRv2 is, for all intents and > >>>>> purposes, a new protocol documented by this new RFC. > >>>>> > >>>>> Regards, > >>>>> Stan > >>>>> > >>>>> > >>>>> On Jun 8, 2012, at 2:13 PM, Teco Boot wrote: > >>>>> > >>>>> > >>>>> > >>>>> Op 8 jun. 2012 om 19:25 heeft Abdussalam Baryun > > >>>>> het volgende geschreven: > >>>>> > >>>>> > >>>>> Hi Teco, > >>>>> > >>>>> > >>>>> > >>>>> More precisely, we work on a replacement for the initial experimental > >>>>> > >>>>> version. > >>>>> > >>>>> > >>>>> > >>>>> you mean that there is a work for replacement, I don't see any > >>>>> > >>>>> discussion befor about that, please advise, > >>>>> > >>>>> > >>>>> I guess you can find it in the archives. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> RFC 3626 is not updated. It could get historic one day. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> same what I thought, but one author of OLSRv2 mentioned that I may > >>>>> > >>>>> misunderstood the process of OLSRv2, even though the authors don't > >>>>> > >>>>> specify what will happen to RFC3626 when OLSRv2 is an RFC. I seen > >>>>> > >>>>> other I-D when submitted for IESG they put inside the draft what the > >>>>> > >>>>> draft authors intention if they obslete another documents or if their > >>>>> > >>>>> new draft is updating any thing, > >>>>> > >>>>> > >>>>> > >>>>> I have confidence in authors' knowledge on the proces. Dito for chairs. > >>>>> > >>>>> > >>>>> > >>>>> OLSRv2 does not mention the process of update, which IMHO it should if > >>>>> > >>>>> authors want to update RFC3626, > >>>>> > >>>>> > >>>>> I believe they don't. > >>>>> Same for workgroup. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> I may be wrong, but I hope the chair updates me with the status, may > >>>>> > >>>>> be he received a private request of update out of the discussion list, > >>>>> > >>>>> please advise, > >>>>> > >>>>> > >>>>> I guess you misunderstood him. > >>>>> > >>>>> Enjoy your weekend. > >>>>> Teco > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Regards > >>>>> > >>>>> > >>>>> > >>>>> AB > >>>>> > >>>>> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>>> > >>>>> > >>>>> > >>>>> On 6/8/12, Teco Boot wrote: > >>>>> > >>>>> > >>>>> > >>>>> Op 8 jun. 2012, om 14:31 heeft Henning Rogge het volgende geschreven: > >>>>> > >>>>> > >>>>> > >>>>> On Fri, Jun 8, 2012 at 1:44 PM, Abdussalam Baryun > >>>>> > >>>>> wrote: > >>>>> > >>>>> Hi Chris, > >>>>> > >>>>> > >>>>> > >>>>> Please note that MANET WG is doing OLSRv2 without updating RFC3626 > >>>>> > >>>>> which make people think why? > >>>>> > >>>>> > >>>>> > >>>>> This sentence doesn't make sense. > >>>>> > >>>>> > >>>>> > >>>>> OLSRv2 IS the update of RFC 3626. > >>>>> > >>>>> More precisely, we work on a replacement for the initial experimental > >>>>> > >>>>> version. > >>>>> > >>>>> RFC 3626 is not updated. It could get historic one day. > >>>>> > >>>>> > >>>>> > >>>>> Teco > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Are you sure you understand how the IETF works to update existing > >>>>> > >>>>> protocols? > >>>>> > >>>>> > >>>>> > >>>>> Henning Rogge > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> > >>>>> Steven Hawkings about cosmic inflation: "An increase of billions of > >>>>> > >>>>> billions of percent in a tiny fraction of a second. Of course, that > >>>>> > >>>>> was before the present government." > >>>>> > >>>>> _______________________________________________ > >>>>> > >>>>> manet mailing list > >>>>> > >>>>> manet@ietf.org > >>>>> > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> manet mailing list > >>>>> manet@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>>> _______________________________________________ > >>>>> manet mailing list > >>>>> manet@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> manet mailing list > >>>>> manet@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/manet > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Steven Hawkings about cosmic inflation: "An increase of billions of > >>>> billions of percent in a tiny fraction of a second. Of course, that > >>>> was before the present government." > >>>> _______________________________________________ > >>>> manet mailing list > >>>> manet@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/manet > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> From sratliff@cisco.com Mon Jun 11 09:55:03 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1B21F8645 for ; Mon, 11 Jun 2012 09:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uPhUg0kT6weJ for ; Mon, 11 Jun 2012 09:55:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 447B721F84BF for ; Mon, 11 Jun 2012 09:55:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=2944; q=dns/txt; s=iport; t=1339433702; x=1340643302; h=from:subject:date:references:to:message-id:mime-version; bh=wKytQlwcwdjIxXf9cQm1+K3U7N+yPDWeJj3UoUyLEUU=; b=bDFlg+XYE0fEG6b3uy1Dto0AV8S8otU1eZNXb/nYn1b9cCmr5EotZoFi mH8heufoO7x7mZW2wAXiJvkhX2Pz+McQPAfBejgDUPpMoRF0Mk44DtzRp FZal+ParB9gfjsAJxXympMfd9NBn+b4RhBwCRr1F8lzVy9pqAG+a96C/3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmMGAH0i1k+tJV2c/2dsb2JhbABFpGqHMgGIfIEHghgBAQEDARIBawsPDQMBAi9NAggGEyKHZAULmGOfVYskhQlgA5UegRKNA4Fmgnw X-IronPort-AV: E=Sophos;i="4.75,750,1330905600"; d="scan'208,217";a="91197069" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jun 2012 16:54:56 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q5BGsub4000651 for ; Mon, 11 Jun 2012 16:54:56 GMT From: Stan Ratliff Content-Type: multipart/alternative; boundary="Apple-Mail=_5130B41E-8FDB-40A5-8EAC-740480F58B91" Date: Mon, 11 Jun 2012 12:54:56 -0400 References: <20120611161215.5982.54913.idtracker@ietfa.amsl.com> To: manet IETF Message-Id: <322204E7-FF58-477E-8012-0963D4B571CC@cisco.com> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [manet] Fwd: ID Tracker State Update Notice: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:55:03 -0000 --Apple-Mail=_5130B41E-8FDB-40A5-8EAC-740480F58B91 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii FYI Regards, Stan Begin forwarded message: > From: IETF Secretariat > Subject: ID Tracker State Update Notice: > Date: June 11, 2012 12:12:15 PM EDT > To: , > > State changed to AD Evaluation from Publication Requested > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ > --Apple-Mail=_5130B41E-8FDB-40A5-8EAC-740480F58B91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: IETF Secretariat = <ietf-secretariat-reply@iet= f.org>
Subject: ID Tracker State Update Notice: = <draft-ietf-manet-olsrv2-15.txt>
Date: June 11, 2012 = 12:12:15 PM EDT

State changed to AD = Evaluation from Publication Requested
ID Tracker URL: http://d= atatracker.ietf.org/doc/draft-ietf-manet-olsrv2/


= --Apple-Mail=_5130B41E-8FDB-40A5-8EAC-740480F58B91-- From abdussalambaryun@gmail.com Tue Jun 12 03:01:45 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAFD21F8512 for ; Tue, 12 Jun 2012 03:01:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4Wz3A+huPMq for ; Tue, 12 Jun 2012 03:01:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 646BA21F84FB for ; Tue, 12 Jun 2012 03:01:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3272185vbb.31 for ; Tue, 12 Jun 2012 03:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=1ajXmRLFkjwqJUM9PljfiuewRzK1fwvQpd+RvXjV49o=; b=Jvw6ZwC2/ACOfjoSDWGupHQqPf/KpQM80lXjm4JFEpD0BrFOYWx7fHHSscf6Zs9hPi exwGT94C10C0hOtusk37uV/K6+UUIirOP6XECKP20SxcooZcGaKwLb4JFSdqQHZGYS6I QmYywuIK5bDTUQ6wbZu1g7t/preIuTeAlcCFrDxssMw3dTog4kjEWjCytW78rYTdAPqV ons03lkss0l/4cb7L/3lNzPupQrvvQIWWT8a81ApnaC2zvKjgwJkN9pxzciGV0WARlPU vCV+Y0qO+pz1D0axiIDnQ1L6jl/OGqKv7WGdP2i5wMndDh4CwVMNMfUnkVIKnmAzDF6J kUUA== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr12126602vdb.10.1339495302807; Tue, 12 Jun 2012 03:01:42 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 12 Jun 2012 03:01:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Jun 2012 12:01:42 +0200 Message-ID: From: Abdussalam Baryun To: Thomas Heide Clausen Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 10:01:45 -0000 Dear Thomas, I don't understand why you mentioning that I suggested that 'MANET WG chairs are not doing their job'. Please note that I never written nor said that ever (under this above subject and even in all my posts with other subjects). I beleive that they are doing their job, please inform me where you seen that, then I can/will reply to your below email. However, I thank you for your email because we need to make things clear ;) You maybe misunderstood, with the ad-hoc-autoconfig WG (in another post subject). Which I did not blame them either, but I just mentioned that it was the fault of WG and chairs of the close. Abdussalam Baryun +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/11/12, Thomas Heide Clausen wrote: > Dear Abdussalam, > > First of all, it is always encouraging when new people become interested = a > domain we've been working on for the past 15 or so years in the IETF. > > Also, over the past 15 years, a great many things have been brought forth= , > discussed, experimented, consensus reached (sometimes rough consensus - b= ut > that's the game), and decisions made - leading to the work-items that are > currently active in the working group, and the designs that are currently > the fundament of those work-items (roughly: the currently active I-Ds in = the > group). > > The working group chairs have the thankless job of getting progress on th= ose > work-items. That's actually quite bit more complex than what may meet the > eye: constraints and requirements from elsewhere in the IETF, such as > security and MIBs and ...., as well as whipping (not too hard ;) ) variou= s > authors to produce updated documents, getting timely cross-area reviews, > ...... and of course, ensure that the mailing list is available for > discussions of related topics. > > I for one think that the MANET wg chairs are striking a fairly good balan= ce > and are doing a good, no great, job at seeing things progress through the > process to completion. > > It is honorable to be curious as to the history, and wanting to understan= d > how decisions were made and how consensus was reached. That is why - I gu= ess > - that some have pointed you to some of the mailing list archives (for > manet@ietf as well as other lists) so that you may be able to acquire suc= h > understanding. I am sure that you understand that we can't rehash every > discussion that's happened in the past 15 years " on a whim" if, at the s= ame > time, we want to get progress on the work-items that are before us. > > I do not think that it's particularly helpful or productive to suggest th= at > the WG chairs are not doing their job (they definitely are), that the ADs > are not doing their job (they definitely are too!) or that references to > mailing list archives are inappropriate: I allow myself to remind you tha= t > working group mailing lists are where official working group business is > conducted, arguments advanced and (rough) consensus established and > confirmed - so, if anything, those archives are the right place to point = you > for further information. > > Rough consensus and running code ;) > > Thomas > > On Jun 9, 2012, at 12:09 , Abdussalam Baryun wrote: > >> Hi Folks, >> >> IMHO, there are difference between discussion that MAY become >> argumentable and/or debatable. In a healthy-discussion you produce new >> ideas and educate yourself and others, but in unproductive-discussion >> you MAY block any progress and waste time. I define productive >> discussion as the posting/speaking of a point of view referenced by >> scientific facts or RFCs. I define debates as the posting/speaking of >> points without good-referencing or without good-reasoning. IMHO these >> debating inputs with no good reference will not provide progress in >> discussions, even though it may (in low probability) start indirectly >> an interest/input to a work-in-progress. >> >> For example, in one of the WG discussion on list, two members of WG >> have referenced a history-discussion and informed me to read them >> regarding some subject, I did do that but was *lost in translation*. I >> now think that the memebrs' advise was to a wrong direction. We SHOULD >> NOT refer in our current discussions to any other >> history-subjected-discussions (thoes discussion had no approve by WG >> consensus nor IESG review) in any WGs. Also referring to old >> discussions in the list result to waste time and MAY make current >> arguments long (i.e. long means more than 5 working days), or even >> makes the current argument unproductive.Old-discussions MAY be >> misleading/incorrect/invalid, even if they are helpful to gain some >> knowledge. >> >> We should *reference* mostly RFCs in our discussion, because RFCs are >> correct resource. The reason is because only RFCs are productions of >> healthy discussions and reviewed by experts in IESG. IMHO the IETF >> sees that RFCs are the correct-progress-reference. All Discussions are >> important for the IETF processes and to produce RFCs. Memebers of the >> WG should try to direct their discussions in the direction of progress >> without discouraging debate-input. Discussions that produce I-D that >> in the end submits are the most productive >> discussions. IMO it is accepted in discussions to reference scientific >> research papers, reviewed publications, industry experience, or RFCs, >> but please don=92t accept in discussion the validity of ; a) a reference >> to a specific historic discussion that possibly were with wrong >> arguments, or b) a reference to unproductive discussions. >> >> In conclusion, we should try with the help of the WGs chairs to direct >> our discussions to become more productive, and within a reasonable >> time, and if we see any good-correct ideas, we SHOULD react quickly >> and input in a informational I-D and submit to WG for approval so we >> don't repeat refering to wrong-argumental-discussion. >> >> If you feel differently please advise, thanking you :) >> >> Best regards >> >> Abdussalam Baryun >> University of Glamorgan, UK. >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >> < In discussions one may be wrong, or may be right, but it does not >> matter if we work together as a group to progress and resolve all >> issues. IETF WGs are always right > >> ************************************************************************= **************** >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From teco@inf-net.nl Tue Jun 12 04:55:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A3D21F8668 for ; Tue, 12 Jun 2012 04:55:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDKu6q5n8CQ3 for ; Tue, 12 Jun 2012 04:55:39 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAA6D21F8667 for ; Tue, 12 Jun 2012 04:55:38 -0700 (PDT) Received: by eaaq13 with SMTP id q13so3020297eaa.31 for ; Tue, 12 Jun 2012 04:55:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=au6CBRPOEd3XMONSF9pdk/LE0IV0H8E+xEMfUZiQKyE=; b=IsPKaHDXL4h2VKI+3zEEGs4zmCAHRlo52dIrZy/LlGi7K1Kr7aCHc6sRV5lqAezx9t 1wEyRjtB21hYYL8jYfCFrpWxUyJrrJCr3QRtnHvJ3B3J8BMIbi4YM6S7ldGpaRLXr5Tg 2uc6i9JOxJRPGDZ1ZvgZJjHbXSca4oZZmlmpiRYwNggprVL1ayO4CeljkFGGnb/tzD+F i8Mx1pDPmJdiSGw1gGlG8nKRaeWpZNhSPT7vcLJUbVDnoV2iUqz641lipMXFowVTZmAk x9hs7WN70uxO2UTMZ13ZPIv4L8xkVRkMyEZlKKuHZs3coZ3yp/BQBlJHQUkje90m+zDs lAtw== Received: by 10.14.187.142 with SMTP id y14mr99314eem.215.1339502137469; Tue, 12 Jun 2012 04:55:37 -0700 (PDT) Received: from [172.16.4.184] ([188.205.88.52]) by mx.google.com with ESMTPS id n52sm63495780eeh.9.2012.06.12.04.55.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 12 Jun 2012 04:55:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Tue, 12 Jun 2012 13:55:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0F3A15F1-47CA-4DA3-A163-7E936A0033AE@inf-net.nl> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQni9I6wScRBN+L5c/ao5UEKlYMNXBaZGu7ow7s2iiG+g9gwS5FReLTqI6q/iBemPR7+UEP4 Cc: MANET List Subject: Re: [manet] Comments and Discussions on the MANET list X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 11:55:40 -0000 Could you try to be productive? I suggest you post drafts=20 on your ideas and ask the WG chairs a few minutes next meeting for presenting. Please keep it short. Recent postings costs us already a fairly amount of time. No need to respond... Teco Op 12 jun. 2012, om 12:01 heeft Abdussalam Baryun het volgende = geschreven: > Dear Thomas, >=20 > I don't understand why you mentioning that I suggested that 'MANET WG > chairs are not doing their job'. Please note that I never written nor > said that ever (under this above subject and even in all my posts with > other subjects). I beleive that they are doing their job, please > inform me where you seen that, then I can/will reply to your below > email. However, I thank you for your email because we need to make > things clear ;) >=20 > You maybe misunderstood, with the ad-hoc-autoconfig WG (in another > post subject). Which I did not blame them either, but I just mentioned > that it was the fault of WG and chairs of the close. >=20 > Abdussalam Baryun > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On 6/11/12, Thomas Heide Clausen wrote: >> Dear Abdussalam, >>=20 >> First of all, it is always encouraging when new people become = interested a >> domain we've been working on for the past 15 or so years in the IETF. >>=20 >> Also, over the past 15 years, a great many things have been brought = forth, >> discussed, experimented, consensus reached (sometimes rough consensus = - but >> that's the game), and decisions made - leading to the work-items that = are >> currently active in the working group, and the designs that are = currently >> the fundament of those work-items (roughly: the currently active I-Ds = in the >> group). >>=20 >> The working group chairs have the thankless job of getting progress = on those >> work-items. That's actually quite bit more complex than what may meet = the >> eye: constraints and requirements from elsewhere in the IETF, such as >> security and MIBs and ...., as well as whipping (not too hard ;) ) = various >> authors to produce updated documents, getting timely cross-area = reviews, >> ...... and of course, ensure that the mailing list is available for >> discussions of related topics. >>=20 >> I for one think that the MANET wg chairs are striking a fairly good = balance >> and are doing a good, no great, job at seeing things progress through = the >> process to completion. >>=20 >> It is honorable to be curious as to the history, and wanting to = understand >> how decisions were made and how consensus was reached. That is why - = I guess >> - that some have pointed you to some of the mailing list archives = (for >> manet@ietf as well as other lists) so that you may be able to acquire = such >> understanding. I am sure that you understand that we can't rehash = every >> discussion that's happened in the past 15 years " on a whim" if, at = the same >> time, we want to get progress on the work-items that are before us. >>=20 >> I do not think that it's particularly helpful or productive to = suggest that >> the WG chairs are not doing their job (they definitely are), that the = ADs >> are not doing their job (they definitely are too!) or that references = to >> mailing list archives are inappropriate: I allow myself to remind you = that >> working group mailing lists are where official working group business = is >> conducted, arguments advanced and (rough) consensus established and >> confirmed - so, if anything, those archives are the right place to = point you >> for further information. >>=20 >> Rough consensus and running code ;) >>=20 >> Thomas >>=20 >> On Jun 9, 2012, at 12:09 , Abdussalam Baryun wrote: >>=20 >>> Hi Folks, >>>=20 >>> IMHO, there are difference between discussion that MAY become >>> argumentable and/or debatable. In a healthy-discussion you produce = new >>> ideas and educate yourself and others, but in = unproductive-discussion >>> you MAY block any progress and waste time. I define productive >>> discussion as the posting/speaking of a point of view referenced by >>> scientific facts or RFCs. I define debates as the posting/speaking = of >>> points without good-referencing or without good-reasoning. IMHO = these >>> debating inputs with no good reference will not provide progress in >>> discussions, even though it may (in low probability) start = indirectly >>> an interest/input to a work-in-progress. >>>=20 >>> For example, in one of the WG discussion on list, two members of WG >>> have referenced a history-discussion and informed me to read them >>> regarding some subject, I did do that but was *lost in translation*. = I >>> now think that the memebrs' advise was to a wrong direction. We = SHOULD >>> NOT refer in our current discussions to any other >>> history-subjected-discussions (thoes discussion had no approve by WG >>> consensus nor IESG review) in any WGs. Also referring to old >>> discussions in the list result to waste time and MAY make current >>> arguments long (i.e. long means more than 5 working days), or even >>> makes the current argument unproductive.Old-discussions MAY be >>> misleading/incorrect/invalid, even if they are helpful to gain some >>> knowledge. >>>=20 >>> We should *reference* mostly RFCs in our discussion, because RFCs = are >>> correct resource. The reason is because only RFCs are productions of >>> healthy discussions and reviewed by experts in IESG. IMHO the IETF >>> sees that RFCs are the correct-progress-reference. All Discussions = are >>> important for the IETF processes and to produce RFCs. Memebers of = the >>> WG should try to direct their discussions in the direction of = progress >>> without discouraging debate-input. Discussions that produce I-D that >>> in the end submits are the most = productive >>> discussions. IMO it is accepted in discussions to reference = scientific >>> research papers, reviewed publications, industry experience, or = RFCs, >>> but please don=92t accept in discussion the validity of ; a) a = reference >>> to a specific historic discussion that possibly were with wrong >>> arguments, or b) a reference to unproductive discussions. >>>=20 >>> In conclusion, we should try with the help of the WGs chairs to = direct >>> our discussions to become more productive, and within a reasonable >>> time, and if we see any good-correct ideas, we SHOULD react quickly >>> and input in a informational I-D and submit to WG for approval so we >>> don't repeat refering to wrong-argumental-discussion. >>>=20 >>> If you feel differently please advise, thanking you :) >>>=20 >>> Best regards >>>=20 >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>>=20 >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> < In discussions one may be wrong, or may be right, but it does not >>> matter if we work together as a group to progress and resolve all >>> issues. IETF WGs are always right > >>> = **************************************************************************= ************** >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Wed Jun 20 06:46:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E472721F8631 for ; Wed, 20 Jun 2012 06:46:55 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 u3eRkkU4BSZK for ; Wed, 20 Jun 2012 06:46:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBCAF21F8551 for ; Wed, 20 Jun 2012 06:46:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4461810vbb.31 for ; Wed, 20 Jun 2012 06:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Qg0f02v+CezAi62TM3WdpBaVNhhhPWjn8fIrfVx3EeY=; b=v1LBYK7BSiCKY2Q1kU/3dlhbWsHUHXAQGXXbOi1hlT2Y5I4dFAtJ0tqkMwjYu3iUpz Bpc6uTq1mPL3CZ6/xW71jNbiliKtH1LiYVrpaGcz7QD1Mpb508khsOrRIyD4GeePphOa ayDym7afXOEdC/A8TtZMAxdzwWXdz6dTEIH+4Mwv+rZvlWQqNiyX2Z6z+g9ZJCSSIkMk x7SgG/yq9JVeFriiCBuONtl3WPdhdTLA5mDV1e6mGR1FC4kr1Z6lSyDUwKb+PeSBe6xX JDIonDEgOi1qqVmjUNAAP4aoOPSIIXIxxXuINIjGHXGlkY/RQdx/R5oD0EjYLiADs6QF 7+ig== MIME-Version: 1.0 Received: by 10.220.228.193 with SMTP id jf1mr2492588vcb.73.1340200014446; Wed, 20 Jun 2012 06:46:54 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Wed, 20 Jun 2012 06:46:54 -0700 (PDT) Date: Wed, 20 Jun 2012 15:46:54 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Request to update MANET-WG-Milestones X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2012 13:46:56 -0000 As copied below from 2012-06-13-Charter, checking the milestones of MANET WG, please update the NHDP and SMF works are already [Done], but not amended, DLEP work does not appear as milestone, please add, AB ============================ Goals and Milestones: Done - Post as an informational Internet-Drafts a discussion of mobile ad-hoc networking and issues. Done - Agenda bashing, discussion of charter and of mobile ad hoc networking draft. Done - Discuss proposed protocols and issues. Redefine charter. Done - Publish Informational RFC on manet design considerations Done - Review the WG Charter and update Done - Submit AODV specification to IESG for publication as Experimental RFC Done - Develop I-D for potential common manet encapsulation protocol approach Done - Submit initial I-D(s) of candidate proposed routing protocols and design frameworks Done - Promote implementation, revision, and testing of initial proposed I-D(s) Done - Explore basic performance and implementation issues of initial approaches Done - Explore proposed proactive protocol design commonalities Done - Submit DSR specification to IESG for publication as Experimental RFC Done - Submit OLSR specification to IESG for publication as Experimental RFC Done - Submit TBRPF specification to IESG for publication as Experimental RFC Done - Develop a further focused problem statement and address an approach for a common engineering work effort Done - Reevaluate the WG's potential based on the problem statement consensus Done - Submit initial ID of RMP for WG review Done - Submit initial ID of PMP for WG review Done - Submit inital ID of generalized MANET flooding approach Done - Revise WG documents and review Done - Document initial implementation progress and experience Revise documents based upon implementation experience Done - Submit initial WG ID on Neighborhood Discovery (NHDP) Done - Submit PacketBB to IESG Done - Submit initial WG ID on MIB for NHDP, DYMO, OLSRv2 Apr 2007 - Submit NHDP to IESG Apr 2007 - Submit DYMO to IESG Apr 2007 - Submit OLSRv2 to IESG Apr 2007 - Submit SMF to IESG ======================================= From abdussalambaryun@gmail.com Thu Jun 21 09:10:56 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B4821F875A for ; Thu, 21 Jun 2012 09:10:56 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 O6W6KwWcTjFB for ; Thu, 21 Jun 2012 09:10:51 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE64B21F8682 for ; Thu, 21 Jun 2012 09:10:50 -0700 (PDT) Received: by vcqp1 with SMTP id p1so471531vcq.31 for ; Thu, 21 Jun 2012 09:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=1Z5Vp30YXyIZTcRT253lpUZxljCdzhDmZ8tj4iiLTVI=; b=LqeLD5gKttojXi8BWZCYvXRHIRRxaSNoi+Pd/lPCyeC2KD+nsYuz22hpieGiHvVKWn RkJowgslDmAe7ypOjriZ028wk8eBZyUj/2dpIcpwlxvxnlCEyn72qdG0rKOCbaZNsqjU kJzlHvtoBrmVM96TVkzFk212rSRTF54lB76xopEmKGFaatdTZaWsYzYGeSaIMUqbJMvD iLbke7mGraahN9neXdWAL2njx2xP9hn08qnhMzAu4p7IQZtxMEEKPZ2zb5G7K05Ni6SH 4tYuEDcRf5YplEGLPrkVfHk+Hmk+NiyG4bFMjfFci+MljmFrrBXG6KUv+SmBDBvVPm9I 6eUA== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr13946037vcw.55.1340295050193; Thu, 21 Jun 2012 09:10:50 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Thu, 21 Jun 2012 09:10:49 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jun 2012 18:10:49 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Could we Update RFC2501? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 16:10:56 -0000 >Could we Update RFC2501? I see that RFC2501 some how defines MANET technologies, which will be a good reference in the draft I am writting of L2 subnets, but maybe RFC2501 is enough for the protocols, and no need for a new draft. However, that will depend on the WG discussion and decision :) I got no answer of the question so far, therefore, I will propose it to be discussed in the next meeting IETF 84. AB ===================================================== On 6/6/12, Abdussalam Baryun wrote: > Hi Folks, > > the RFC2501 is the best RFC I read and I like it because it is easy to > read, understandable, and covers solid issues of MANET. I hope the > authors give us a feedback if they want to make new one as Version 2. > > I see that it is old (1999), and it may be interesting to update it > some how, I hope the authors can update its issues and evaluation, now > we got new RFCs and industries have new needs than 90s, it does not > cover different devices constraints as sensors and LLNs, and IPv6, > 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are > getting renew versions. > > As I can see OLSRv2 and AODVv2 are going in progress, why we don't try > to update RFC2501 as well, it will only take few days or a month, to > draft and submit so why leave it old-documents with old > considerations? Please advise, > > Abdussalam Baryun > University of Glamorgan, UK. > ========================================================= > From charliep@computer.org Thu Jun 21 14:58:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23F811E8072 for ; Thu, 21 Jun 2012 14:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.281 X-Spam-Level: X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599] 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 Nuxryzg+8M0e for ; Thu, 21 Jun 2012 14:58:55 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5F11E807F for ; Thu, 21 Jun 2012 14:58:55 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1ShpOw-0004ss-Ja; Thu, 21 Jun 2012 17:58:54 -0400 Message-ID: <4FE3991E.6020707@computer.org> Date: Thu, 21 Jun 2012 14:58:54 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86fa0a00d8b3871853ec815e4493c723ab350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] Could we Update RFC2501? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2012 21:58:56 -0000 Hello Abdussalam, I didn't see what part of RFC 2501 needed to be revised. Do you have a specific proposal? I think that, before you could expect any discussion on revising that document, you would have to point out what part or parts need work. Regards, Charlie P. On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >> Could we Update RFC2501? > I see that RFC2501 some how defines MANET technologies, which will be > a good reference in the draft I am writting of L2 subnets, but maybe > RFC2501 is enough for the protocols, and no need for a new draft. > However, that will depend on the WG discussion and decision :) > > I got no answer of the question so far, therefore, I will propose it > to be discussed in the next meeting IETF 84. > > AB > ===================================================== > On 6/6/12, Abdussalam Baryun wrote: >> Hi Folks, >> >> the RFC2501 is the best RFC I read and I like it because it is easy to >> read, understandable, and covers solid issues of MANET. I hope the >> authors give us a feedback if they want to make new one as Version 2. >> >> I see that it is old (1999), and it may be interesting to update it >> some how, I hope the authors can update its issues and evaluation, now >> we got new RFCs and industries have new needs than 90s, it does not >> cover different devices constraints as sensors and LLNs, and IPv6, >> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >> getting renew versions. >> >> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >> to update RFC2501 as well, it will only take few days or a month, to >> draft and submit so why leave it old-documents with old >> considerations? Please advise, >> >> Abdussalam Baryun >> University of Glamorgan, UK. >> ========================================================= >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From abdussalambaryun@gmail.com Fri Jun 22 13:54:57 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC1011E80C9; Fri, 22 Jun 2012 13:54:57 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 lmwQsEosJs3E; Fri, 22 Jun 2012 13:54:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3C11E80C7; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1226464vbb.31 for ; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=on0C8nVMgAfO4V31apkRbQ+9xKVa/hTXBBvz7KRc5eg=; b=pZYqV1iSYOpfVhYtLm2eYhnROZYPdNjhpymZ9DshzUYLjTemOu9dGCpMqTc6dkk8wo gzsw3aBkf1YzQDAdi8kUe+Tymb/vVEEtCa87KGm1Vhc8rbGaR4RvxRgnyaQAdzbVmWdK fyjGJkolxvbWXJzn14aRita3DsQg3tfTNDwcZdrOKOKAnhYJ0mOzFXg4lN6E6EjicwzN xcFdvbCRkGkOAfXKnx+0Tnk/oFgPBbjm6CM9JVhUWu3n/Ar33RMlGrRUXsvE0NLqPluV PqHxAHkFHU5bofnXGK5e75DP2JknbUOg1vPqa3KK4+rvuCWNmeWpO4m8pblmdIbkqtGa Vk5Q== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr1436385vds.117.1340398496057; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 22 Jun 2012 13:54:55 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Fri, 22 Jun 2012 22:54:55 +0200 Message-ID: From: Abdussalam Baryun To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Pascal Thubert \(pthubert\)" , manet , roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [manet] [Roll] Node Ability to Participate (NAP) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 20:54:58 -0000 Hi C=E9dric, I am writing the draft for NAP, and studying different approaches. Yes RFC6551 will help thanks, I see in may be used under the . I will try to update the ROLL WG in the coming weeks, with my final suggestions for this idea protocol. The general idea is that each node may get to a situation to advertise its *ability* limits for the network benefit, on the other hand, some nodes in some situation may request information about such *ability* for their benefit. I think the NAP idea and protocol can be used for LLN, MANET and other dynamic networks. I thank you again for you comments, Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On 6/22/12, C Chauvenet wrote: > Hi, > > Could RFC6551 (the ex-metric draft) help ? > > I think the metric container option could embed a constraint to adress t= he > NAP functionality you are describing > > Best, > > C=E9dric. > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > Abdussalam Baryun > Envoy=E9 : vendredi 8 juin 2012 05:48 > =C0 : Pascal Thubert (pthubert) > Cc : roll; roll-owner > Objet : Re: [Roll] Node Ability to Participate (NAP) > > Hi Pascal, > > I was thinking of route-control enhancement, not network management, > however, I agree it is an iteresting issue as well, you gave me a new poi= nt, > thanks, > > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On 6/7/12, Pascal Thubert (pthubert) wrote: >> Hello Abdussalam: >> >> I'd say it is a great discussion that might end up impacting routing. >> But also basic network operations (DNS, DHCP ...) and services. >> So where is the right place to start with? >> Tthe COMA mailing list is starting about network management, and I'd >> have thought that your discussion could begin there. >> >> What do you think? >> >> >> " >> List address: coma@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/coma/ >> To subscribe: https://www.ietf.org/mailman/listinfo/coma >> >> Purpose: This list is for the discussion related to the management of >> constrained networks and devices. The IETF so far has not developed >> specific technologies for the management of constrained networks. >> There is a need to understand the requirements for the management of >> such a constrained network and its devices. >> " >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of Abdussalam Baryun >> Sent: jeudi 7 juin 2012 11:00 >> To: roll >> Cc: roll-owner >> Subject: [Roll] Node Ability to Participate (NAP) >> >> +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ >> Hi All, >> >> I want to discuss is there a need to consider the node ability to >> participate (NAP) in LLN functions? >> >> I think that the node ability (considering; energy consumption issue, >> routing issue, and environment-event issue), it is good for some >> node-originators to know neighbor nodes/sinks ability ( NAP to-route, >> or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP >> to-manage, or other abilities), but not sure if it is available in >> some of the ROLL or 6lowpan protocols, nor sure if it can make side >> effects to LLN performance. The node-ability can be useful if we have >> different devices capabilities and conditions. This knowledge-factor >> can be useful and may be included in some technique, or forwarding table >> in the protocol specification. >> >> I want to know your advises and opinion, thanking you, >> >> Best regards >> >> Abdussalam Baryun, >> University of Glamorgan, UK. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> < One may be wrong, or may be right, but it does not matter if we >> work together as a group to discuss and resolve all issues. IETF WGs >> are always right > >> ********************************************************************** >> ****************** 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. The contents are comply to the IETF regulations, and WG >> procedures. You should not copy the email nor use it for any purpose >> other than IETF procedures' purposes. >> ********************************************************************** >> ******************* _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > From abdussalambaryun@gmail.com Fri Jun 22 14:29:15 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D953F21F85E5 for ; Fri, 22 Jun 2012 14:29:15 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SoPUPNusInHV for ; Fri, 22 Jun 2012 14:29:15 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67221F85E4 for ; Fri, 22 Jun 2012 14:29:15 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1236996vcq.31 for ; Fri, 22 Jun 2012 14:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=B2IluGe0MVcrEeOyykzMrkADTyqfYME4T11+MLkZ8vI=; b=LwXlhLRB2oWIbozlcvx4cn114MUa8S2KPfLOziIheF/a/ndmQW6u8+SgIRm+/O4m+E K0JutvOPc8YKh0Q3mONjUd8CCzpei5ID/r4HHm1RG+b89115pG/53aVBjUNpCYSrOPnY zVrxbQ7fczf6jfIjtbvu+DwFxngPL1qccXVNdEND5H4/wfmQ4xcYNCDnRv0yD1EDZ4qq QPQEJ5su3BpwrD7myGI4AFaCvDHi6fGZFp7G6YQ106FhnE+lJKO4H90ZtRnGAvMRUcE6 sXSQz+Go3JokUOlAcnuXXLxUSM51PMw/QkM8FznNv2gIvnwznQUhybrv5d5JOJ7mf+aR L4/w== MIME-Version: 1.0 Received: by 10.220.228.193 with SMTP id jf1mr1811060vcb.73.1340400554372; Fri, 22 Jun 2012 14:29:14 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 22 Jun 2012 14:29:13 -0700 (PDT) In-Reply-To: <4FE3991E.6020707@computer.org> References: <4FE3991E.6020707@computer.org> Date: Fri, 22 Jun 2012 23:29:13 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Could we Update RFC2501? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 21:29:16 -0000 Hi All, Thanks Charlie, I will do the proposal in details, and post shortly, My idea was about including: new MANET-issues, LLN considerations, R2RI technology, and others,, If there are any ideas of other proposed updates, please advise, Regards Abdussalam ================================================ On 6/21/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > I didn't see what part of RFC 2501 needed to be revised. > Do you have a specific proposal? I think that, before you > could expect any discussion on revising that document, > you would have to point out what part or parts need > work. > > Regards, > Charlie P. > > On 6/21/2012 9:10 AM, Abdussalam Baryun wrote: >>> Could we Update RFC2501? >> I see that RFC2501 some how defines MANET technologies, which will be >> a good reference in the draft I am writting of L2 subnets, but maybe >> RFC2501 is enough for the protocols, and no need for a new draft. >> However, that will depend on the WG discussion and decision :) >> >> I got no answer of the question so far, therefore, I will propose it >> to be discussed in the next meeting IETF 84. >> >> AB >> ===================================================== >> On 6/6/12, Abdussalam Baryun wrote: >>> Hi Folks, >>> >>> the RFC2501 is the best RFC I read and I like it because it is easy to >>> read, understandable, and covers solid issues of MANET. I hope the >>> authors give us a feedback if they want to make new one as Version 2. >>> >>> I see that it is old (1999), and it may be interesting to update it >>> some how, I hope the authors can update its issues and evaluation, now >>> we got new RFCs and industries have new needs than 90s, it does not >>> cover different devices constraints as sensors and LLNs, and IPv6, >>> 6LoWPAN, furthermore, some old MANET routings RFC3561, RFC3626 are >>> getting renew versions. >>> >>> As I can see OLSRv2 and AODVv2 are going in progress, why we don't try >>> to update RFC2501 as well, it will only take few days or a month, to >>> draft and submit so why leave it old-documents with old >>> considerations? Please advise, >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>> ========================================================= >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From abdussalambaryun@gmail.com Tue Jun 26 04:40:16 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8592C21F862A for ; Tue, 26 Jun 2012 04:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 oMUCdpZ6iQjC for ; Tue, 26 Jun 2012 04:40:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CFC0321F8631 for ; Tue, 26 Jun 2012 04:40:15 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2917035vbb.31 for ; Tue, 26 Jun 2012 04:40:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=afezteqdsK8qM9WN4sVHprAzp7C6MxNv7EP65zIdqzM=; b=LSkhOpfSAXdGTpYwVLodZHlA2BJ9YNDMFX07bwYfO+miCilcjEKH+0rCFI5AbsrRsV uI3VY/Tb5LbeUrEiEFYt9RQGWYNw4EC5+1h5mvUVRoqDZhGxpKVWicpHQXswtEc4ND/b JdC97K4iAxhzNzGdi2QUH7aiqDtQ8NyC3AmGLcoSz4fCtLwHFRNrjmfGnR18SpggqQcA 4I07j2JZRoxHcYElsp1zBg0wgyehdgvJ2obXTpJoD/+GQ/BrID1uMk0WIJ+2Fs71U2hq JkjkB7lYo4U3Hkcd5nvJN35t+TkCq5HQAgI8k0+ygj1+QkT3kpMRiHR3BsEvlNXOIOxs OssQ== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr8833169vdb.66.1340710815334; Tue, 26 Jun 2012 04:40:15 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Tue, 26 Jun 2012 04:40:15 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 13:40:15 +0200 Message-ID: From: Abdussalam Baryun To: Emmanuel.Baccelli@inria.fr, "charliep@computer.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] draft-baccelli-manet-multihop-communication-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 11:40:16 -0000 Hi Emmanuel and Perkins, To add to my previous posts, I RECOMMEND also to include Mobile-IP [RFC6275] to be considered and referenced with its relations to the draft models, Best Regards Abdussalam Baryun ================= From abdussalambaryun@gmail.com Tue Jun 26 05:09:06 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AF621F8599 for ; Tue, 26 Jun 2012 05:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 EQimDYRxcaP8 for ; Tue, 26 Jun 2012 05:09:06 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E102221F8596 for ; Tue, 26 Jun 2012 05:09:05 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2932503vcq.31 for ; Tue, 26 Jun 2012 05:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vcAFP6BzG7tqT4qks6Rac/F3KLednw8w1LWOJWciPyc=; b=noaszGOSLYtwEazJux9pcmmBhz66oDiiwvU9oQ8zrKhn6sBywZlFN9X4rEaYGAtGaj +1XXr5K3lLc4YWEjgoyZ/+UC9u9nhyGWtde4v3MTg5CkJGJWvS6lb4NY/UVXvE4P1pn3 PZDdGgkvs5VSVn9Ybi4Ji7yTo6qzNmcUUqqBxKO7jYKgMZi7JH+sXJ+B2ffi/fOPdCLL mt4oPOMjDfjSjnxKWs7drdJ3QC0reztepnnPD/ojdRof60BljdZQQPP/86dHp5fvUfjD no5p/C+1j9mwq+/9C10pV30OwqJMzn5mtrHKbSKOyOMv9+qE7zZGNYXkPgEn24HI3cj9 0DgQ== MIME-Version: 1.0 Received: by 10.220.155.130 with SMTP id s2mr3440770vcw.43.1340712545227; Tue, 26 Jun 2012 05:09:05 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Tue, 26 Jun 2012 05:09:05 -0700 (PDT) Date: Tue, 26 Jun 2012 14:09:05 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 12:09:06 -0000 Hi, I think the purpose of IETF is to standard the *Internet* protocols and technologies. I agree with one message-input below, that we should complete first MANET single-domain tasks then look into future tasks (e.g. policy related). However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] considerations (i.e. requirements and services) are somehow related to MANET-considerations, which may help in the future to direct MANET future tasks to include thoes Internet issues. I will include small section to discuss (including the below information) NEMO issues/considerations in my draft of MANET technologies. Regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thread Subject: [manet] MANET Protocol Applicability Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 http://www.ietf.org/mail-archive/web/manet/current/msg13022.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 http://www.ietf.org/mail-archive/web/manet/current/msg13020.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? Date: Thu, 07 Jun 2012 09:22:04 -0700 http://www.ietf.org/mail-archive/web/manet/current/msg13015.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 http://www.ietf.org/mail-archive/web/manet/current/msg13014.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 http://www.ietf.org/mail-archive/web/manet/current/msg13013.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: Re: [manet] Subnet definition -- why do we need one that is different than standard IP? Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 http://www.ietf.org/mail-archive/web/manet/current/msg13009.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Message Subject: [manet] Subnet definition -- why do we need one that is different than standard IP? Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 http://www.ietf.org/mail-archive/web/manet/current/msg12994.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thread Subject: [manet] Defining subnet models used by our protocols Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 http://www.ietf.org/mail-archive/web/manet/current/msg12961.html +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From teco@inf-net.nl Tue Jun 26 07:40:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EF021F8592 for ; Tue, 26 Jun 2012 07:40:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RO9tAfV19zcB for ; Tue, 26 Jun 2012 07:40:28 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6623321F859E for ; Tue, 26 Jun 2012 07:40:28 -0700 (PDT) Received: by bkty8 with SMTP id y8so4798294bkt.31 for ; Tue, 26 Jun 2012 07:40:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=fUGzPUsrtJlukuJkcJrWGzqBcB8WAtZRQhk2nY6xXHg=; b=h6WcyVi1G6adi22QubApclLBQ9E+kBJeYvqcXlK/GZTH/1mGroqcsmacq0RjNdpnnO is6RVQOySJ4ebxdkCr6Ft8kSo/SAxKiykSfj+ZStefDpS3Na+VcEFJPQ2I8A0uG7ns4l KH5sGXbH2CyvKPZfNcozH+XvrVSAx55EU4H+nrjawL8Vgfd6Q02JpKuTA3CFZYuLy7nh 0HbD1B4QHL6ZiMJQKm4ciwqJrdi3cw/1UIL2ivBHsGO/qXUWvY64sRSA/dA3g+adzxex ksKwLZT6T0zTxJ0H4m8vbEETQTkzQMXxs9kxV7oWx3PsRd3HW8QixYoYN1BeTyy2OzEq kZwA== Received: by 10.204.133.200 with SMTP id g8mr5549612bkt.110.1340721627181; Tue, 26 Jun 2012 07:40:27 -0700 (PDT) Received: from [10.87.7.5] ([80.187.201.33]) by mx.google.com with ESMTPS id gm18sm51080726bkc.7.2012.06.26.07.40.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 07:40:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Tue, 26 Jun 2012 16:40:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkFG6Oh+srWamYLYRXbML2O4YxKDrUTg5tcTkyCIxrT/BBUWKiTlnNZJU7Vuvh/BDKfx9gl Cc: manet Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:40:29 -0000 I'm puzzling on how RFC6275 and RFC3963 relate to MANET L2 Technology. I hope it doesn't. Teco =20 Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende = geschreven: > Hi, >=20 > I think the purpose of IETF is to standard the *Internet* protocols = and > technologies. I agree with one message-input below, that we should > complete first MANET single-domain tasks then look into future tasks > (e.g. policy related). >=20 > However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] considerations = (i.e. > requirements and services) are somehow related to > MANET-considerations, which may help in the future to direct MANET > future tasks to include thoes Internet issues. I will include small > section to discuss (including the below information) NEMO > issues/considerations in my draft of MANET technologies. >=20 > Regards >=20 > Abdussalam Baryun > University of Glamorgan, UK >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Thread Subject: [manet] MANET Protocol Applicability > Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13022.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: Re: [manet] Subnet definition -- why do we need one = that is > different than standard IP? > Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13020.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: Re: [manet] Subnet definition -- why do we need one = that is > different than standard IP? > Date: Thu, 07 Jun 2012 09:22:04 -0700 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13015.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: Re: [manet] Subnet definition -- why do we need one = that is > different than standard IP? > Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13014.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: Re: [manet] Subnet definition -- why do we need one = that is > different than standard IP? > Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13013.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: Re: [manet] Subnet definition -- why do we need one = that is > different than standard IP? > Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg13009.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Message Subject: [manet] Subnet definition -- why do we need one that = is > different than standard IP? > Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg12994.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Thread Subject: [manet] Defining subnet models used by our protocols > Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 >=20 > http://www.ietf.org/mail-archive/web/manet/current/msg12961.html > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Tue Jun 26 07:49:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A57521F85F3 for ; Tue, 26 Jun 2012 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 F6KoF-mB91sJ for ; Tue, 26 Jun 2012 07:49:39 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 826D521F85E6 for ; Tue, 26 Jun 2012 07:49:39 -0700 (PDT) Received: from [71.6.86.44] (helo=[10.142.135.215]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SjX5F-0001cG-Tk; Tue, 26 Jun 2012 10:49:38 -0400 Message-ID: <4FE9CBFE.4060006@computer.org> Date: Tue, 26 Jun 2012 07:49:34 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad861fe451b7b5d4104841f30c22342d2ff4350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.6.86.44 Cc: Emmanuel.Baccelli@inria.fr, manet Subject: Re: [manet] draft-baccelli-manet-multihop-communication-01 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 14:49:40 -0000 Hello folks, Since Mobile IP is an infrastructure protocol, and the draft under discussion focusses on neighborhood effects instead of more distant connectivity, I don't think there is a close enough relationship to cover Mobile IP. But I appreciate your interest - thanks! Regards, Charlie P. On 6/26/2012 4:40 AM, Abdussalam Baryun wrote: > Hi Emmanuel and Perkins, > > To add to my previous posts, I RECOMMEND also to include Mobile-IP > [RFC6275] to be considered and referenced with its relations to the > draft models, > > Best Regards > Abdussalam Baryun > ================= > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From abdussalambaryun@gmail.com Tue Jun 26 10:18:28 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7649521F84EA for ; Tue, 26 Jun 2012 10:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 PZEN+W+Yh3yg for ; Tue, 26 Jun 2012 10:18:27 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 706E921F84CE for ; Tue, 26 Jun 2012 10:18:27 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so103711vbb.31 for ; Tue, 26 Jun 2012 10:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aVcH6BsSW41XwDDqqq6lmmrp1gOFUBIKAp0k5pi5BVQ=; b=TiG0ZthxYIhBH+Gw4hP0jOoBvEI37tkOWZ2BoVc0ZemBIpuBwPEno6cuKrmvAw78NY NKfh591txAVVRZUV2pInOmND0QMHWhynwtxttHCagJ2dBpKDaFI7rwoZcAzSQyWBzH5r fO4aWaJldupZW9KkQnq9sPEYV98mKaYCfXiezpfK+uk+tcGlnmv8//q5lqyo/rIzdnAQ Z3TVWIZRWXlXLAdzlo+1cQo64I87CxuDGRws86qK1AKtx6WJogatWLfiZ8FKYTmHb0bG ypT9lyCU/et2CukLOqtHeAbSRPWIxNCzUoX7WEyGV415OomW6Dd8zF6PXcRg4RQRc59X 4IFA== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr9804520vdb.10.1340731106604; Tue, 26 Jun 2012 10:18:26 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Tue, 26 Jun 2012 10:18:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 26 Jun 2012 19:18:25 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 17:18:28 -0000 It can be understood from reading the below pointed discussion-messages and/or thread. However, I am sure that it is still under arguments/non-final-decision at Internet community or IETF memebrs, Abdussalam ============== On 6/26/12, Teco Boot wrote: > I'm puzzling on how RFC6275 and RFC3963 relate to MANET L2 Technology. > I hope it doesn't. > > Teco > > Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende geschreven: > >> Hi, >> >> I think the purpose of IETF is to standard the *Internet* protocols and >> technologies. I agree with one message-input below, that we should >> complete first MANET single-domain tasks then look into future tasks >> (e.g. policy related). >> >> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] considerations >> (i.e. >> requirements and services) are somehow related to >> MANET-considerations, which may help in the future to direct MANET >> future tasks to include thoes Internet issues. I will include small >> section to discuss (including the below information) NEMO >> issues/considerations in my draft of MANET technologies. >> >> Regards >> >> Abdussalam Baryun >> University of Glamorgan, UK >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Thread Subject: [manet] MANET Protocol Applicability >> Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13022.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: Re: [manet] Subnet definition -- why do we need one that >> is >> different than standard IP? >> Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13020.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: Re: [manet] Subnet definition -- why do we need one that >> is >> different than standard IP? >> Date: Thu, 07 Jun 2012 09:22:04 -0700 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13015.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: Re: [manet] Subnet definition -- why do we need one that >> is >> different than standard IP? >> Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13014.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: Re: [manet] Subnet definition -- why do we need one that >> is >> different than standard IP? >> Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13013.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: Re: [manet] Subnet definition -- why do we need one that >> is >> different than standard IP? >> Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg13009.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Message Subject: [manet] Subnet definition -- why do we need one that is >> different than standard IP? >> Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg12994.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Thread Subject: [manet] Defining subnet models used by our protocols >> Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 >> >> http://www.ietf.org/mail-archive/web/manet/current/msg12961.html >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From teco@inf-net.nl Tue Jun 26 12:19:22 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77C21F8595 for ; Tue, 26 Jun 2012 12:19:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vxWHIxmLPzm for ; Tue, 26 Jun 2012 12:19:21 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3316821F8594 for ; Tue, 26 Jun 2012 12:19:20 -0700 (PDT) Received: by wibhr14 with SMTP id hr14so218877wib.13 for ; Tue, 26 Jun 2012 12:19:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rJZF/tDltr80rG3GqZCzAjPYEe8KPdX7k2k59/3DnlE=; b=VzEo8SBR+DfJtje/gbadUs29xqF0GSdcJ+hwQOKIwCwPSYZ6UXAvdOsxk122MVxRmB Bpp1Qi0ZEVwZM0tyVVBWL3nBpe7i+P3eOeJpLPNzW5J2mH+7Jz4fQfXQwln5xtpmU0+S wLIM0RdSYPvHi/ujkEneJGQ0e5Djkmmb/NvvVBQRXD+4xyPhhXw8q6Ay95VEOtF2dudR FeXI9IC28J25jIfLM1nI3nNSI4UBmGhCrvN7TWozNTe65eShXUFJgdUgamOzmYD5GyhY BGXJKgojbX8NNtXzhDsnaaPtIL/0KB2z+HfjwqtLldRCwTpgbOKeFRec7oRJRgy05OT+ lpUA== Received: by 10.216.226.78 with SMTP id a56mr9028539weq.133.1340738360236; Tue, 26 Jun 2012 12:19:20 -0700 (PDT) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id m4sm5775274wie.1.2012.06.26.12.19.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Jun 2012 12:19:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Tue, 26 Jun 2012 21:19:18 +0200 Content-Transfer-Encoding: 7bit Message-Id: <4FE51F49-B9CA-443B-B702-19D90C3C2CAA@inf-net.nl> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkQyuy2/5PQmikQAIBcdRRGo9nkr56z4rJ57iOgJlojgwhu/jnIaFBMmZ+Q5iK5CRSjhuTD Cc: manet Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2012 19:19:22 -0000 Sorry, I don't have time to analyze MB's of archives. As said before, I suggest you post your ideas in a draft. Hint: you might have more time to write than others have for reading. So keep it as short as possible. Teco Op 26 jun. 2012, om 19:18 heeft Abdussalam Baryun het volgende geschreven: > It can be understood from reading the below pointed > discussion-messages and/or thread. However, I am sure that it is still > under arguments/non-final-decision at Internet community or IETF > memebrs, > > Abdussalam > ============== > > On 6/26/12, Teco Boot wrote: >> I'm puzzling on how RFC6275 and RFC3963 relate to MANET L2 Technology. >> I hope it doesn't. >> >> Teco >> >> Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende geschreven: >> >>> Hi, >>> >>> I think the purpose of IETF is to standard the *Internet* protocols and >>> technologies. I agree with one message-input below, that we should >>> complete first MANET single-domain tasks then look into future tasks >>> (e.g. policy related). >>> >>> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] considerations >>> (i.e. >>> requirements and services) are somehow related to >>> MANET-considerations, which may help in the future to direct MANET >>> future tasks to include thoes Internet issues. I will include small >>> section to discuss (including the below information) NEMO >>> issues/considerations in my draft of MANET technologies. >>> >>> Regards >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Thread Subject: [manet] MANET Protocol Applicability >>> Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13022.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: Re: [manet] Subnet definition -- why do we need one that >>> is >>> different than standard IP? >>> Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13020.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: Re: [manet] Subnet definition -- why do we need one that >>> is >>> different than standard IP? >>> Date: Thu, 07 Jun 2012 09:22:04 -0700 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13015.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: Re: [manet] Subnet definition -- why do we need one that >>> is >>> different than standard IP? >>> Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13014.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: Re: [manet] Subnet definition -- why do we need one that >>> is >>> different than standard IP? >>> Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13013.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: Re: [manet] Subnet definition -- why do we need one that >>> is >>> different than standard IP? >>> Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg13009.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Message Subject: [manet] Subnet definition -- why do we need one that is >>> different than standard IP? >>> Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg12994.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Thread Subject: [manet] Defining subnet models used by our protocols >>> Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 >>> >>> http://www.ietf.org/mail-archive/web/manet/current/msg12961.html >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> From valerio.arnaboldi@iit.cnr.it Wed Jun 27 00:07:55 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB7921F85D6 for ; Wed, 27 Jun 2012 00:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 3APx6gsuFhaB for ; Wed, 27 Jun 2012 00:07:54 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89A21F85D4 for ; Wed, 27 Jun 2012 00:07:35 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id A60333D826F; Wed, 27 Jun 2012 09:07:01 +0200 (CEST) Date: Wed, 27 Jun 2012 09:07:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4feab115.JtnIV33pKMIWhsfT%valerio.arnaboldi@iit.cnr.it> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [manet] SustainIT 2012 - Ph.D. Forum: Call for extended abstracts - Deadline Extended to June 30 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 07:07:56 -0000 ------------------------------------------------------------------------ PhD FORUM: CALL FOR EXTENDED ABSTRACTS SustainIT 2012 Second IFIP Conference on Sustainable Internet and ICT for Sustainability http://cnd.iit.cnr.it/sustainit2012/ October 4-5, 2012 Pisa, Tuscany, Italy ******* PHD FORUM EXTENDED DEADLINE: June 30, 2012 ******* ------------------------------------------------------------------------ SustainIT 2012 hosts the PhD Forum on Sustainable Internet and ICT for Sustainability. The Forum will provide an opportunity for PhD students to present their dissertation research, including work in progress. In addition, it will be a platform for PhD students to interact both with their peers as well as with experienced researchers from industry and academia. The Forum will be organized as a poster session and will include a '1-minute madness' introduction by each student. Current PhD students and researchers who completed their PhD dissertations after December 2011 are encouraged to submit extended abstracts. The PhD student and his/her advisor(s) can be the only authors. Submissions will be reviewed to ensure quality and relevance. Authors of accepted submissions are expected to attend SustainIT 2012 and present their poster at the PhD Forum. Accepted extended abstracts will appear in conference proceedings. SUBMISSION GUIDELINES: PhD students are invited to submit an extended abstract describing current research and potential contributions to theory and innovation in the areas of Sustainable Internet and ICT for Sustainability. Extended abstracts should include the authors' names, affiliation, and email address. Submissions must be PDF files, written in English. Submissions should adhere to the IEEE format and be no more than 3 pages in size (all inclusive). Abstracts must be submitted by e-mail to the following address: sustainit2012-PHD@gerad.ca. Please send the PDF file as attachment of an e-mail having as subject: "PhD-Submission-AUTHORS(last names only, separated by a '-')". IMPORTANT DATES: Manuscript submissions: June 11, 2012 (Extended to June 30, 2012) Notification of acceptance: July 9, 2012 Camera-ready copy due: July 30, 2012 Conference date: October 4-5, 2012 PhD Forum Co-Chairs Franco Davoli, University of Genova, Italy Brunilde Sanso, Ecole Polytechnique de Montreal, Canada ============================================== Valerio Arnaboldi - SUSTAINIT2012 Publicity Chair Institute for Informatics and Telematics (IIT) Italian National Research Council (CNR) Via G. Moruzzi, 1 - 56124 Pisa, Italy phone: +39 050 315 2195 email: valerio.arnaboldi@iit.cnr.it From abdussalambaryun@gmail.com Wed Jun 27 01:24:19 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69F21F86A0 for ; Wed, 27 Jun 2012 01:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 CUtFpMm4PaS8 for ; Wed, 27 Jun 2012 01:24:18 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B98F21F8650 for ; Wed, 27 Jun 2012 01:24:17 -0700 (PDT) Received: by vcqp1 with SMTP id p1so557490vcq.31 for ; Wed, 27 Jun 2012 01:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=j51hv4/bbiQcIxRDRY9RXdCSpvb5GKAwbKh83U2O+Ig=; b=cSn6TEajUZGUYa0RpUPSZGrdk6VuhHKnXhEDO/WMLYQDBW8Jq11qVijqZKYmjfjj9i jQzEttCZk2szr5UurfiuwNKyT6Dckrt926TVGEsKE946v5EOij2vahzeQgqinmD3tuck hLDks85AUsiitE1Ae5uKWold45GW9bVTH2bAqRmVmpNoSUpltkiNQ5p1VvoanhyiZ/h4 Iiz7tGyKLh0nDHXMEI//H8/M9+9W4u1wTwupopLLjroUUCTPrOaMk/yACUeizHf5WieF zpwi8Jkuuk/n2njmeXkS7vpK2RNuF4ahauU7lA2/v6FAA2lIQsOj158L5NtI9BZxthyS v75Q== MIME-Version: 1.0 Received: by 10.52.90.144 with SMTP id bw16mr11127765vdb.129.1340785457285; Wed, 27 Jun 2012 01:24:17 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Wed, 27 Jun 2012 01:24:17 -0700 (PDT) In-Reply-To: <4FE51F49-B9CA-443B-B702-19D90C3C2CAA@inf-net.nl> References: <4FE51F49-B9CA-443B-B702-19D90C3C2CAA@inf-net.nl> Date: Wed, 27 Jun 2012 09:24:17 +0100 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: multipart/alternative; boundary=20cf307f33e0e6ca0a04c36ff02a Cc: manet Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:24:19 -0000 --20cf307f33e0e6ca0a04c36ff02a Content-Type: text/plain; charset=ISO-8859-1 I think that the messages I pointed to are only about 8 messages/paragraphs. IMO WGs need to read to function efficiently (the reading time delay doesn't matter). We can take our time if we are bussy now until maybe 28 days, because IMO the discussion list is a delay tolerance communication tool. I will like to know your comments, because IMO discussions (the source of I-Ds) are more important than I-Ds. Overall, I agree that we/I should be short in I-D, but not in discussions. However, I will follow your suggestion for my I-D, thanks, AB ======================== On Tue, Jun 26, 2012 at 8:19 PM, Teco Boot wrote: > Sorry, I don't have time to analyze MB's of archives. > As said before, I suggest you post your ideas in a draft. > Hint: you might have more time to write than others have > for reading. So keep it as short as possible. > > Teco > > > Op 26 jun. 2012, om 19:18 heeft Abdussalam Baryun het volgende geschreven: > > > It can be understood from reading the below pointed > > discussion-messages and/or thread. However, I am sure that it is still > > under arguments/non-final-decision at Internet community or IETF > > memebrs, > > > > Abdussalam > > ============== > > > > On 6/26/12, Teco Boot wrote: > >> I'm puzzling on how RFC6275 and RFC3963 relate to MANET L2 Technology. > >> I hope it doesn't. > >> > >> Teco > >> > >> Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende > geschreven: > >> > >>> Hi, > >>> > >>> I think the purpose of IETF is to standard the *Internet* protocols and > >>> technologies. I agree with one message-input below, that we should > >>> complete first MANET single-domain tasks then look into future tasks > >>> (e.g. policy related). > >>> > >>> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] considerations > >>> (i.e. > >>> requirements and services) are somehow related to > >>> MANET-considerations, which may help in the future to direct MANET > >>> future tasks to include thoes Internet issues. I will include small > >>> section to discuss (including the below information) NEMO > >>> issues/considerations in my draft of MANET technologies. > >>> > >>> Regards > >>> > >>> Abdussalam Baryun > >>> University of Glamorgan, UK > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Thread Subject: [manet] MANET Protocol Applicability > >>> Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13022.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need one > that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13020.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need one > that > >>> is > >>> different than standard IP? > >>> Date: Thu, 07 Jun 2012 09:22:04 -0700 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13015.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need one > that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13014.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need one > that > >>> is > >>> different than standard IP? > >>> Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13013.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need one > that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13009.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: [manet] Subnet definition -- why do we need one that > is > >>> different than standard IP? > >>> Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg12994.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Thread Subject: [manet] Defining subnet models used by our protocols > >>> Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg12961.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> > > --20cf307f33e0e6ca0a04c36ff02a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think that the messages I pointed=A0to are only about=A08 messages/p= aragraphs. IMO WGs need to read to function efficiently (the reading time d= elay doesn't matter).=A0We can take our time if we are bussy now until = maybe 28 days, because IMO the discussion list is a delay tolerance communi= cation tool. I will like to know your comments,=A0because IMO discussions (= the source of I-Ds) are more important than I-Ds. Overall, I agree that we/= I should be short in I-D, but not in discussions. However, I will follow yo= ur suggestion for my I-D, thanks,
=A0
AB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Tue, Jun 26, 2012 at 8:19 PM, Teco Boot <teco@= inf-net.nl> wrote:
Sorry, I don't have time to analy= ze MB's of archives.
As said before, I suggest you post your ideas i= n a draft.
Hint: you might have more time to write than others have
for reading. So= keep it as short as possible.

Teco


Op 26 jun. 2012, om 1= 9:18 heeft Abdussalam Baryun het volgende geschreven:

> It can be understood from reading the below poin= ted
> discussion-messages and/or thread. However, I am sure that it i= s still
> under arguments/non-final-decision at Internet community or= IETF
> memebrs,
>
> Abdussalam
> =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>
> On 6/26/12, Teco Boot <teco@inf-net.nl> wrote:
>> I'm puz= zling on how RFC6275 and RFC3963 relate to MANET L2 Technology.
>> I hope it doesn't.
>>
>> Teco
>>>> Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende ge= schreven:
>>
>>> Hi,
>>>
>>> I= think the purpose of IETF is to standard the *Internet* protocols and
>>> technologies. I agree with one message-input below, that we sh= ould
>>> complete first MANET single-domain tasks then look int= o future tasks
>>> (e.g. policy related).
>>>
>>> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] consid= erations
>>> (i.e.
>>> requirements and services) a= re somehow related to
>>> MANET-considerations, which may help = in the future to direct MANET
>>> future tasks to include thoes Internet issues. I will include = small
>>> section to discuss (including the below information) = NEMO
>>> issues/considerations in my draft of MANET technologie= s.
>>>
>>> Regards
>>>
>>> Abduss= alam Baryun
>>> University of Glamorgan, UK
>>>
= >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Thread Subject: [manet] MANET Protocol Applicability
>&g= t;> Date/Time: Fri, 8 Jun 2012 05:42:13 +0200
>>>
>>= ;> http://www.ietf.org/mail-archive/web/manet/curren= t/msg13022.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: Re: [manet] Subnet definition -- why do we n= eed one that
>>> is
>>> different than standard IP?=
>>> Date/Time: Thu, 07 Jun 2012 12:52:11 -0400
>>>
= >>> http://www.ietf.org/mail-archive/web/manet= /current/msg13020.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: Re: [manet] Subnet definition -- why do we n= eed one that
>>> is
>>> different than standard IP?=
>>> Date: Thu, 07 Jun 2012 09:22:04 -0700
>>>
>&= gt;> http://www.ietf.org/mail-archive/web/manet/curr= ent/msg13015.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: Re: [manet] Subnet definition -- why do we n= eed one that
>>> is
>>> different than standard IP?=
>>> Date/Time: Thu, 7 Jun 2012 10:21:42 -0600
>>>
&= gt;>> http://www.ietf.org/mail-archive/web/manet/= current/msg13014.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: Re: [manet] Subnet definition -- why do we n= eed one that
>>> is
>>> different than standard IP?=
>>> Date/Time:Thu, 7 Jun 2012 16:08:34 +0000
>>>
&g= t;>> http://www.ietf.org/mail-archive/web/manet/c= urrent/msg13013.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: Re: [manet] Subnet definition -- why do we n= eed one that
>>> is
>>> different than standard IP?=
>>> Date/Time: Thu, 7 Jun 2012 09:12:56 -0600
>>>
&= gt;>> http://www.ietf.org/mail-archive/web/manet/= current/msg13009.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> Message Subject: [manet] Subnet definition -- why do we need = one that is
>>> different than standard IP?
>>> Dat= e/Time: Wed, 6 Jun 2012 11:13:48 -0600
>>>
>>> http://www.ietf.org/mail-a= rchive/web/manet/current/msg12994.html
>>> ++++++++++++++++= +++++++++++++++++++++++++++++++++++++++++++
>>> Thread Subject: [manet] Defining subnet models used by our pro= tocols
>>> Date/Time: Sat, 2 Jun 2012 10:12:55 +0200
>>= ;>
>>> http://www.ietf.org/mail-archive/= web/manet/current/msg12961.html
>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++>>> _______________________________________________
>>&g= t; manet mailing list
>>> man= et@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>>
= >>


--20cf307f33e0e6ca0a04c36ff02a-- From teco@inf-net.nl Wed Jun 27 01:54:41 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48B521F8646 for ; Wed, 27 Jun 2012 01:54:41 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 HMkqmqmQpqZG for ; Wed, 27 Jun 2012 01:54:40 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A59621F8643 for ; Wed, 27 Jun 2012 01:54:40 -0700 (PDT) Received: by werb13 with SMTP id b13so622875wer.31 for ; Wed, 27 Jun 2012 01:54:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=UJMn+WDWRwFhW1QFh9mL4boIuUz21fUFLJBCArwZ4O4=; b=VGSGjz8nE9Ap53fO8bKYO18INJ6Fpu+hPneEeCKvAGzB8oQCOpTLYj8JBD4cUc3TkW TnMG++ih4oU9AVVcMVz16gpr8OYijNcnDMFc6iv/YvEDKSxsPm88BDvjy4AUUriknxMY Qfqb+xlcwdYV1/4m0C0UBUcnbtwrFP3S+BQnaVx5MOnYpLAlfspq6GLBzVZppSNn6N5L 63YEwsi3ajcmTdi1sA6QUlaRqrZ03GcmPzIRFT8wVb84wD0p7icjFeN+PIET8sG7mxuy 3ru3KTP1DFA5xd0lZlAbT+f9rMNqBKkRKbqEwKt7X6ymGTO7BBJsfXjSVkRBWPdbOvhX piwA== Received: by 10.180.97.135 with SMTP id ea7mr2901485wib.11.1340787274516; Wed, 27 Jun 2012 01:54:34 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id q6sm9993782wiy.0.2012.06.27.01.54.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 27 Jun 2012 01:54:33 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_0C766503-6089-40EF-B461-488B4D3E56AC" From: Teco Boot In-Reply-To: Date: Wed, 27 Jun 2012 10:54:31 +0200 Message-Id: References: <4FE51F49-B9CA-443B-B702-19D90C3C2CAA@inf-net.nl> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmrBmfJy2hDFZyt1IJkiC8zvqdEpHqGUD4FXAc0BoTAnVJ4+84WdZwRiPalNudDckIQaSea Cc: manet Subject: Re: [manet] Start of Defining the MANET L2 Technology X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 08:54:42 -0000 --Apple-Mail=_0C766503-6089-40EF-B461-488B4D3E56AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 You may submit a -00 draft before cut-off date for Vancouver. http://www.ietf.org/meeting/cutoff-dates-2012.html#IETF84 Teco Op 27 jun. 2012, om 10:24 heeft Abdussalam Baryun het volgende = geschreven: > I think that the messages I pointed to are only about 8 = messages/paragraphs. IMO WGs need to read to function efficiently (the = reading time delay doesn't matter). We can take our time if we are bussy = now until maybe 28 days, because IMO the discussion list is a delay = tolerance communication tool. I will like to know your comments, because = IMO discussions (the source of I-Ds) are more important than I-Ds. = Overall, I agree that we/I should be short in I-D, but not in = discussions. However, I will follow your suggestion for my I-D, thanks, > =20 > AB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > On Tue, Jun 26, 2012 at 8:19 PM, Teco Boot wrote: > Sorry, I don't have time to analyze MB's of archives. > As said before, I suggest you post your ideas in a draft. > Hint: you might have more time to write than others have > for reading. So keep it as short as possible. >=20 > Teco >=20 >=20 > Op 26 jun. 2012, om 19:18 heeft Abdussalam Baryun het volgende = geschreven: >=20 > > It can be understood from reading the below pointed > > discussion-messages and/or thread. However, I am sure that it is = still > > under arguments/non-final-decision at Internet community or IETF > > memebrs, > > > > Abdussalam > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > On 6/26/12, Teco Boot wrote: > >> I'm puzzling on how RFC6275 and RFC3963 relate to MANET L2 = Technology. > >> I hope it doesn't. > >> > >> Teco > >> > >> Op 26 jun. 2012, om 14:09 heeft Abdussalam Baryun het volgende = geschreven: > >> > >>> Hi, > >>> > >>> I think the purpose of IETF is to standard the *Internet* = protocols and > >>> technologies. I agree with one message-input below, that we should > >>> complete first MANET single-domain tasks then look into future = tasks > >>> (e.g. policy related). > >>> > >>> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] = considerations > >>> (i.e. > >>> requirements and services) are somehow related to > >>> MANET-considerations, which may help in the future to direct MANET > >>> future tasks to include thoes Internet issues. I will include = small > >>> section to discuss (including the below information) NEMO > >>> issues/considerations in my draft of MANET technologies. > >>> > >>> Regards > >>> > >>> Abdussalam Baryun > >>> University of Glamorgan, UK > >>> > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Thread Subject: [manet] MANET Protocol Applicability > >>> Date/Time: Fri, 8 Jun 2012 05:42:13 +0200 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13022.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need = one that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 07 Jun 2012 12:52:11 -0400 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13020.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need = one that > >>> is > >>> different than standard IP? > >>> Date: Thu, 07 Jun 2012 09:22:04 -0700 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13015.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need = one that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 7 Jun 2012 10:21:42 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13014.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need = one that > >>> is > >>> different than standard IP? > >>> Date/Time:Thu, 7 Jun 2012 16:08:34 +0000 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13013.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: Re: [manet] Subnet definition -- why do we need = one that > >>> is > >>> different than standard IP? > >>> Date/Time: Thu, 7 Jun 2012 09:12:56 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg13009.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Message Subject: [manet] Subnet definition -- why do we need one = that is > >>> different than standard IP? > >>> Date/Time: Wed, 6 Jun 2012 11:13:48 -0600 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg12994.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> Thread Subject: [manet] Defining subnet models used by our = protocols > >>> Date/Time: Sat, 2 Jun 2012 10:12:55 +0200 > >>> > >>> http://www.ietf.org/mail-archive/web/manet/current/msg12961.html > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www.ietf.org/mailman/listinfo/manet > >> > >> >=20 >=20 --Apple-Mail=_0C766503-6089-40EF-B461-488B4D3E56AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 You = may submit a -00 draft before cut-off date for Vancouver.

Teco

Op 27 jun. 2012, om 10:24 heeft = Abdussalam Baryun het volgende geschreven:

I = think that the messages I pointed to are only about 8 = messages/paragraphs. IMO WGs need to read to function efficiently (the = reading time delay doesn't matter). We can take our time if we are = bussy now until maybe 28 days, because IMO the discussion list is a = delay tolerance communication tool. I will like to know your = comments, because IMO discussions (the source of I-Ds) are more = important than I-Ds. Overall, I agree that we/I should be short in I-D, = but not in discussions. However, I will follow your suggestion for my = I-D, thanks,
 
AB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Tue, Jun 26, 2012 at 8:19 PM, Teco Boot = <teco@inf-net.nl> wrote:
Sorry, I don't have time = to analyze MB's of archives.
As said before, I suggest you post your = ideas in a draft.
Hint: you might have more time to write than others have
for reading. = So keep it as short as possible.

Teco


Op 26 jun. 2012, = om 19:18 heeft Abdussalam Baryun het volgende geschreven:

> It can be understood from reading the below = pointed
> discussion-messages and/or thread. However, I am sure = that it is still
> under arguments/non-final-decision at Internet = community or IETF
> memebrs,
>
> Abdussalam
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On 6/26/12, = Teco Boot <teco@inf-net.nl> = wrote:
>> I'm puzzling on how RFC6275 and RFC3963 relate to = MANET L2 Technology.
>> I hope it doesn't.
>>
>> = Teco
>>
>> Op 26 jun. 2012, om 14:09 heeft Abdussalam = Baryun het volgende geschreven:
>>
>>> = Hi,
>>>
>>> I think the purpose of IETF is to = standard the *Internet* protocols and
>>> technologies. I agree with one message-input below, that we = should
>>> complete first MANET single-domain tasks then = look into future tasks
>>> (e.g. policy = related).
>>>
>>> However, IMO the Mobile-IP [RFC6275] and NEMO [RFC3963] = considerations
>>> (i.e.
>>> requirements and = services) are somehow related to
>>> MANET-considerations, = which may help in the future to direct MANET
>>> future tasks to include thoes Internet issues. I will = include small
>>> section to discuss (including the below = information) NEMO
>>> issues/considerations in my draft of = MANET technologies.
>>>
>>> Regards
>>>
>>> = Abdussalam Baryun
>>> University of Glamorgan, = UK
>>>
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Thread Subject: [manet] MANET Protocol = Applicability
>>> Date/Time: Fri, 8 Jun 2012 05:42:13 = +0200
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 022.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: Re: [manet] Subnet definition -- why do we need one = that
>>> is
>>> different than standard IP?
>>> Date/Time: Thu, 07 Jun 2012 12:52:11 = -0400
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 020.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: Re: [manet] Subnet definition -- why do we need one = that
>>> is
>>> different than standard IP?
>>> Date: Thu, 07 Jun 2012 09:22:04 = -0700
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 015.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: Re: [manet] Subnet definition -- why do we need one = that
>>> is
>>> different than standard IP?
>>> Date/Time: Thu, 7 Jun 2012 10:21:42 = -0600
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 014.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: Re: [manet] Subnet definition -- why do we need one = that
>>> is
>>> different than standard IP?
>>> Date/Time:Thu, 7 Jun 2012 16:08:34 = +0000
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 013.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: Re: [manet] Subnet definition -- why do we need one = that
>>> is
>>> different than standard IP?
>>> Date/Time: Thu, 7 Jun 2012 09:12:56 = -0600
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg13= 009.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; Message Subject: [manet] Subnet definition -- why do we need one that = is
>>> different than standard IP?
>>> = Date/Time: Wed, 6 Jun 2012 11:13:48 -0600
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg12= 994.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> Thread Subject: [manet] Defining subnet models used by our = protocols
>>> Date/Time: Sat, 2 Jun 2012 10:12:55 = +0200
>>>
>>> http://www.ietf.org/mail-archive/web/manet/current/msg12= 961.html
>>> = +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>= ; _______________________________________________
>>> manet = mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/manet
>&= gt;
>>



= --Apple-Mail=_0C766503-6089-40EF-B461-488B4D3E56AC-- From abdussalambaryun@gmail.com Thu Jun 28 02:11:58 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038E721F89B5 for ; Thu, 28 Jun 2012 02:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 4Zs0Fttp-WNl for ; Thu, 28 Jun 2012 02:11:57 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD621F89B4 for ; Thu, 28 Jun 2012 02:11:57 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1463449vcq.31 for ; Thu, 28 Jun 2012 02:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=U+FtNHpWbbfUVV0to+hwFFy99N4Ct95vCn3CtcV4w+I=; b=L8SzrJjPv/1INCt1Rq0TnAn9xdHzl6qYLz2VNTL+bSULThHFaJ9wFPkmimpoEaU6PN v/PKTSTPhd+KicJhf6VCgejfFtMGb319HXY/a+8HvzJZiAi5yiZ7s9/a9o+fb3wqXEAi PqcIeFGzQZ2YSg2M1loU02kPwo/v4fOPtTDt3CUjVdjpDJeGHM9L3rthUz9i37dkX2vR BUJrbMxxoJxRs65wLeeM77FQZzSvWH6FQLZrl/BSGapjFbhCn/efe54y+Eoc2TZdF7HN +DagAPvI0JQJUEjo+kodVc+jtCAveFtpTXgznUvHJvX3rdQsdp4nUMUKTNm/3SKE+FLP 334g== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr650979vdb.103.1340874716907; Thu, 28 Jun 2012 02:11:56 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Thu, 28 Jun 2012 02:11:56 -0700 (PDT) Date: Thu, 28 Jun 2012 11:11:56 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 09:11:58 -0000 Hi All, I have seen no draft that defines terminology in MANET WG, which I feel it is a basic RFC that should be in any WG so they agree on terminology within the group. I understand from my experience in this WG that the only RFC agreed on is the RFC2501 as a background for definitions. I want to work on defining terminology which I will update the draft expired below. Is there any one want to join me in authoring, (will first finish update comments on RFC2501 which will post shortly). draft-ietf-manet-term-01 (Nov 1998) http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 Please note that documents MAY expire but right knowledge/experience NEVER expires :) Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From Chris.Dearlove@baesystems.com Thu Jun 28 02:46:42 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E8C21F885E for ; Thu, 28 Jun 2012 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 82bfcwcCtqEQ for ; Thu, 28 Jun 2012 02:46:41 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4040E21F8848 for ; Thu, 28 Jun 2012 02:46:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,490,1336345200"; d="scan'208";a="250679594" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 28 Jun 2012 10:46:39 +0100 Received: from GLKXH0002V.GREENLNK.net ([10.109.2.33]) by baemasmds009.greenlnk.net (Switch-3.4.4/Switch-3.4.4) with ESMTP id q5S9kcUu026884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Jun 2012 10:46:39 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.240]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Thu, 28 Jun 2012 10:46:38 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] MANET Terminology Update Thread-Index: AQHNVQ4X1sXLF0ACJEK4rHoQjckgJZcPd9uw Date: Thu, 28 Jun 2012 09:46:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 09:46:42 -0000 Note that (a) That's a 1998 document. Things can change in 14 years. That includes th= at the purpose of the document was to aid protocol designers' discussions. = We've done that. And we seem to have managed for 14 years without this. (b) You probably don't have permission to update it. That document has no c= opyright assignment on it, and back then I think copyright remained with th= e authors (or possibly their employers, which are likely to have changed in= 14 years) at least at ID stage. And if you want it to remain as a WG docum= ent you would need the WG to agree you take it over. (And the IETF tools wo= n't accept you doing that either without intervention from WG chairs at lea= st.) You could of course avoid that by going back to author status, but see= the earlier part of this point. (c) Lots of definitions in that draft aren't used in any MANET WG document.= For example we have no protocols using clustering. So why do we need to de= fine them? (d) Experience has shown that several of the definitions in that document a= re of things that can cause a great deal of unproductive argument. Let's no= t rehash that. (e) Protocols such as NHDP and OLSRv2 have included their own definitions w= here these are needed. And even if it were desirable for these protocols to= reference an external document, it's too late. --=20 Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=A0| Fax: +44 1245 242124 chris.dearlove@baesystems.com | http://www.baesystems.com 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of A= bdussalam Baryun Sent: 28 June 2012 10:12 To: manet Subject: [manet] MANET Terminology Update ----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. -------------------------------------------------------- Hi All, I have seen no draft that defines terminology in MANET WG, which I feel it is a basic RFC that should be in any WG so they agree on terminology within the group. I understand from my experience in this WG that the only RFC agreed on is the RFC2501 as a background for definitions. I want to work on defining terminology which I will update the draft expired below. Is there any one want to join me in authoring, (will first finish update comments on RFC2501 which will post shortly). draft-ietf-manet-term-01 (Nov 1998) http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 Please note that documents MAY expire but right knowledge/experience NEVER expires :) Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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. ******************************************************************** From abdussalambaryun@gmail.com Thu Jun 28 03:57:33 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA1C21F8649 for ; Thu, 28 Jun 2012 03:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 s-43+lWPnluG for ; Thu, 28 Jun 2012 03:57:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2221F8645 for ; Thu, 28 Jun 2012 03:57:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1531786vbb.31 for ; Thu, 28 Jun 2012 03:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g6FzX0c3fxMsoqkkwuJR/8Mzte1X+8zEWFH17lhHtdQ=; b=NtB/y+aK0SyVYr68y4P2m0JUFsWG586IToNvGKFtIIOo/V8beOmWORbo4zdHwSFUrL z4WPXzOoCKZVZxzi6UEc1PlJzINzUYtarX+llowoJ+vJsoP5PmWu+IrqRjvkPDcKiFWI cL9k9/eFHVI5ITAYHXLUV1VxXnFGWDtR0zD1ZiMLnyiikJFaAPIfgEdVLqN5z+pGOuDX e4YrQer+ZvSqCP4o3com5xaroHx7rSgTin2ZpwEVzYr0+zOrb4URI8LEZcysxpu4c1Bo qFuizirFatjF8xo9+ebGL5bVjTv6w3099MlXGSWu0uBfJb8QJ4hxLMtQK8WIyGi+b3kP sWRg== MIME-Version: 1.0 Received: by 10.220.149.15 with SMTP id r15mr1133001vcv.1.1340881051378; Thu, 28 Jun 2012 03:57:31 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Thu, 28 Jun 2012 03:57:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 28 Jun 2012 12:57:31 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 10:57:33 -0000 I think there is an additional option as I am a MANET-WG memebr so I can write a new draft titled [MANET Protocols Terminology] to the MANET-WG. So it will seam like an update to the expired, but in the same time it is a new proposed (informational RFC), new-file-name-draft-00, and with new authors. I agree we should avoid unproductive-arguments in any MANET-document. So we need to work together in a new-draft of MANET-Terminology so we have new productive-arguments directed to improve new deliverable documents (e.g. draft authored by MANET editor, and/or most of MANET WG members). AB ==== On 6/28/12, Dearlove, Christopher (UK) wrote: > Note that > (a) That's a 1998 document. Things can change in 14 years. That includes > that the purpose of the document was to aid protocol designers' discussions. > We've done that. And we seem to have managed for 14 years without this. > (b) You probably don't have permission to update it. That document has no > copyright assignment on it, and back then I think copyright remained with > the authors (or possibly their employers, which are likely to have changed > in 14 years) at least at ID stage. And if you want it to remain as a WG > document you would need the WG to agree you take it over. (And the IETF > tools won't accept you doing that either without intervention from WG chairs > at least.) You could of course avoid that by going back to author status, > but see the earlier part of this point. > (c) Lots of definitions in that draft aren't used in any MANET WG document. > For example we have no protocols using clustering. So why do we need to > define them? > (d) Experience has shown that several of the definitions in that document > are of things that can cause a great deal of unproductive argument. Let's > not rehash that. > (e) Protocols such as NHDP and OLSRv2 have included their own definitions > where these are needed. And even if it were desirable for these protocols to > reference an external document, it's too late. > > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group > Communications, Networks and Image Analysis Capability > BAE Systems Advanced Technology Centre > West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194 | Fax: +44 1245 242124 > chris.dearlove@baesystems.com | http://www.baesystems.com > > 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: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 28 June 2012 10:12 > To: manet > Subject: [manet] MANET Terminology Update > > ----------------------! WARNING ! ---------------------- > This message originates from outside our organisation, > either from an external partner or from the internet. > Keep this in mind if you answer this message. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- > > Hi All, > > I have seen no draft that defines terminology in MANET WG, which I > feel it is a basic RFC that should be in any WG so they agree on > terminology within the group. I understand from my experience in this > WG that the only RFC agreed on is the RFC2501 as a background for > definitions. I want to work on defining terminology which I will > update the draft expired below. Is there any one want to join me in > authoring, (will first finish update comments on RFC2501 which will > post shortly). > > draft-ietf-manet-term-01 (Nov 1998) > http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 > > Please note that documents MAY expire but right knowledge/experience > NEVER expires :) > > Abdussalam Baryun > University of Glamorgan, UK > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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. > ******************************************************************** > > From sratliff@cisco.com Thu Jun 28 09:13:38 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C79621F8526 for ; Thu, 28 Jun 2012 09:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 FgKVx-vHSTHv for ; Thu, 28 Jun 2012 09:13:37 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 695A521F8518 for ; Thu, 28 Jun 2012 09:13:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=5450; q=dns/txt; s=iport; t=1340900017; x=1342109617; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NKu5w33Mwd484pUAbwFg+nvWvorjY+kskQmdvv9k2hw=; b=eUeYZ27g4/ljJaWx0Sr+FSGTH7KK3IJ7ucoI4jGor93D6M3N89bsTqwO 0lupyaU6jewx85oTYVZbim6DqeFEaOvA7+XKnRzL0m96MSvmt8V/5Acl1 4JhoTz1Zld7LMNSE5tzIiHTQdnyFJY7vlZv5yV3Y7ViMrZEBua5L14wsw I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH6B7E+tJXG9/2dsb2JhbABFtiuBB4IYAQEBAwEBAQEPAUIZAwMFBQcECxEEAQEBJwcnHwkIBhMih2QFC5hHoGSLNxQOhQhgA5UygRKNC4FmgnuBOgk X-IronPort-AV: E=Sophos;i="4.77,493,1336348800"; d="scan'208";a="96937221" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jun 2012 16:13:19 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5SGDJdD003225; Thu, 28 Jun 2012 16:13:19 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Stan Ratliff In-Reply-To: Date: Thu, 28 Jun 2012 12:13:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <231272E3-0BD9-441C-9719-36CE8755E7AF@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 16:13:38 -0000 Abdussalam,=20 On Jun 28, 2012, at 6:57 AM, Abdussalam Baryun wrote: > I think there is an additional option as I am a MANET-WG memebr so I > can write a new draft titled [MANET Protocols Terminology] to the > MANET-WG. So it will seam like an update to the expired, but in the > same time it is a new proposed (informational RFC), > new-file-name-draft-00, and with new authors. >=20 > I agree we should avoid unproductive-arguments in any MANET-document. > So we need to work together in a new-draft of MANET-Terminology so we > have new productive-arguments directed to improve new deliverable > documents (e.g. draft authored by MANET editor, and/or most of MANET > WG members). Seems to me that you are somewhat defining an "unproductive argument" as = "an argument where anyone disagrees with Abdussalam"=85. :-/ As a working group member, I'm going to add my voice to Chris Dearlove's = - I fail to see the need for this type of effort.=20 Regards, Stan >=20 > AB > =3D=3D=3D=3D >=20 > On 6/28/12, Dearlove, Christopher (UK) = wrote: >> Note that >> (a) That's a 1998 document. Things can change in 14 years. That = includes >> that the purpose of the document was to aid protocol designers' = discussions. >> We've done that. And we seem to have managed for 14 years without = this. >> (b) You probably don't have permission to update it. That document = has no >> copyright assignment on it, and back then I think copyright remained = with >> the authors (or possibly their employers, which are likely to have = changed >> in 14 years) at least at ID stage. And if you want it to remain as a = WG >> document you would need the WG to agree you take it over. (And the = IETF >> tools won't accept you doing that either without intervention from WG = chairs >> at least.) You could of course avoid that by going back to author = status, >> but see the earlier part of this point. >> (c) Lots of definitions in that draft aren't used in any MANET WG = document. >> For example we have no protocols using clustering. So why do we need = to >> define them? >> (d) Experience has shown that several of the definitions in that = document >> are of things that can cause a great deal of unproductive argument. = Let's >> not rehash that. >> (e) Protocols such as NHDP and OLSRv2 have included their own = definitions >> where these are needed. And even if it were desirable for these = protocols to >> reference an external document, it's too late. >>=20 >> -- >> Christopher Dearlove >> Senior Principal Engineer, Communications Group >> Communications, Networks and Image Analysis Capability >> BAE Systems Advanced Technology Centre >> West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK >> Tel: +44 1245 242194 | Fax: +44 1245 242124 >> chris.dearlove@baesystems.com | http://www.baesystems.com >>=20 >> 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 >>=20 >>=20 >> -----Original Message----- >> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On = Behalf Of >> Abdussalam Baryun >> Sent: 28 June 2012 10:12 >> To: manet >> Subject: [manet] MANET Terminology Update >>=20 >> ----------------------! WARNING ! ---------------------- >> This message originates from outside our organisation, >> either from an external partner or from the internet. >> Keep this in mind if you answer this message. >> Follow the 'Report Suspicious Emails' link on IT matters >> for instructions on reporting suspicious email messages. >> -------------------------------------------------------- >>=20 >> Hi All, >>=20 >> I have seen no draft that defines terminology in MANET WG, which I >> feel it is a basic RFC that should be in any WG so they agree on >> terminology within the group. I understand from my experience in this >> WG that the only RFC agreed on is the RFC2501 as a background for >> definitions. I want to work on defining terminology which I will >> update the draft expired below. Is there any one want to join me in >> authoring, (will first finish update comments on RFC2501 which will >> post shortly). >>=20 >> draft-ietf-manet-term-01 (Nov 1998) >> http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 >>=20 >> Please note that documents MAY expire but right knowledge/experience >> NEVER expires :) >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 >> ******************************************************************** >> 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. >> ******************************************************************** >>=20 >>=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From charliep@computer.org Thu Jun 28 10:15:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDE521F85AC for ; Thu, 28 Jun 2012 10:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=-1.548, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 UtIdQcl+f2Uj for ; Thu, 28 Jun 2012 10:15:45 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id D8D2921F854F for ; Thu, 28 Jun 2012 10:15:45 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.252.74]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SkIJl-00018k-Bx; Thu, 28 Jun 2012 13:15:45 -0400 Message-ID: <4FEC9139.6060407@computer.org> Date: Thu, 28 Jun 2012 10:15:37 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad867af76588ba91c3e495aaedc7f78f8160350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 17:15:46 -0000 Hello Abdussalam, That draft brings back a lot of memories. It was a good start, but was eventually folded into another draft that, if I remember correctly, became an RFC. I remember that the follow-on draft tried to make a distinction between vertical and horizontal mobility, which is much more about marketing than actual technology. I lost that argument and many more, but overall the document never really seemed to make very much difference even after its publication. Regards, Charlie P. On 6/28/2012 2:11 AM, Abdussalam Baryun wrote: > Hi All, > > I have seen no draft that defines terminology in MANET WG, which I > feel it is a basic RFC that should be in any WG so they agree on > terminology within the group. I understand from my experience in this > WG that the only RFC agreed on is the RFC2501 as a background for > definitions. I want to work on defining terminology which I will > update the draft expired below. Is there any one want to join me in > authoring, (will first finish update comments on RFC2501 which will > post shortly). > > draft-ietf-manet-term-01 (Nov 1998) > http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 > > Please note that documents MAY expire but right knowledge/experience > NEVER expires :) > > Abdussalam Baryun > University of Glamorgan, UK > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Regards, Charlie P. From abdussalambaryun@gmail.com Thu Jun 28 16:42:46 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD4021F8582 for ; Thu, 28 Jun 2012 16:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-1.493, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 e0I4nEi8dvN2 for ; Thu, 28 Jun 2012 16:42:45 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8321F84A5 for ; Thu, 28 Jun 2012 16:42:45 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2107156vcq.31 for ; Thu, 28 Jun 2012 16:42:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vq8uFR/KN/Na3hlYTdc2d3YSxQCvRLsXi8c8wcmnXAs=; b=xxjQpyJsnA5REoGBZBK030btBQ3iFcJvHPl3vKG8LDWNPdg/2ToO7+CFZPx/WgwceR SzPY/4OqmIHP+CEJfkQa5wi3NP03Htr/Dn07hTMx6DsDa9eDk40wZMGF3Z5qc9j0Rd+o 6yoN8X+UXmTlZYZLOf8ESIBZunKJIcdh8aJ6Z25MBIooAO1m9ANj9pQYNX70qxGeU+lU H1JkAz3Qlw01PhFPH0Swvt+ztYwz8GBfT/UESGPRjCwXMwc1POsZfEIn95/nnFWlWtJq P106LVHnco+VXHFV0or5L7TpdNYWt5M8dYWuxEkDe7uTMYMgPGPlQWRiRDnUiB9zxMKC x9RA== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr2468666vdi.86.1340926964675; Thu, 28 Jun 2012 16:42:44 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Thu, 28 Jun 2012 16:42:44 -0700 (PDT) In-Reply-To: <4FEC9139.6060407@computer.org> References: <4FEC9139.6060407@computer.org> Date: Fri, 29 Jun 2012 01:42:44 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 23:42:46 -0000 Hi Perkins, Thanks for your help, so I may understand that you don't mind if a I-D of terminology is to be active in the MANET-WG. I was wondering why some other WG have a terminology defined shared in documents while MANET doesn't. I think if we have it will make us more focus group, or using terms from one resource/document. My suggestion for a RFC that combines all terms of MANET-WG into one RFC is reasonable now, because we have RFC5444 and RFC6130 that are MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of terminology but there is no RFC of agreed terminology or refered to by MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term [LINK] differently, I don't like to expand this old problem into future when we have more documents as RFCs. Regards Abdussalam +++++++++++++++++++++++++++++++++++++++ On 6/28/12, Charles E. Perkins wrote: > > Hello Abdussalam, > > That draft brings back a lot of memories. It was a good start, but > was eventually folded into another draft that, if I remember correctly, > became an RFC. > > I remember that the follow-on draft tried to make a distinction > between vertical and horizontal mobility, which is much more about > marketing than actual technology. I lost that argument and many > more, but overall the document never really seemed to make very > much difference even after its publication. > > Regards, > Charlie P. > > > > On 6/28/2012 2:11 AM, Abdussalam Baryun wrote: >> Hi All, >> >> I have seen no draft that defines terminology in MANET WG, which I >> feel it is a basic RFC that should be in any WG so they agree on >> terminology within the group. I understand from my experience in this >> WG that the only RFC agreed on is the RFC2501 as a background for >> definitions. I want to work on defining terminology which I will >> update the draft expired below. Is there any one want to join me in >> authoring, (will first finish update comments on RFC2501 which will >> post shortly). >> >> draft-ietf-manet-term-01 (Nov 1998) >> http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 >> >> Please note that documents MAY expire but right knowledge/experience >> NEVER expires :) >> >> Abdussalam Baryun >> University of Glamorgan, UK >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > -- > Regards, > Charlie P. > > From teco@inf-net.nl Thu Jun 28 23:13:40 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1E11E808F for ; Thu, 28 Jun 2012 23:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 ehe+dcmhFpxy for ; Thu, 28 Jun 2012 23:13:40 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 195A511E8085 for ; Thu, 28 Jun 2012 23:13:39 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1291547eaa.31 for ; Thu, 28 Jun 2012 23:13:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=ubvCEdk4zOV9XN9TR4NS3ESceMHQr5d3D/Inko6BK08=; b=BbsvIij4e48v1tOj61s3cn4M5upW3eSCC+csb+w1A1enwFIHys21fA+ro9BOH1uDm2 H/oc5yyB3c1o/v5RtkvZfbAfq5nqeT+kZEZiDOZ3vWr7eCbHvqmM40VDXfMLECwKuCKo BrXJirJZm2CCULLZaw6r2lhLFnAbwEndzKLBQ1153q1+U76c8yF6TZG9IPzxRa/9spQz 1D7XB+zR5MoKp9DfrYgJALDP+/YqVyS1qabgW4POctp57fIudqD2WF0Ek39YqqoQrpl7 T8UY/mniaRIBKMKjQfWNtugx8V21jwQynV8G7SjlFzvpWS7GtroHG+MFTvsVy2XlbHlC xQmQ== Received: by 10.14.95.199 with SMTP id p47mr229988eef.22.1340950418248; Thu, 28 Jun 2012 23:13:38 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id q53sm4467222eef.8.2012.06.28.23.13.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 28 Jun 2012 23:13:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Fri, 29 Jun 2012 08:13:35 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <4FEC9139.6060407@computer.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQkqHAvJFTdi1CfA5/3pAIRW2Uk9wil32unKOTuOjR/qxqmqbD6GkJqyBhDOJnFXHTfCCuCf Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 06:13:41 -0000 I suggest you start a WG on "what is a link". You could dig archives and find out it wouldn't bring you somewhere. Anyway: good luck ! Teco Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschreven: > Hi Perkins, > > Thanks for your help, so I may understand that you don't mind if a I-D > of terminology is to be active in the MANET-WG. I was wondering why > some other WG have a terminology defined shared in documents while > MANET doesn't. I think if we have it will make us more focus group, or > using terms from one resource/document. > > My suggestion for a RFC that combines all terms of MANET-WG into one > RFC is reasonable now, because we have RFC5444 and RFC6130 that are > MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of > terminology but there is no RFC of agreed terminology or refered to by > MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term > [LINK] differently, I don't like to expand this old problem into > future when we have more documents as RFCs. > > Regards > Abdussalam > +++++++++++++++++++++++++++++++++++++++ > On 6/28/12, Charles E. Perkins wrote: >> >> Hello Abdussalam, >> >> That draft brings back a lot of memories. It was a good start, but >> was eventually folded into another draft that, if I remember correctly, >> became an RFC. >> >> I remember that the follow-on draft tried to make a distinction >> between vertical and horizontal mobility, which is much more about >> marketing than actual technology. I lost that argument and many >> more, but overall the document never really seemed to make very >> much difference even after its publication. >> >> Regards, >> Charlie P. >> >> >> >> On 6/28/2012 2:11 AM, Abdussalam Baryun wrote: >>> Hi All, >>> >>> I have seen no draft that defines terminology in MANET WG, which I >>> feel it is a basic RFC that should be in any WG so they agree on >>> terminology within the group. I understand from my experience in this >>> WG that the only RFC agreed on is the RFC2501 as a background for >>> definitions. I want to work on defining terminology which I will >>> update the draft expired below. Is there any one want to join me in >>> authoring, (will first finish update comments on RFC2501 which will >>> post shortly). >>> >>> draft-ietf-manet-term-01 (Nov 1998) >>> http://trac.tools.ietf.org/html/draft-ietf-manet-term-01 >>> >>> Please note that documents MAY expire but right knowledge/experience >>> NEVER expires :) >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> >> >> -- >> Regards, >> Charlie P. >> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jun 29 02:39:43 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B6F21F8741 for ; Fri, 29 Jun 2012 02:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=-1.457, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 38cTEE3SWpBR for ; Fri, 29 Jun 2012 02:39:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE421F873B for ; Fri, 29 Jun 2012 02:39:42 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2369780vcq.31 for ; Fri, 29 Jun 2012 02:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EA3Ikr2nchl7ZxZB9Lbn3fQ2MUh8wkomkdB8ULuUZso=; b=R4bfewXAl4XeGFeuLGtzfe5MAAesTLqtQFCw/q8KRvWbfdlpYh2G6UPmIgeTPM0Ma3 QB27+/c1gNTY5BHmaMFEgPpC+TSfOapjoRJknM7sBiwf6tUG8WfPOiZ09Y69NrcIQDPy 42TwbWudxZjjICvag53oxH9ft46M2IwmMlNIy70t+QddFurJkAyGCTyBuw3C2Y8INuER y/zlKl1XELQSncVBPLosGLtKXHBDUNd1O01CVX1yuB3xhRyu+mvHSFmZHhZxXdJFAiBp jKc2RTm8THCQRHRsKonpXrS8Ctz0jB6Rzkc/38zG1D1w2u3/UpZKrLCZoLR2++MExAw1 eEiw== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr415467vds.117.1340962781767; Fri, 29 Jun 2012 02:39:41 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Fri, 29 Jun 2012 02:39:41 -0700 (PDT) In-Reply-To: References: <4FEC9139.6060407@computer.org> Date: Fri, 29 Jun 2012 11:39:41 +0200 Message-ID: From: Abdussalam Baryun To: Teco Boot Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 09:39:43 -0000 Dear Teco, <[Ri] = Reason> I like doing efforts/works related within MANET-WG and don't like to do a mistake to open a new WG that is related to MANET just because I want to produce a RFC (e.g. RFC5889). IMHO, we should be consistent in our documents within our IETF WG, also we should author documents with some interaction among our previous RFCs and we have our experience interaction within our WG and among other IETF-WGs' experiences [R1]. IMHO we should not open another related WG just to avoid some problems (e.g. autoconfig WG). MANET-WG community needs to decide about the Terminology because it still didn't decide as far I know, and still has arguments among terms between members (if you ask I can give examples pointed in the list) [R2]. So my post subject is to find out community decision. Please note that I have good intentions and good reasons why I wanted an active I-D of terminology, and I will do my best to convince the MANET-WG at least to decide. However, I don't still see your reason why you don't want it. For me It is not only the reason for definition of [Link] that was an example for you to understand my argument. My main motivation was that I wanted to use RFC5444 and RFC6130 in my I-D, but have problem of their terminology are not consistent with mine, and if I use my own terminology and in the same time depend on these RFCs, it may confuse the reader in understanding terms/semantics [R3]. Please provide me with your reason, because only Chris and Charlie have gave feedback-reasons. Overall, some IETF-WGs when they open/start, they define terminology, purpose-with-requirements, and use-case, to be able to network efforts and synchronize. Even nodes in MANET may communicate when they have consistent messages format. Most of our MANET-documents have dependency plans but lack interaction-terms among them, because of different terminology used [R4]. In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the Internet-community takes the subject issue into consideration and make a sound decision. I propose this in the list and will do same in meeting 84, and will need to get the decision of this WG clear to progress in my I-D and others submitted to it. Thanking you, Best Regards Abdussalam Baryun University of Glamorgan, UK. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 6/29/12, Teco Boot wrote: > I suggest you start a WG on "what is a link". You could dig archives > and find out it wouldn't bring you somewhere. Anyway: good luck ! > > Teco > > Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschreven: > >> Hi Perkins, >> >> Thanks for your help, so I may understand that you don't mind if a I-D >> of terminology is to be active in the MANET-WG. I was wondering why >> some other WG have a terminology defined shared in documents while >> MANET doesn't. I think if we have it will make us more focus group, or >> using terms from one resource/document. >> >> My suggestion for a RFC that combines all terms of MANET-WG into one >> RFC is reasonable now, because we have RFC5444 and RFC6130 that are >> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of >> terminology but there is no RFC of agreed terminology or refered to by >> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term >> [LINK] differently, I don't like to expand this old problem into >> future when we have more documents as RFCs. >> >> Regards >> Abdussalam >> +++++++++++++++++++++++++++++++++++++++ From teco@inf-net.nl Fri Jun 29 03:18:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7862121F86C4 for ; Fri, 29 Jun 2012 03:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 scUub7r36urI for ; Fri, 29 Jun 2012 03:18:11 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 01EE221F8734 for ; Fri, 29 Jun 2012 03:18:08 -0700 (PDT) Received: by eaaq13 with SMTP id q13so1505109eaa.31 for ; Fri, 29 Jun 2012 03:18:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rdXCUKZ/b6aRfxcmDogCiAoaTGd8nqt7Pg2rXdVCjR4=; b=B1vqTKKRWmgPUJnN/vEpVQhNuOuXVXodWW/5XUhh4nwTagJDJITMQ53B+G3yKdMgUg sxmYcaXuURJDmRFM93cdp+EMcCLsE4Ku7c9iwl0shq1v3o423cBZOWJnIHrKYKi4rydX atINjZ1MXvrWLerB6WG21TTwfxSmX45e5hL3fOvXoFkAprlAN8l6QLvz88DpxS6HgjRL iOYvkRoyaFtgAAwbeNuXYIkiU657TliafSNYHaRSIrO3CG8G8GiCOOY5gcT4jMsSYd+f zJoCxsWgKw5STgDH3Kqz9IFZssE/A2BeYNRvfkSyp2gbk9R1thsBVSzCGR7pZPoQ5Tmg Nq3Q== Received: by 10.14.39.194 with SMTP id d42mr470622eeb.68.1340965087184; Fri, 29 Jun 2012 03:18:07 -0700 (PDT) Received: from ?IPv6:2001:470:7a9b:1:55eb:39c5:f236:3444? ([2001:470:7a9b:1:55eb:39c5:f236:3444]) by mx.google.com with ESMTPS id u14sm6382634eem.4.2012.06.29.03.18.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 03:18:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 29 Jun 2012 12:18:03 +0200 Content-Transfer-Encoding: 7bit Message-Id: <2B11A720-48D6-4FA3-87BE-BB41DD195AEA@inf-net.nl> References: <4FEC9139.6060407@computer.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQmSZqhyu0+1gzQR4jANFtpw/jbeAxzIgFqtMWJD1nw++iAa2Yp9Dra7kBmmO/l5sHxsfCro Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 10:18:12 -0000 Op 29 jun. 2012, om 11:39 heeft Abdussalam Baryun het volgende geschreven: > Dear Teco, > > <[Ri] = Reason> > > I like doing efforts/works related within MANET-WG and don't like to > do a mistake to open a new WG that is related to MANET just because I > want to produce a RFC (e.g. RFC5889). Go ahead, publish your I-D. Teco > IMHO, we should be consistent in > our documents within our IETF WG, also we should author documents with > some interaction among our previous RFCs and we have our experience > interaction within our WG and among other IETF-WGs' experiences [R1]. > IMHO we should not open another related WG just to avoid some problems > (e.g. autoconfig WG). > > MANET-WG community needs to decide about the Terminology because it > still didn't decide as far I know, and still has arguments among terms > between members (if you ask I can give examples pointed in the list) > [R2]. So my post subject is to find out community decision. Please > note that I have good intentions and good reasons why I wanted an > active I-D of terminology, and I will do my best to convince the > MANET-WG at least to decide. However, I don't still see your reason > why you don't want it. For me It is not only the reason for definition > of [Link] that was an example for you to understand my argument. My > main motivation was that I wanted to use RFC5444 and RFC6130 in my > I-D, but have problem of their terminology are not consistent with > mine, and if I use my own terminology and in the same time depend on > these RFCs, it may confuse the reader in understanding terms/semantics > [R3]. Please provide me with your reason, because only Chris and > Charlie have gave feedback-reasons. > > Overall, some IETF-WGs when they open/start, they define terminology, > purpose-with-requirements, and use-case, to be able to network efforts > and synchronize. Even nodes in MANET may communicate when they have > consistent messages format. Most of our MANET-documents have > dependency plans but lack interaction-terms among them, because of > different terminology used [R4]. > > In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the > Internet-community takes the subject issue into consideration and make > a sound decision. I propose this in the list and will do same in > meeting 84, and will need to get the decision of this WG clear to > progress in my I-D and others submitted to it. Thanking you, > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > On 6/29/12, Teco Boot wrote: >> I suggest you start a WG on "what is a link". You could dig archives >> and find out it wouldn't bring you somewhere. Anyway: good luck ! >> >> Teco >> >> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschreven: >> >>> Hi Perkins, >>> >>> Thanks for your help, so I may understand that you don't mind if a I-D >>> of terminology is to be active in the MANET-WG. I was wondering why >>> some other WG have a terminology defined shared in documents while >>> MANET doesn't. I think if we have it will make us more focus group, or >>> using terms from one resource/document. >>> >>> My suggestion for a RFC that combines all terms of MANET-WG into one >>> RFC is reasonable now, because we have RFC5444 and RFC6130 that are >>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of >>> terminology but there is no RFC of agreed terminology or refered to by >>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term >>> [LINK] differently, I don't like to expand this old problem into >>> future when we have more documents as RFCs. >>> >>> Regards >>> Abdussalam >>> +++++++++++++++++++++++++++++++++++++++ From sratliff@cisco.com Fri Jun 29 07:43:11 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C229E21F86A3 for ; Fri, 29 Jun 2012 07:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_RAND_BD4=3] 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 z2UEVDo7BBey for ; Fri, 29 Jun 2012 07:43:10 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 70F5521F86D4 for ; Fri, 29 Jun 2012 07:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=4795; q=dns/txt; s=iport; t=1340980990; x=1342190590; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zeNyAUtonTfyBimcuTs4aSRsvMdZYkPT/MCSKXuvodU=; b=mbySlI00Unh7iYQPTczJkU0Wpb2M6Kj0NawOtgEYxtsTt5LcZyVUnN7G CDoXg+rKzuAlwvFylsVoxmhRH0fdZ5a/do0YrVTpzv3xuKKyXmSIXoLvL 3HY83R+9qMYh0fVlOJMAJ6zelLW6ZDSOZ3PzZQGvLK39We17ssGMd3ftg I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAFu+7U+tJV2a/2dsb2JhbABFtleBB4IYAQEBAwEBAQEPASc0CwULCxguJzAGExQOh2QFC5tWoFEEizeFKmADlTOOHYFmgnuBQw X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208";a="97286587" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jun 2012 14:43:10 +0000 Received: from dhcp-64-102-54-116.cisco.com (dhcp-64-102-54-116.cisco.com [64.102.54.116]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q5TEh9U9005878; Fri, 29 Jun 2012 14:43:09 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Fri, 29 Jun 2012 10:43:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <45EC8EE3-3561-45E9-B7B1-58E1D7BDCCDC@cisco.com> References: <4FEC9139.6060407@computer.org> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 14:43:12 -0000 Abdussalam, On Jun 29, 2012, at 5:39 AM, Abdussalam Baryun wrote: > Dear Teco, >=20 > <[Ri] =3D Reason> >=20 > I like doing efforts/works related within MANET-WG and don't like to > do a mistake to open a new WG that is related to MANET just because I > want to produce a RFC (e.g. RFC5889). IMHO, we should be consistent in > our documents within our IETF WG, also we should author documents with > some interaction among our previous RFCs and we have our experience > interaction within our WG and among other IETF-WGs' experiences [R1]. > IMHO we should not open another related WG just to avoid some problems > (e.g. autoconfig WG). >=20 > MANET-WG community needs to decide about the Terminology because it > still didn't decide as far I know, and still has arguments among terms > between members (if you ask I can give examples pointed in the list) > [R2]. So my post subject is to find out community decision. Please > note that I have good intentions and good reasons why I wanted an > active I-D of terminology, and I will do my best to convince the > MANET-WG at least to decide. However, I don't still see your reason > why you don't want it. For me It is not only the reason for definition > of [Link] that was an example for you to understand my argument. My > main motivation was that I wanted to use RFC5444 and RFC6130 in my > I-D, but have problem of their terminology are not consistent with > mine, and if I use my own terminology and in the same time depend on > these RFCs, it may confuse the reader in understanding terms/semantics > [R3]. Please provide me with your reason, because only Chris and > Charlie have gave feedback-reasons. >=20 > Overall, some IETF-WGs when they open/start, they define terminology, > purpose-with-requirements, and use-case, to be able to network efforts > and synchronize. Even nodes in MANET may communicate when they have > consistent messages format. Most of our MANET-documents have > dependency plans but lack interaction-terms among them, because of > different terminology used [R4]. >=20 > In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the > Internet-community takes the subject issue into consideration and make > a sound decision. I propose this in the list and will do same in > meeting 84, and will need to get the decision of this WG clear to > progress in my I-D and others submitted to it. I think you *already have* the decision of the WG - can you point to a = single response on this email list that has been positive and supports = this effort? You've asked the working group about a terminology = document. With varying degrees of bluntness (and one case of some = well-executed sarcasm), and for varying reasons, the people active on = the list have said "No". I haven't seen a single case of anyone saying = anything close to "YES! This would be an important, good thing for the = MANET WG to spend time on!"=20 So as this point, I'm not sure what else to say, other than to reiterate = - I don't think this is a necessary effort; I don't think it will be a = fruitful effort; and I personally believe it spends WG cycles where they = are not needed. Regards, Stan > Thanking you, >=20 > Best Regards >=20 > Abdussalam Baryun > University of Glamorgan, UK. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 >=20 > On 6/29/12, Teco Boot wrote: >> I suggest you start a WG on "what is a link". You could dig archives >> and find out it wouldn't bring you somewhere. Anyway: good luck ! >>=20 >> Teco >>=20 >> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende = geschreven: >>=20 >>> Hi Perkins, >>>=20 >>> Thanks for your help, so I may understand that you don't mind if a = I-D >>> of terminology is to be active in the MANET-WG. I was wondering why >>> some other WG have a terminology defined shared in documents while >>> MANET doesn't. I think if we have it will make us more focus group, = or >>> using terms from one resource/document. >>>=20 >>> My suggestion for a RFC that combines all terms of MANET-WG into one >>> RFC is reasonable now, because we have RFC5444 and RFC6130 that are >>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of >>> terminology but there is no RFC of agreed terminology or refered to = by >>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one = term >>> [LINK] differently, I don't like to expand this old problem into >>> future when we have more documents as RFCs. >>>=20 >>> Regards >>> Abdussalam >>> +++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Fri Jun 29 08:11:49 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145C821F875B for ; Fri, 29 Jun 2012 08:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.024 X-Spam-Level: X-Spam-Status: No, score=-2.024 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 R1ZNTwblRTfu for ; Fri, 29 Jun 2012 08:11:48 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E969421F875A for ; Fri, 29 Jun 2012 08:11:47 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2600686vcq.31 for ; Fri, 29 Jun 2012 08:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6U0eVKEr1wejzzW9Ifr48o2H8OXboT0fnOrpVwvu5uM=; b=IFVHXI+G+i7waPZd/zffGUOZICVHChKDABcTLOCRvMvc9lp6gIpY8C2MGCW03vs02+ xdT4klPP1CjWTN132cJOv9r3fs0A0bATfN65b0ojaH6+2GtSJ6/bfIenoIjKgH40ClOI VxA8/GD3NUqS9vgGFDSlvhXDYUU0ogVsavUhMWTI2LcCXFMriMb9TRuC8I+VFP6AnPpj FsLt4lY813L6MMWu8IhvsXUo31eelDkYrjWn0za2GUPO6n9fX9LVKkH1QIgfHC3rkZQ+ DQ2uVVsLSqpptRbuVewL6jMwlp012ZsPCp4FmnLgVPdVRVzAIgXwTmX+hyjNyH1qyUm/ AA6g== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr1211023vcw.55.1340982707250; Fri, 29 Jun 2012 08:11:47 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Fri, 29 Jun 2012 08:11:47 -0700 (PDT) In-Reply-To: <45EC8EE3-3561-45E9-B7B1-58E1D7BDCCDC@cisco.com> References: <4FEC9139.6060407@computer.org> <45EC8EE3-3561-45E9-B7B1-58E1D7BDCCDC@cisco.com> Date: Fri, 29 Jun 2012 17:11:47 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:11:49 -0000 I got a response of go ahead, that is enough for me, AB +++++++++++++++++++++++++++++++++++++++++++ On 6/29/12, Stan Ratliff wrote: > Abdussalam, > > On Jun 29, 2012, at 5:39 AM, Abdussalam Baryun wrote: > >> Dear Teco, >> >> <[Ri] = Reason> >> >> I like doing efforts/works related within MANET-WG and don't like to >> do a mistake to open a new WG that is related to MANET just because I >> want to produce a RFC (e.g. RFC5889). IMHO, we should be consistent in >> our documents within our IETF WG, also we should author documents with >> some interaction among our previous RFCs and we have our experience >> interaction within our WG and among other IETF-WGs' experiences [R1]. >> IMHO we should not open another related WG just to avoid some problems >> (e.g. autoconfig WG). >> >> MANET-WG community needs to decide about the Terminology because it >> still didn't decide as far I know, and still has arguments among terms >> between members (if you ask I can give examples pointed in the list) >> [R2]. So my post subject is to find out community decision. Please >> note that I have good intentions and good reasons why I wanted an >> active I-D of terminology, and I will do my best to convince the >> MANET-WG at least to decide. However, I don't still see your reason >> why you don't want it. For me It is not only the reason for definition >> of [Link] that was an example for you to understand my argument. My >> main motivation was that I wanted to use RFC5444 and RFC6130 in my >> I-D, but have problem of their terminology are not consistent with >> mine, and if I use my own terminology and in the same time depend on >> these RFCs, it may confuse the reader in understanding terms/semantics >> [R3]. Please provide me with your reason, because only Chris and >> Charlie have gave feedback-reasons. >> >> Overall, some IETF-WGs when they open/start, they define terminology, >> purpose-with-requirements, and use-case, to be able to network efforts >> and synchronize. Even nodes in MANET may communicate when they have >> consistent messages format. Most of our MANET-documents have >> dependency plans but lack interaction-terms among them, because of >> different terminology used [R4]. >> >> In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the >> Internet-community takes the subject issue into consideration and make >> a sound decision. I propose this in the list and will do same in >> meeting 84, and will need to get the decision of this WG clear to >> progress in my I-D and others submitted to it. > > I think you *already have* the decision of the WG - can you point to a > single response on this email list that has been positive and supports this > effort? You've asked the working group about a terminology document. With > varying degrees of bluntness (and one case of some well-executed sarcasm), > and for varying reasons, the people active on the list have said "No". I > haven't seen a single case of anyone saying anything close to "YES! This > would be an important, good thing for the MANET WG to spend time on!" > > So as this point, I'm not sure what else to say, other than to reiterate - I > don't think this is a necessary effort; I don't think it will be a fruitful > effort; and I personally believe it spends WG cycles where they are not > needed. > > Regards, > Stan > > >> Thanking you, >> >> Best Regards >> >> Abdussalam Baryun >> University of Glamorgan, UK. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> >> On 6/29/12, Teco Boot wrote: >>> I suggest you start a WG on "what is a link". You could dig archives >>> and find out it wouldn't bring you somewhere. Anyway: good luck ! >>> >>> Teco >>> >>> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende >>> geschreven: >>> >>>> Hi Perkins, >>>> >>>> Thanks for your help, so I may understand that you don't mind if a I-D >>>> of terminology is to be active in the MANET-WG. I was wondering why >>>> some other WG have a terminology defined shared in documents while >>>> MANET doesn't. I think if we have it will make us more focus group, or >>>> using terms from one resource/document. >>>> >>>> My suggestion for a RFC that combines all terms of MANET-WG into one >>>> RFC is reasonable now, because we have RFC5444 and RFC6130 that are >>>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of >>>> terminology but there is no RFC of agreed terminology or refered to by >>>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term >>>> [LINK] differently, I don't like to expand this old problem into >>>> future when we have more documents as RFCs. >>>> >>>> Regards >>>> Abdussalam >>>> +++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From teco@inf-net.nl Fri Jun 29 08:32:12 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075D321F86E4 for ; Fri, 29 Jun 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 1-fWa7rkbzFW for ; Fri, 29 Jun 2012 08:32:11 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AED621F86CF for ; Fri, 29 Jun 2012 08:32:09 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2167793wgb.13 for ; Fri, 29 Jun 2012 08:32:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=xZHdw5lsYxy1M+OcV06BwSDN42sGDozbPKo3XV5yxG0=; b=TTZ6lbPc/3hi3cuXaLukGR7381U4SJUf/+Ws9ga6aKJ5IZWfh1RwXCtR1MTs6n4gNY LYfvfUnzsx1RHxnojxw0/K4yxKFKGApkWP7PtyHAJMu6+y7etRux7UnLINSQKIljPf6X wlxoVFHBqhbSJESuYLFwd+56lJd46951VbxpDXq3d2NZnZfHGLj/OGRW0Hnil0kjrkuN 0lGjgwBhhLaIINc8pl4vcsQqx6SEY+zwzdTybkrqewwHxFERBRZQXvBcMjSf1WL+k2xa WQ0/a2phsJ1FW90aWXBCwFavJaW4l1Ft/h8h3Qb0NRGyTAMxY+XkA6kJ7uCwngsu2yWi +SSA== Received: by 10.216.225.230 with SMTP id z80mr1113354wep.182.1340983928817; Fri, 29 Jun 2012 08:32:08 -0700 (PDT) Received: from [10.175.173.95] (524A14A4.cm-4-3a.dynamic.ziggo.nl. [82.74.20.164]) by mx.google.com with ESMTPS id eb8sm6267943wib.11.2012.06.29.08.32.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 08:32:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Teco Boot In-Reply-To: Date: Fri, 29 Jun 2012 17:32:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5598A1A8-E4F3-40AB-8B15-E1799954A415@inf-net.nl> References: <4FEC9139.6060407@computer.org> <45EC8EE3-3561-45E9-B7B1-58E1D7BDCCDC@cisco.com> To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-Gm-Message-State: ALoCoQl50YsKalMifb2KXRMvQ6fTM5U+RlZVhcxJBsg/eAu37Bi40KSF8aWU+BA3Em+aYzCyd44J Cc: manet , Stan Ratliff Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:32:12 -0000 Op 29 jun. 2012, om 17:11 heeft Abdussalam Baryun het volgende = geschreven: > I got a response of go ahead, that is enough for me, I suggested multiple times to post less and put your energy in publish = an I-D, if you want interest of the WG. Then you ask the WG their = opinion. In that order. I hope you get the message now. Teco. >=20 > AB > +++++++++++++++++++++++++++++++++++++++++++ >=20 > On 6/29/12, Stan Ratliff wrote: >> Abdussalam, >>=20 >> On Jun 29, 2012, at 5:39 AM, Abdussalam Baryun wrote: >>=20 >>> Dear Teco, >>>=20 >>> <[Ri] =3D Reason> >>>=20 >>> I like doing efforts/works related within MANET-WG and don't like to >>> do a mistake to open a new WG that is related to MANET just because = I >>> want to produce a RFC (e.g. RFC5889). IMHO, we should be consistent = in >>> our documents within our IETF WG, also we should author documents = with >>> some interaction among our previous RFCs and we have our experience >>> interaction within our WG and among other IETF-WGs' experiences = [R1]. >>> IMHO we should not open another related WG just to avoid some = problems >>> (e.g. autoconfig WG). >>>=20 >>> MANET-WG community needs to decide about the Terminology because it >>> still didn't decide as far I know, and still has arguments among = terms >>> between members (if you ask I can give examples pointed in the list) >>> [R2]. So my post subject is to find out community decision. Please >>> note that I have good intentions and good reasons why I wanted an >>> active I-D of terminology, and I will do my best to convince the >>> MANET-WG at least to decide. However, I don't still see your reason >>> why you don't want it. For me It is not only the reason for = definition >>> of [Link] that was an example for you to understand my argument. My >>> main motivation was that I wanted to use RFC5444 and RFC6130 in my >>> I-D, but have problem of their terminology are not consistent with >>> mine, and if I use my own terminology and in the same time depend on >>> these RFCs, it may confuse the reader in understanding = terms/semantics >>> [R3]. Please provide me with your reason, because only Chris and >>> Charlie have gave feedback-reasons. >>>=20 >>> Overall, some IETF-WGs when they open/start, they define = terminology, >>> purpose-with-requirements, and use-case, to be able to network = efforts >>> and synchronize. Even nodes in MANET may communicate when they have >>> consistent messages format. Most of our MANET-documents have >>> dependency plans but lack interaction-terms among them, because of >>> different terminology used [R4]. >>>=20 >>> In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the >>> Internet-community takes the subject issue into consideration and = make >>> a sound decision. I propose this in the list and will do same in >>> meeting 84, and will need to get the decision of this WG clear to >>> progress in my I-D and others submitted to it. >>=20 >> I think you *already have* the decision of the WG - can you point to = a >> single response on this email list that has been positive and = supports this >> effort? You've asked the working group about a terminology document. = With >> varying degrees of bluntness (and one case of some well-executed = sarcasm), >> and for varying reasons, the people active on the list have said = "No". I >> haven't seen a single case of anyone saying anything close to "YES! = This >> would be an important, good thing for the MANET WG to spend time on!" >>=20 >> So as this point, I'm not sure what else to say, other than to = reiterate - I >> don't think this is a necessary effort; I don't think it will be a = fruitful >> effort; and I personally believe it spends WG cycles where they are = not >> needed. >>=20 >> Regards, >> Stan >>=20 >>=20 >>> Thanking you, >>>=20 >>> Best Regards >>>=20 >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>>=20 >>> On 6/29/12, Teco Boot wrote: >>>> I suggest you start a WG on "what is a link". You could dig = archives >>>> and find out it wouldn't bring you somewhere. Anyway: good luck ! >>>>=20 >>>> Teco >>>>=20 >>>> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende >>>> geschreven: >>>>=20 >>>>> Hi Perkins, >>>>>=20 >>>>> Thanks for your help, so I may understand that you don't mind if a = I-D >>>>> of terminology is to be active in the MANET-WG. I was wondering = why >>>>> some other WG have a terminology defined shared in documents while >>>>> MANET doesn't. I think if we have it will make us more focus = group, or >>>>> using terms from one resource/document. >>>>>=20 >>>>> My suggestion for a RFC that combines all terms of MANET-WG into = one >>>>> RFC is reasonable now, because we have RFC5444 and RFC6130 that = are >>>>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D = of >>>>> terminology but there is no RFC of agreed terminology or refered = to by >>>>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one = term >>>>> [LINK] differently, I don't like to expand this old problem into >>>>> future when we have more documents as RFCs. >>>>>=20 >>>>> Regards >>>>> Abdussalam >>>>> +++++++++++++++++++++++++++++++++++++++ >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >>=20 From ulrich@herberg.name Fri Jun 29 09:58:32 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D7E21F86D4 for ; Fri, 29 Jun 2012 09:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_RAND_BD4=3] 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 HTzG-yNixjr4 for ; Fri, 29 Jun 2012 09:58:31 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83A3A21F86D5 for ; Fri, 29 Jun 2012 09:58:31 -0700 (PDT) Received: by ggnc4 with SMTP id c4so3272581ggn.31 for ; Fri, 29 Jun 2012 09:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=at3ffX/VB15UbdXsz1wObqNGkAZX7JTARZFfRbEv27c=; b=goHkPLsgl/h4ALQyBIXH41zISIxAAgJj3lILmwsMOkaHg1eDnt8Hbumz33kFDoyCkF bWHzslKJt1xw7EERn0rsoefnRH/d9cCLcex1ZwF6QHcGdu06EsElV2Qxy3uItgCbtvUG fTFBClE9f7ztOzV0j4ZKrL1t/WnjuvSXX5kLA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=at3ffX/VB15UbdXsz1wObqNGkAZX7JTARZFfRbEv27c=; b=XvD3tVwjMuo1lu4cDP3KbanrfQMgeeIy5B8bJqMN/Jpq/BYdhoAbswpQKxPENW+zZK Q+Sdb2jlJ2sYpGwkgjyVZK27CzfQHzy2htqeTklVpxwIO+4S9gaP6IDs9FKP+PxWIzP0 I7rFW1ZpIa83inmrRwXyUEetz8DIwrOcP4JYuOrLZ7LQC9rdF6pKRAonnxWskiCd+GsP J6diAJ1ZI0odUxL/xOFY5h4mlMt4fMVI3KREvIFIvhHtCFY1XgQ6te9nBQklfmac+Oro stK9r5wZCNiUPenF8dYkY58q75xdv9oARBi49PIiWhLC+0AePXppRdN63VZO9EMQg+VI zp6w== MIME-Version: 1.0 Received: by 10.101.165.29 with SMTP id s29mr1055515ano.2.1340989110958; Fri, 29 Jun 2012 09:58:30 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Fri, 29 Jun 2012 09:58:30 -0700 (PDT) In-Reply-To: References: <4FEC9139.6060407@computer.org> Date: Fri, 29 Jun 2012 09:58:30 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=001636c5bea19b3c3804c39f5b88 X-Gm-Message-State: ALoCoQmB3F305Uu/h71hCIa5JYXH8PSjIW/QK9wiGeSFyJXOiWMC4t3BQGa8ZUiTleHqAaPC5XAP Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:58:33 -0000 --001636c5bea19b3c3804c39f5b88 Content-Type: text/plain; charset=ISO-8859-1 Abdussalam, On Fri, Jun 29, 2012 at 2:39 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Dear Teco, > > <[Ri] = Reason> > > I like doing efforts/works related within MANET-WG and don't like to > do a mistake to open a new WG that is related to MANET just because I > want to produce a RFC (e.g. RFC5889). You are mistaken. MANET WG is in the routing area, AUTOCONF was in the Internet area. That is a totally different focus, and there were good reasons to have a separate WG. > IMHO, we should be consistent in > our documents within our IETF WG, also we should author documents with > some interaction among our previous RFCs and we have our experience > interaction within our WG and among other IETF-WGs' experiences [R1]. > IMHO we should not open another related WG just to avoid some problems > (e.g. autoconfig WG). > I believe that the RFCs we have published recently in MANET (and the WG drafts that are about to be sent to the IESG), are consistent in their terminology. I have not seen any problem of producing solutions because of misleading terminology, and I therefore believe it would be unnecessary to spend time on this. > > MANET-WG community needs to decide about the Terminology because it > still didn't decide as far I know, and still has arguments among terms > between members (if you ask I can give examples pointed in the list) > [R2]. So my post subject is to find out community decision. Please > note that I have good intentions and good reasons why I wanted an > active I-D of terminology, and I will do my best to convince the > MANET-WG at least to decide. However, I don't still see your reason > why you don't want it. For me It is not only the reason for definition > of [Link] that was an example for you to understand my argument. > My > main motivation was that I wanted to use RFC5444 and RFC6130 in my > I-D, but have problem of their terminology are not consistent with > mine, Well, how about you change your terminology then to make it consistent with existing MANET RFCs and WG documents? > and if I use my own terminology and in the same time depend on > these RFCs, it may confuse the reader in understanding terms/semantics > [R3]. Please provide me with your reason, because only Chris and > Charlie have gave feedback-reasons. > > Overall, some IETF-WGs when they open/start, they define terminology, > purpose-with-requirements, and use-case, to be able to network efforts > and synchronize. Even nodes in MANET may communicate when they have > consistent messages format. Most of our MANET-documents have > dependency plans but lack interaction-terms among them, because of > different terminology used [R4]. > I believe we have a lot of interaction between the different protocols; they all use the same packet format, several of them use RFC6130. I don't know what you mean by lack of interaction. And most certainly, I don't see a problem of terminology. > > In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the > Internet-community takes the subject issue into consideration and make > a sound decision. I propose this in the list and will do same in > meeting 84, and will need to get the decision of this WG clear to > progress in my I-D and others submitted to it. Thanking you, > Abdussalam, we spend a lot of cycles on these discussion of yours; I second Teco and suggest that instead of writing many long emails, you work on the drafts and propose them to the WG. Best Ulrich > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > On 6/29/12, Teco Boot wrote: > > I suggest you start a WG on "what is a link". You could dig archives > > and find out it wouldn't bring you somewhere. Anyway: good luck ! > > > > Teco > > > > Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende > geschreven: > > > >> Hi Perkins, > >> > >> Thanks for your help, so I may understand that you don't mind if a I-D > >> of terminology is to be active in the MANET-WG. I was wondering why > >> some other WG have a terminology defined shared in documents while > >> MANET doesn't. I think if we have it will make us more focus group, or > >> using terms from one resource/document. > >> > >> My suggestion for a RFC that combines all terms of MANET-WG into one > >> RFC is reasonable now, because we have RFC5444 and RFC6130 that are > >> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of > >> terminology but there is no RFC of agreed terminology or refered to by > >> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term > >> [LINK] differently, I don't like to expand this old problem into > >> future when we have more documents as RFCs. > >> > >> Regards > >> Abdussalam > >> +++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001636c5bea19b3c3804c39f5b88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Abdussalam,

On Fri, Jun 29, 2012 at 2:39 = AM, Abdussalam Baryun <abdussalambaryun@gmail.com> = wrote:
Dear Teco,

<[Ri] =3D Reason>

I like doing efforts/works related within MANET-WG and don't like to do a mistake to open a new WG that is related to MANET just because I
want to produce a RFC (e.g. RFC5889).

You are mistake= n. MANET WG is in the routing area, AUTOCONF was in the Internet area. That= is a totally different focus, and there were good reasons to have a separa= te WG.

=A0
IMHO, we sho= uld be consistent in
our documents within our IETF WG, also we should author documents with
some interaction among our previous RFCs and we have our experience
interaction within our WG and among other IETF-WGs' experiences [R1]. IMHO we should not open another related WG just to avoid some problems
(e.g. autoconfig WG).


I believe that the RFCs = we have published recently in MANET (and the WG drafts that are about to be= sent to the IESG), are consistent in their terminology. I have not seen an= y problem of producing solutions because of misleading terminology, and I t= herefore believe it would be unnecessary to spend time on this.
=A0

=A0MANET-WG community needs to decide about the Terminology because it
still didn't decide as far I know, and still has arguments among terms<= br> between members (if you ask I can give examples pointed in the list)
[R2]. So my post subject is to find out community decision. Please
note that I have good intentions and good reasons why I wanted an
active =A0I-D of terminology, and I will do my best to convince the
MANET-WG at least to decide. However, I don't still see your reason
why you don't want it. For me It is not only the reason for definition<= br> of [Link] that was an example for you to understand my argument.
My
main motivation was that I wanted to use RFC5444 and RFC6130 in my
I-D, but have problem of their terminology are not consistent with
mine,


Well, how about you change your terminology = then to make it consistent with existing MANET RFCs and WG documents?
=A0
and if I use my own terminology and in the same time depend on
these RFCs, it may confuse the reader in understanding terms/semantics
[R3]. Please provide me with your reason, because only Chris and
Charlie have gave feedback-reasons.

Overall, some IETF-WGs when they open/start, they define terminology,
purpose-with-requirements, and use-case, to be able to network efforts
and synchronize. Even nodes in MANET may communicate when they have
consistent messages format. Most of our MANET-documents have
dependency plans but lack interaction-terms among them, because of
different terminology used [R4].


I believe we = have a lot of interaction between the different protocols; they all use the= same packet format, several of them use RFC6130. I don't know what you= mean by lack of interaction. And most certainly, I don't see a problem= of terminology.

=A0

In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the
Internet-community takes the subject issue into consideration and make
a sound decision. I propose this in the list and will do same in
meeting 84, and will need to get the decision of this WG clear to
progress in my I-D and others submitted to it. Thanking you,


Abdussalam, we spend a lot of cycles on these discussion of = yours; I second Teco and suggest that instead of writing many long emails, = you work on the drafts and propose them to the WG.

Best
Ulrich


=A0

Best Regards

Abdussalam Baryun
University of Glamorgan, UK.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++


On 6/29/12, Teco Boot <teco@inf-net.n= l> wrote:
> I suggest you start a WG on "what is a link". You could dig = archives
> and find out it wouldn't bring you somewhere. Anyway: good luck !<= br> >
> Teco
>
> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschre= ven:
>
>> Hi Perkins,
>>
>> Thanks for your help, so I may understand that you don't mind = if a I-D
>> of terminology is to be active in the MANET-WG. I was wondering wh= y
>> some other WG have a terminology defined shared in documents while=
>> MANET doesn't. I think if we have it will make us more focus g= roup, or
>> using terms from one resource/document.
>>
>> My suggestion for a RFC that combines all terms of MANET-WG into o= ne
>> RFC is reasonable now, because we have RFC5444 and RFC6130 that ar= e
>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D = of
>> terminology but there is no RFC of agreed terminology or refered t= o by
>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one = term
>> [LINK] differently, I don't like to expand this old problem in= to
>> future when we have more documents as RFCs.
>>
>> Regards
>> Abdussalam
>> +++++++++++++++++++++++++++++++++++++++
_____________________________= __________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--001636c5bea19b3c3804c39f5b88-- From d.sturek@att.net Fri Jun 29 12:01:29 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801C21F88A7 for ; Fri, 29 Jun 2012 12:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[AWL=-2.163, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_RAND_BD4=3] 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 RDkMejF2-TwL for ; Fri, 29 Jun 2012 12:01:26 -0700 (PDT) Received: from nm30-vm0.bullet.mail.ac4.yahoo.com (nm30-vm0.bullet.mail.ac4.yahoo.com [98.139.52.250]) by ietfa.amsl.com (Postfix) with SMTP id ED1F821F888C for ; Fri, 29 Jun 2012 12:01:25 -0700 (PDT) Received: from [98.139.52.188] by nm30.bullet.mail.ac4.yahoo.com with NNFMP; 29 Jun 2012 19:01:20 -0000 Received: from [68.142.194.243] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 29 Jun 2012 19:01:19 -0000 Received: from [66.94.237.125] by t1.bullet.mud.yahoo.com with NNFMP; 29 Jun 2012 19:01:19 -0000 Received: from [127.0.0.1] by omp1030.access.mail.mud.yahoo.com with NNFMP; 29 Jun 2012 19:01:19 -0000 X-Yahoo-Newman-Id: 693335.16358.bm@omp1030.access.mail.mud.yahoo.com Received: (qmail 4577 invoked from network); 29 Jun 2012 19:01:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1340996479; bh=L+3qND5Eoisr4qEiC98tRSBa+WL8+Jc0PDQwgnwvqX8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type; b=r4gvtBrOF5YhD9Vfre2NwOKVMjjWD4yvk+ybVgkTeGluABeZ4iJUOwjMAT+mQ+sWHIaYCE8rMsmaj4pXotTHMCDuvY++R9kD2lMcs27qFVCFtUsDIX7eosUGN3DNaN4ZKrAXIayPnbxrX4bRUb+d9pi5R/4IZTkH0rqX3M/0/nc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6MyvAYcVM1kostCeFTK6ru_EFdFU11X9bQZIc9nzM2fqedr n0hWgTe8MZuHY5EPXw1e_89vd0mNU8MbGVylu2WL7.U7YfxXzzhc1wtTN7Wb CB5uI6jFLUYaimJdHuh4NhQxYpgVEJgB1VcjZCggXdBhmoEua9nDI8Y6XLZE Jm_30o7DnJSiSCGpm8cDM6cvS9VFE97U8N8LF2v.579sLCn0E2lo5cA1Wc7Y YKfM512aIOrxOgDzHsRaw.1e8RUoXiiYcK.2EOHNda1FYlHdQoBBtqS5tv23 P8QwIBBbhF6z3CedW.r2cIdmTn_i7ECh1wYkYBkpaBam1FPEbw5wkfDFYDdn i8hfT1tLmgy3_BE8X_DlvNm2WwvUiK7.7rWg9Cpe5I3IuyTzHhhTKMqv8jQO SeFrCG4FDpi.ZPdNaTZu0gSEp_a3Lx5LYTNU- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.30.0.104] (d.sturek@87.123.125.225 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 29 Jun 2012 12:00:57 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 29 Jun 2012 11:59:59 -0700 From: Don Sturek To: Ulrich Herberg , Abdussalam Baryun Message-ID: Thread-Topic: [manet] MANET Terminology Update In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3423816057_81340" Cc: manet Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:01:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3423816057_81340 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit +1 More (relevant) drafts and less e-mail would work for me! Don From: Ulrich Herberg Date: Friday, June 29, 2012 9:58 AM To: Abdussalam Baryun Cc: manet Subject: Re: [manet] MANET Terminology Update Abdussalam, On Fri, Jun 29, 2012 at 2:39 AM, Abdussalam Baryun wrote: > Dear Teco, > > <[Ri] = Reason> > > I like doing efforts/works related within MANET-WG and don't like to > do a mistake to open a new WG that is related to MANET just because I > want to produce a RFC (e.g. RFC5889). You are mistaken. MANET WG is in the routing area, AUTOCONF was in the Internet area. That is a totally different focus, and there were good reasons to have a separate WG. > IMHO, we should be consistent in > our documents within our IETF WG, also we should author documents with > some interaction among our previous RFCs and we have our experience > interaction within our WG and among other IETF-WGs' experiences [R1]. > IMHO we should not open another related WG just to avoid some problems > (e.g. autoconfig WG). I believe that the RFCs we have published recently in MANET (and the WG drafts that are about to be sent to the IESG), are consistent in their terminology. I have not seen any problem of producing solutions because of misleading terminology, and I therefore believe it would be unnecessary to spend time on this. > > MANET-WG community needs to decide about the Terminology because it > still didn't decide as far I know, and still has arguments among terms > between members (if you ask I can give examples pointed in the list) > [R2]. So my post subject is to find out community decision. Please > note that I have good intentions and good reasons why I wanted an > active I-D of terminology, and I will do my best to convince the > MANET-WG at least to decide. However, I don't still see your reason > why you don't want it. For me It is not only the reason for definition > of [Link] that was an example for you to understand my argument. > My > main motivation was that I wanted to use RFC5444 and RFC6130 in my > I-D, but have problem of their terminology are not consistent with > mine, Well, how about you change your terminology then to make it consistent with existing MANET RFCs and WG documents? > and if I use my own terminology and in the same time depend on > these RFCs, it may confuse the reader in understanding terms/semantics > [R3]. Please provide me with your reason, because only Chris and > Charlie have gave feedback-reasons. > > Overall, some IETF-WGs when they open/start, they define terminology, > purpose-with-requirements, and use-case, to be able to network efforts > and synchronize. Even nodes in MANET may communicate when they have > consistent messages format. Most of our MANET-documents have > dependency plans but lack interaction-terms among them, because of > different terminology used [R4]. I believe we have a lot of interaction between the different protocols; they all use the same packet format, several of them use RFC6130. I don't know what you mean by lack of interaction. And most certainly, I don't see a problem of terminology. > > In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the > Internet-community takes the subject issue into consideration and make > a sound decision. I propose this in the list and will do same in > meeting 84, and will need to get the decision of this WG clear to > progress in my I-D and others submitted to it. Thanking you, Abdussalam, we spend a lot of cycles on these discussion of yours; I second Teco and suggest that instead of writing many long emails, you work on the drafts and propose them to the WG. Best Ulrich > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > > On 6/29/12, Teco Boot wrote: >> > I suggest you start a WG on "what is a link". You could dig archives >> > and find out it wouldn't bring you somewhere. Anyway: good luck ! >> > >> > Teco >> > >> > Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschreven: >> > >>> >> Hi Perkins, >>> >> >>> >> Thanks for your help, so I may understand that you don't mind if a I-D >>> >> of terminology is to be active in the MANET-WG. I was wondering why >>> >> some other WG have a terminology defined shared in documents while >>> >> MANET doesn't. I think if we have it will make us more focus group, or >>> >> using terms from one resource/document. >>> >> >>> >> My suggestion for a RFC that combines all terms of MANET-WG into one >>> >> RFC is reasonable now, because we have RFC5444 and RFC6130 that are >>> >> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D of >>> >> terminology but there is no RFC of agreed terminology or refered to by >>> >> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one term >>> >> [LINK] differently, I don't like to expand this old problem into >>> >> future when we have more documents as RFCs. >>> >> >>> >> Regards >>> >> Abdussalam >>> >> +++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --B_3423816057_81340 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
+1

= More (relevant) drafts and less e-mail would work for me!

Don



From: Ulrich Herberg <ulrich@herberg.name>
Date: <= /span> Friday, June 29, 2012 9:58 AM
To: <= /span> Abdussalam Baryun <abd= ussalambaryun@gmail.com>
Cc: manet <manet@ietf.org>
Subject: Re: [manet] MANET Terminology Upda= te

Abdussalam,

On Fr= i, Jun 29, 2012 at 2:39 AM, Abdussalam Baryun <abdussalambaryun@gmail.com= > wrote:
Dear Teco,

<[Ri] =3D Reason>

I like doing efforts/works related within MANET-WG and don't like to
do a mistake to open a new WG that is related to MANET just because I
want to produce a RFC (e.g. RFC5889).

You are mistake= n. MANET WG is in the routing area, AUTOCONF was in the Internet area. That = is a totally different focus, and there were good reasons to have a separate= WG.

 
IMHO, w= e should be consistent in
our documents within our IETF WG, also we should author documents with
some interaction among our previous RFCs and we have our experience
interaction within our WG and among other IETF-WGs' experiences [R1].
IMHO we should not open another related WG just to avoid some problems
(e.g. autoconfig WG).


I believe that the RFCs = we have published recently in MANET (and the WG drafts that are about to be = sent to the IESG), are consistent in their terminology. I have not seen any = problem of producing solutions because of misleading terminology, and I ther= efore believe it would be unnecessary to spend time on this.
 

 MANET-WG community needs to decide about the Terminology because it still didn't decide as far I know, and still has arguments among terms
between members (if you ask I can give examples pointed in the list)
[R2]. So my post subject is to find out community decision. Please
note that I have good intentions and good reasons why I wanted an
active  I-D of terminology, and I will do my best to convince the
MANET-WG at least to decide. However, I don't still see your reason
why you don't want it. For me It is not only the reason for definition
of [Link] that was an example for you to understand my argument.
My
main motivation was that I wanted to use RFC5444 and RFC6130 in my
I-D, but have problem of their terminology are not consistent with
mine,


Well, how about you change your terminology = then to make it consistent with existing MANET RFCs and WG documents?
 
and if I use my own terminology and in the same time depend on
these RFCs, it may confuse the reader in understanding terms/semantics
[R3]. Please provide me with your reason, because only Chris and
Charlie have gave feedback-reasons.

Overall, some IETF-WGs when they open/start, they define terminology,
purpose-with-requirements, and use-case, to be able to network efforts
and synchronize. Even nodes in MANET may communicate when they have
consistent messages format. Most of our MANET-documents have
dependency plans but lack interaction-terms among them, because of
different terminology used [R4].


I believe we = have a lot of interaction between the different protocols; they all use the = same packet format, several of them use RFC6130. I don't know what you mean = by lack of interaction. And most certainly, I don't see a problem of termino= logy.

 

In conclusion, due to [R1, R2, R3, R4] I RECOMMEND the
Internet-community takes the subject issue into consideration and make
a sound decision. I propose this in the list and will do same in
meeting 84, and will need to get the decision of this WG clear to
progress in my I-D and others submitted to it. Thanking you,


Abdussalam, we spend a lot of cycles on these discussion of y= ours; I second Teco and suggest that instead of writing many long emails, yo= u work on the drafts and propose them to the WG.

Best
Ulrich

 

Best Regards

Abdussalam Baryun
University of Glamorgan, UK.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
<= div class=3D"im HOEnZb">

On 6/29/12, Teco Boot <teco@inf-net.nl<= /a>> wrote:
> I suggest you start a WG on "what is a link". You could dig archives > and find out it wouldn't bring you somewhere. Anyway: good luck !
>
> Teco
>
> Op 29 jun. 2012, om 01:42 heeft Abdussalam Baryun het volgende geschre= ven:
>
>> Hi Perkins,
>>
>> Thanks for your help, so I may understand that you don't mind if a= I-D
>> of terminology is to be active in the MANET-WG. I was wondering wh= y
>> some other WG have a terminology defined shared in documents while=
>> MANET doesn't. I think if we have it will make us more focus group= , or
>> using terms from one resource/document.
>>
>> My suggestion for a RFC that combines all terms of MANET-WG into o= ne
>> RFC is reasonable now, because we have RFC5444 and RFC6130 that ar= e
>> MANET-Packet and MANET-NHDP. I know we have 14 years from the I-D = of
>> terminology but there is no RFC of agreed terminology or refered t= o by
>> MANET memebr authors. Furthermore, RFC3626 and RFC3561 define one = term
>> [LINK] differently, I don't like to expand this old problem into >> future when we have more documents as RFCs.
>>
>> Regards
>> Abdussalam
>> +++++++++++++++++++++++++++++++++++++++

_______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/= mailman/listinfo/manet
--B_3423816057_81340-- From abdussalambaryun@gmail.com Fri Jun 29 15:21:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6689521F84DF for ; Fri, 29 Jun 2012 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 k55Bhry2yjGD for ; Fri, 29 Jun 2012 15:21:12 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E747B21F86B8 for ; Fri, 29 Jun 2012 15:21:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2875633vbb.31 for ; Fri, 29 Jun 2012 15:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=myzLP0rVBz+VMy0UDIUM2vTt1gzSR3j2V+/kOFLbt30=; b=RqQrO5KNSe6Ndo7BjbVddnWaG/6zWb11la+B9jHmztwGcEZ5BgBdCNV+zTlH1kVZXk 24jkmCfok4iPCDg2bqA6NW4icsEeo1Cs8vzFNPlv3uyy0AHER1VYXekfCl3N1/+svaq1 qqupNe6PQ2Ef0ntMJvT7gw4zS19FWYHPnLn9b/I0UMGq+UJgCk6dMa5N/kUq95UkD20Z hBmQkc6Ei3A+XKPV0AUuOy0U1sGcJG+xE+cXF5x6Vmbfwsmf0/JNLkrYpC1WFYyhg11C JZNrPi4Xqd2rQUovRhvLnsKGbCN20BYOO9MqKXxv4lfuaAbh1uJ6346XqHjjZvk8uF/I +iig== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr1636294vdi.86.1341008468179; Fri, 29 Jun 2012 15:21:08 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Fri, 29 Jun 2012 15:21:08 -0700 (PDT) In-Reply-To: References: <4FEC9139.6060407@computer.org> Date: Sat, 30 Jun 2012 00:21:08 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] MANET Terminology Update X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 22:21:13 -0000 I think we need more discussions about the related work(s), and not discussing about the way one member is doing his Work. Let us focus on our group-works only and be positive. AB ++ From adrian@olddog.co.uk Sat Jun 30 11:59:13 2012 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE73C21F85B1 for ; Sat, 30 Jun 2012 11:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599] 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 cALw8E+ibgNi for ; Sat, 30 Jun 2012 11:59:13 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFEF21F85AF for ; Sat, 30 Jun 2012 11:59:12 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5UIxAK7023570; Sat, 30 Jun 2012 19:59:11 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5UIx9b4023562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Jun 2012 19:59:10 +0100 From: "Adrian Farrel" To: "'manet'" Date: Sat, 30 Jun 2012 19:59:09 +0100 Message-ID: <0d3d01cd56f2$6ebb1080$4c313180$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1W8mrrqw7G+F57Q6GVASHyoXBG6w== Content-Language: en-gb Cc: 'Abdussalam Baryun' Subject: [manet] Being productive X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 18:59:13 -0000 Abdussalam's enthusiasm to contribute is to be applauded, but as a newcomer he is having a little trouble settling into the "IETF way." It is, of course, reasonable to ask "is anyone interested in this" before starting work. It is also entirely up to Abdussalam how he judges the responses. I don't think it is a valuable use of time for anyone to debate the meaning of the responses or their number. Abdussalam: - You are not a member of the MANET WG. There is no IETF membership. You are welcome as a participant. - IETF work progress substantially by posting I-Ds and then discussing their content. If no-one else is interested in an I-D it is unlikely to progress through a working group no matter how enthusiastic the author is. - You may post any number of I-Ds with names such as: draft-baryun-manet-foo-00.txt and you may draw them to the attention of the mailing list. If people on the list find the topic of interest, they will discuss the I-Ds with you in private or on the list. If there are issues of substance to be resolved, you may be granted a slot to lead a discussion at a MANET WG meeting. But let's be clear about one thing: if you believe that the WG needs to do something, then you should pick up your pen and lead the work. There is no staff in the WG and no participant with spare cycles. We look forward to reading your I-Ds. Adrian (with his AD hat firmly in place and pulled down tightly over his ears) > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: 29 June 2012 23:21 > To: manet > Subject: Re: [manet] MANET Terminology Update > > I think we need more discussions about the related work(s), and not > discussing about the way one member is doing his Work. Let us focus on > our group-works only and be positive. > > AB > ++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet