From abdussalambaryun@gmail.com Tue May 1 04:41: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 B2CDA21F84F3 for ; Tue, 1 May 2012 04:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.019 X-Spam-Level: X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_92=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 PuVNPoOwShnF for ; Tue, 1 May 2012 04:41:22 -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 EAE8B21F84F0 for ; Tue, 1 May 2012 04:41:21 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3148054vbb.31 for ; Tue, 01 May 2012 04:41:21 -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=k722RcOkGEStMhGk1K09vLNVYo9IX5IL9JnwxhRCRqw=; b=WISZkTN72LeppiXRpaqNc7kd+l7g+Uu/yQVMFao/cnp8vq9eoY18t2ttGM7VeT3y13 88vkBCbnjMbBaNfjnBqILqRO2EnlweHMIUi5BBW6mZr1wVYEZ2UJQx24AnhGm7a37r14 5AJHBRMGLsYjl/IAnRs/+GrR1zgoYd4lIMZ1vFaVTD2RHlhtPRoD7TTZKqWyS3fcV3ZU 7DikPn1NLxz0PoPUORr5ygJeMDE0n3TJcLXcLvR0tijQOLLzpOsY9jKo+aggnr111RLS 43mvT86KtDDohvmofZkwKFAHzv1yDMLDkuZUX6q7BFb87vzSCk9t+lUbXlYwuJaKmfR6 7yYA== MIME-Version: 1.0 Received: by 10.220.155.197 with SMTP id t5mr20284474vcw.6.1335872481360; Tue, 01 May 2012 04:41:21 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Tue, 1 May 2012 04:41:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 May 2012 12:41:21 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg , ietf@thomasclausen.org Content-Type: multipart/alternative; boundary=f46d043890f5b77af504bef80c6e Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 11:41:23 -0000 --f46d043890f5b77af504bef80c6e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). >IMO, unless other people in the WG see the same danger of confusion, I would not change it. I have no problem with your reaction, so than wait until you get other voices then (not sure how many you want), as long as the draft doesn't care about each single review-comment it only follows majority agreement on comments. This type of review-system makes the document not include all readers level of knowledge, that means the document is for specific group which exclueds other readers or groups. However, I just will mention my comments and do my work, I really don't care of the outcome decision, but I will care if I authored a reviewed document. clausen>An OLSRv2 interface can be physical or virtual. Chris explained it well, I suggest re-reading his email. chris explained>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MANET interface is a data li= nk interface=94 is wrong. Ok, I read again. It does not mention that it may be physical. I understand from him it never can be physical, so I needed that to be clear, but now you mentioned that it can be physical. Abdussalam Baryun +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++ On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg wrote= : > Abdussalam, > > so far, nobody else seemed to be confused on which layer OLSRv2 is used > (or how the interfaces are defined). IMO, unless other people in the WG s= ee > the same danger of confusion, I would not change it. > > Regards > Ulrich > > > On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Herberg, >> >> I am suggesting to clarify interfaces, I donot like to change if >> unnecessary. Mentioning that an interface is in the layer 3, or its >> logical, or even just explaining the way Chris defined to me, really mak= es >> difference. My question is why is the draft not mentioning that >> OLSRv2-interface is an IP-interface or a logical-interface? Does the >> authors see that this information is not important? or even >> MANET-interfaces are in layer 3. If we define protocols without mention= ing >> which layer it is located in, then how can we define such protocol, its >> layer-location is more important than its functionality, because each la= yer >> has its special interfaces, functions, services, and messages. There are >> many documents that explain interface in the same model that OLSRv2 is >> presenting so why didn't have confusion when I read them? >> >> >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >> is an IP interface, one which IP >receives packets on, has one or more I= P >> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t >= care >> about that. Your statement =93a MANET interface is a data link interface= =94 is >> wrong. >> >> >I don't think there is any confusion. Chris has pointed out the >> relationship between MANET interface and OLSRv2 >interface clearly. I th= ink >> that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. I= f >> you would like to >change anything, please suggest concrete text to >> replace, so that I can better understand what you mean. >> >> I disagree that there is no confusion. There are confusions in defining >> terms in MANET WG, I have seen in the past a long discussion between man= y, >> just arguing about defining host or router, and now l was confused of >> interfaces in OLSRv2-draft. Maybe because I am not much familiar with OL= SR, >> or reading about network-interface in many papers, and I read RFC2501 (i= t >> refers alot to wireless interface and communications) and mentioned in >> RFC6130 for the interface as attach to communication medium, I thought i= t >> was a medium as physical medium. >> >> I suggest to clarify by adding information in one of the following >> explanation to the draft (even a line will do): >> >> - Mentioning which layer(s) the OLSRv2-interface works or allowed to be >> at by the protocol, or >> - defining the MANET-interface as Chris defined (IP-interface, at layer >> 3) in terminology, or >> - mentioning that OLSRv2-interface is not a wireless interface, or >> - defining MANET-interface as logical interface. >> >> I am sorry to disturb, I actually still have many comments for >> OLSRv2-draft and will try to submit, and let the WG to decide. However, = I >> thank you and Chris to explain to me so at least my other comments will = be >> in understanding. >> >> Abdussalam >> ++++++++++++++++++ >> >> On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wro= te: >> >>> Abdussalam, >>> >>> RFC6130 defines: >>> >>> >>> MANET interface: >>> An interface participating in a MANET and using this neighborhood >>> discovery protocol. A router may have several MANET interfaces. >>> >>> And draft-ietf-manet-olsrv2 defines: >>> >>> OLSRv2 interface: >>> A MANET interface running this protocol. A router running this >>> protocol MUST have at least one OLSRv2 interface. >>> >>> In one of the last OLSRv2 revisions, we made sure that OLSRv2 >>> differentiates between neighbors running only NHDP and neighbors runnin= g >>> also OLSRv2, and only the latter are used for MPR selection, etc. I do = not >>> understand what you would like to change in the OLSRv2 draft. >>> >>> See comments below: >>> >>> On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> Hi Henning, >>>> >>>> Please note that I read the first pages of draft many times before >>>> posting any information. >>>> >>>> HR>I would suggest reading the OLSRv2-draft again, especially section >>>> 2. >>>> >>>> >>>> >OLSRv2 interface: >>>> >A MANET interface running this protocol. A router running this >>>> >protocol MUST have at least one OLSRv2 interface. >>>> >>>> HR>A routing protocol which does not run on any interface would be >>>> pretty >>>> >useless, right? >>>> You reply to the second sentence not the first which has 'running this >>>> protocol' relating it not to the router it is relating it to the inter= face. >>>> I know that router must have at least a network-interface ( or >>>> data-link-layer) or MANET interface, this is not what I commenting and= the >>>> draft is mentioning. We don't assume at least Data-Link because it is >>>> obvious and we are following TCP/IP model in the internet, but not at = least >>>> a specific-interface called bla bla. >>>> >>>> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS >>>> this protocol (OLSRv2) this means there is some thing related to OLSRv= 2 in >>>> the layer-2. You should read again another paragraph mentioning as if = there >>>> is difference between MANET-interface and OLSRv2-interface. >>>> >>>> OLSRv2-14>p9> >>>> >>>> Supports routers that each have one or more participating OLSRv2 >>>> >>>> interfaces, which will consist of some or all of its MANET >>>> >>>> interfaces using [RFC6130]. The set of a router=92s OLSRv2 >>>> >>>> interfaces, and the sets of its other MANET and non-MANET >>>> >>>> interfaces, may change over time. Each interface may have one or >>>> >>>> more network addresses (which may have prefix lengths), and these >>>> >>>> may also be dynamically changing. >>>> >>>> AB> it is clear from the above draft-page-9, that all MANET >>>> interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are >>>> MANET-interfaces. So we have to have in or node at least an >>>> OLSRv2-interface, not at least one MANET-interfac so the protocol to w= ork >>>> correctly. >>>> >>>> AB> The above page-9 mentions NHDP as well that interfaces need this >>>> protocol. What if there is not NHDP, or if it is not working, what wil= l >>>> happen. The draft SHOULD explain these issues. >>>> >>> >>> >>> >>>> AB> It may be that all OLSRv2 routers (as implementation point of >>>> practice) only need at least one MANET interface. But the authors need= to >>>> change. therefore, we know that All routers need at least on interface= , but >>>> the draft-wording has a special OLSRv2-interface. Then we need to chan= ge >>>> the draft wording to the right explaination. >>>> >>> >>> >>> Can you suggest what you would like to change? I don't understand your >>> point. >>> >>> Best regards >>> Ulrich >>> +++++++++++++++++++++++++++++++++++++++++++ >>> >> >> >> Hi Chris >> >> ok then if it was simple to explain as a special interface as >> IP-interface why we have OLSRv2_draft saying that it is network-interfac= e >> as MANET is a network, but IP is not it is a protocol. IMO it is wrong t= o >> refer to a network while you mean a protocol, even though I know I may >> misunderstood. I sugget that this SHOULD be explained clearly. I think >> every one seems to understand that network-interface must >> include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should defin= e >> well as you did. I thank you for your comment, >> >> Therefore I suggest to change OLSRv2-interface definition as Chris >> defined it very clearly. I hope the draft can change the definition, >> >> Abdussalam >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + >> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) > at baesystems.com> wrote: >> >> >> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >> is an IP interface, one which IP receives packets on, has one or more IP >> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t c= are >> about that. Your statement =93a MANET interface is a data link interface= =94 is >> wrong. >> >> >> >> -- >> >> 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 at baesystems.com | http://www.baesystems.com >> >> >> > --f46d043890f5b77af504bef80c6e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Herberg>so far, nobody else seemed to be confused on which layer OL= SRv2 is used (or how the interfaces are defined). >IMO, unless other peo= ple in the WG see the same danger of confusion, I would not change it.
I have no problem with your reaction, so than wait until you get other= voices then (not sure how many you want), as long as the draft doesn't= care about each single review-comment it only follows majority agreement o= n comments. This type of review-system makes the document=A0not include all= readers level of knowledge, that means the document is for specific group = which exclueds other readers or groups. However, I just will mention my com= ments and do my work, I really don't care of the outcome decision, but = I will care if I authored a reviewed document.

clausen>An OLSRv2 interface can be physical or virtual. Chris expla= ined it well, I suggest re-reading his email.
=A0
chris explained>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is= an IP interface, one which IP receives packets on, has one or more IP addr= esses etc. It has a data link layer below it, but OLSRv2 doesn=92t care abo= ut that. Your statement =93a MANET interface is a data link interface=94 is= wrong.

Ok, I read again.=A0It does not mention that it may be physical. I unde= rstand from him it never can be physical, so I needed that to be clear, but= now you mentioned that it can be physical.
=A0
Abdussalam Baryun
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++
=A0
On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg= <ulrich@herberg.name> wrote:
Abdussalam,

so far, nobody els= e seemed to be confused on which layer OLSRv2 is used (or how the interface= s are defined). IMO, unless other people in the WG see the same danger of c= onfusion, I would not change it.

Regards
Ulrich= =20


On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Herberg,
=A0
I am suggesting to clarify interfaces, I d= onot like=A0to change=A0if unnecessary. Mentioning that an interface is in = the layer 3, or its logical, or even just explaining the way Chris defined = to me, really makes difference. My question is why is the draft not mention= ing that OLSRv2-interface is an IP-interface or a logical-interface? Does t= he authors see that this information is not important? or even MANET-interf= aces are in layer 3.=A0 If we define protocols without mentioning which lay= er it is located in, then how can we define such protocol, its layer-locati= on is more important than its functionality, because each layer has its spe= cial interfaces, functions, services, and messages. There are many document= s that explain interface in the same model that OLSRv2 is presenting so why= didn't have confusion when I read them?

>An OLSRv2 interface (a special case of a MANET= interface, see RFC 6130) is an IP interface, one which IP >receives pac= kets on, has one or more IP addresses etc. It has a data link layer below i= t, but OLSRv2 doesn=92t >care about that. Your statement =93a MANET inte= rface is a data link interface=94 is wrong.

>I don't think there is any confusion. Chris has pointed out the= relationship between MANET interface and OLSRv2 >interface clearly. I t= hink that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly.= If you would like to >change anything, please suggest concrete text to = replace, so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining= terms in MANET WG, I have seen in the past a long discussion between many,= just arguing about defining host or router, and now l was confused of inte= rfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or = reading about network-interface in many papers, and I read RFC2501 (it refe= rs alot to wireless interface and communications) and mentioned in RFC6130 = for the interface as attach to communication medium, I thought it was a med= ium as physical medium.

I suggest to clarify by adding information in one of the following expl= anation to the draft (even a line will do):
=A0
- Mentioning which layer(s)=A0the OLSRv2-interface works or allowed to= be at by the protocol, or
- defining the MANET-interface as=A0Chris defined (IP-interface, at la= yer 3) in terminology, or
- mentioning that OLSRv2-interface is not a wireless interface, or
- defining MANET-interface as logical interface.

I am sorry to disturb, I actually still have many comments for OLS= Rv2-draft and will try to submit, and let the WG to decide. However, I than= k you and Chris to explain to me so at least my other comments will be in u= nderstanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 defines:= =20


MANET interface:
An interface participating in a MANET and = using this neighborhood
=A0=A0=A0=A0=A0 discovery protocol.=A0 A router = may have several MANET interfaces.

And draft-ietf-manet-olsrv2= defines:=20

OLSRv2 interface:
=A0=A0=A0=A0=A0 A MANET interface running thi= s protocol.=A0 A router running this
=A0=A0=A0=A0=A0 protocol MUST have = at least one OLSRv2 interface.

In one of the last OLSRv2 revis= ions, we made sure that OLSRv2 differentiates between neighbors running onl= y NHDP and neighbors running also OLSRv2, and only the latter are used for = MPR selection, etc. I do not understand what you would like to change in th= e OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.=20


>OLSRv2 interface:
>A MANET interface running this pr= otocol. =A0A router running this
>protocol MUST have at least one OLS= Rv2 interface.

HR>A routing protocol which does not run on = any interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.


=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.


Can you suggest what you would like to change? I don't und= erstand your point.

Best regards
Ul= rich
=A0+++++++++++++++++++++++++++++++++++++++++++


Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as IP-int= erface why we have OLSRv2_draft saying that it is network-interface as MANE= T is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer = to a network while you mean a protocol, even though I know I may misunderst= ood. I sugget that this SHOULD be explained clearly. I think every one seem= s to understand that network-interface must include=A0Data-Link-layer, ther= efore, RFC6130 or OLSRv2-draft should define well as you did. I thank you f= or your comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris def= ined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, C= hristopher (UK) <Chris.Dearlove at bae= systems.com> wrote:


An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194<= /a>=A0|=A0 Fax: +44 1245 242124

chris.dearlove at baesystems.com | http://www.baesys= tems.com


<= br>

--f46d043890f5b77af504bef80c6e-- From Chris.Dearlove@baesystems.com Tue May 1 05:19: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 EB7E621F8898 for ; Tue, 1 May 2012 05:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=-0.886, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=0.6, 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 lGi8LJeRDmJn for ; Tue, 1 May 2012 05:19:24 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFAB21F896F for ; Tue, 1 May 2012 05:19:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,510,1330905600"; d="scan'208,217";a="235400406" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 01 May 2012 13:19:22 +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 q41CJMPY006814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 May 2012 13:19:22 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Tue, 1 May 2012 13:19:22 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Ulrich Herberg , "ietf@thomasclausen.org" Thread-Topic: [manet] Comments for OLSRv2-14 Thread-Index: AQHNJxWqRtsKbTFEyEWXGg3Be+0nRpaz0Y8AgADuKoCAABseMA== Date: Tue, 1 May 2012 12:19: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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014419GLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 12:19:32 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D014419GLKXM0002VGREENLN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I explicitly said it could be physical (but it doesn't matter) in a different email than the one you quoted. -- 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: 01 May 2012 12:41 To: Ulrich Herberg; ietf@thomasclausen.org Cc: manet; Dearlove, Christopher (UK) Subject: Re: [manet] Comments for OLSRv2-14 *** 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. Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). >IMO, unless other people in the WG see the same danger of confusion, I would not change it. I have no problem with your reaction, so than wait until you get other voices then (not sure how many you want), as long as the draft doesn't care about each single review-comment it only follows majority agreement on comments. This type of review-system makes the document not include all readers level of knowledge, that means the document is for specific group which exclueds other readers or groups. However, I just will mention my comments and do my work, I really don't care of the outcome decision, but I will care if I authored a reviewed document. clausen>An OLSRv2 interface can be physical or virtual. Chris explained it well, I suggest re-reading his email. chris explained>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn't care about that. Your statement "a MANET interface is a data link interface" is wrong. Ok, I read again. It does not mention that it may be physical. I understand from him it never can be physical, so I needed that to be clear, but now you mentioned that it can be physical. Abdussalam Baryun +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg > wrote: Abdussalam, so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). IMO, unless other people in the WG see the same danger of confusion, I would not change it. Regards Ulrich On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun > wrote: Hi Herberg, I am suggesting to clarify interfaces, I donot like to change if unnecessary. Mentioning that an interface is in the layer 3, or its logical, or even just explaining the way Chris defined to me, really makes difference. My question is why is the draft not mentioning that OLSRv2-interface is an IP-interface or a logical-interface? Does the authors see that this information is not important? or even MANET-interfaces are in layer 3. If we define protocols without mentioning which layer it is located in, then how can we define such protocol, its layer-location is more important than its functionality, because each layer has its special interfaces, functions, services, and messages. There are many documents that explain interface in the same model that OLSRv2 is presenting so why didn't have confusion when I read them? >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn't >care about that. Your statement "a MANET interface is a data link interface" is wrong. >I don't think there is any confusion. Chris has pointed out the relationship between MANET interface and OLSRv2 >interface clearly. I think that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would like to >change anything, please suggest concrete text to replace, so that I can better understand what you mean. I disagree that there is no confusion. There are confusions in defining terms in MANET WG, I have seen in the past a long discussion between many, just arguing about defining host or router, and now l was confused of interfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or reading about network-interface in many papers, and I read RFC2501 (it refers alot to wireless interface and communications) and mentioned in RFC6130 for the interface as attach to communication medium, I thought it was a medium as physical medium. I suggest to clarify by adding information in one of the following explanation to the draft (even a line will do): - Mentioning which layer(s) the OLSRv2-interface works or allowed to be at by the protocol, or - defining the MANET-interface as Chris defined (IP-interface, at layer 3) in terminology, or - mentioning that OLSRv2-interface is not a wireless interface, or - defining MANET-interface as logical interface. I am sorry to disturb, I actually still have many comments for OLSRv2-draft and will try to submit, and let the WG to decide. However, I thank you and Chris to explain to me so at least my other comments will be in understanding. Abdussalam ++++++++++++++++++ On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg > wrote: Abdussalam, RFC6130 defines: MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. And draft-ietf-manet-olsrv2 defines: OLSRv2 interface: A MANET interface running this protocol. A router running this protocol MUST have at least one OLSRv2 interface. In one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiates between neighbors running only NHDP and neighbors running also OLSRv2, and only the latter are used for MPR selection, etc. I do not understand what you would like to change in the OLSRv2 draft. See comments below: On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun > wrote: Hi Henning, Please note that I read the first pages of draft many times before posting any information. HR>I would suggest reading the OLSRv2-draft again, especially section 2. >OLSRv2 interface: >A MANET interface running this protocol. A router running this >protocol MUST have at least one OLSRv2 interface. HR>A routing protocol which does not run on any interface would be pretty >useless, right? You reply to the second sentence not the first which has 'running this protocol' relating it not to the router it is relating it to the interface. I know that router must have at least a network-interface ( or data-link-layer) or MANET interface, this is not what I commenting and the draft is mentioning. We don't assume at least Data-Link because it is obvious and we are following TCP/IP model in the internet, but not at least a specific-interface called bla bla. Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this protocol (OLSRv2) this means there is some thing related to OLSRv2 in the layer-2. You should read again another paragraph mentioning as if there is difference between MANET-interface and OLSRv2-interface. OLSRv2-14>p9> Supports routers that each have one or more participating OLSRv2 interfaces, which will consist of some or all of its MANET interfaces using [RFC6130]. The set of a router's OLSRv2 interfaces, and the sets of its other MANET and non-MANET interfaces, may change over time. Each interface may have one or more network addresses (which may have prefix lengths), and these may also be dynamically changing. AB> it is clear from the above draft-page-9, that all MANET interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. So we have to have in or node at least an OLSRv2-interface, not at least one MANET-interfac so the protocol to work correctly. AB> The above page-9 mentions NHDP as well that interfaces need this protocol. What if there is not NHDP, or if it is not working, what will happen. The draft SHOULD explain these issues. AB> It may be that all OLSRv2 routers (as implementation point of practice) only need at least one MANET interface. But the authors need to change. therefore, we know that All routers need at least on interface, but the draft-wording has a special OLSRv2-interface. Then we need to change the draft wording to the right explaination. Can you suggest what you would like to change? I don't understand your point. Best regards Ulrich +++++++++++++++++++++++++++++++++++++++++++ Hi Chris ok then if it was simple to explain as a special interface as IP-interface why we have OLSRv2_draft saying that it is network-interface as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that this SHOULD be explained clearly. I think every one seems to understand that network-interface must include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you did. I thank you for your comment, Therefore I suggest to change OLSRv2-interface definition as Chris defined it very clearly. I hope the draft can change the definition, Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) > wrote: An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn't care about that. Your statement "a MANET interface is a data link interface" is wrong. -- 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 at baesystems.com | http://www.baesystems.com ******************************************************************** 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_B31EEDDDB8ED7E4A93FDF12A4EECD30D014419GLKXM0002VGREENLN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

I explicitly said it could be physical (but it doesn’t matter) in a different email than the one you quoted.

 

--

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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 01 May 2012 12:41
To: Ulrich Herberg; ietf@thomasclausen.org
Cc: manet; Dearlove, Christopher (UK)
Subject: Re: [manet] Comments for OLSRv2-14

 

 

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

Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). >IMO, unless other people in the WG see the same danger of confusion, I would not change it.

I have no problem with your reaction, so than wait until you get other voices then (not sure how many you want), as long as the draft doesn't care about each single review-comment it only follows majority agreement on comments. This type of review-system makes the document not include all readers level of knowledge, that means the document is for specific group which exclueds other readers or groups. However, I just will mention my comments and do my work, I really don't care of the outcome decision, but I will care if I authored a reviewed document.

clausen>An OLSRv2 interface can be physical or virtual. Chris explained it well, I suggest re-reading his email.

 

chris explained>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn’t care about that. Your statement “a MANET interface is a data link interface” is wrong.

Ok, I read again. It does not mention that it may be physical. I understand from him it never can be physical, so I needed that to be clear, but now you mentioned that it can be physical.

 

Abdussalam Baryun

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

 

On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

Abdussalam,

so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). IMO, unless other people in the WG see the same danger of confusion, I would not change it.

Regards
Ulrich

 

On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Herberg,

 

I am suggesting to clarify interfaces, I donot like to change if unnecessary. Mentioning that an interface is in the layer 3, or its logical, or even just explaining the way Chris defined to me, really makes difference. My question is why is the draft not mentioning that OLSRv2-interface is an IP-interface or a logical-interface? Does the authors see that this information is not important? or even MANET-interfaces are in layer 3.  If we define protocols without mentioning which layer it is located in, then how can we define such protocol, its layer-location is more important than its functionality, because each layer has its special interfaces, functions, services, and messages. There are many documents that explain interface in the same model that OLSRv2 is presenting so why didn't have confusion when I read them?

>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP >receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn’t >care about that. Your statement “a MANET interface is a data link interface” is wrong.

>I don't think there is any confusion. Chris has pointed out the relationship between MANET interface and OLSRv2 >interface clearly. I think that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would like to >change anything, please suggest concrete text to replace, so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining terms in MANET WG, I have seen in the past a long discussion between many, just arguing about defining host or router, and now l was confused of interfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or reading about network-interface in many papers, and I read RFC2501 (it refers alot to wireless interface and communications) and mentioned in RFC6130 for the interface as attach to communication medium, I thought it was a medium as physical medium.

I suggest to clarify by adding information in one of the following explanation to the draft (even a line will do):

 

- Mentioning which layer(s) the OLSRv2-interface works or allowed to be at by the protocol, or

- defining the MANET-interface as Chris defined (IP-interface, at layer 3) in terminology, or

- mentioning that OLSRv2-interface is not a wireless interface, or

- defining MANET-interface as logical interface.


I am sorry to disturb, I actually still have many comments for OLSRv2-draft and will try to submit, and let the WG to decide. However, I thank you and Chris to explain to me so at least my other comments will be in understanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg <ulrich@herberg.name> wrote:

Abdussalam,

RFC6130 defines:



MANET interface:
An interface participating in a MANET and using this neighborhood
      discovery protocol.  A router may have several MANET interfaces.

And draft-ietf-manet-olsrv2 defines:


OLSRv2 interface:
      A MANET interface running this protocol.  A router running this
      protocol MUST have at least one OLSRv2 interface.

In one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiates between neighbors running only NHDP and neighbors running also OLSRv2, and only the latter are used for MPR selection, etc. I do not understand what you would like to change in the OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Hi Henning,

 

Please note that I read the first pages of draft many times before posting any information.

 

HR>I would suggest reading the OLSRv2-draft again, especially section 2.



>OLSRv2 interface:
>A MANET interface running this protocol.  A router running this
>protocol MUST have at least one OLSRv2 interface.

HR>A routing protocol which does not run on any interface would be pretty
>useless, right?

You reply to the second sentence not the first which has 'running this protocol' relating it not to the router it is relating it to the interface. I know that router must have at least a network-interface ( or data-link-layer) or MANET interface, this is not what I commenting and the draft is mentioning. We don't assume at least Data-Link because it is obvious and we are following TCP/IP model in the internet, but not at least a specific-interface called bla bla.

 

Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this protocol (OLSRv2) this means there is some thing related to OLSRv2 in the layer-2. You should read again another paragraph mentioning as if there is difference between MANET-interface and OLSRv2-interface.

 

OLSRv2-14>p9>

Supports routers that each have one or more participating OLSRv2

interfaces, which will consist of some or all of its MANET

interfaces using [RFC6130]. The set of a router’s OLSRv2

interfaces, and the sets of its other MANET and non-MANET

interfaces, may change over time. Each interface may have one or

more network addresses (which may have prefix lengths), and these

may also be dynamically changing.

 

AB> it is clear from the above draft-page-9, that all MANET interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. So we have to have in or node at least an OLSRv2-interface, not at least one MANET-interfac so the protocol to work correctly.

 

AB> The above page-9 mentions NHDP as well that interfaces need this protocol. What if there is not NHDP, or if it is not working, what will happen. The draft SHOULD explain these issues.

 

 

AB> It may be that all OLSRv2 routers (as implementation point of practice) only need at least one MANET interface. But the authors need to change. therefore, we know that All routers need at least on interface, but the draft-wording has a special OLSRv2-interface. Then we need to change the draft wording to the right explaination.



Can you suggest what you would like to change? I don't understand your point.

Best regards
Ulrich
 +++++++++++++++++++++++++++++++++++++++++++



Hi Chris

 

ok then if it was simple to explain as a special interface as IP-interface why we have OLSRv2_draft saying that it is network-interface as MANET is a network, but IP is not it is a protocol. IMO it is wrong to refer to a network while you mean a protocol, even though I know I may misunderstood. I sugget that this SHOULD be explained clearly. I think every one seems to understand that network-interface must include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you did. I thank you for your comment,

 

Therefore I suggest to change OLSRv2-interface definition as Chris defined it very clearly. I hope the draft can change the definition,

 

Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) <Chris.Dearlove at baesystems.com> wrote:

 

An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is an IP interface, one which IP receives packets on, has one or more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn’t care about that. Your statement “a MANET interface is a data link interface” is wrong.

 

--

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 at baesystems.com | http://www.baesystems.com

 

 

 


********************************************************************
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_B31EEDDDB8ED7E4A93FDF12A4EECD30D014419GLKXM0002VGREENLN_-- From ietf@thomasclausen.org Tue May 1 05:23: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 54EFC21F89E4 for ; Tue, 1 May 2012 05:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.167 X-Spam-Level: X-Spam-Status: No, score=-0.167 tagged_above=-999 required=5 tests=[AWL=-1.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=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 xsDmQ9eqvH65 for ; Tue, 1 May 2012 05:22:59 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D556221F89EA for ; Tue, 1 May 2012 05:22:59 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 8BFB3558212 for ; Tue, 1 May 2012 05:22:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 0031D1CE1ADD; Tue, 1 May 2012 05:22:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.249] (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 mailc2.tigertech.net (Postfix) with ESMTPSA id 821D21CE1ADB; Tue, 1 May 2012 05:22:57 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-D42F746A-172C-44B1-B6DF-5E9351613302 Message-Id: X-Mailer: iPad Mail (9B176) From: Thomas Heide Clausen Date: Tue, 1 May 2012 14:23:09 +0200 To: Abdussalam Baryun Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 12:23:02 -0000 --Apple-Mail-D42F746A-172C-44B1-B6DF-5E9351613302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 1 May 2012, at 13:41, Abdussalam Baryun wrot= e: > Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 is= used (or how the interfaces are defined). >IMO, unless other people in the W= G see the same danger of confusion, I would not change it. > I have no problem with your reaction, so than wait until you get other voi= ces then (not sure how many you want), as long as the draft doesn't care abo= ut each single review-comment it only follows majority agreement on comments= . This type of review-system makes the document not include all readers leve= l of knowledge, that means the document is for specific group which exclueds= other readers or groups. However, I just will mention my comments and do my= work, I really don't care of the outcome decision, but I will care if I aut= hored a reviewed document. >=20 > clausen>An OLSRv2 interface can be physical or virtual. Chris explained it= well, I suggest re-reading his email. > =20 > chris explained>An OLSRv2 interface (a special case of a MANET interface, s= ee RFC 6130) is an IP interface, one which IP receives packets on, has one o= r more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn= =E2=80=99t care about that. Your statement =E2=80=9Ca MANET interface is a d= ata link interface=E2=80=9D is wrong. >=20 > Ok, I read again. It does not mention that it may be physical. I understan= d from him it never can be physical, so I needed that to be clear, but now y= ou mentioned that it can be physical. > =20 Again, you misunderstand. I state that it's immaterial which it is, as long a= s it satisfies the characteristics that Chris describe. Thomas > Abdussalam Baryun > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++ > =20 > On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg wro= te: > Abdussalam, >=20 > so far, nobody else seemed to be confused on which layer OLSRv2 is used (o= r how the interfaces are defined). IMO, unless other people in the WG see th= e same danger of confusion, I would not change it. >=20 > Regards > Ulrich >=20 >=20 > On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun wrote: > Hi Herberg, > =20 > I am suggesting to clarify interfaces, I donot like to change if unnecessa= ry. Mentioning that an interface is in the layer 3, or its logical, or even j= ust explaining the way Chris defined to me, really makes difference. My ques= tion is why is the draft not mentioning that OLSRv2-interface is an IP-inter= face or a logical-interface? Does the authors see that this information is n= ot important? or even MANET-interfaces are in layer 3. If we define protoco= ls without mentioning which layer it is located in, then how can we define s= uch protocol, its layer-location is more important than its functionality, b= ecause each layer has its special interfaces, functions, services, and messa= ges. There are many documents that explain interface in the same model that O= LSRv2 is presenting so why didn't have confusion when I read them?=20 >=20 > >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s an IP interface, one which IP >receives packets on, has one or more IP add= resses etc. It has a data link layer below it, but OLSRv2 doesn=E2=80=99t >c= are about that. Your statement =E2=80=9Ca MANET interface is a data link int= erface=E2=80=9D is wrong. >=20 > >I don't think there is any confusion. Chris has pointed out the relations= hip between MANET interface and OLSRv2 >interface clearly. I think that RFC6= 130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would l= ike to >change anything, please suggest concrete text to replace, so that I c= an better understand what you mean. >=20 > I disagree that there is no confusion. There are confusions in defining te= rms in MANET WG, I have seen in the past a long discussion between many, jus= t arguing about defining host or router, and now l was confused of interface= s in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or readin= g about network-interface in many papers, and I read RFC2501 (it refers alot= to wireless interface and communications) and mentioned in RFC6130 for the i= nterface as attach to communication medium, I thought it was a medium as phy= sical medium. >=20 > I suggest to clarify by adding information in one of the following explana= tion to the draft (even a line will do): > =20 > - Mentioning which layer(s) the OLSRv2-interface works or allowed to be at= by the protocol, or > - defining the MANET-interface as Chris defined (IP-interface, at layer 3)= in terminology, or > - mentioning that OLSRv2-interface is not a wireless interface, or > - defining MANET-interface as logical interface. >=20 > I am sorry to disturb, I actually still have many comments for OLSRv2-draf= t and will try to submit, and let the WG to decide. However, I thank you and= Chris to explain to me so at least my other comments will be in understandi= ng. >=20 > Abdussalam > ++++++++++++++++++ >=20 > On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wrot= e: > Abdussalam, >=20 > RFC6130 defines: >=20 >=20 > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces. >=20 > And draft-ietf-manet-olsrv2 defines: >=20 > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface. >=20 > In one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiat= es between neighbors running only NHDP and neighbors running also OLSRv2, an= d only the latter are used for MPR selection, etc. I do not understand what y= ou would like to change in the OLSRv2 draft. >=20 > See comments below: >=20 > On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun wrote: > Hi Henning, > =20 > Please note that I read the first pages of draft many times before posting= any information. > =20 > HR>I would suggest reading the OLSRv2-draft again, especially section 2. >=20 >=20 > >OLSRv2 interface: > >A MANET interface running this protocol. A router running this > >protocol MUST have at least one OLSRv2 interface. >=20 > HR>A routing protocol which does not run on any interface would be pretty > >useless, right? > You reply to the second sentence not the first which has 'running this pro= tocol' relating it not to the router it is relating it to the interface. I k= now that router must have at least a network-interface ( or data-link-layer)= or MANET interface, this is not what I commenting and the draft is mentioni= ng. We don't assume at least Data-Link because it is obvious and we are foll= owing TCP/IP model in the internet, but not at least a specific-interface ca= lled bla bla. > =20 > Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this p= rotocol (OLSRv2) this means there is some thing related to OLSRv2 in the lay= er-2. You should read again another paragraph mentioning as if there is diff= erence between MANET-interface and OLSRv2-interface. > =20 > OLSRv2-14>p9> > Supports routers that each have one or more participating OLSRv2 > interfaces, which will consist of some or all of its MANET > interfaces using [RFC6130]. The set of a router=E2=80=99s OLSRv2 > interfaces, and the sets of its other MANET and non-MANET > interfaces, may change over time. Each interface may have one or > more network addresses (which may have prefix lengths), and these > may also be dynamically changing. > =20 > AB> it is clear from the above draft-page-9, that all MANET interfaces are= not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. So= we have to have in or node at least an OLSRv2-interface, not at least one M= ANET-interfac so the protocol to work correctly. > =20 > AB> The above page-9 mentions NHDP as well that interfaces need this proto= col. What if there is not NHDP, or if it is not working, what will happen. T= he draft SHOULD explain these issues. >=20 >=20 > =20 > AB> It may be that all OLSRv2 routers (as implementation point of practice= ) only need at least one MANET interface. But the authors need to change. th= erefore, we know that All routers need at least on interface, but the draft-= wording has a special OLSRv2-interface. Then we need to change the draft wor= ding to the right explaination. >=20 >=20 > Can you suggest what you would like to change? I don't understand your poi= nt. >=20 > Best regards > Ulrich > +++++++++++++++++++++++++++++++++++++++++++ >=20 >=20 > Hi Chris > =20 > ok then if it was simple to explain as a special interface as IP-interface= why we have OLSRv2_draft saying that it is network-interface as MANET is a n= etwork, but IP is not it is a protocol. IMO it is wrong to refer to a networ= k while you mean a protocol, even though I know I may misunderstood. I sugge= t that this SHOULD be explained clearly. I think every one seems to understa= nd that network-interface must include Data-Link-layer, therefore, RFC6130 o= r OLSRv2-draft should define well as you did. I thank you for your comment, > =20 > Therefore I suggest to change OLSRv2-interface definition as Chris defined= it very clearly. I hope the draft can change the definition, > =20 > Abdussalam >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) wrote: >=20 >=20 > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is= an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn=E2=80=99t care= about that. Your statement =E2=80=9Ca MANET interface is a data link interf= ace=E2=80=9D is wrong. >=20 > =20 >=20 > -- >=20 > Christopher Dearlove >=20 > 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 >=20 > chris.dearlove at baesystems.com | http://www.baesystems.com >=20 >=20 >=20 >=20 --Apple-Mail-D42F746A-172C-44B1-B6DF-5E9351613302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1 May 20= 12, at 13:41, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

Herberg>so far, nobody else seemed to be c= onfused on which layer OLSRv2 is used (or how the interfaces are defined). &= gt;IMO, unless other people in the WG see the same danger of confusion, I wo= uld not change it.
I have no problem with your reaction, so than wait until you get other v= oices then (not sure how many you want), as long as the draft doesn't care a= bout each single review-comment it only follows majority agreement on commen= ts. This type of review-system makes the document not include all reade= rs level of knowledge, that means the document is for specific group which e= xclueds other readers or groups. However, I just will mention my comments an= d do my work, I really don't care of the outcome decision, but I will care i= f I authored a reviewed document.

clausen>An OLSRv2 interface can be physical or virtual. Chris explai= ned it well, I suggest re-reading his email.
 
chris explained>= An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is a= n IP interface, one which IP receives packets on, has one or more IP address= es etc. It has a data link layer below it, but OLSRv2 doesn=E2=80=99t care a= bout that. Your statement =E2=80=9Ca MANET interface is a data link interfac= e=E2=80=9D is wrong.

Ok, I read again. It does not mention that it may be physical. I un= derstand from him it never can be physical, so I needed that to be clear, bu= t now you mentioned that it can be physical.
 

Again, you misunders= tand. I state that it's immaterial which it is, as long as it satisfies the c= haracteristics that Chris describe.


= Thomas

Abdussalam Baryun
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++
 
On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg <= span dir=3D"ltr"><ulrich@herberg.name> wrote:
Abdussalam,

so far, nobody else s= eemed to be confused on which layer OLSRv2 is used (or how the interfaces ar= e defined). IMO, unless other people in the WG see the same danger of confus= ion, I would not change it.

Regards
Ulrich<= /span>=20


On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryu= n <abdussalambaryun@gmail.com> wrote:
Hi Herberg,
 
I am suggesting to clarify interfaces, I donot like to c= hange if unnecessary. Mentioning that an interface is in the layer 3, o= r its logical, or even just explaining the way Chris defined to me, really m= akes difference. My question is why is the draft not mentioning that OLSRv2-= interface is an IP-interface or a logical-interface? Does the authors see th= at this information is not important? or even MANET-interfaces are in layer 3= .  If we define protocols without mentioning which layer it is located i= n, then how can we define such protocol, its layer-location is more importan= t than its functionality, because each layer has its special interfaces, fun= ctions, services, and messages. There are many documents that explain interf= ace in the same model that OLSRv2 is presenting so why didn't have confusion= when I read them?

>An OLSRv2 interface (a special case of a MANET interface, see RFC= 6130) is an IP interface, one which IP >receives packets on, has one or m= ore IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=E2= =80=99t >care about that. Your statement =E2=80=9Ca MANET interface is a d= ata link interface=E2=80=9D is wrong.

>I don't think there is any confusion. Chris has pointed out the rela= tionship between MANET interface and OLSRv2 >interface clearly. I think t= hat RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you= would like to >change anything, please suggest concrete text to replace,= so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining t= erms in MANET WG, I have seen in the past a long discussion between many, ju= st arguing about defining host or router, and now l was confused of interfac= es in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or readi= ng about network-interface in many papers, and I read RFC2501 (it refers alo= t to wireless interface and communications) and mentioned in RFC6130 for the= interface as attach to communication medium, I thought it was a medium as p= hysical medium.

I suggest to clarify by adding information in one of the following expla= nation to the draft (even a line will do):
 
- Mentioning which layer(s) the OLSRv2-interface works or allowed t= o be at by the protocol, or
- defining the MANET-interface as Chris defined (IP-interface, at l= ayer 3) in terminology, or
- mentioning that OLSRv2-interface is not a wireless interface, or
- defining MANET-interface as logical interface.

I am sorry to disturb, I actually still have many comments for OLSR= v2-draft and will try to submit, and let the WG to decide. However, I thank y= ou and Chris to explain to me so at least my other comments will be in under= standing.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg <= span dir=3D"ltr"><ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 defines:=20


MANET interface:
An interface participating in a MANET and u= sing this neighborhood
      discovery protocol.=   A router may have several MANET interfaces.

And draft-ie= tf-manet-olsrv2 defines:=20

OLSRv2 interface:
      A MANET interfa= ce running this protocol.  A router running this
   &= nbsp;  protocol MUST have at least one OLSRv2 interface.

I= n one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiates b= etween neighbors running only NHDP and neighbors running also OLSRv2, and on= ly the latter are used for MPR selection, etc. I do not understand what you w= ould like to change in the OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &l= t;abdussalam= baryun@gmail.com> wrote:
Hi Henning,
 
Please note that I read the first pages of draft many times before= posting any information.
 
HR>I would suggest reading the OLSRv2-draft again, especially sectio= n 2.=20


>OLSRv2 interface:
>A MANET interface running this pro= tocol.  A router running this
>protocol MUST have at least one OL= SRv2 interface.

HR>A routing protocol which does not run on a= ny interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running this p= rotocol' relating it not to the router it is relating it to the interface. I= know that router must have at least a network-interface ( or data-link-laye= r) or MANET interface, this is not what I commenting and the draft= is mentioning. We don't assume at least Data-Link because it is obvious and= we are following TCP/IP model in the internet, but not at least a specific-= interface called bla bla.
 
Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS th= is protocol (OLSRv2) this means there is some thing related to OLSRv2 i= n the layer-2. You should read again another paragraph mentioning as if ther= e is difference between MANET-interface and OLSRv2-interface.
 
OLSRv2-14>p9>

Supports routers that each h= ave one or more participating OLSRv2

interfaces, which will cons= ist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=E2=80=99s OLSRv2

interfaces, and the sets of= its other MANET and non-MANET

interfaces, may change over= time. Each interface may have one or

more network addresses (whi= ch may have prefix lengths), and these

may also be dynamically cha= nging.

 
AB> it is clear from the above draft-page-9, that all MANET interfac= es are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-int= erfaces. So we have to have in or node at least an OLSRv2-interface, not at l= east one MANET-interfac so the protocol to work correctly.
 
AB> The above page-9 mentions NHDP as well that interfaces need this= protocol. What if there is not NHDP, or if it is not working, what will hap= pen. The draft SHOULD explain these issues.


 
AB> It may be that all OLSRv2 routers (as implementation point of pr= actice) only need at least one MANET interface. But the authors need to chan= ge. therefore, we know that All routers need at least on interface, but the d= raft-wording has a special OLSRv2-interface. Then we need to change the draf= t wording to the right explaination.


Can you suggest what you would like to change? I don't understa= nd your point.

Best regards
Ulrich +++++++++++++++++++++++++++++++++++++++++++


Hi Chris
 
ok then if it was simple to explain as a special interface as IP-i= nterface why we have OLSRv2_draft saying that it is network-interface as MAN= ET is a network, but IP is not it is a protocol. IMO it is wrong to ref= er to a network while you mean a protocol, even though I know I may misunder= stood. I sugget that this SHOULD be explained clearly. I think every one see= ms to understand that network-interface must include Data-Link-layer, t= herefore, RFC6130 or OLSRv2-draft should define well as you did. I thank you= for your comment,
 
Therefore I suggest to change OLSRv2-interface definition as Chris defi= ned it very clearly. I hope the draft can change the definition,
 
Abdussalam

+++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Chr= istopher (UK) <Chris.Dearlove at baesyst= ems.com> wrote:


An OLSRv2 interface (a special case of a MANET in= terface, see RFC 6130) is an IP interface, one which IP receives packets on,= has one or more IP addresses etc. It has a data link layer below it, but OL= SRv2 doesn=E2=80=99t care about that. Your statement =E2=80=9Ca MANET interf= ace is a data link interface=E2=80=9D is wrong.

 

--

Christopher Dearlove

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

chris.= dearlove at baesystems.com | http://www.baesystems.com




= --Apple-Mail-D42F746A-172C-44B1-B6DF-5E9351613302-- From abdussalambaryun@gmail.com Tue May 1 05:31: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 CBB6321F86DC for ; Tue, 1 May 2012 05:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=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 pKPc4P-c4pMJ for ; Tue, 1 May 2012 05:31: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 A6F4521F8527 for ; Tue, 1 May 2012 05:31:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3174067vbb.31 for ; Tue, 01 May 2012 05:31: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 :cc:content-type; bh=d0+97+Feq1djdNjAlid/mxEl0FiYjhcoU5AVyG/Bnns=; b=i7856UR2MEa3eqqSv5vpvbrv6Ou+ZfqGl02Ai/GOtFiDbK7avYoMQTfKzx0+Bj8wg2 9gjWs6hsVRagB4oi3LlA640Zowf+/3P7T/Hycsz1PCmBUPqCMZCKAxPZaZGpV5WGeovH KMqIg45e7AZ32JiAHkNOEkzcMNT+InMypyhJRHGnIGM6QRtOmPTLwGYd77u5NSL6Riwk fFChwz7MFWi8dazJhV9VMhq13SuYGO2/9x8eE/bOD4cvlwfVCHUdrL/iiibzCFMqJpth ufksBGEQdTOTcdj9RaW7XLLvn38hTF6xU5gyshU27dniGJDsDicJfkh/AC57vNMt9Bvq J/2w== MIME-Version: 1.0 Received: by 10.52.68.77 with SMTP id u13mr9839526vdt.81.1335875473707; Tue, 01 May 2012 05:31:13 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Tue, 1 May 2012 05:31:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 May 2012 13:31:13 +0100 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=20cf307d022c1312af04bef8bf63 Cc: manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 12:31:17 -0000 --20cf307d022c1312af04bef8bf63 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Chris if it cannot be physical and cannot be in the underlying data-link layer (data link was mentioned in draft), then I don't care much for the change or addition, but if it can be all in physical and logical, I beleive it must state both physical and logical as long the draft states data link. I am completely lost here, I started to think to that I should wait for any other commenters before my last reply comments. Abdussalam On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christopher (UK) < Chris.Dearlove@baesystems.com> wrote: > I explicitly said it could be physical (but it doesn=92t matter) in a > different email than the one you quoted.**** > > ** ** > > -- **** > > 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:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* 01 May 2012 12:41 > *To:* Ulrich Herberg; ietf@thomasclausen.org > *Cc:* manet; Dearlove, Christopher (UK) > *Subject:* Re: [manet] Comments for OLSRv2-14**** > > ** ** > > ** ** > > **** 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 processon how t= o deal with suspicious emails. > ***** > > Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 i= s > used (or how the interfaces are defined). >IMO, unless other people in th= e > WG see the same danger of confusion, I would not change it.**** > > I have no problem with your reaction, so than wait until you get other > voices then (not sure how many you want), as long as the draft doesn't ca= re > about each single review-comment it only follows majority agreement on > comments. This type of review-system makes the document not include all > readers level of knowledge, that means the document is for specific group > which exclueds other readers or groups. However, I just will mention my > comments and do my work, I really don't care of the outcome decision, but= I > will care if I authored a reviewed document.**** > > clausen>An OLSRv2 interface can be physical or virtual. Chris explained i= t > well, I suggest re-reading his email.**** > > **** > > chris explained>An OLSRv2 interface (a special case of a MANET interface, > see RFC 6130) is an IP interface, one which IP receives packets on, has o= ne > or more IP addresses etc. It has a data link layer below it, but OLSRv2 > doesn=92t care about that. Your statement =93a MANET interface is a data = link > interface=94 is wrong. > > Ok, I read again. It does not mention that it may be physical. I > understand from him it never can be physical, so I needed that to be clea= r, > but now you mentioned that it can be physical.**** > > **** > > Abdussalam Baryun**** > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ > **** > > **** > > On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg > wrote:**** > > Abdussalam, > > so far, nobody else seemed to be confused on which layer OLSRv2 is used > (or how the interfaces are defined). IMO, unless other people in the WG s= ee > the same danger of confusion, I would not change it. > > Regards > Ulrich **** > > ** ** > > On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote:**** > > Hi Herberg,**** > > **** > > I am suggesting to clarify interfaces, I donot like to change if > unnecessary. Mentioning that an interface is in the layer 3, or its > logical, or even just explaining the way Chris defined to me, really make= s > difference. My question is why is the draft not mentioning that > OLSRv2-interface is an IP-interface or a logical-interface? Does the > authors see that this information is not important? or even > MANET-interfaces are in layer 3. If we define protocols without mentioni= ng > which layer it is located in, then how can we define such protocol, its > layer-location is more important than its functionality, because each lay= er > has its special interfaces, functions, services, and messages. There are > many documents that explain interface in the same model that OLSRv2 is > presenting so why didn't have confusion when I read them? > > >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) > is an IP interface, one which IP >receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t >c= are > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong. > > >I don't think there is any confusion. Chris has pointed out the > relationship between MANET interface and OLSRv2 >interface clearly. I thi= nk > that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If > you would like to >change anything, please suggest concrete text to > replace, so that I can better understand what you mean. > > I disagree that there is no confusion. There are confusions in defining > terms in MANET WG, I have seen in the past a long discussion between many= , > just arguing about defining host or router, and now l was confused of > interfaces in OLSRv2-draft. Maybe because I am not much familiar with OLS= R, > or reading about network-interface in many papers, and I read RFC2501 (it > refers alot to wireless interface and communications) and mentioned in > RFC6130 for the interface as attach to communication medium, I thought it > was a medium as physical medium. > > I suggest to clarify by adding information in one of the following > explanation to the draft (even a line will do):**** > > **** > > - Mentioning which layer(s) the OLSRv2-interface works or allowed to be a= t > by the protocol, or**** > > - defining the MANET-interface as Chris defined (IP-interface, at layer 3= ) > in terminology, or**** > > - mentioning that OLSRv2-interface is not a wireless interface, or**** > > - defining MANET-interface as logical interface.**** > > > I am sorry to disturb, I actually still have many comments for > OLSRv2-draft and will try to submit, and let the WG to decide. However, I > thank you and Chris to explain to me so at least my other comments will b= e > in understanding. > > Abdussalam > ++++++++++++++++++**** > > On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg > wrote:**** > > Abdussalam, > > RFC6130 defines: **** > > > > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces.***= * > > And draft-ietf-manet-olsrv2 defines: **** > > > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface.**** > > In one of the last OLSRv2 revisions, we made sure that OLSRv2 > differentiates between neighbors running only NHDP and neighbors running > also OLSRv2, and only the latter are used for MPR selection, etc. I do no= t > understand what you would like to change in the OLSRv2 draft. > > See comments below:**** > > On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote:**** > > Hi Henning,**** > > **** > > Please note that I read the first pages of draft many times before postin= g > any information.**** > > **** > > HR>I would suggest reading the OLSRv2-draft again, especially section 2. = * > *** > > > > >OLSRv2 interface: > >A MANET interface running this protocol. A router running this > >protocol MUST have at least one OLSRv2 interface.**** > > HR>A routing protocol which does not run on any interface would be pretty > >useless, right?**** > > You reply to the second sentence not the first which has 'running this > protocol' relating it not to the router it is relating it to the interfac= e. > I know that router must have at least a network-interface ( or > data-link-layer) or MANET interface, this is not what I commenting and th= e > draft is mentioning. We don't assume at least Data-Link because it is > obvious and we are following TCP/IP model in the internet, but not at lea= st > a specific-interface called bla bla.**** > > **** > > Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this > protocol (OLSRv2) this means there is some thing related to OLSRv2 in the > layer-2. You should read again another paragraph mentioning as if there i= s > difference between MANET-interface and OLSRv2-interface.**** > > **** > > OLSRv2-14>p9>**** > > Supports routers that each have one or more participating OLSRv2**** > > interfaces, which will consist of some or all of its MANET**** > > interfaces using [RFC6130]. The set of a router=92s OLSRv2**** > > interfaces, and the sets of its other MANET and non-MANET**** > > interfaces, may change over time. Each interface may have one or**** > > more network addresses (which may have prefix lengths), and these**** > > may also be dynamically changing.**** > > **** > > AB> it is clear from the above draft-page-9, that all MANET interfaces ar= e > not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. = So > we have to have in or node at least an OLSRv2-interface, not at least one > MANET-interfac so the protocol to work correctly.**** > > **** > > AB> The above page-9 mentions NHDP as well that interfaces need this > protocol. What if there is not NHDP, or if it is not working, what will > happen. The draft SHOULD explain these issues.**** > > ** ** > > **** > > AB> It may be that all OLSRv2 routers (as implementation point of > practice) only need at least one MANET interface. But the authors need to > change. therefore, we know that All routers need at least on interface, b= ut > the draft-wording has a special OLSRv2-interface. Then we need to change > the draft wording to the right explaination.**** > > > > Can you suggest what you would like to change? I don't understand your > point. > > Best regards > Ulrich > +++++++++++++++++++++++++++++++++++++++++++**** > > > > Hi Chris**** > > **** > > ok then if it was simple to explain as a special interface as IP-interfac= e > why we have OLSRv2_draft saying that it is network-interface as MANET is = a > network, but IP is not it is a protocol. IMO it is wrong to refer to a > network while you mean a protocol, even though I know I may misunderstood= . > I sugget that this SHOULD be explained clearly. I think every one seems t= o > understand that network-interface must include Data-Link-layer, therefore= , > RFC6130 or OLSRv2-draft should define well as you did. I thank you for yo= ur > comment,**** > > **** > > Therefore I suggest to change OLSRv2-interface definition as Chris define= d > it very clearly. I hope the draft can change the definition,**** > > **** > > Abdussalam**** > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) at baesystems.com> wrote:**** > > ** ** > > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s > an IP interface, one which IP receives packets on, has one or more IP > addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t ca= re > about that. Your statement =93a MANET interface is a data link interface= =94 is > wrong.**** > > **** > > -- **** > > 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 at baesystems.com | http://www.baesystems.com**** > > ** ** > > ** ** > > ** ** > > ******************************************************************** > 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. > ******************************************************************** > > --20cf307d022c1312af04bef8bf63 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Chris
=A0
if it cannot be physical and cannot be in the underlying data-link lay= er (data link=A0was mentioned in draft), then I don't care much for the= change or addition, but if it can be all in physical and logical, I beleiv= e it must state both physical and logical=A0as long the draft states data l= ink. I am completely lost here,
=A0
I started to think to that I should wait for any other commenters befo= re my last reply comments.
=A0
Abdussalam

On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christ= opher (UK) <Chris.Dearlove@baesystems.com> wrote= :

I explicitly said it could be p= hysical (but it doesn=92t matter) in a different email than the one you quo= ted.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: <= a href=3D"tel:%2B44%201245%20242124" target=3D"_blank" value=3D"+4412452421= 24">+44 1245 242124

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

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

=A0

From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: 01 May 2012 12:41
To: Ulrich Herberg; ietf@thomasclausen.orgCc: manet; Dearlove, Christopher (UK)
Subject: Re: [manet= ] Comments for OLSRv2-14

=A0

=A0

*** WARNING ***<= /p>

This message originat= es from outside our organisation, either from an external partner or the in= ternet.
Keep t= his in mind if you answer this message.
Please see this process on= how to deal with suspicious emails.

Herberg>so far, nobody else seemed to be confused= on which layer OLSRv2 is used (or how the interfaces are defined). >IMO= , unless other people in the WG see the same danger of confusion, I would n= ot change it.

I have no problem with = your reaction, so than wait until you get other voices then (not sure how m= any you want), as long as the draft doesn't care about each single revi= ew-comment it only follows majority agreement on comments. This type of rev= iew-system makes the document=A0not include all readers level of knowledge,= that means the document is for specific group which exclueds other readers= or groups. However, I just will mention my comments and do my work, I real= ly don't care of the outcome decision, but I will care if I authored a = reviewed document.

clausen>An OLSRv2 interface can be physical or vi= rtual. Chris explained it well, I suggest re-reading his email.

=A0

chris explained>An OLSRv2 interface (a spec= ial case of a MANET interface, see RFC 6130) is an IP interface, one which = IP receives packets on, has one or more IP addresses etc. It has a data lin= k layer below it, but OLSRv2 doesn=92t care about that. Your statement =93a= MANET interface is a data link interface=94 is wrong.

Ok, I read again.=A0It does not mention that it may be physical. I unde= rstand from him it never can be physical, so I needed that to be clear, but= now you mentioned that it can be physical.

=A0

Abdussalam Baryun

++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++

=A0

On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg <= ;ulrich@herberg.na= me> wrote:

Abdussalam,

so far, nobody else seemed to be = confused on which layer OLSRv2 is used (or how the interfaces are defined).= IMO, unless other people in the WG see the same danger of confusion, I wou= ld not change it.

Regards
Ulrich =

=A0

On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Herberg,

=A0

I am suggesting to clarify interfaces, I donot like= =A0to change=A0if unnecessary. Mentioning that an interface is in the layer= 3, or its logical, or even just explaining the way Chris defined to me, re= ally makes difference. My question is why is the draft not mentioning that = OLSRv2-interface is an IP-interface or a logical-interface? Does the author= s see that this information is not important? or even MANET-interfaces are = in layer 3.=A0 If we define protocols without mentioning which layer it is = located in, then how can we define such protocol, its layer-location is mor= e important than its functionality, because each layer has its special inte= rfaces, functions, services, and messages. There are many documents that ex= plain interface in the same model that OLSRv2 is presenting so why didn'= ;t have confusion when I read them?

>An OLSRv2 interface (a special case of a MANET= interface, see RFC 6130) is an IP interface, one which IP >receives pac= kets on, has one or more IP addresses etc. It has a data link layer below i= t, but OLSRv2 doesn=92t >care about that. Your statement =93a MANET inte= rface is a data link interface=94 is wrong.

>I don't think there is any confusion. Chris has pointed out the= relationship between MANET interface and OLSRv2 >interface clearly. I t= hink that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly.= If you would like to >change anything, please suggest concrete text to = replace, so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining= terms in MANET WG, I have seen in the past a long discussion between many,= just arguing about defining host or router, and now l was confused of inte= rfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or = reading about network-interface in many papers, and I read RFC2501 (it refe= rs alot to wireless interface and communications) and mentioned in RFC6130 = for the interface as attach to communication medium, I thought it was a med= ium as physical medium.

I suggest to clarify by adding information in one of the following expl= anation to the draft (even a line will do):

=A0

- Mentioning which layer(s)=A0the OLSRv2-interface w= orks or allowed to be at by the protocol, or

- defining the MANET-interface as=A0Chris defined (I= P-interface, at layer 3) in terminology, or

- mentioning that OLSRv2-interface is not a wireless= interface, or

- defining MANET-interface as logical interface.<= /u>


I am sorry to distu= rb, I actually still have many comments for OLSRv2-draft and will try to su= bmit, and let the WG to decide. However, I thank you and Chris to explain t= o me so at least my other comments will be in understanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg <= ulrich@herberg.nam= e> wrote:

Abdussalam,

RFC6130 defines:



MANET interface= :
An interface participating in a MANET and using this neighborhood
= =A0=A0=A0=A0=A0 discovery protocol.=A0 A router may have several MANET inte= rfaces.

And draft-ietf-manet-olsrv2 defines: <= /p>


OLSRv2 interface:=A0=A0=A0=A0=A0 A MANET interface running this protocol.=A0 A router runn= ing this
=A0=A0=A0=A0=A0 protocol MUST have at least one OLSRv2 interfac= e.

In one of the last OLSR= v2 revisions, we made sure that OLSRv2 differentiates between neighbors run= ning only NHDP and neighbors running also OLSRv2, and only the latter are u= sed for MPR selection, etc. I do not understand what you would like to chan= ge in the OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:

Hi Henning,

=A0

Please note that I read the first pages of draft=A0m= any times before posting any information.

=A0

HR>I would suggest reading the OLSRv2-draft again= , especially section 2.



>OLSRv2 inte= rface:
>A MANET interface running this protocol. =A0A router running = this
>protocol MUST have at least one OLSRv2 interface.=

HR>A routing protocol which does not run on any i= nterface would be pretty
>useless, right?

You reply to the second sentence not the first which= has 'running this protocol' relating it not to the router it is re= lating it to the interface. I know that router must have at least a network= -interface ( or data-link-layer)=A0or=A0MANET interface, this is not what I= commenting and the draft is mentioning. We don't assume at least Data-= Link because it is obvious and we are following TCP/IP model in the interne= t, but not at least a specific-interface called bla bla.

=A0

Why it defines the 'OLSRv2-interface' as a M= ANET-interface that RUNS this protocol (OLSRv2) this means there is some th= ing=A0related to OLSRv2 in the layer-2. You should read again another parag= raph mentioning as if there is difference between MANET-interface and OLSRv= 2-interface.

=A0

OLSRv2-14>p9>

Supports routers that each have one or more participating OL= SRv2

interfaces, which will consist of some or all of its MANET

interfaces using [RFC6130]= . The set of a router=92s OLSRv2

interfaces, and the sets of its other MANET and non-MANET

interfaces, may change over time. Each interface may have on= e or

more network addresses (which may have prefix lengths), and = these

may also be dynamically changing.

=A0

AB> it is clear from the above draft-page-9, that= all MANET interfaces=A0are not an OLSRv2-interface, but All OLSRv2 interfa= ces are MANET-interfaces. So we have to have in or node at least an OLSRv2-= interface, not at least one MANET-interfac so the protocol to work correctl= y.

=A0

AB> The above page-9 mentions NHDP as well that i= nterfaces need this protocol. What if there is not NHDP, or if it is not wo= rking, what will happen. The draft SHOULD explain these issues.

=A0

=A0

AB> It may be that all OLSRv2 routers (as impleme= ntation point of practice) only need at least one MANET interface. But the = authors need to change. therefore, we know that All routers need at least o= n interface, but the draft-wording has a special OLSRv2-interface. Then we = need to change the draft wording to the right explaination.



Can you suggest what you would like to chang= e? I don't understand your point.

Best regards
Ulrich
=A0+++++++++++++++++++++++++++++++++++++++++++



Hi Chris

=A0

ok then if it was simple to explain as a special int= erface=A0as IP-interface why we have OLSRv2_draft saying that it is network= -interface as MANET is a network, but IP is not it is a protocol. IMO it=A0= is wrong to refer to a network while you mean a protocol, even though I kno= w I may misunderstood. I sugget that this SHOULD be explained clearly. I th= ink every one seems to understand that network-interface must include=A0Dat= a-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as you = did. I thank you for your comment,

=A0

Therefore I suggest to change OLSRv2-interface defin= ition as Chris defined it very clearly. I hope the draft can=A0change the d= efinition,

=A0

Abdussalam

++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christo= pher (UK) <Chris.Dearlove at baesystems.com> wrote:<= /p>

=A0

An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove<= /u>

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194=A0|=A0 Fax: +44 1245 242124

chris.dearlove at baesystem= s.com | http://www.baesystems.com

=A0

=A0

=A0


*********= ***********************************************************
This email a= nd any attachments are confidential to the intended
recipient and may al= so be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You s= hould not copy it or use it for any purpose nor disclose or
distribute i= ts contents to any other person.
***************************************= *****************************


--20cf307d022c1312af04bef8bf63-- From ietf@thomasclausen.org Tue May 1 05:50: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 6BEE421E8522 for ; Tue, 1 May 2012 05:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.199 X-Spam-Level: X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[AWL=-0.733, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=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 pIns25qAQSy5 for ; Tue, 1 May 2012 05:50:28 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9942C21E84DF for ; Tue, 1 May 2012 05:50:28 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 815D9557FC6 for ; Tue, 1 May 2012 05:50:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id DF94E1CE1DBC; Tue, 1 May 2012 05:50:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.249] (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 mailc2.tigertech.net (Postfix) with ESMTPSA id 72B4C1CE1DB8; Tue, 1 May 2012 05:50:26 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-804989D6-C6F6-458D-8B2F-2FDBB8EB6620 Message-Id: <208504DC-6A9D-4DB5-B222-A8AA69BE19D4@thomasclausen.org> X-Mailer: iPad Mail (9B176) From: Thomas Heide Clausen Date: Tue, 1 May 2012 14:50:40 +0200 To: Abdussalam Baryun Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 12:50:30 -0000 --Apple-Mail-804989D6-C6F6-458D-8B2F-2FDBB8EB6620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 1 May 2012, at 14:31, Abdussalam Baryun wrot= e: > Hi Chris > =20 > if it cannot be physical and cannot be in the underlying data-link layer (= data link was mentioned in draft), That was not at all what Chris wrote. > then I don't care much for the change or addition, but if it can be all in= physical and logical, I beleive it must state both physical and logical as l= ong the draft states data link. No, that doesn't follow either. Thomas > I am completely lost here, > =20 > I started to think to that I should wait for any other commenters before m= y last reply comments. > =20 > Abdussalam >=20 > On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christopher (UK) wrote: > I explicitly said it could be physical (but it doesn=E2=80=99t matter) in a= different email than the one you quoted. >=20 > =20 >=20 > -- >=20 > Christopher Dearlove >=20 > 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 >=20 > 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 >=20 > From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 > Sent: 01 May 2012 12:41 > To: Ulrich Herberg; ietf@thomasclausen.org > Cc: manet; Dearlove, Christopher (UK) > Subject: Re: [manet] Comments for OLSRv2-14 >=20 > =20 >=20 > =20 >=20 > *** WARNING *** >=20 > This message originates from outside our organisation, either from an exte= rnal partner or the internet. > Keep this in mind if you answer this message. > Please see this process on how to deal with suspicious emails. >=20 > Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 is= used (or how the interfaces are defined). >IMO, unless other people in the W= G see the same danger of confusion, I would not change it. >=20 > I have no problem with your reaction, so than wait until you get other voi= ces then (not sure how many you want), as long as the draft doesn't care abo= ut each single review-comment it only follows majority agreement on comments= . This type of review-system makes the document not include all readers leve= l of knowledge, that means the document is for specific group which exclueds= other readers or groups. However, I just will mention my comments and do my= work, I really don't care of the outcome decision, but I will care if I aut= hored a reviewed document. >=20 > clausen>An OLSRv2 interface can be physical or virtual. Chris explained it= well, I suggest re-reading his email. >=20 > =20 >=20 > chris explained>An OLSRv2 interface (a special case of a MANET interface, s= ee RFC 6130) is an IP interface, one which IP receives packets on, has one o= r more IP addresses etc. It has a data link layer below it, but OLSRv2 doesn= =E2=80=99t care about that. Your statement =E2=80=9Ca MANET interface is a d= ata link interface=E2=80=9D is wrong. >=20 > Ok, I read again. It does not mention that it may be physical. I understan= d from him it never can be physical, so I needed that to be clear, but now y= ou mentioned that it can be physical. >=20 > =20 >=20 > Abdussalam Baryun >=20 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++ >=20 > =20 >=20 > On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg wro= te: >=20 > Abdussalam, >=20 > so far, nobody else seemed to be confused on which layer OLSRv2 is used (o= r how the interfaces are defined). IMO, unless other people in the WG see th= e same danger of confusion, I would not change it. >=20 > Regards > Ulrich >=20 > =20 >=20 > On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun wrote: >=20 > Hi Herberg, >=20 > =20 >=20 > I am suggesting to clarify interfaces, I donot like to change if unnecessa= ry. Mentioning that an interface is in the layer 3, or its logical, or even j= ust explaining the way Chris defined to me, really makes difference. My ques= tion is why is the draft not mentioning that OLSRv2-interface is an IP-inter= face or a logical-interface? Does the authors see that this information is n= ot important? or even MANET-interfaces are in layer 3. If we define protoco= ls without mentioning which layer it is located in, then how can we define s= uch protocol, its layer-location is more important than its functionality, b= ecause each layer has its special interfaces, functions, services, and messa= ges. There are many documents that explain interface in the same model that O= LSRv2 is presenting so why didn't have confusion when I read them?=20 >=20 > >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s an IP interface, one which IP >receives packets on, has one or more IP add= resses etc. It has a data link layer below it, but OLSRv2 doesn=E2=80=99t >c= are about that. Your statement =E2=80=9Ca MANET interface is a data link int= erface=E2=80=9D is wrong. >=20 > >I don't think there is any confusion. Chris has pointed out the relations= hip between MANET interface and OLSRv2 >interface clearly. I think that RFC6= 130/draft-ietf-manet-olsrv2 define the terminology correctly. If you would l= ike to >change anything, please suggest concrete text to replace, so that I c= an better understand what you mean. >=20 > I disagree that there is no confusion. There are confusions in defining te= rms in MANET WG, I have seen in the past a long discussion between many, jus= t arguing about defining host or router, and now l was confused of interface= s in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or readin= g about network-interface in many papers, and I read RFC2501 (it refers alot= to wireless interface and communications) and mentioned in RFC6130 for the i= nterface as attach to communication medium, I thought it was a medium as phy= sical medium. >=20 > I suggest to clarify by adding information in one of the following explana= tion to the draft (even a line will do): >=20 > =20 >=20 > - Mentioning which layer(s) the OLSRv2-interface works or allowed to be at= by the protocol, or >=20 > - defining the MANET-interface as Chris defined (IP-interface, at layer 3)= in terminology, or >=20 > - mentioning that OLSRv2-interface is not a wireless interface, or >=20 > - defining MANET-interface as logical interface. >=20 >=20 > I am sorry to disturb, I actually still have many comments for OLSRv2-draf= t and will try to submit, and let the WG to decide. However, I thank you and= Chris to explain to me so at least my other comments will be in understandi= ng. >=20 > Abdussalam > ++++++++++++++++++ >=20 > On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wrot= e: >=20 > Abdussalam, >=20 > RFC6130 defines: >=20 >=20 >=20 > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces. >=20 > And draft-ietf-manet-olsrv2 defines: >=20 >=20 > OLSRv2 interface: > A MANET interface running this protocol. A router running this > protocol MUST have at least one OLSRv2 interface. >=20 > In one of the last OLSRv2 revisions, we made sure that OLSRv2 differentiat= es between neighbors running only NHDP and neighbors running also OLSRv2, an= d only the latter are used for MPR selection, etc. I do not understand what y= ou would like to change in the OLSRv2 draft. >=20 > See comments below: >=20 > On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun wrote: >=20 > Hi Henning, >=20 > =20 >=20 > Please note that I read the first pages of draft many times before posting= any information. >=20 > =20 >=20 > HR>I would suggest reading the OLSRv2-draft again, especially section 2. >=20 >=20 >=20 > >OLSRv2 interface: > >A MANET interface running this protocol. A router running this > >protocol MUST have at least one OLSRv2 interface. >=20 > HR>A routing protocol which does not run on any interface would be pretty > >useless, right? >=20 > You reply to the second sentence not the first which has 'running this pro= tocol' relating it not to the router it is relating it to the interface. I k= now that router must have at least a network-interface ( or data-link-layer)= or MANET interface, this is not what I commenting and the draft is mentioni= ng. We don't assume at least Data-Link because it is obvious and we are foll= owing TCP/IP model in the internet, but not at least a specific-interface ca= lled bla bla. >=20 > =20 >=20 > Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS this p= rotocol (OLSRv2) this means there is some thing related to OLSRv2 in the lay= er-2. You should read again another paragraph mentioning as if there is diff= erence between MANET-interface and OLSRv2-interface. >=20 > =20 >=20 > OLSRv2-14>p9> >=20 > Supports routers that each have one or more participating OLSRv2 >=20 > interfaces, which will consist of some or all of its MANET >=20 > interfaces using [RFC6130]. The set of a router=E2=80=99s OLSRv2 >=20 > interfaces, and the sets of its other MANET and non-MANET >=20 > interfaces, may change over time. Each interface may have one or >=20 > more network addresses (which may have prefix lengths), and these >=20 > may also be dynamically changing. >=20 > =20 >=20 > AB> it is clear from the above draft-page-9, that all MANET interfaces are= not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. So= we have to have in or node at least an OLSRv2-interface, not at least one M= ANET-interfac so the protocol to work correctly. >=20 > =20 >=20 > AB> The above page-9 mentions NHDP as well that interfaces need this proto= col. What if there is not NHDP, or if it is not working, what will happen. T= he draft SHOULD explain these issues. >=20 > =20 >=20 > =20 >=20 > AB> It may be that all OLSRv2 routers (as implementation point of practice= ) only need at least one MANET interface. But the authors need to change. th= erefore, we know that All routers need at least on interface, but the draft-= wording has a special OLSRv2-interface. Then we need to change the draft wor= ding to the right explaination. >=20 >=20 >=20 > Can you suggest what you would like to change? I don't understand your poi= nt. >=20 > Best regards > Ulrich > +++++++++++++++++++++++++++++++++++++++++++ >=20 >=20 >=20 > Hi Chris >=20 > =20 >=20 > ok then if it was simple to explain as a special interface as IP-interface= why we have OLSRv2_draft saying that it is network-interface as MANET is a n= etwork, but IP is not it is a protocol. IMO it is wrong to refer to a networ= k while you mean a protocol, even though I know I may misunderstood. I sugge= t that this SHOULD be explained clearly. I think every one seems to understa= nd that network-interface must include Data-Link-layer, therefore, RFC6130 o= r OLSRv2-draft should define well as you did. I thank you for your comment, >=20 > =20 >=20 > Therefore I suggest to change OLSRv2-interface definition as Chris defined= it very clearly. I hope the draft can change the definition, >=20 > =20 >=20 > Abdussalam >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) wrote: >=20 > =20 >=20 > An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is= an IP interface, one which IP receives packets on, has one or more IP addre= sses etc. It has a data link layer below it, but OLSRv2 doesn=E2=80=99t care= about that. Your statement =E2=80=9Ca MANET interface is a data link interf= ace=E2=80=9D is wrong. >=20 > =20 >=20 > -- >=20 > Christopher Dearlove >=20 > 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 >=20 > chris.dearlove at baesystems.com | http://www.baesystems.com >=20 > =20 >=20 > =20 >=20 > =20 >=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 --Apple-Mail-804989D6-C6F6-458D-8B2F-2FDBB8EB6620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

=

On 1 May 2012, at 14:31, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
Hi Chris
 
if it cannot be physical and cannot be in the underlying data-link laye= r (data link was mentioned in draft),

=
That was not at all what Chris wrote.

then I don't care much for the change or addit= ion, but if it can be all in physical and logical, I beleive it must state b= oth physical and logical as long the draft states data link.

No, that doesn't follow either.

Thomas

I am com= pletely lost here,
 
I started to think to that I should wait for any other commenters befor= e my last reply comments.
 
Abdussalam

On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christo= pher (UK) <Chris.Dearlove@baesystems.com> wrote:

I explicitly said it could be physical (but it do= esn=E2=80=99t matter) in a different email than the one you quoted.

 

--

Christopher Dearlove

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

chris.de= arlove@baesystems.com | http://www.baesystems.com

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

 

From: Abdussalam Baryun [mailto:= abdussalamba= ryun@gmail.com]
Sent: 01 May 2012 12:41
To: Ulrich Herberg; ietf@thomasclausen.org
<= b>Cc: manet; Dearlove, Christopher (UK)
Subject: Re: [manet] C= omments for OLSRv2-14

 

 

*** WARNING ***

This message originates from outside our= organisation, either from an external partner or the internet.<= i>
Keep this in mind if yo= u answer this message.
Please see this process on how to deal with suspicious emails.<= /span>

Herberg>so far, nobody else seemed to be confused o= n which layer OLSRv2 is used (or how the interfaces are defined). >IMO, u= nless other people in the WG see the same danger of confusion, I would not c= hange it.

I have no problem with y= our reaction, so than wait until you get other voices then (not sure how man= y you want), as long as the draft doesn't care about each single review-comm= ent it only follows majority agreement on comments. This type of review-syst= em makes the document not include all readers level of knowledge, that m= eans the document is for specific group which exclueds other readers or grou= ps. However, I just will mention my comments and do my work, I really don't c= are of the outcome decision, but I will care if I authored a reviewed docume= nt.

clausen>An OLSRv2 interface can be physical or vir= tual. Chris explained it well, I suggest re-reading his email.=

 

chris explained>An OLSRv2 interface (a special case of a MANE= T interface, see RFC 6130) is an IP interface, one which IP receives packets= on, has one or more IP addresses etc. It has a data link layer below it, bu= t OLSRv2 doesn=E2=80=99t care about that. Your statement =E2=80=9Ca MANET in= terface is a data link interface=E2=80=9D is wrong.

Ok, I read again. It does not mention that it may be physical. I un= derstand from him it never can be physical, so I needed that to be clear, bu= t now you mentioned that it can be physical.

 

Abdussalam Baryun

+++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++++++

 

On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg <= ulrich@herberg.name= > wrote:

Abdussalam,

so far, nobody else seemed to be c= onfused on which layer OLSRv2 is used (or how the interfaces are defined). I= MO, unless other people in the WG see the same danger of confusion, I would n= ot change it.

Regards
Ulrich <= /u>

 

=

On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun &l= t;abdussalam= baryun@gmail.com> wrote:

Hi Herberg,

 

I am suggesting to clarify interfaces, I donot like&n= bsp;to change if unnecessary. Mentioning that an interface is in the la= yer 3, or its logical, or even just explaining the way Chris defined to me, r= eally makes difference. My question is why is the draft not mentioning that O= LSRv2-interface is an IP-interface or a logical-interface? Does the authors s= ee that this information is not important? or even MANET-interfaces are in l= ayer 3.  If we define protocols without mentioning which layer it is lo= cated in, then how can we define such protocol, its layer-location is more i= mportant than its functionality, because each layer has its special interfac= es, functions, services, and messages. There are many documents that explain= interface in the same model that OLSRv2 is presenting so why didn't have co= nfusion when I read them?

>An OLSRv2 interface (a special case of a MANET interface, see RFC= 6130) is an IP interface, one which IP >receives packets on, has one or m= ore IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=E2= =80=99t >care about that. Your statement =E2=80=9Ca MANET interface is a d= ata link interface=E2=80=9D is wrong.

>I don't think there is any confusion. Chris has pointed out the rela= tionship between MANET interface and OLSRv2 >interface clearly. I think t= hat RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. If you= would like to >change anything, please suggest concrete text to replace,= so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining t= erms in MANET WG, I have seen in the past a long discussion between many, ju= st arguing about defining host or router, and now l was confused of interfac= es in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or readi= ng about network-interface in many papers, and I read RFC2501 (it refers alo= t to wireless interface and communications) and mentioned in RFC6130 for the= interface as attach to communication medium, I thought it was a medium as p= hysical medium.

I suggest to clarify by adding information in one of the following expla= nation to the draft (even a line will do):

 

- Mentioning which layer(s) the OLSRv2-interface= works or allowed to be at by the protocol, or

- defining the MANET-interface as Chris defined (= IP-interface, at layer 3) in terminology, or

- mentioning that OLSRv2-interface is not a wireless i= nterface, or

- defining MANET-interface as logical interface.


I am sorry to distur= b, I actually still have many comments for OLSRv2-draft and will try to subm= it, and let the WG to decide. However, I thank you and Chris to explain to m= e so at least my other comments will be in understanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg <<= a href=3D"mailto:ulrich@herberg.name" target=3D"_blank">ulrich@herberg.name<= /a>> wrote:

Abdussalam,

RFC6130 defines:



MANET interface:=
An interface participating in a MANET and using this neighborhood
&nb= sp;     discovery protocol.  A router may have seve= ral MANET interfaces.

And draft-ietf-manet-olsrv2 defines:


OLSRv2 interface:      A MANET interface running this protocol.&nbs= p; A router running this
      protocol MUST hav= e at least one OLSRv2 interface.

In one of the last OLSRv= 2 revisions, we made sure that OLSRv2 differentiates between neighbors runni= ng only NHDP and neighbors running also OLSRv2, and only the latter are used= for MPR selection, etc. I do not understand what you would like to change i= n the OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &l= t;abdussalam= baryun@gmail.com> wrote:

Hi Henning,

 

Please note that I read the first pages of draft = ;many times before posting any information.

 

HR>I would suggest reading the OLSRv2-draft again,= especially section 2.



>OLSRv2 inter= face:
>A MANET interface running this protocol.  A router running= this
>protocol MUST have at least one OLSRv2 interface.=

HR>A routing protocol which does not run on any in= terface would be pretty
>useless, right?

You reply to the second sentence not the first which h= as 'running this protocol' relating it not to the router it is relating it t= o the interface. I know that router must have at least a network-interface (= or data-link-layer) or MANET interface, this is not what I commen= ting and the draft is mentioning. We don't assume at least Data-Link because= it is obvious and we are following TCP/IP model in the internet, but not at= least a specific-interface called bla bla.

 

Why it defines the 'OLSRv2-interface' as a MANET-inte= rface that RUNS this protocol (OLSRv2) this means there is some thing r= elated to OLSRv2 in the layer-2. You should read again another paragraph men= tioning as if there is difference between MANET-interface and OLSRv2-interfa= ce.

 

OLSRv2-14>p9>

Su= pports routers that each have one or more participating OLSRv2=

in= terfaces, which will consist of some or all of its MANET

in= terfaces using [RFC6130]. The set of a rou= ter=E2=80=99s OLSRv2

in= terfaces, and the sets of its other MANET and non-MANET=

in= terfaces, may change over time. Each interface may have one or=

mo= re network addresses (which may have prefix lengths), and these

ma= y also be dynamically changing.

 

AB> it is clear from the above draft-page-9, that a= ll MANET interfaces are not an OLSRv2-interface, but All OLSRv2 interfa= ces are MANET-interfaces. So we have to have in or node at least an OLSRv2-i= nterface, not at least one MANET-interfac so the protocol to work correctly.=

 

AB> The above page-9 mentions NHDP as well that in= terfaces need this protocol. What if there is not NHDP, or if it is not work= ing, what will happen. The draft SHOULD explain these issues.<= /p>

 

=

 

AB> It may be that all OLSRv2 routers (as implemen= tation point of practice) only need at least one MANET interface. But the au= thors need to change. therefore, we know that All routers need at least on i= nterface, but the draft-wording has a special OLSRv2-interface. Then we need= to change the draft wording to the right explaination.



Can you suggest what you would like to change= ? I don't understand your point.

Best regards
Ulrich
 +++++++++++++++++++++++++++++++++++++++++++=



Hi Chris

 

ok then if it was simple to explain as a special inte= rface as IP-interface why we have OLSRv2_draft saying that it is networ= k-interface as MANET is a network, but IP is not it is a protocol. IMO it&nb= sp;is wrong to refer to a network while you mean a protocol, even though I k= now I may misunderstood. I sugget that this SHOULD be explained clearly. I t= hink every one seems to understand that network-interface must include = Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should define well as yo= u did. I thank you for your comment,

 

Therefore I suggest to change OLSRv2-interface defini= tion as Chris defined it very clearly. I hope the draft can change the d= efinition,

 

Abdussalam=

+++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christoph= er (UK) <Chris.Dearlove at baesystems.com> wrote:

 

An OLSRv2 interface (a special case of a MANET in= terface, see RFC 6130) is an IP interface, one which IP receives packets on,= has one or more IP addresses etc. It has a data link layer below it, but OL= SRv2 doesn=E2=80=99t care about that. Your statement =E2=80=9Ca MANET interf= ace is a data link interface=E2=80=9D is wrong.

 

--

Christopher Dearlove

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

chris.dearlove at baesystems.com | <= a href=3D"http://www.baesystems.com/" target=3D"_blank">http://www.baesystem= s.com

 

 

 


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


= --Apple-Mail-804989D6-C6F6-458D-8B2F-2FDBB8EB6620-- From ulrich@herberg.name Tue May 1 10:04: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 08D6021E834B for ; Tue, 1 May 2012 10:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=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 P0yb-WyA5cDS for ; Tue, 1 May 2012 10:04:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4914621E8345 for ; Tue, 1 May 2012 10:04:41 -0700 (PDT) Received: by yhq56 with SMTP id 56so410909yhq.31 for ; Tue, 01 May 2012 10:04:41 -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=whNAyJvHGdhTxlIVmeV7IECs3scBGrasbHpR4OYD74M=; b=rPZ2qgo0TFDbAuKTjRsj9565naMn/XnkTntPV4m0PaWqUIr7C6E6qzfyDaMhpaGU3g WEr3DZyDGBqDZ7Lf7uYYtx95VCSF/+v6C4RJlcmVJ9PRRBFbnvq1f81cy0OedwW8if20 hEbOoErYv2nPkJo+g5m/8J0uS7XNnPKONd0Zk= 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=whNAyJvHGdhTxlIVmeV7IECs3scBGrasbHpR4OYD74M=; b=Bv8ds+rVgeAqA95dbL+U3bFm8I347pXvTXqykZFgVNWm5JUqOtbRj6CjQeJCVAVUa0 20zIsVef7Il2ff0GAIvoMm4wkopgP3h2fRvS8rVUTw9vM6CMkMrRS1XXeKDdz2KxItXK pHCMHXaF0qdDsFhVsEnl5qbj341Qc1dNZTlbz+ivj/yMhnseSLRyqDcSKZ5fvOK14CTr sgvmnBKR/0ptdZToCtLbYRdxg3M5bZ+e1NkS3ig0W8+7AAEt3rAyUWSsMOQv5p4AUAdG snWTm4inNGzMFGWoj4brzr1cRNdQb+EpgH+kJoikKpUeyaA56gLkVRevF0BxVG9xbvhC +aLQ== MIME-Version: 1.0 Received: by 10.68.220.2 with SMTP id ps2mr59788689pbc.109.1335891880301; Tue, 01 May 2012 10:04:40 -0700 (PDT) Received: by 10.142.89.17 with HTTP; Tue, 1 May 2012 10:04:40 -0700 (PDT) In-Reply-To: References: Date: Tue, 1 May 2012 10:04:40 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7b2ee199fbd30d04befc90bb X-Gm-Message-State: ALoCoQmh22X6KOQCsiE0HiR0rE8ii0FkSJ14nZlayLTE66s2MoUYAf3PedRsLq+Ho/tFtnRwsUSM Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] Comments for OLSRv2-14 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, 01 May 2012 17:04:46 -0000 --047d7b2ee199fbd30d04befc90bb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam, On Tue, May 1, 2012 at 4:41 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 i= s > used (or how the interfaces are defined). >IMO, unless other people in th= e > WG see the same danger of confusion, I would not change it. > I have no problem with your reaction, so than wait until you get other > voices then (not sure how many you want), as long as the draft doesn't ca= re > about each single review-comment it only follows majority agreement on > comments. This type of review-system makes the document not include all > readers level of knowledge, that means the document is for specific group > which exclueds other readers or groups. > The IETF does not work by means of "majority" (which is not even possible since there is no formal membership), but by rough consensus (and running code). And every individual can (and should!) review a document and give suggestions, which can help to improve a document. I just don't see how your suggestions about the MANET/OLSRv2 interfaces would improve the OLSRv2 draft (for the reasons that Chris, Thomas and I have pointed out). Regards Ulrich > However, I just will mention my comments and do my work, I really don't > care of the outcome decision, but I will care if I authored a reviewed > document. > > clausen>An OLSRv2 interface can be physical or virtual. Chris explained i= t > well, I suggest re-reading his email. > > chris explained>An OLSRv2 interface (a special case of a MANET interface, > see RFC 6130) is an IP interface, one which IP receives packets on, has o= ne > or more IP addresses etc. It has a data link layer below it, but OLSRv2 > doesn=92t care about that. Your statement =93a MANET interface is a data = link > interface=94 is wrong. > > Ok, I read again. It does not mention that it may be physical. I > understand from him it never can be physical, so I needed that to be clea= r, > but now you mentioned that it can be physical. > > Abdussalam Baryun > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++ > > On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg wro= te: > >> Abdussalam, >> >> so far, nobody else seemed to be confused on which layer OLSRv2 is used >> (or how the interfaces are defined). IMO, unless other people in the WG = see >> the same danger of confusion, I would not change it. >> >> Regards >> Ulrich >> >> >> On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >> >>> Hi Herberg, >>> >>> I am suggesting to clarify interfaces, I donot like to change if >>> unnecessary. Mentioning that an interface is in the layer 3, or its >>> logical, or even just explaining the way Chris defined to me, really ma= kes >>> difference. My question is why is the draft not mentioning that >>> OLSRv2-interface is an IP-interface or a logical-interface? Does the >>> authors see that this information is not important? or even >>> MANET-interfaces are in layer 3. If we define protocols without mentio= ning >>> which layer it is located in, then how can we define such protocol, its >>> layer-location is more important than its functionality, because each l= ayer >>> has its special interfaces, functions, services, and messages. There ar= e >>> many documents that explain interface in the same model that OLSRv2 is >>> presenting so why didn't have confusion when I read them? >>> >>> >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130= ) >>> is an IP interface, one which IP >receives packets on, has one or more = IP >>> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t = >care >>> about that. Your statement =93a MANET interface is a data link interfac= e=94 is >>> wrong. >>> >>> >I don't think there is any confusion. Chris has pointed out the >>> relationship between MANET interface and OLSRv2 >interface clearly. I t= hink >>> that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly. = If >>> you would like to >change anything, please suggest concrete text to >>> replace, so that I can better understand what you mean. >>> >>> I disagree that there is no confusion. There are confusions in defining >>> terms in MANET WG, I have seen in the past a long discussion between ma= ny, >>> just arguing about defining host or router, and now l was confused of >>> interfaces in OLSRv2-draft. Maybe because I am not much familiar with O= LSR, >>> or reading about network-interface in many papers, and I read RFC2501 (= it >>> refers alot to wireless interface and communications) and mentioned in >>> RFC6130 for the interface as attach to communication medium, I thought = it >>> was a medium as physical medium. >>> >>> I suggest to clarify by adding information in one of the following >>> explanation to the draft (even a line will do): >>> >>> - Mentioning which layer(s) the OLSRv2-interface works or allowed to be >>> at by the protocol, or >>> - defining the MANET-interface as Chris defined (IP-interface, at layer >>> 3) in terminology, or >>> - mentioning that OLSRv2-interface is not a wireless interface, or >>> - defining MANET-interface as logical interface. >>> >>> I am sorry to disturb, I actually still have many comments for >>> OLSRv2-draft and will try to submit, and let the WG to decide. However,= I >>> thank you and Chris to explain to me so at least my other comments will= be >>> in understanding. >>> >>> Abdussalam >>> ++++++++++++++++++ >>> >>> On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg wr= ote: >>> >>>> Abdussalam, >>>> >>>> RFC6130 defines: >>>> >>>> >>>> MANET interface: >>>> An interface participating in a MANET and using this neighborhood >>>> discovery protocol. A router may have several MANET interfaces. >>>> >>>> And draft-ietf-manet-olsrv2 defines: >>>> >>>> OLSRv2 interface: >>>> A MANET interface running this protocol. A router running this >>>> protocol MUST have at least one OLSRv2 interface. >>>> >>>> In one of the last OLSRv2 revisions, we made sure that OLSRv2 >>>> differentiates between neighbors running only NHDP and neighbors runni= ng >>>> also OLSRv2, and only the latter are used for MPR selection, etc. I do= not >>>> understand what you would like to change in the OLSRv2 draft. >>>> >>>> See comments below: >>>> >>>> On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote: >>>> >>>>> Hi Henning, >>>>> >>>>> Please note that I read the first pages of draft many times before >>>>> posting any information. >>>>> >>>>> HR>I would suggest reading the OLSRv2-draft again, especially section >>>>> 2. >>>>> >>>>> >>>>> >OLSRv2 interface: >>>>> >A MANET interface running this protocol. A router running this >>>>> >protocol MUST have at least one OLSRv2 interface. >>>>> >>>>> HR>A routing protocol which does not run on any interface would be >>>>> pretty >>>>> >useless, right? >>>>> You reply to the second sentence not the first which has 'running thi= s >>>>> protocol' relating it not to the router it is relating it to the inte= rface. >>>>> I know that router must have at least a network-interface ( or >>>>> data-link-layer) or MANET interface, this is not what I commenting an= d the >>>>> draft is mentioning. We don't assume at least Data-Link because it is >>>>> obvious and we are following TCP/IP model in the internet, but not at= least >>>>> a specific-interface called bla bla. >>>>> >>>>> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS >>>>> this protocol (OLSRv2) this means there is some thing related to OLSR= v2 in >>>>> the layer-2. You should read again another paragraph mentioning as if= there >>>>> is difference between MANET-interface and OLSRv2-interface. >>>>> >>>>> OLSRv2-14>p9> >>>>> >>>>> Supports routers that each have one or more participating OLSRv2 >>>>> >>>>> interfaces, which will consist of some or all of its MANET >>>>> >>>>> interfaces using [RFC6130]. The set of a router=92s OLSRv2 >>>>> >>>>> interfaces, and the sets of its other MANET and non-MANET >>>>> >>>>> interfaces, may change over time. Each interface may have one or >>>>> >>>>> more network addresses (which may have prefix lengths), and these >>>>> >>>>> may also be dynamically changing. >>>>> >>>>> AB> it is clear from the above draft-page-9, that all MANET >>>>> interfaces are not an OLSRv2-interface, but All OLSRv2 interfaces are >>>>> MANET-interfaces. So we have to have in or node at least an >>>>> OLSRv2-interface, not at least one MANET-interfac so the protocol to = work >>>>> correctly. >>>>> >>>>> AB> The above page-9 mentions NHDP as well that interfaces need this >>>>> protocol. What if there is not NHDP, or if it is not working, what wi= ll >>>>> happen. The draft SHOULD explain these issues. >>>>> >>>> >>>> >>>> >>>>> AB> It may be that all OLSRv2 routers (as implementation point of >>>>> practice) only need at least one MANET interface. But the authors nee= d to >>>>> change. therefore, we know that All routers need at least on interfac= e, but >>>>> the draft-wording has a special OLSRv2-interface. Then we need to cha= nge >>>>> the draft wording to the right explaination. >>>>> >>>> >>>> >>>> Can you suggest what you would like to change? I don't understand your >>>> point. >>>> >>>> Best regards >>>> Ulrich >>>> +++++++++++++++++++++++++++++++++++++++++++ >>>> >>> >>> >>> Hi Chris >>> >>> ok then if it was simple to explain as a special interface as >>> IP-interface why we have OLSRv2_draft saying that it is network-interfa= ce >>> as MANET is a network, but IP is not it is a protocol. IMO it is wrong = to >>> refer to a network while you mean a protocol, even though I know I may >>> misunderstood. I sugget that this SHOULD be explained clearly. I think >>> every one seems to understand that network-interface must >>> include Data-Link-layer, therefore, RFC6130 or OLSRv2-draft should defi= ne >>> well as you did. I thank you for your comment, >>> >>> Therefore I suggest to change OLSRv2-interface definition as Chris >>> defined it very clearly. I hope the draft can change the definition, >>> >>> Abdussalam >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++ >>> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) >> at baesystems.com> wrote: >>> >>> >>> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >>> is an IP interface, one which IP receives packets on, has one or more I= P >>> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t = care >>> about that. Your statement =93a MANET interface is a data link interfac= e=94 is >>> wrong. >>> >>> >>> >>> -- >>> >>> 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 at baesystems.com | http://www.baesystems.com >>> >>> >>> >> > --047d7b2ee199fbd30d04befc90bb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Abdussalam,


--047d7b2ee199fbd30d04befc90bb-- From abdussalambaryun@gmail.com Tue May 1 15:01: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 32EBF21E80C3 for ; Tue, 1 May 2012 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=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 OQK5lsoMcWPe for ; Tue, 1 May 2012 15:01:17 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA82F21E80C0 for ; Tue, 1 May 2012 15:01:16 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so3261703wib.13 for ; Tue, 01 May 2012 15:01: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=XRyzuViYfVbhenDutwZzdVYKcjFGyme/T+nrDNEOp34=; b=X/1vuA77M75b89K0QLZYQC82B0I8A07yIFkfRnKQxtodan6jDPlze3z90J5BhFoKyd dkl5ratBZ0ShLU4FkmSGew0J6u7pMXpln6TDZwPBcKGHm3TR3QWAqlCY/QHLFjGsca+j DOQz3RN+T9LvUtJMebOpxzydcinN0ZdJuy+IN1CgLMn94hBs/E7wSa84GFvV3uuGqrf9 iivcDlrh09DH90Opc5++z8qyKgxC1gQJgWJdw+Evzxyu0SZGKNotg9D2XSnlks5l5or3 QQIVVfmE1eQbA0XxrWzbTwe6FY0CTBVRKyw2f3Wotql1/yRL3d/cI+1S8Dt/q8tyG64F 9+lg== MIME-Version: 1.0 Received: by 10.216.45.146 with SMTP id p18mr5028673web.47.1335909676054; Tue, 01 May 2012 15:01:16 -0700 (PDT) Received: by 10.180.100.10 with HTTP; Tue, 1 May 2012 15:01:15 -0700 (PDT) Date: Tue, 1 May 2012 23:01:15 +0100 Message-ID: From: Abdussalam Baryun To: charliep@computer.org Content-Type: multipart/alternative; boundary=0016e6db6c4eb1778104bf00b505 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 01 May 2012 22:01:18 -0000 --0016e6db6c4eb1778104bf00b505 Content-Type: text/plain; charset=ISO-8859-1 Hi >Also, 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. I support/prefer the option: AODVv2 without packet-bb first then, to submit consideration another document that uses packet-BB, with different name. To make things simple and leaving messaging issues in the end, the functionality is more important. Abdussalam Baryun University of Glamorgan,UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Hello folks, I have not participated very much in any discussions about packet-BB other than to encourage header size reduction and offer a few suggestions about how to achieve it. During that time, it was claimed that for many networks of interest, the use of packet-BB would *decrease* header size, perhaps especially for proactive protocols. This is a question very suitable for resolution by way of simulation. If, as I suspect, packet-BB does (on average) introduce header enlargement on some networks that cannot afford it, I would be in favor to introduce the option to run AODV (or OLSR, for that matter) with some sort of "reduced" header. This should only be deployed in networks where otherwise there would be no feasible deployment of an ad-hoc networking protocol. From that perspective, it's almost a no brainer -- either deploy the standard stripped- down version, or deploy something else nonstandard that looks exactly like the stripped-down version. In summary, if there are cases where the [manet] protocols can only be deployed without packet-BB header overhead, then I think we should provide a solution for those cases. To be clear, I am happy either way, whether or not packet-BB headers are mandates in all cases. Also, 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. Regards, Charlie P. --0016e6db6c4eb1778104bf00b505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0
Hi

>Also, to be clear, we can standardize AODVv2 *with* packet-BB<= br>>right now, and submit for consideration another document for
>= AODVv2 that does not require packet-BB.=A0 Or, we can enable both
>wa= ys in the next revision.=A0 Or, we can standardize AODVv2
>that does NOT use packet-BB, and then submit for consideration
>a= nother document that DOES use packet-BB.=A0 All cases are just
>fine = with me, depending on what the working group wants.
I support/prefer=A0the option: =A0AODVv2 without packet-bb first then,= to submit consideration
another document that uses packet-BB, with diff= erent name. To make things simple and leaving
messaging issues in the end, the functionality is more important.
=A0
=A0
Abdussalam Baryun
University of Glamorgan,UK

++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++++++
Hello folks,

I have not participated very much in any discussio= ns about
packet-BB other than to encourage header size reduction and
= offer a few suggestions about how to achieve it.=A0 During that
time, it= was claimed that for many networks of interest, the
use of packet-BB would *decrease* header size, perhaps
especially for pr= oactive protocols.=A0 This is a question
very suitable for resolution by= way of simulation.

If, as I suspect, packet-BB does (on average) in= troduce
header enlargement on some networks that cannot afford it,
I would be in= favor to introduce the option to run AODV
(or OLSR, for that matter) wi= th some sort of "reduced"
header.=A0 This should only be deplo= yed in networks where
otherwise there would be no feasible deployment of an
ad-hoc networking = protocol.=A0 From that perspective, it's
almost a no brainer -- eith= er deploy the standard stripped-
down version, or deploy something else = nonstandard that
looks exactly like the stripped-down version.

In summary, if there a= re cases where the [manet] protocols
can only be deployed without packet= -BB header overhead,
then I think we should provide a solution for those= cases.

To be clear, I am happy either way, whether or not packet-BB
headers= are mandates in all cases.

Also, to be clear, we can standardize AO= DVv2 *with* packet-BB
right now, and submit for consideration another do= cument for
AODVv2 that does not require packet-BB.=A0 Or, we can enable both
ways i= n the next revision.=A0 Or, we can standardize AODVv2
that does NOT use = packet-BB, and then submit for consideration
another document that DOES = use packet-BB.=A0 All cases are just
fine with me, depending on what the working group wants.

Regards,Charlie P.


--0016e6db6c4eb1778104bf00b505-- From Chris.Dearlove@baesystems.com Wed May 2 01:50: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 87F5521F8A5B for ; Wed, 2 May 2012 01:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, 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 nFMryED+7LCR for ; Wed, 2 May 2012 01:50:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 40CE421F8A47 for ; Wed, 2 May 2012 01:50:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,515,1330905600"; d="scan'208,217";a="235655868" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 May 2012 09:50:48 +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 q428olou013144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 May 2012 09:50:47 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.01.0355.002; Wed, 2 May 2012 09:50:47 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , "charliep@computer.org" Thread-Topic: [manet] A view on packet-BB Thread-Index: AQHNJ+X7nMtvbPBQX0OYzXHJO0L0ZZa2LxGA Date: Wed, 2 May 2012 08:50:47 +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: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01462BGLKXM0002VGREENLN_" MIME-Version: 1.0 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 02 May 2012 08:50:52 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01462BGLKXM0002VGREENLN_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The constraints here are first that RFC 5498 mandates use of RFC 5444 (formerly packetbb) for protocols using the manet UDP port or manet IP protocol. If anything not using RFC 5444 were to do so that would cause interoperability issues. But of course AODVv2 could use another port, for example AODV's port (except there could be compatibility problems there, but that's not something I've considered). That comes up against a second issue, that the rough consensus in the WG was that all Standards Track protocols developed in the WG would use RFC 5498/5444. Of course could change - unlike RFCs that can't be overturned that way - but it hasn't been yet. -- 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 Abdussalam Baryun Sent: 01 May 2012 23:01 To: charliep@computer.org Cc: manet Subject: Re: [manet] A view on packet-BB *** 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. Hi >Also, 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. I support/prefer the option: AODVv2 without packet-bb first then, to submit consideration another document that uses packet-BB, with different name. To make things simple and leaving messaging issues in the end, the functionality is more important. Abdussalam Baryun University of Glamorgan,UK +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Hello folks, I have not participated very much in any discussions about packet-BB other than to encourage header size reduction and offer a few suggestions about how to achieve it. During that time, it was claimed that for many networks of interest, the use of packet-BB would *decrease* header size, perhaps especially for proactive protocols. This is a question very suitable for resolution by way of simulation. If, as I suspect, packet-BB does (on average) introduce header enlargement on some networks that cannot afford it, I would be in favor to introduce the option to run AODV (or OLSR, for that matter) with some sort of "reduced" header. This should only be deployed in networks where otherwise there would be no feasible deployment of an ad-hoc networking protocol. From that perspective, it's almost a no brainer -- either deploy the standard stripped- down version, or deploy something else nonstandard that looks exactly like the stripped-down version. In summary, if there are cases where the [manet] protocols can only be deployed without packet-BB header overhead, then I think we should provide a solution for those cases. To be clear, I am happy either way, whether or not packet-BB headers are mandates in all cases. Also, 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. 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. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01462BGLKXM0002VGREENLN_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit

The constraints here are first that RFC 5498 mandates use of RFC 5444 (formerly packetbb) for protocols using the manet UDP port or manet IP protocol. If anything not using RFC 5444 were to do so that would cause interoperability issues.

 

But of course AODVv2 could use another port, for example AODV's port (except there could be compatibility problems there, but that's not something I've considered). That comes up against a second issue, that the rough consensus in the WG was that all Standards Track protocols developed in the WG would use RFC 5498/5444. Of course could change - unlike RFCs that can't be overturned that way - but it hasn't been yet.

 

--

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 Abdussalam Baryun
Sent: 01 May 2012 23:01
To: charliep@computer.org
Cc: manet
Subject: Re: [manet] A view on packet-BB

 

 

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

 

Hi


>Also, 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.

I support/prefer the option:  AODVv2 without packet-bb first then, to submit consideration
another document that uses packet-BB, with different name. To make things simple and leaving

messaging issues in the end, the functionality is more important.

 

 

Abdussalam Baryun

University of Glamorgan,UK

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

Hello folks,

I have not participated very much in any discussions about
packet-BB other than to encourage header size reduction and
offer a few suggestions about how to achieve it.  During that
time, it was claimed that for many networks of interest, the
use of packet-BB would *decrease* header size, perhaps
especially for proactive protocols.  This is a question
very suitable for resolution by way of simulation.

If, as I suspect, packet-BB does (on average) introduce
header enlargement on some networks that cannot afford it,
I would be in favor to introduce the option to run AODV
(or OLSR, for that matter) with some sort of "reduced"
header.  This should only be deployed in networks where
otherwise there would be no feasible deployment of an
ad-hoc networking protocol.  From that perspective, it's
almost a no brainer -- either deploy the standard stripped-
down version, or deploy something else nonstandard that
looks exactly like the stripped-down version.

In summary, if there are cases where the [manet] protocols
can only be deployed without packet-BB header overhead,
then I think we should provide a solution for those cases.

To be clear, I am happy either way, whether or not packet-BB
headers are mandates in all cases.

Also, 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.

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D01462BGLKXM0002VGREENLN_-- From abdussalambaryun@gmail.com Wed May 2 04:48:17 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 4BDAD21F8A0B for ; Wed, 2 May 2012 04:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_92=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 DsXY4vppZmdJ for ; Wed, 2 May 2012 04:48: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 34E0621F8A0A for ; Wed, 2 May 2012 04:48:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so404939vbb.31 for ; Wed, 02 May 2012 04:48: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=von7IYMcaFVTYzHM48nc0quzDNGCz49UFx90Agpgy3U=; b=X26X+S+EXdgB4LpZHcCwsioCJH8Yy/RovZYVWcm9nIV4K4GJReGBDViY7NZcrlSLLn izpTyty2Cd/o9HyFFrDepOgF2sCGbrUv64CI+yi5j+ldIKbvhkeWARu02/4oafPbciSB ZgaClsKsntXmTttGajOLg8AqVp00JijeRD6pAglHiJsMDMjH4L/uW/H1sU2TzD9KP8kC jPWw/6c/qZtVWF7+k131ZfMQeNSXQyYUDcnswTP6+XUeoyVQWyLQEZqAMDUfOu/MjQM0 a34Z6Tn6Mfp8xehCForD5Kwge9zO/+EHRDogoc9z4akEZ9oe13pbW/ZEHjAuMTbSeAvp c2tg== MIME-Version: 1.0 Received: by 10.220.155.197 with SMTP id t5mr24070450vcw.6.1335959295675; Wed, 02 May 2012 04:48:15 -0700 (PDT) Received: by 10.220.27.8 with HTTP; Wed, 2 May 2012 04:48:15 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 13:48:15 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 02 May 2012 11:48:17 -0000 On 5/2/12, Dearlove, Christopher (UK) wrote: > The constraints here are first that RFC 5498 mandates use of RFC 5444 > (formerly packetbb) for protocols using the manet UDP port or manet IP > protocol. If anything not using RFC 5444 were to do so that would cause > interoperability issues. Yes, 5498 is for a specific port not for all and not in general, even though the word general is mentioned in packet-bb 5444, which I think it is not general format because it specifies some rules that try to cover all aspects. > > But of course AODVv2 could use another port, for example AODV's port (except > there could be compatibility problems there, but that's not something I've > considered). That comes up against a second issue, that the rough consensus > in the WG was that all Standards Track protocols developed in the WG would > use RFC 5498/5444. Of course could change - unlike RFCs that can't be > overturned that way - but it hasn't been yet. > Yes, I suggested AODVv2 uses another port, and every protocol that does not use 5444. The issue is if any protocol does not use 5444 it MUST have different port than the RFC5498, but we don't say all MANET use 5444 and then it must use that port of RFC5498. The reason why is because the 5444 does not state that all MANET routing protocols SHOULD use packet-bb, if it does state that then we have to update 5498 to include all ports that do cover all MANET routings including AODV. First, the best development and testing approach in the experimental wroking in progress stage, that we focus on the protocol's ideas first and then think if they may join a format, a method, a standard, etc. Secondly, is to update this general format 5444 to match really all protocols in their interest as was clarified by the first poster of the topic. Thirdly update RFC5498 as well. But another complicated approach is going in the other direction, to start adjusting protocol ideas to adapt to the message format and port assigned by 5444/5498, then testing functionality, or testing twice with and without. This may limit some of the design-protocol-functionality which should be carefully considered if this second direction approach was choosen. Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++ > -- > 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 > Abdussalam Baryun > Sent: 01 May 2012 23:01 > To: charliep@computer.org > Cc: manet > Subject: Re: [manet] A view on packet-BB > > > *** 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. > > Hi > >>Also, 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. > I support/prefer the option: AODVv2 without packet-bb first then, to submit > consideration > another document that uses packet-BB, with different name. To make things > simple and leaving > messaging issues in the end, the functionality is more important. > > > Abdussalam Baryun > University of Glamorgan,UK > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Hello folks, > > I have not participated very much in any discussions about > packet-BB other than to encourage header size reduction and > offer a few suggestions about how to achieve it. During that > time, it was claimed that for many networks of interest, the > use of packet-BB would *decrease* header size, perhaps > especially for proactive protocols. This is a question > very suitable for resolution by way of simulation. > > If, as I suspect, packet-BB does (on average) introduce > header enlargement on some networks that cannot afford it, > I would be in favor to introduce the option to run AODV > (or OLSR, for that matter) with some sort of "reduced" > header. This should only be deployed in networks where > otherwise there would be no feasible deployment of an > ad-hoc networking protocol. From that perspective, it's > almost a no brainer -- either deploy the standard stripped- > down version, or deploy something else nonstandard that > looks exactly like the stripped-down version. > > In summary, if there are cases where the [manet] protocols > can only be deployed without packet-BB header overhead, > then I think we should provide a solution for those cases. > > To be clear, I am happy either way, whether or not packet-BB > headers are mandates in all cases. > > Also, 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. > > 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 Chris.Dearlove@baesystems.com Wed May 2 05:28: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 152F621F84BD for ; Wed, 2 May 2012 05:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 CN95Q7wZR8b3 for ; Wed, 2 May 2012 05:28:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75421F84B6 for ; Wed, 2 May 2012 05:28:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,516,1330905600"; d="scan'208";a="235767203" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 02 May 2012 13:28:20 +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 q42CSJaE022026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 May 2012 13:28:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Wed, 2 May 2012 13:28:19 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] A view on packet-BB Thread-Index: AQHNJ+X7nMtvbPBQX0OYzXHJO0L0ZZa2LxGAgAAjSoCAABrw8A== Date: Wed, 2 May 2012 12:28:19 +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] A view on packet-BB 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, 02 May 2012 12:28:22 -0000 You refer to the experimental stage. But the reactive protocol that the MAN= ET WG is supposed to be working on is meant to be Standards Track, not Expe= rimental. AODV (v1) and DSR were supposed to be the experimental stage. Updating 5444 and 5498 is really not what we need to do. --=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: 02 May 2012 12:48 To: Dearlove, Christopher (UK) Cc: charliep@computer.org; manet Subject: Re: [manet] A view on packet-BB ----------------------! 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 5/2/12, Dearlove, Christopher (UK) wrote= : > The constraints here are first that RFC 5498 mandates use of RFC 5444 > (formerly packetbb) for protocols using the manet UDP port or manet IP > protocol. If anything not using RFC 5444 were to do so that would cause > interoperability issues. Yes, 5498 is for a specific port not for all and not in general, even though the word general is mentioned in packet-bb 5444, which I think it is not general format because it specifies some rules that try to cover all aspects. > > But of course AODVv2 could use another port, for example AODV's port (exc= ept > there could be compatibility problems there, but that's not something I'v= e > considered). That comes up against a second issue, that the rough consens= us > in the WG was that all Standards Track protocols developed in the WG woul= d > use RFC 5498/5444. Of course could change - unlike RFCs that can't be > overturned that way - but it hasn't been yet. > Yes, I suggested AODVv2 uses another port, and every protocol that does not use 5444. The issue is if any protocol does not use 5444 it MUST have different port than the RFC5498, but we don't say all MANET use 5444 and then it must use that port of RFC5498. The reason why is because the 5444 does not state that all MANET routing protocols SHOULD use packet-bb, if it does state that then we have to update 5498 to include all ports that do cover all MANET routings including AODV. First, the best development and testing approach in the experimental wroking in progress stage, that we focus on the protocol's ideas first and then think if they may join a format, a method, a standard, etc. Secondly, is to update this general format 5444 to match really all protocols in their interest as was clarified by the first poster of the topic. Thirdly update RFC5498 as well. But another complicated approach is going in the other direction, to start adjusting protocol ideas to adapt to the message format and port assigned by 5444/5498, then testing functionality, or testing twice with and without. This may limit some of the design-protocol-functionality which should be carefully considered if this second direction approach was choosen. Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++ > -- > 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 > Abdussalam Baryun > Sent: 01 May 2012 23:01 > To: charliep@computer.org > Cc: manet > Subject: Re: [manet] A view on packet-BB > > > *** 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. > > Hi > >>Also, 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. > I support/prefer the option: AODVv2 without packet-bb first then, to sub= mit > consideration > another document that uses packet-BB, with different name. To make things > simple and leaving > messaging issues in the end, the functionality is more important. > > > Abdussalam Baryun > University of Glamorgan,UK > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Hello folks, > > I have not participated very much in any discussions about > packet-BB other than to encourage header size reduction and > offer a few suggestions about how to achieve it. During that > time, it was claimed that for many networks of interest, the > use of packet-BB would *decrease* header size, perhaps > especially for proactive protocols. This is a question > very suitable for resolution by way of simulation. > > If, as I suspect, packet-BB does (on average) introduce > header enlargement on some networks that cannot afford it, > I would be in favor to introduce the option to run AODV > (or OLSR, for that matter) with some sort of "reduced" > header. This should only be deployed in networks where > otherwise there would be no feasible deployment of an > ad-hoc networking protocol. From that perspective, it's > almost a no brainer -- either deploy the standard stripped- > down version, or deploy something else nonstandard that > looks exactly like the stripped-down version. > > In summary, if there are cases where the [manet] protocols > can only be deployed without packet-BB header overhead, > then I think we should provide a solution for those cases. > > To be clear, I am happy either way, whether or not packet-BB > headers are mandates in all cases. > > Also, 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. > > 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 abdussalambaryun@gmail.com Wed May 2 09:23: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 0AE2011E8081 for ; Wed, 2 May 2012 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_92=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 yhzMOgI+csTr for ; Wed, 2 May 2012 09:23:09 -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 7DC1021F8617 for ; Wed, 2 May 2012 09:23:09 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so570654wgb.13 for ; Wed, 02 May 2012 09:23: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 :cc:content-type; bh=zNU/99k+FvUfsQt2xF1akUK6dhIJPWbRDqde/tF7o08=; b=Fa+shGkaCDBjSAuL8J0gaOSrDGHrsBB33+W+Wli97hLK7hS3YikMC8lQZ7znBAcKI/ vb3V1JQ96Vo6rYkKDPzW6Dasgp5RNurNpdThdulvOoHd1d2mF2ImESeKxh7W3OvxBuL9 HXjaKIWWYzn+b6l4RvwQPjNdw3NGkIRRi0ZTJRJAco3aYM86fLGVYfivwESLkahBGjL6 FIsEAiKMWqlsW2QcILK2r+DPCs0KhAO2CEAJQgrAHl1+8CCmFCHrVWvQfmy4FnYuVstK xhxc02RXQK5M0CPMa5d55zn+flekKRlo3ae8wOrd4vGYv6x/ryEZSJrsAe2eFD9QfTaE BFFw== MIME-Version: 1.0 Received: by 10.180.77.233 with SMTP id v9mr6020547wiw.22.1335975788426; Wed, 02 May 2012 09:23:08 -0700 (PDT) Received: by 10.180.100.10 with HTTP; Wed, 2 May 2012 09:23:08 -0700 (PDT) In-Reply-To: References: Date: Wed, 2 May 2012 18:23:08 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 02 May 2012 16:23:11 -0000 Hi Chris, thanks for your explanation, I missed to understand different standards tracks. But do you think it is a good idea to make all routing protocols use packet-bb, and do we got some results that it is suitable for all reactive, proactive and hybrid. I have results of OLSRv2 as the proactive but no reactive using it nor hybrid or i am wrong, I hope that also protocols that don't use 5444 mention why they don't so we can know, Thanks Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/2/12, Dearlove, Christopher (UK) wrote: > You refer to the experimental stage. But the reactive protocol that the > MANET WG is supposed to be working on is meant to be Standards Track, not > Experimental. AODV (v1) and DSR were supposed to be the experimental stage. > > Updating 5444 and 5498 is really not what we need to do. > > -- > 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 02 May 2012 12:48 > To: Dearlove, Christopher (UK) > Cc: charliep@computer.org; manet > Subject: Re: [manet] A view on packet-BB > > ----------------------! 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 5/2/12, Dearlove, Christopher (UK) > wrote: >> The constraints here are first that RFC 5498 mandates use of RFC 5444 >> (formerly packetbb) for protocols using the manet UDP port or manet IP >> protocol. If anything not using RFC 5444 were to do so that would cause >> interoperability issues. > > Yes, 5498 is for a specific port not for all and not in general, even > though the word general is mentioned in packet-bb 5444, which I think > it is not general format because it specifies some rules that try to > cover all aspects. > >> >> But of course AODVv2 could use another port, for example AODV's port >> (except >> there could be compatibility problems there, but that's not something >> I've >> considered). That comes up against a second issue, that the rough >> consensus >> in the WG was that all Standards Track protocols developed in the WG >> would >> use RFC 5498/5444. Of course could change - unlike RFCs that can't be >> overturned that way - but it hasn't been yet. >> > > Yes, I suggested AODVv2 uses another port, and every protocol that > does not use 5444. The issue is if any protocol does not use 5444 it > MUST have different port than the RFC5498, but we don't say all MANET > use 5444 and then it must use that port of RFC5498. The reason why is > because the 5444 does not state that all MANET routing protocols > SHOULD use packet-bb, if it does state that then we have to update > 5498 to include all ports that do cover all MANET routings including > AODV. > > First, the best development and testing approach in the experimental > wroking in progress stage, that we focus on the protocol's ideas first > and then think if they may join a format, a method, a standard, etc. > Secondly, is to update this general format 5444 to match really all > protocols in their interest as was clarified by the first poster of > the topic. Thirdly update RFC5498 as well. But another complicated > approach is going in the other direction, to start adjusting protocol > ideas to adapt to the message format and port assigned by 5444/5498, > then testing functionality, or testing twice with and without. This > may limit some of the design-protocol-functionality which should be > carefully considered if this second direction approach was choosen. > > Abdussalam Baryun > University of Glamorgan, UK > ++++++++++++++++++++++ >> -- >> 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 >> Abdussalam Baryun >> Sent: 01 May 2012 23:01 >> To: charliep@computer.org >> Cc: manet >> Subject: Re: [manet] A view on packet-BB >> >> >> *** 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. >> >> Hi >> >>>Also, 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. >> I support/prefer the option: AODVv2 without packet-bb first then, to >> submit >> consideration >> another document that uses packet-BB, with different name. To make things >> simple and leaving >> messaging issues in the end, the functionality is more important. >> >> >> Abdussalam Baryun >> University of Glamorgan,UK >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Hello folks, >> >> I have not participated very much in any discussions about >> packet-BB other than to encourage header size reduction and >> offer a few suggestions about how to achieve it. During that >> time, it was claimed that for many networks of interest, the >> use of packet-BB would *decrease* header size, perhaps >> especially for proactive protocols. This is a question >> very suitable for resolution by way of simulation. >> >> If, as I suspect, packet-BB does (on average) introduce >> header enlargement on some networks that cannot afford it, >> I would be in favor to introduce the option to run AODV >> (or OLSR, for that matter) with some sort of "reduced" >> header. This should only be deployed in networks where >> otherwise there would be no feasible deployment of an >> ad-hoc networking protocol. From that perspective, it's >> almost a no brainer -- either deploy the standard stripped- >> down version, or deploy something else nonstandard that >> looks exactly like the stripped-down version. >> >> In summary, if there are cases where the [manet] protocols >> can only be deployed without packet-BB header overhead, >> then I think we should provide a solution for those cases. >> >> To be clear, I am happy either way, whether or not packet-BB >> headers are mandates in all cases. >> >> Also, 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. >> >> 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 Chris.Dearlove@baesystems.com Thu May 3 01: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 CBD3121F8601 for ; Thu, 3 May 2012 01:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 7gkx35tc+F8H for ; Thu, 3 May 2012 01:40:28 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA1121F8603 for ; Thu, 3 May 2012 01:40:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,522,1330905600"; d="scan'208";a="235995203" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 03 May 2012 09:40:16 +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 q438eFuY016972 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 May 2012 09:40:15 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Thu, 3 May 2012 09:40:15 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] A view on packet-BB Thread-Index: AQHNJ+X7nMtvbPBQX0OYzXHJO0L0ZZa2LxGAgAAjSoCAABrw8IAAMd0AgAEfpHA= Date: Thu, 3 May 2012 08:40: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 Subject: Re: [manet] A view on packet-BB 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, 03 May 2012 08:40:29 -0000 Is it a good idea for all current MANET WG protocols to use 5444? I think s= o, because there are some clear gains, especially in flexibility for future= expansion. Is it the best idea? That's still a matter for discussion. I don't think it would be appropriate for a final RFC of any protocol not u= sing 5444 to say why not. It would be necessary in discussion before that. = It could be mentioned in earlier versions of the ID. --=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: 02 May 2012 17:23 To: Dearlove, Christopher (UK) Cc: charliep@computer.org; manet Subject: Re: [manet] A view on packet-BB ----------------------! 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, thanks for your explanation, I missed to understand different standards tracks. But do you think it is a good idea to make all routing protocols use packet-bb, and do we got some results that it is suitable for all reactive, proactive and hybrid. I have results of OLSRv2 as the proactive but no reactive using it nor hybrid or i am wrong, I hope that also protocols that don't use 5444 mention why they don't so we can know, Thanks Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/2/12, Dearlove, Christopher (UK) wrote= : > You refer to the experimental stage. But the reactive protocol that the > MANET WG is supposed to be working on is meant to be Standards Track, not > Experimental. AODV (v1) and DSR were supposed to be the experimental stag= e. > > Updating 5444 and 5498 is really not what we need to do. > > -- > 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 02 May 2012 12:48 > To: Dearlove, Christopher (UK) > Cc: charliep@computer.org; manet > Subject: Re: [manet] A view on packet-BB > > ----------------------! 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 5/2/12, Dearlove, Christopher (UK) > wrote: >> The constraints here are first that RFC 5498 mandates use of RFC 5444 >> (formerly packetbb) for protocols using the manet UDP port or manet IP >> protocol. If anything not using RFC 5444 were to do so that would cause >> interoperability issues. > > Yes, 5498 is for a specific port not for all and not in general, even > though the word general is mentioned in packet-bb 5444, which I think > it is not general format because it specifies some rules that try to > cover all aspects. > >> >> But of course AODVv2 could use another port, for example AODV's port >> (except >> there could be compatibility problems there, but that's not something >> I've >> considered). That comes up against a second issue, that the rough >> consensus >> in the WG was that all Standards Track protocols developed in the WG >> would >> use RFC 5498/5444. Of course could change - unlike RFCs that can't be >> overturned that way - but it hasn't been yet. >> > > Yes, I suggested AODVv2 uses another port, and every protocol that > does not use 5444. The issue is if any protocol does not use 5444 it > MUST have different port than the RFC5498, but we don't say all MANET > use 5444 and then it must use that port of RFC5498. The reason why is > because the 5444 does not state that all MANET routing protocols > SHOULD use packet-bb, if it does state that then we have to update > 5498 to include all ports that do cover all MANET routings including > AODV. > > First, the best development and testing approach in the experimental > wroking in progress stage, that we focus on the protocol's ideas first > and then think if they may join a format, a method, a standard, etc. > Secondly, is to update this general format 5444 to match really all > protocols in their interest as was clarified by the first poster of > the topic. Thirdly update RFC5498 as well. But another complicated > approach is going in the other direction, to start adjusting protocol > ideas to adapt to the message format and port assigned by 5444/5498, > then testing functionality, or testing twice with and without. This > may limit some of the design-protocol-functionality which should be > carefully considered if this second direction approach was choosen. > > Abdussalam Baryun > University of Glamorgan, UK > ++++++++++++++++++++++ >> -- >> 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 O= f >> Abdussalam Baryun >> Sent: 01 May 2012 23:01 >> To: charliep@computer.org >> Cc: manet >> Subject: Re: [manet] A view on packet-BB >> >> >> *** 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. >> >> Hi >> >>>Also, 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. >> I support/prefer the option: AODVv2 without packet-bb first then, to >> submit >> consideration >> another document that uses packet-BB, with different name. To make thing= s >> simple and leaving >> messaging issues in the end, the functionality is more important. >> >> >> Abdussalam Baryun >> University of Glamorgan,UK >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Hello folks, >> >> I have not participated very much in any discussions about >> packet-BB other than to encourage header size reduction and >> offer a few suggestions about how to achieve it. During that >> time, it was claimed that for many networks of interest, the >> use of packet-BB would *decrease* header size, perhaps >> especially for proactive protocols. This is a question >> very suitable for resolution by way of simulation. >> >> If, as I suspect, packet-BB does (on average) introduce >> header enlargement on some networks that cannot afford it, >> I would be in favor to introduce the option to run AODV >> (or OLSR, for that matter) with some sort of "reduced" >> header. This should only be deployed in networks where >> otherwise there would be no feasible deployment of an >> ad-hoc networking protocol. From that perspective, it's >> almost a no brainer -- either deploy the standard stripped- >> down version, or deploy something else nonstandard that >> looks exactly like the stripped-down version. >> >> In summary, if there are cases where the [manet] protocols >> can only be deployed without packet-BB header overhead, >> then I think we should provide a solution for those cases. >> >> To be clear, I am happy either way, whether or not packet-BB >> headers are mandates in all cases. >> >> Also, 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. >> >> 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 abdussalambaryun@gmail.com Thu May 3 13:15: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 3947F21F8691 for ; Thu, 3 May 2012 13:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=-1.334, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_28=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=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 ZHX-ZB2lmTUb for ; Thu, 3 May 2012 13:15:50 -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 93E1B21F868A for ; Thu, 3 May 2012 13:15:50 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1898222vbb.31 for ; Thu, 03 May 2012 13:15:50 -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=8uOvCIYwJBbsc/LRLhT2/2TUg1ozMx593jzEnlaUBio=; b=w8TvZlofdNArxfYItA3z75mlHhowYceB/do/87Kd8UUyeNcWxXvC6eTOYi70jWHwv6 zIQdNwxW3tkEGASDRqb/H10AkkUJDovEXE79y9Z3qmkLBtuSy4QRC6NrqLxheB22E2/k FfQrtV7mADm/Ib6AED0bBvAudsBwpmU7hL4F+QFc+NSq3O3UN0SebX/aGSt6gCH2dLWQ MZ4cC1nLY7/55zOxjefTakgKJIFmkB2IubliI5pm47Z6Nspa4ZA5DAIIxffc/R7YEDDo 6usUhW6vizhsrx+TIrwcFjki7ronG2fnU1fjsTVx1qPnD7gMf4RO9swR+hYCjfG1cYYW 2JXA== MIME-Version: 1.0 Received: by 10.220.227.70 with SMTP id iz6mr2145243vcb.29.1336076149559; Thu, 03 May 2012 13:15:49 -0700 (PDT) Received: by 10.220.116.19 with HTTP; Thu, 3 May 2012 13:15:49 -0700 (PDT) Date: Thu, 3 May 2012 22:15:49 +0200 Message-ID: From: Abdussalam Baryun To: manet , "ian.chakeres" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [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: Thu, 03 May 2012 20:15:52 -0000 Hi Ian Chakeres, i have completed my work for commenting on AODVv2, I hope you can answer my questions. thanking you, Abdussalam Baryun (AB) 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 AB>Overall> The dymo-22 draft is well organized and represents the protocol operations, operation location, and messages (when initiating its process, its conditions, and how processed) in section-by-section basis. However, it was difficult to read because I think the concept of version 2 and because the introduction and presentation was not representing the new issues added to the old version and even not seen the DSR-idea use in this version as mentioned.The draft lacks explanations of the relationship between AODV and AODVv2, because both protocols carry the similar name it is preferable to give more details to avoid misunderstanding. The similar name may indicate that both protocols can work together, or that AODVv2 router understands correctly AODV router, or they may be integrated in some network solutions. AB> Suggesting> that section 3 put before section 2 to clarify the definition of some items of the protocol introduction presentation. AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July 26 2010, sub:dymo-21: C2B>The nets do not have to be mobile, and DYMO may be applicable in low po= wer C2B>lossy sensor networks. Without lots of details about a particular netwo= rk C2B>deployment and application traffic, it is very hard to make C2B>generalizations in MANET. AB> suggest> Preferable to be mentioned in overview this discussion explana= tion. AB> suggest> If this protocol is able to be used in LLN nets as well as MANET, it is important to clarify it (LLN was only mentioned in acknowledgement section) and its relation with LLN information exchange requirements, because the protocol applicable to other nodes (e.g. LLN node) including MANET nodes. AB>thought and questions>The word =93node=94 was used without indicating that it is MANET node, which its node may be a router. In addition, Originating Node (OrigNode) in the terminology is not defined to be a MANET node (e.g. if we compare with AODV RFC3561). So could it be a MANET node or it could not? This makes the network architecture used not clear. Are all nodes in this network architecture, MANET nodes? If all messages/packets are MANET-units as RFC5444 therefore, all nodes are MANET. Moreover, the draft has some indirect indications that there MAY be more than one routing protocol (other than AODVv2) per net-interface in some nodes which is preferable to be mentioned. AB>thought and questions>Is the protocol a specific purpose or general purpose or both, this should be specified. All MANET routing protocols need the purpose statement that specifies clearly its location in practical situation. AB>thought and questions>The draft has not categorized the network=92s devices/nodes (using only the word routing instead of nodes). The draft does not make explaination of the protocol=92s interaction with ad hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router). AB> The draft had some paragraph that not followed the RFC2119, but some amended as (there may be other, that needs to be amended): +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-10>required> A RteMsg REQUIRES the following information: +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-25>required> If no UnreachableNode addresses remain in the RERR, no other handling is REQUIRED and the RERR is discarded. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-27>required> In table title: =93REQUIRED Administratively Configured Parameters=94 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to LL-MANET-Routers on all their AODVv2 interfaces. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>page-32>must> Note that if multicast is used, any confidentiality and integrity algorithms used MUST permit multiple receivers to handle the message. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #Abstract >The Dynamic MANET On-demand (AODVv2) routing protocol is intended for >use by mobile routers in wireless, multihop networks. AODVv2 >determines unicast routes among AODVv2 routers within the network in >an on-demand fashion, offering on-demand convergence in dynamic >topologies. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest change> =93The Dynamic MANET On-demand (AODVv2)=94, to be changed to =93The Dynamic MANET On-demand Distance Vector (D-AODVv2)=94, because the term =93AODVv2=94 has letter =93A=94 which is presented in the second letter of the abbreviation word MANET, but AODVv2 has the D and V letters which is the abbreviation of Distance Vector. Regarding the word Dynamic an abbriviation =93D=94 preferable to be added. The =93v2=94 m= ay be left to indicate its origin protocol source-idea RFC3561 AODV, however, this can be explained in the overview. AB>general comment> AODVv2 is a routing protocol that determines unicast routes within the mobile routers. AB> due to mentioning the protocol route-determination and on-demand, It is useful to specify in abstract, to mention the protocol special method/technique (e.g. its name or what it uses) used for this determination and/or the convergence (i.e. to differentiate it from other reactive protocols for summary or future purposes). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #In (Content) >4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> Routing Messages. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #In section (1. Overview) >Route discovery is performed when an AODVv2 router receives a packet from = a >node under its responsibility to a destination for which it does not have = a >route. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> which kind of node under responsibility of another? An ad hoc node responsible for another ad hoc node, IMO may mean that the node gets its routing information from another! (dependent-node). AB>Statements seen after, in section-2, page-5> =93other nodes, attached via participating or non-participating interfaces=94. This was not described well, and not sure if it has relation with the shared address among routers mentioned later in section-2, page-5. AB> does it mean that it only performs discovery when . . . , as if the router itself cannot be a source of demand. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >During route discovery, the originator=92s AODVv2 router initiates >dissemination of a Route Request (RREQ) throughout the network to >find a route to a particular destination, via the AODVv2 router >responsible for this destination. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not clear> originator; what did this node originate? Do we mean the router=92s responsible for one, and it request for a connection to destination (as the responsibility is at destination or at source side. AB>suggest adding words> =93Route Request message (RREQ)=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >During this hop-by-hop dissemination process, each intermediate AODVv2 >router records a route to the originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> During the hop-by-hop dissemination process, each intermediate AODVv2 router receiving the RREQ message records a route to the originator. AB> the target also should records a route to the originator.. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. >Sequence numbers enable AODVv2 routers to determine the temporal >order of AODVv2 route discovery messages, thereby avoiding use of >stale routing information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> =93AODVv2 uses routers=92 sequence numbers=94. Or AB>suggest amendments> =93AODVv2 uses routers=92 AODVv2 sequence numbers (S= eqNum)=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #In section (2. Applicability Statement) >AODVv2 handles a wide variety of mobility patterns by dynamically >determining routes on-demand. AODVv2 also handles a wide variety of traffi= c >patterns. In networks with a large number of routers, AODVv2 is best suite= d >for sparse traffic scenarios where routers forward packets to only a small >portion of the other AODVv2 routers, due to the on-demand nature of route >discovery and route maintenance. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> the word =93other=94 confused, one side large and another side small of MANET network. AB>maybe because> where the large number (portion) of AODVv2 routers forward packets to other small portion (number) of AODVv2 routers, AB>idea not clear> =93due to the on-demand nature of route discovery and route maintenance=94, what is the problem with both on-demand(discovery) or reactive(maintenance) nature? Do both create the different portion sides of routes? AB>discussion> Does the reason of the protocol suitability include traffic pattern and network density? Even though the paragraph claims AODVv2 handles them as mentioned. In the paragraph there is no clear relation between traffic and on-demand nature, even though on-demand is traffic oriented, so it seems positive to use an on-demand (the negative is not clear). Also for the route maintenance is related with route changes, which is positive. It is preferable to change the paragraph to describe both ideas; what AODVv2 cannot handle more suitable, with mentioning what it is best suitable. However, mentioning the reactive nature suitability will relate/reflect to all MANET Reactive Protocols not just AODVv2. This can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >AODVv2 is applicable to memory constrained devices, since little >routing state is maintained in each AODVv2 router. Only routing >information related to active sources and destinations is maintained, >in contrast to most proactive routing protocols that require routing >information to all routers within the routing region be maintained. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> =93information related routes to active sources and to destinations is maintained=94. AB>suggest replace> =93proactive routing protocols=94 with =93MANET Proactive Routing protocols (MPRs)=94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >At any time within an AODVv2 routing region, only one AODVv2 router >SHOULD be responsible for, i.e. "own", any particular address. >Coordination among multiple AODVv2 routers to distribute routing >information correctly for a shared address (i.e. an address that is >advertised and can be reached via multiple AODVv2 routers) is not >described in this document. The router behavior for shifting >responsibility for an address from one AODVv2 router to another is >mentioned in Appendix C. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> At all times within an AODVv2 routing region, only one AODVv2 router SHOULD be responsible for (i.e. the routing-address region owner) any particular address. The coordination among multiple AODVv2 routers to distribute routing information correctly for a shared address (i.e. an address that is advertised and can be reached via multiple AODVv2 routers) is not described in this document. The AODVv2 router operation of shifting responsibility for an address from one AODVv2 router to another is mentioned in Appendix C. AB>not sure question> Is router behavior responsible for the address or for the address assignment? Not sure. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>RFC2119> =93Otherwise, persistent packet loss MAY occur=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >AODVv2 only utilizes bidirectional links. In the case of possible >unidirectional links, either blacklists (see Section 7.2) or other >means (e.g. adjacency establishment with only neighboring routers >that have bidirectional communication as indicated by NHDP >[I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality >is recommended. Otherwise, persistent packet loss may occur. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not clear> How does it not utilize unidirectional links, while mentioned, or who does this blacklisting, is it another protocol? Not sure why mention in this protocol draft while it is not clear what operates the blacklisting. This was not clear even in section 7.2. Usually some routing protocols operate the blacklisting, so does this mean that any/some AODVv2 router(s) in such situation may use blacklisting which does not affect the network=92s routings. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + >The routing algorithm in AODVv2 may be operated at layers other than >the network layer, using layer-appropriate addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be operated at another layer than the network layer, using the layer=92s appropriate addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + #In section (3. Terminology) >AODVv2 Sequence Number (SeqNum) >An AODVv2 Sequence Number is maintained by each AODVv2 router >process. This sequence number is used by other AODVv2 routers to >identify the temporal order of routing information generated and >ensure loop-free routes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> An AODVv2 Sequence Number is maintained by each AODVv2 router process. The AODVv2 router=92s sequence number is used by other AODVv2 routers to identify the temporal order of routing information generated and ensure loop-free routes. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Originating Node (OrigNode) >The originating node is the source, its AODVv2 router creates a >AODVv2 control message on its behalf in an effort to disseminate >some routing information. The originating node is also referred >to as a particular message=92s originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> The originating node is the data source node. Its AODVv2 router or responsible AODVv2 router creates a AODVv2 control message on its behalf in an effort to disseminate some routing information. The originating node is also referred to as a particular message=92s originator. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >This Node (ThisNode) >ThisNode corresponds to the AODVv2 router process currently >performing a calculation or attending to a message. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>confused!> the term ThisNode is not indicating to its definition (which makes the draft reading misunderstanding), maybe =93RouterProcess=94 is more closer and clear. The word =93node=94 is used i= n draft as a router is responsible for, therefore, the node may not perform route process, so it the term =93ThisNode=94 may confuse while reading elsewhere. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Type-Length-Value structure (TLV) >A generic way to represent information, please see [RFC5444] for >additional information. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>idea not clear> which kind of represent-information, does it only include routing or discovery information or other? Maybe say =93routing information=94. AB> add> the explanation of such types of information as: A generic way to represent information (add suitable types: routing, control, monitoring, Adjacency, etc.), AB>question> does the AODVv2 use RFC5444 if not, it will confuse. Refering to 5444 for more information may mean that 5444 is used in AODVv2 format. AB> suggested amendment> A generic way to represent information and as TLV is defined in RFC5444. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Unreachable Node (UnreachableNode) >An UnreachableNode is a node for which a forwarding route is unknown. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest amendments> Unreachable Node (UnreachableNode) An UnreachableNode is a node for which its forwarding route is unknown. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In addition to using this IP protocol number, AODVv2 may use the UDP port 269 (manet) [RFC5498] in conjunction with the IP Protocol Number 17 (UDP). AB> if it may use the 269 port I think only if it uses 5444. I don=92t see statement that how will AODVv2 use 5444 info-format, and may not. #In section 4.2.1. Generalized Packet and Message Structure: >For interoperability with other AODVv2 routers, all AODVv2 messages >specified in this document SHOULD sent using the IP protocol number >(138) reserved for manet protocols [RFC5498]; or the UDP destination >port (269) reserved for manet protocols [RFC5498] and IP protocol >number for UDP. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>suggest> delete the =93with other=94, it seems like they are different routers, we may replace with =93among all=94. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >A packet is made up of messages. A message is made up of a >message header, message TLV block, and zero or more address blocks. >Each of the address blocks may also have an associated address TLV >block. AB> is it an IP packet made up of messages or it is another type of packets? The packet should be clarified. Maybe it is =935444 packet=94 or we have a name for it as MANET-Packet. Are the messages AODV messages or UDP encapsulating AODV messages? The answer is not clear her neither in RFC5444 that this document refers to. Messages can be AODVv2 messages, but what about addresses. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >Most AODVv2 messages are sent with the IP destination address set to >the link-local multicast address LL-MANET-Routers [RFC5498] unless >otherwise stated. Therefore, all AODVv2 routers SHOULD subscribe to >LL-MANET-Routers [RFC5498] for receiving control packets. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>not sure> what is control packet, is it routing control? Please amend. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ #In section 5.3.3 >For each of the additional addresses considered, ThisNode first >checks the that the address is a multihop-capable unicast address. >If the address is not a unicast address, the address and all related >info= rmation MUST be removed. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ AB>delete and add> delete =93the=94 in =93checks the that=94 Add =93then=94 before =93address and all related=94. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # section 6 >If, RESPONSIBLE_ADDRESSES is zero, this AODVv2 router is only responsible = >for its own addresses. AB> does it have a list of its addresses that are its responsibility, and does it have a list of its addresses that are not its responsibility (i.e. possibility some its addresses is other router responsibility). From abdussalambaryun@gmail.com Fri May 4 03:00: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 B8E0C21F870A for ; Fri, 4 May 2012 03:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 AgBOLytk6a8i for ; Fri, 4 May 2012 03:00: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 1750321F8709 for ; Fri, 4 May 2012 03:00:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2278932vbb.31 for ; Fri, 04 May 2012 03:00: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; bh=VfLflZLfCNWN6kcYie7hDjZcNK1N2/6W/DchuV96zcM=; b=sylTgFe0qh5U10iUzx9ysee3E8o+SshrD0AG1hk62lgPWEcK17vd3bwtqfVRiup8w8 936MopoZf6HiRAr8wbb659L5ZZf6qFDUb/dSJPlFBFHUgEpBdx1OW2YJaoDJtjEUeoty 4cUp6DaY//BB152R0H8RqDqKcIbR56tuFH3ejMVWTC1AFfUaeRPLs726i//0SayVkmPF sViKcitcSTPfyJUYxucpOLaChMwXvrxqd4nZ6Yb1FjnomQ667wBPfEgyclfsDvBqFlVJ rCQ6zMLO+ojMPcLKmM+InYhVy7n4wg1TB9C2QXg1hufHgm2aZdwC2sYfZXdp2LsBerKe u44g== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr3450761vcw.20.1336125643635; Fri, 04 May 2012 03:00:43 -0700 (PDT) Received: by 10.220.116.19 with HTTP; Fri, 4 May 2012 03:00:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 May 2012 12:00:43 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 04 May 2012 10:00:44 -0000 Hi Chris, The packet of RFC 5444 do I call it RFC5444-Packet, or which name do you use/prefer, is it Packet-BB, MANET-Packet, General-MANET-Packet? and Is it specified the name for the packet in RFC5444 or other RFC, to distiguish with other packets of other IETF groups? Thanking you, Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++ From henning.rogge@fkie.fraunhofer.de Fri May 4 05:52: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 EDBC021F8618 for ; Fri, 4 May 2012 05:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.706 X-Spam-Level: X-Spam-Status: No, score=-4.706 tagged_above=-999 required=5 tests=[AWL=1.543, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Byh2V3svDVT6 for ; Fri, 4 May 2012 05:52:54 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id CDE1C21F8615 for ; Fri, 4 May 2012 05:52: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 1SQI0B-00045T-Go for manet@ietf.org; Fri, 04 May 2012 14:52: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 1SQI0B-0005QI-EE for manet@ietf.org; Fri, 04 May 2012 14:52: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); Fri, 4 May 2012 14:52:51 +0200 Received: from MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.56) by MAILSERV2ACAS.lorien.fkie.fgan.de (128.7.96.54) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 May 2012 14:52:51 +0200 Received: from [128.7.5.36] (128.7.5.36) by MAILSERV2BCAS.lorien.fkie.fgan.de (128.7.96.58) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 4 May 2012 14:52:50 +0200 Message-ID: <4FA3D121.6080503@fkie.fraunhofer.de> Date: Fri, 4 May 2012 14:52:49 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040904070708050804000706" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 04 May 2012 12:52:51.0218 (UTC) FILETIME=[D09AD720:01CD29F4] X-Virus-Scanned: yes (ClamAV 0.97.3/14874/Fri May 4 03:33:38 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: dad17b0fa7a976ea34f8545b3e71195d Subject: [manet] Update on my DLEP experiments 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, 04 May 2012 12:52:55 -0000 --------------ms040904070708050804000706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I have continued some experiments with DLEP and would like to share the=20 result. We had some discussions in the past how DLEP should be used (independent = of the packet format). I worked on three different use cases: a) Radio and router are within (linklocal-) multicast distance. Radio=20 initiates the connection with 'discovery' messages, router responds with = 'connect' message, radio sends metric/neighbor information. b) Radio pushs metric/neighbor information, router listens passively. c) Router is out of multicast distance of radio. Router sends connect=20 request, radio responds with discovery and metric/neighbor information. (the third case is important for the CONFINE project I am working in,=20 because we have virtualized containers that are not directly bridged to=20 the control interface towards the DLEP-capable radio). I managed to implement all three use-cases with two DLEP orders=20 ('interface discovery' and 'connect router') by adding one additional=20 message TLV to the 'connect router' order to signal that the DLEP radio=20 should respond to it with unicast, not multicast. The rest is just done=20 by some configuration parameters. I think this shows we will be able to satisfy all mentioned use cases=20 without adding a lot of complexity to the protocol. 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 --------------ms040904070708050804000706 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 Fw0xMjA1MDQxMjUyNDlaMCMGCSqGSIb3DQEJBDEWBBTkkzQaPyX8AFhD+mQWKJcfNZj5ejBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQAmFNEB9OWY7Drbbxx179lWrASolHh3FRQexR48TSVN6Ki4xB8OWbp/6wKTn08e QJY7VTa5NIHtP53IaGY3DDcZcbMIZqFtrOhBQuuRcPSHGvuBhIVGUHYhMlboijCcwBm9rHa5 HFr0/+zndhltUG/ftV9WR8BCN97ypGH5i+ieq9e+hZMQK1Vpyis0LZS2P5pC5/AN8uHCtich bJdqO5A2MsUqH6AeuE9IRRsW9aBkMiWv7XTI3ZIU5eUXIBo68PD/vcUnXv74I2dKfzUXV80P jFFrcaOt31QuGf8lCZap8lamRVgv99VpCjiLUx6VrQzni6fFar27Ya/X1Qn8Ra2tAAAAAAAA --------------ms040904070708050804000706-- From internet-drafts@ietf.org Sun May 6 07:29: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 ABBE521F84D9; Sun, 6 May 2012 07:29:16 -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 JLfaTgGmhTNZ; Sun, 6 May 2012 07:29:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4961321F84CF; Sun, 6 May 2012 07:29:16 -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: <20120506142916.9270.40465.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2012 07:29:16 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-mib-13.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: Sun, 06 May 2012 14:29:16 -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-13.txt Pages : 63 Date : 2012-05-06 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-13.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-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ From rgcole01@comcast.net Sun May 6 07:41: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 8D23921F8493 for ; Sun, 6 May 2012 07:41:16 -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 dLM+9uWHBAnc for ; Sun, 6 May 2012 07:41:14 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 64A1721F8478 for ; Sun, 6 May 2012 07:41:14 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id 6egz1j0020EZKEL5DehEPL; Sun, 06 May 2012 14:41:14 +0000 Received: from [10.0.1.195] ([68.55.94.27]) by omta01.westchester.pa.mail.comcast.net with comcast id 6ehE1j0080bRkG43MehExu; Sun, 06 May 2012 14:41:14 +0000 From: Robert G Cole To: jmh@joelhalpern.com In-Reply-To: References: <4F7E279C.3030707@nostrum.com> <4F7F12CA.9010009@joelhalpern.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 May 2012 10:41:11 -0400 Message-ID: <1336315271.2040.6.camel@chapman> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: gen-art@ietf.org, manet@ietf.org, "A. Jean Mahoney" , sratliff@cisco.com Subject: Re: [manet] Fwd: [Gen-art] review: draft-ietf-manet-nhdp-mib-12 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, 06 May 2012 14:41:16 -0000 Joel, Ulrich and I have updated the NHDP-MIB module to address your questions and suggestions. We hope these changes are satisfactory? Thanks, Bob and Ulrich ----- Original Message ----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Sunday, May 06, 2012 02:29 PM To: manet-chairs@tools.ietf.org ; draft-ietf-manet-nhdp-mib@tools.ietf.org ; adrian@olddog.co.uk Subject: New Version Notification - draft-ietf-manet-nhdp-mib-13.txt New version (-13) has been submitted for draft-ietf-manet-nhdp-mib-13.txt: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-mib-13.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-mib/ Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-manet-nhdp-mib-13 IETF Secretariat. On Mon, 2012-04-23 at 11:14 -0700, Ulrich Herberg wrote: > Dear Joel, > > thank you very much for your review. Find our answers below, and > please tell us if they address your comments. > > ---------- Forwarded message ---------- > From: Joel M. Halpern > Date: Fri, Apr 6, 2012 at 8:59 AM > Subject: [manet] [Gen-art] review: draft-ietf-manet-nhdp-mib-12 > To: gen-art@ietf.org > Cc: manet@ietf.org, "A. Jean Mahoney" , > sratliff@cisco.com > > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-manet-nhdp-mib-12 > Definition of Managed Objects for the > Neighborhood Discovery Protocol > Reviewer: Joel M. Halpern > Review Date: 6-April-2012 > IETF LC End Date: 16-April-2012 > IESG Telechat date: (if known) > > Summary: This document is almost ready for publication as a Proposed > Standard. > > > That's good :-) > > > Major issues: > Section 5.1.3.1 on Ignoring Initial Activity is trying to do a very > reasonable thing, namely suppress notifications for activity which is > expected. The text references RFC 4750 as precedent. RFC 4750 is > clear that the suppress window is tied to specific events (interface > up and election as a DR.) Section 5.1.3.1 does not specify which > condition(s) start(s) the suppress window. If, as seems likely, it is > Interface Up which starts the window, please state that explicitly in > the text. > > > > [To Bob: I am not so sure if the below is correct. Can you check?] > Yes, we agree. How about adding the following sentence at the end of > the paragraph of 5.1.3.1: > "The suppression window for notifications is started by Interface Up." > > > In section 5.4, in addition to describing objects which are defined > in the MIB, the text describes, under the heading "The following > objects return statistics related to HELLO messages:", a number of > what it refers to as "Derived Objects". These do not appear to be > actual elements of the MIB. They appear rather to be descriptions of > calculations which the manager can perform using the information from > the MIB. It is not at all clear why they are here. If I am > understanding their role properly, and if they belong in this > document, they belong in some other section, as they are NOT objects > which return statistics related to HELLO messages. They appear not to > be returned by the managed device at all. > > > [To Bob: It is true that we actually don't use the derived objects. I > am not quite sure what to do about it. Shall we remove the derived > objects? > > > > Minor issues: > I can not find the object that corresponds to the setting for > Ignoring the Initial Activity. I presume this is my error. The > document would be helped if the object were named in section 5.1.3.1. > > > [To Bob: Do we have such object? I am not sure... does OSPF-MIB have > one?] > > > I believe section 5.1.3.2 on Throttling Traps is intended to refer > to the StateChange Threshold and StateChangeWindow objects. It would > be very helpful if these were actually named in section 5.1.3.2. > > > How about adding the following sentence to 5.1.3.2: > The following objects are used to define the thresholds and time > windows: nhdpNbrStateChangeThreshold, > nhdpNbrStateChangeWindow, nhdp2HopNbrStateChangeThreshold, > nhdp2HopNbrStateChangeWindow, nhdpIfRxBadPacketThreshold, > nhdpIfRxBadPacketWindow. > > > > Most MIBs I review have a description of the tables they contain, > how the tables relate to each other, and how they are indexed, in the > front matter that is roughly equivalent to section 5.2, 5.3, and 5.4. > As I am not a MIB Doctor, I do not know if that is formally required, > but I find it very helpful, and am surprised not to see it here. > > > [To Bob: I am not sure if we need this. I suggest to refer to the MIB > Doctor review; if they request it, it should be easy to copy the text] > > > In looking at the fields in the NhdpInterfaceEntry, some of the > field definitions include some of the constraints from RFC 6130 > section 5 in their DESCRIPTION clauses. Some do not. (For exampple, > REFRESH_INTERVAL >= HELLO_INTERVAL is captured in > nhdbpRefreshInterval, but not in nhdpHelloInterval. The requirement > that nhdpHelloInterval be greater than 0 is not captured anywhere. > Neither is H_HOLD_TIME >= REFRESH_INTERVAL captured.) Some elements > have a statement that the object is persistent, while others do not, > but these do not seem to correspond to a difference in RFC 6130. It > is possible that there is a good reason for this apparent variation. > Is there? > > > [To Bob: That's true. I can go through all constraints from NHDP and > add them to the MIB.] > > > Particularly for top-level objects such as nhdpNHoldTime and > NhdpIHoldTime I would really like to see a better description than > just this is object from section 5 of RFC 6130. Someone who > is using the MIB, who is looking at the description clause for > assistance, really needs something more than the name of the field in > the MIB. (I think better descriptions would be a good idea through > much of the MIB.) > > > [To Bob: I can look at the descriptions and copy some more text from > NHDP. However, I would like to avoid copying all NHDP into the MIB.] > > > Nits/editorial comments: > The tracker claims this is "In WG Last Call (manet), but also seems > to indicate that it is in IETF Last Call. Are the two happening at > the same time? > > > We actually don't know, and will ask the chairs about that. > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > From henning.rogge@fkie.fraunhofer.de Thu May 10 00:00: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 A477021F85B4 for ; Thu, 10 May 2012 00:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[AWL=1.509, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 wCNG9-On9KZx for ; Thu, 10 May 2012 00:00:45 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 813CA21F852E for ; Thu, 10 May 2012 00:00:45 -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 1SSNMh-0004iv-T2 for manet@ietf.org; Thu, 10 May 2012 09:00:43 +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 1SSNMh-0002Tu-Qk for manet@ietf.org; Thu, 10 May 2012 09:00:43 +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); Thu, 10 May 2012 09:00:43 +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; Thu, 10 May 2012 09:00:43 +0200 Message-ID: <4FAB679A.1060205@fkie.fraunhofer.de> Date: Thu, 10 May 2012 09:00:42 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: "manet@ietf.org" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050704090704030607020805" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 May 2012 07:00:43.0624 (UTC) FILETIME=[9E0E5680:01CD2E7A] X-Virus-Scanned: yes (ClamAV 0.97.3/14906/Thu May 10 05:32:10 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: 1835fb2b1f494bb0880b86f87a4ad6ad Subject: [manet] Question about OLSRv2 link metric implementation 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, 10 May 2012 07:00:46 -0000 --------------ms050704090704030607020805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I am working on reviving my Freifunk-ETX draft again and thinking about=20 to split it into two different drafts. One that discusses the general=20 aspects of an ETX metric implementation. Most times ETX metrics are described as a symmetric metric, where the=20 link cost does include both directions of the link, and I think there=20 are several link layer designs where combining the packet loss in both=20 directions makes sense (not necessarily with the same weight). For this both sides of the Metric implementation have to communicate=20 with each other outside the normal metric TLV described in the OLSRv2-dra= ft. Do you think it makes sense to ask IANA to allocate a generic "Private=20 Link Metric Data" TVL, that will use the same extension types as the=20 metric TLV in OLSRv2 and allows a metric implementation to exchange data = with the other side of the link? Allocating an "ETX specific TLV" sounds even worse. 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 --------------ms050704090704030607020805 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 Fw0xMjA1MTAwNzAwNDJaMCMGCSqGSIb3DQEJBDEWBBQa07D4oCDvLdXkcBrIIIlHXx7nFzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQB0C7gKJVgpGhCtuNl86tN6k5njgR15awXsSMw33bcLt/9V0fLO3m6zZLuTJzSV /61Cy28La/JWJ4xlOOlpqiJo2huoMqEYoNcJdh7W+Me/47sXTHEAZeO9GzQT0v/dCpL8NEBE beRNNk5A34ow5zMAsZ9I9KOaBtu2HPI8VVdNPQ3hsHLIZKoE4u3YKuF77tBxd4wPnzRr8lv7 Nw6KcSiyjZuhXf0cpbWtaXTReU0ROeJlwbnz3Y1BkDKRdjwLCx1irQUzxugKXwBYDM9uWUCK dMS7hxTU8xHSMbLeItXlG9U4I66M5xQXJABozzr208ZZODJVIUU7glwgyvR0h5KhAAAAAAAA --------------ms050704090704030607020805-- From Chris.Dearlove@baesystems.com Thu May 10 02:08: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 AF15721F85FC for ; Thu, 10 May 2012 02:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.54 X-Spam-Level: X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 5-Y5nazg+a5h for ; Thu, 10 May 2012 02:08:21 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4EA21F85F8 for ; Thu, 10 May 2012 02:08:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="237643610" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 10 May 2012 10:08:19 +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 q4A98JZE023078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 May 2012 10:08:19 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Thu, 10 May 2012 10:08:19 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Question about OLSRv2 link metric implementation Thread-Index: AQHNLnqnrG52V+xcUEuAGS8hv5lf6JbCuruQ Date: Thu, 10 May 2012 09:08:18 +0000 Message-ID: References: <4FAB679A.1060205@fkie.fraunhofer.de> In-Reply-To: <4FAB679A.1060205@fkie.fraunhofer.de> 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] Question about OLSRv2 link metric implementation 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, 10 May 2012 09:08:22 -0000 I'm not a great fan of either. Allocating a whole range of type extensions = may include type extensions with no need to communicate. And if link metric= type X needs to communicate, it won't necessarily send link metrics as its= supplementary information. But as you say, an ETX specific TLV isn't nice = either. I realise that anyone who says "I don't like either" should make a third pr= oposal. Right now I don't have one, though I will think about it. This is r= eally to say if anyone has any alternative suggestions, they would be welco= me. --=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: 10 May 2012 08:01 To: manet@ietf.org Subject: [manet] Question about OLSRv2 link metric implementation Hi, I am working on reviving my Freifunk-ETX draft again and thinking about=20 to split it into two different drafts. One that discusses the general=20 aspects of an ETX metric implementation. Most times ETX metrics are described as a symmetric metric, where the=20 link cost does include both directions of the link, and I think there=20 are several link layer designs where combining the packet loss in both=20 directions makes sense (not necessarily with the same weight). For this both sides of the Metric implementation have to communicate=20 with each other outside the normal metric TLV described in the OLSRv2-draft= . Do you think it makes sense to ask IANA to allocate a generic "Private=20 Link Metric Data" TVL, that will use the same extension types as the=20 metric TLV in OLSRv2 and allows a metric implementation to exchange data=20 with the other side of the link? Allocating an "ETX specific TLV" sounds even worse. 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 ******************************************************************** 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 henning.rogge@fkie.fraunhofer.de Thu May 10 02:22: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 3B13221F85FC for ; Thu, 10 May 2012 02:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.773 X-Spam-Level: X-Spam-Status: No, score=-4.773 tagged_above=-999 required=5 tests=[AWL=1.476, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rOHpsb-s1G4Z for ; Thu, 10 May 2012 02:22:02 -0700 (PDT) Received: from a.mx.fkie.fraunhofer.de (mailguard.fkie.fraunhofer.de [128.7.3.5]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7421F85ED for ; Thu, 10 May 2012 02:21:55 -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 1SSPZK-0005FB-Ly; Thu, 10 May 2012 11:21:54 +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 1SSPZK-0008Pr-JI; Thu, 10 May 2012 11:21:54 +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); Thu, 10 May 2012 11:21:54 +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; Thu, 10 May 2012 11:21:54 +0200 Message-ID: <4FAB88B1.9070008@fkie.fraunhofer.de> Date: Thu, 10 May 2012 11:21:53 +0200 From: Henning Rogge User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120424 Thunderbird/12.0 MIME-Version: 1.0 To: "manet@ietf.org" References: <4FAB679A.1060205@fkie.fraunhofer.de> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040906090100020000030204" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 10 May 2012 09:21:54.0447 (UTC) FILETIME=[570F59F0:01CD2E8E] X-Virus-Scanned: yes (ClamAV 0.97.3/14906/Thu May 10 05:32:10 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: ff5b53f4d81aecd7a6b2d230e03a1f9e Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] Question about OLSRv2 link metric implementation 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, 10 May 2012 09:22:03 -0000 --------------ms040906090100020000030204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 05/10/2012 11:08 AM, Dearlove, Christopher (UK) wrote: > I'm not a great fan of either. Allocating a whole range of type > extensions may include type extensions with no need to communicate. > And if link metric type X needs to communicate, it won't necessarily > send link metrics as its supplementary information. But as you say, > an ETX specific TLV isn't nice either. That's exactly my problem. Both solutions are not nice, but something is = necessary. > I realise that anyone who says "I don't like either" should make a > third proposal. Right now I don't have one, though I will think about > it. This is really to say if anyone has any alternative suggestions, > they would be welcome. Hmm... I just had another "not so nice" thought. We use a 4 bit header in our metric TLV value to encode the context of=20 the metric value (link incoming/outgoing, tc incoming/outgoing). Could we use the unused 0000 header combination used with HELLO message=20 addresses for transferring data between the two link metrics on both=20 sides of the link? 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 --------------ms040906090100020000030204 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 Fw0xMjA1MTAwOTIxNTNaMCMGCSqGSIb3DQEJBDEWBBQugYnB4CbEkN7its7uSk0hb2Ge6zBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQB8GhXVEBUqZi0xBMFSBpDl7Fp4TCv00wZA4p2zWcv0197trBEaabOtCE9A/xM1 lzYGDtkZB7l4PtA56XPzXmHP26/QgCPGDqii5MeSalRhcvrD5+PddVLQfHNouVvwl3H534HB JF8iXaAXurC3I4RVuFHsgkFKCRnUfV9qx+nuX0Sz+L2cx+kNykk/+LsV2lRP317cGrabaNLW 4QoM+xCQt6/LzKQ9mMoPWxednjL5knTkKsaGskc2kIxnWbr6fMaKq567kOKkzE4FcIsZE4mo hEBpw7tymS+92AFeVWdzYwWbS0dXRPpBi8Re0y+64xvSa/lIWybXK0AkZkb27l/0AAAAAAAA --------------ms040906090100020000030204-- From ietf@thomasclausen.org Thu May 10 03:04:47 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 3258E21F8631 for ; Thu, 10 May 2012 03:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 JXTUB+64omiF for ; Thu, 10 May 2012 03:04:46 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6524A21F8540 for ; Thu, 10 May 2012 03:04:46 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 31EE9557FBB for ; Thu, 10 May 2012 03:04:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 582891C00B49; Thu, 10 May 2012 03:04:45 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 960D21C00B44; Thu, 10 May 2012 03:04:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: Date: Thu, 10 May 2012 12:04:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22EF9D49-8468-4EBD-AE80-2D362B4453F1@thomasclausen.org> References: <4FAB679A.1060205@fkie.fraunhofer.de> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1257) Cc: "manet@ietf.org" Subject: Re: [manet] Question about OLSRv2 link metric implementation 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, 10 May 2012 10:04:47 -0000 I do agree with Chris - I've got about 5 other I-Ds taking cycles right = now, so I do not have a good idea - but will think about it once they're = out the door. That said, I do think that it is a good initiative, Henning, and I would = encourage (and offer assistance on) production of an ETX metric for = OLSRv2. I also would very much encourage documenting "The FunkFeuer Exeperience" = in an informational RFC; I believe that as you guys have an operational, = large and long-standing MANET running, it'd be valuable information for = others deploying such networks. Thus, 100% support from me on that also. Best, Thomas On May 10, 2012, at 11:08 , Dearlove, Christopher (UK) wrote: > I'm not a great fan of either. Allocating a whole range of type = extensions may include type extensions with no need to communicate. And = if link metric type X needs to communicate, it won't necessarily send = link metrics as its supplementary information. But as you say, an ETX = specific TLV isn't nice either. >=20 > I realise that anyone who says "I don't like either" should make a = third proposal. Right now I don't have one, though I will think about = it. This is really to say if anyone has any alternative suggestions, = they would be welcome. >=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 > -----Original Message----- > From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf = Of Henning Rogge > Sent: 10 May 2012 08:01 > To: manet@ietf.org > Subject: [manet] Question about OLSRv2 link metric implementation >=20 > Hi, >=20 > I am working on reviving my Freifunk-ETX draft again and thinking = about=20 > to split it into two different drafts. One that discusses the general=20= > aspects of an ETX metric implementation. >=20 > Most times ETX metrics are described as a symmetric metric, where the=20= > link cost does include both directions of the link, and I think there=20= > are several link layer designs where combining the packet loss in both=20= > directions makes sense (not necessarily with the same weight). >=20 > For this both sides of the Metric implementation have to communicate=20= > with each other outside the normal metric TLV described in the = OLSRv2-draft. >=20 > Do you think it makes sense to ask IANA to allocate a generic "Private=20= > Link Metric Data" TVL, that will use the same extension types as the=20= > metric TLV in OLSRv2 and allows a metric implementation to exchange = data=20 > with the other side of the link? >=20 > Allocating an "ETX specific TLV" sounds even worse. >=20 > 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 >=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 From Chris.Dearlove@baesystems.com Thu May 10 03:41: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 B001721F861D for ; Thu, 10 May 2012 03:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 7lSXxY6BMaCp for ; Thu, 10 May 2012 03:41:51 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA121F8636 for ; Thu, 10 May 2012 03:41:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,564,1330905600"; d="scan'208";a="237689909" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 10 May 2012 11:41:50 +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 q4AAfnNm025767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 10 May 2012 11:41:50 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.01.0355.002; Thu, 10 May 2012 11:41:50 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] Question about OLSRv2 link metric implementation Thread-Index: AQHNLnqnrG52V+xcUEuAGS8hv5lf6JbCuruQ///0OICAACYfcA== Date: Thu, 10 May 2012 10:41:48 +0000 Message-ID: References: <4FAB679A.1060205@fkie.fraunhofer.de> <4FAB88B1.9070008@fkie.fraunhofer.de> In-Reply-To: <4FAB88B1.9070008@fkie.fraunhofer.de> 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] Question about OLSRv2 link metric implementation 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, 10 May 2012 10:41:52 -0000 There is one possible (but not documented) existing use of 0000. That is to= enable a multi-value TLV to run over a range of addresses, one of which (p= erhaps a LOST LINK_STATUS) doesn't need a metric, but no harm would be prod= uced if given a 0000 one. Using the one multivalue TLV might be easier/more= efficient. --=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: Henning Rogge [mailto:henning.rogge@fkie.fraunhofer.de]=20 Sent: 10 May 2012 10:22 To: manet@ietf.org Cc: Dearlove, Christopher (UK) Subject: Re: [manet] Question about OLSRv2 link metric implementation On 05/10/2012 11:08 AM, Dearlove, Christopher (UK) wrote: > I'm not a great fan of either. Allocating a whole range of type > extensions may include type extensions with no need to communicate. > And if link metric type X needs to communicate, it won't necessarily > send link metrics as its supplementary information. But as you say, > an ETX specific TLV isn't nice either. That's exactly my problem. Both solutions are not nice, but something is=20 necessary. > I realise that anyone who says "I don't like either" should make a > third proposal. Right now I don't have one, though I will think about > it. This is really to say if anyone has any alternative suggestions, > they would be welcome. Hmm... I just had another "not so nice" thought. We use a 4 bit header in our metric TLV value to encode the context of=20 the metric value (link incoming/outgoing, tc incoming/outgoing). Could we use the unused 0000 header combination used with HELLO message=20 addresses for transferring data between the two link metrics on both=20 sides of the link? 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 ******************************************************************** 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 May 10 11:21: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 25CA011E80A5 for ; Thu, 10 May 2012 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=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 ts8pbktrESPs for ; Thu, 10 May 2012 11:21:34 -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 56B1421F872A for ; Thu, 10 May 2012 11:21:34 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2210504vbb.31 for ; Thu, 10 May 2012 11:21:33 -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=mFTzLrmwXHEAn70KgRtHyHgUk0loPWRKui0HjS+NWlk=; b=n/1UZ/0tuF/5wnEmD9wpG8f4z/VdWAVR7X+vBvfsQUMKDp6OzEUO2mBvALHF3Unh0k ocKFuIDoPIyRIqOckOpammJB++vwVTgTMvMwZ2a85fELgvRSuml4bwSENWTMlYcFELQm ci/7i2QO+4wy6POsRfzY+M1nzACUNYkoGWEEqskmtZQeQRfa7NfJpnTOcKVilmYvIyWs He6qjtwo0AWrBy+b7CyY9nXCZDFPOxKzCDkCbGWKxwZ8y/N/UcMEvlOZESlhYghMXFws KWIilNE8G1f1sX9+x/HqjbrJpEBq0yRTP3bX1rdIgib7Rera+y90ySSw11AxAiRmARyc EUTQ== MIME-Version: 1.0 Received: by 10.52.178.129 with SMTP id cy1mr2606928vdc.8.1336674093529; Thu, 10 May 2012 11:21:33 -0700 (PDT) Received: by 10.220.116.19 with HTTP; Thu, 10 May 2012 11:21:33 -0700 (PDT) In-Reply-To: <208504DC-6A9D-4DB5-B222-A8AA69BE19D4@thomasclausen.org> References: <208504DC-6A9D-4DB5-B222-A8AA69BE19D4@thomasclausen.org> Date: Thu, 10 May 2012 20:21:33 +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 for OLSRv2-14 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, 10 May 2012 18:21:36 -0000 Hi Thomas, I did not reply your last mail to me because didn't have references and don't want to argue, but I got now some references to you to give you a picture of my understanding, please read below, Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++ In OLSRv2-draft [1] Page 7: OLSRv2 makes no assumptions about the underlying link layer. OLSRv2, through its use of [RFC6130], may use link layer information and notifications when available and applicable. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This draft has a routing protocol that carries the word =93Link=94 but still it is indicated in two different meanings in the document; first as link-layer-state (e.g. BW), and second as hearing-existence between neighbors for communication. However, [1] states that this routing protocol has no assumption about the underlying data link layer, but it needs at least on olsrv2-interface. However, this draft uses the definitions of RFC6130 [2] and refers to RFC2501 for MANET. The term =93Interface=94 was defined in RFC6130 [2] not consistent with [4, 5, 6] and RFC2501 indicates that manet-interface may be wireless interface (as a link-layer interface), which can be understood from its definition by [4]. The words =93communication medium=94 was used in RFC6130 to define interface, but if compared to [5], the words =93communication facility=94 was added with =93medium=94. In addition, the RFC2501 [7] distinguishes between node identifier and interface identifier, meaning that the network interfaces are in different layer than routing protocol. In [1] the olsrv2-interface runs the NHDP[2], and some terms in [1] are defined as in [2]: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Interface: A router=92s attachment to a communications medium. An interface is assigned one or more addresses. MANET interface: An interface participating in a MANET and using this neighborhood discovery protocol. A router may have several MANET interfaces. Link: A link between two MANET interfaces exists if either can be heard by the ot= her. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D These above terms=92 definitions are different than in [4, 5, and 6]. Therefore, the reviewer wanted to clarify the definitions in RFC6130 [2], or to explain the olsrv2-interface in manet-olsrv2-14 [1]. The reviewer was confused about the definition of RFC6130 for a =93Link=94, because it describes it as the existing of link/connection, not the term meaning. Furthermore, it was used in defining a link in [1, 2] router=92s attachment to, but in [4] it was node=92s attachment to, the reviewer is not sure why authors ignored the host (destination) connection within the network. An interface was defined in [2] not attachment to link, but attachment to communication medium. The =93communication medium=94 was defined in [4] as free-space, cable, or fiber, which means that in [1, 2] may make a misleading concept of defining the term =93interface=94. References: =3D=3D=3D=3D=3D=3D=3D=3D=3D 1- Clausen, T., Dearlove, C., Jacquet, P., Herberg, U., =93The Optimized Link State Routing Protocol version 2=94, work in progress, IETF, March 2012. 2- Clausen, T., Dearlove, C., Dean, J., =93Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)=94, RFC6130, IETF, April 2011. 3- Melia, T., Gundavelli, S., =93Logical Interface Support for multi-mode IP Hosts=94, work in progress, IETF, April, 2012. 4- Perkins, C.,=93Mobile Ad Hoc Networking Terminology=94, work in progress, IETF, Nov. 1998. 5- Narten, T., Nordmark, E., Simpson, W., Soliman, H., =93Neighbor Discovery for IP version 6 (IPv6)=94, RFC4861, IETF, Sep. 2007. 6- Blanchet, M., Seite, P., =93Multiple Interfaces and Provisioning Domains Problem Statement=94, RFC6418, IETF, Nov. 2011. 7- Corson, S., Macker, J., =93Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations=94, RFC2501, IETF, Jan. 1999. ++++++++++++++++++++++++++ On 5/1/12, Thomas Heide Clausen wrote: > > > On 1 May 2012, at 14:31, Abdussalam Baryun > wrote: > >> Hi Chris >> >> if it cannot be physical and cannot be in the underlying data-link layer >> (data link was mentioned in draft), > > That was not at all what Chris wrote. > >> then I don't care much for the change or addition, but if it can be all = in >> physical and logical, I beleive it must state both physical and logical = as >> long the draft states data link. > > No, that doesn't follow either. > > Thomas > >> I am completely lost here, >> >> I started to think to that I should wait for any other commenters before >> my last reply comments. >> >> Abdussalam >> >> On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christopher (UK) >> wrote: >> I explicitly said it could be physical (but it doesn=92t matter) in a >> different email than the one you quoted. >> >> >> >> -- >> >> 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 Centr= e, >> Farnborough, Hants, GU14 6YU, UK >> Registered in England & Wales No: 1996687 >> >> >> >> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 01 May 2012 12:41 >> To: Ulrich Herberg; ietf@thomasclausen.org >> Cc: manet; Dearlove, Christopher (UK) >> Subject: Re: [manet] Comments for OLSRv2-14 >> >> >> >> >> >> *** 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. >> >> Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 = is >> used (or how the interfaces are defined). >IMO, unless other people in t= he >> WG see the same danger of confusion, I would not change it. >> >> I have no problem with your reaction, so than wait until you get other >> voices then (not sure how many you want), as long as the draft doesn't >> care about each single review-comment it only follows majority agreement >> on comments. This type of review-system makes the document not include a= ll >> readers level of knowledge, that means the document is for specific grou= p >> which exclueds other readers or groups. However, I just will mention my >> comments and do my work, I really don't care of the outcome decision, bu= t >> I will care if I authored a reviewed document. >> >> clausen>An OLSRv2 interface can be physical or virtual. Chris explained = it >> well, I suggest re-reading his email. >> >> >> >> chris explained>An OLSRv2 interface (a special case of a MANET interface= , >> see RFC 6130) is an IP interface, one which IP receives packets on, has >> one or more IP addresses etc. It has a data link layer below it, but >> OLSRv2 doesn=92t care about that. Your statement =93a MANET interface is= a >> data link interface=94 is wrong. >> >> Ok, I read again. It does not mention that it may be physical. I >> understand from him it never can be physical, so I needed that to be >> clear, but now you mentioned that it can be physical. >> >> >> >> Abdussalam Baryun >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++ >> >> >> >> On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg >> wrote: >> >> Abdussalam, >> >> so far, nobody else seemed to be confused on which layer OLSRv2 is used >> (or how the interfaces are defined). IMO, unless other people in the WG >> see the same danger of confusion, I would not change it. >> >> Regards >> Ulrich >> >> >> >> On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun >> wrote: >> >> Hi Herberg, >> >> >> >> I am suggesting to clarify interfaces, I donot like to change if >> unnecessary. Mentioning that an interface is in the layer 3, or its >> logical, or even just explaining the way Chris defined to me, really mak= es >> difference. My question is why is the draft not mentioning that >> OLSRv2-interface is an IP-interface or a logical-interface? Does the >> authors see that this information is not important? or even >> MANET-interfaces are in layer 3. If we define protocols without >> mentioning which layer it is located in, then how can we define such >> protocol, its layer-location is more important than its functionality, >> because each layer has its special interfaces, functions, services, and >> messages. There are many documents that explain interface in the same >> model that OLSRv2 is presenting so why didn't have confusion when I read >> them? >> >> >An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) >> > is an IP interface, one which IP >receives packets on, has one or more >> > IP addresses etc. It has a data link layer below it, but OLSRv2 doesn= =92t >> > >care about that. Your statement =93a MANET interface is a data link >> > interface=94 is wrong. >> >> >I don't think there is any confusion. Chris has pointed out the >> > relationship between MANET interface and OLSRv2 >interface clearly. I >> > think that RFC6130/draft-ietf-manet-olsrv2 define the terminology >> > correctly. If you would like to >change anything, please suggest >> > concrete text to replace, so that I can better understand what you >> > mean. >> >> I disagree that there is no confusion. There are confusions in defining >> terms in MANET WG, I have seen in the past a long discussion between man= y, >> just arguing about defining host or router, and now l was confused of >> interfaces in OLSRv2-draft. Maybe because I am not much familiar with >> OLSR, or reading about network-interface in many papers, and I read >> RFC2501 (it refers alot to wireless interface and communications) and >> mentioned in RFC6130 for the interface as attach to communication medium= , >> I thought it was a medium as physical medium. >> >> I suggest to clarify by adding information in one of the following >> explanation to the draft (even a line will do): >> >> >> >> - Mentioning which layer(s) the OLSRv2-interface works or allowed to be = at >> by the protocol, or >> >> - defining the MANET-interface as Chris defined (IP-interface, at layer = 3) >> in terminology, or >> >> - mentioning that OLSRv2-interface is not a wireless interface, or >> >> - defining MANET-interface as logical interface. >> >> >> I am sorry to disturb, I actually still have many comments for >> OLSRv2-draft and will try to submit, and let the WG to decide. However, = I >> thank you and Chris to explain to me so at least my other comments will = be >> in understanding. >> >> Abdussalam >> ++++++++++++++++++ >> >> On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg >> wrote: >> >> Abdussalam, >> >> RFC6130 defines: >> >> >> >> MANET interface: >> An interface participating in a MANET and using this neighborhood >> discovery protocol. A router may have several MANET interfaces. >> >> And draft-ietf-manet-olsrv2 defines: >> >> >> OLSRv2 interface: >> A MANET interface running this protocol. A router running this >> protocol MUST have at least one OLSRv2 interface. >> >> In one of the last OLSRv2 revisions, we made sure that OLSRv2 >> differentiates between neighbors running only NHDP and neighbors running >> also OLSRv2, and only the latter are used for MPR selection, etc. I do n= ot >> understand what you would like to change in the OLSRv2 draft. >> >> See comments below: >> >> On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun >> wrote: >> >> Hi Henning, >> >> >> >> Please note that I read the first pages of draft many times before posti= ng >> any information. >> >> >> >> HR>I would suggest reading the OLSRv2-draft again, especially section 2. >> >> >> >> >OLSRv2 interface: >> >A MANET interface running this protocol. A router running this >> >protocol MUST have at least one OLSRv2 interface. >> >> HR>A routing protocol which does not run on any interface would be prett= y >> >useless, right? >> >> You reply to the second sentence not the first which has 'running this >> protocol' relating it not to the router it is relating it to the >> interface. I know that router must have at least a network-interface ( o= r >> data-link-layer) or MANET interface, this is not what I commenting and t= he >> draft is mentioning. We don't assume at least Data-Link because it is >> obvious and we are following TCP/IP model in the internet, but not at >> least a specific-interface called bla bla. >> >> >> >> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS thi= s >> protocol (OLSRv2) this means there is some thing related to OLSRv2 in th= e >> layer-2. You should read again another paragraph mentioning as if there = is >> difference between MANET-interface and OLSRv2-interface. >> >> >> >> OLSRv2-14>p9> >> >> Supports routers that each have one or more participating OLSRv2 >> >> interfaces, which will consist of some or all of its MANET >> >> interfaces using [RFC6130]. The set of a router=92s OLSRv2 >> >> interfaces, and the sets of its other MANET and non-MANET >> >> interfaces, may change over time. Each interface may have one or >> >> more network addresses (which may have prefix lengths), and these >> >> may also be dynamically changing. >> >> >> >> AB> it is clear from the above draft-page-9, that all MANET interfaces a= re >> not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces. >> So we have to have in or node at least an OLSRv2-interface, not at least >> one MANET-interfac so the protocol to work correctly. >> >> >> >> AB> The above page-9 mentions NHDP as well that interfaces need this >> protocol. What if there is not NHDP, or if it is not working, what will >> happen. The draft SHOULD explain these issues. >> >> >> >> >> >> AB> It may be that all OLSRv2 routers (as implementation point of >> practice) only need at least one MANET interface. But the authors need t= o >> change. therefore, we know that All routers need at least on interface, >> but the draft-wording has a special OLSRv2-interface. Then we need to >> change the draft wording to the right explaination. >> >> >> >> Can you suggest what you would like to change? I don't understand your >> point. >> >> Best regards >> Ulrich >> +++++++++++++++++++++++++++++++++++++++++++ >> >> >> >> Hi Chris >> >> >> >> ok then if it was simple to explain as a special interface as IP-interfa= ce >> why we have OLSRv2_draft saying that it is network-interface as MANET is= a >> network, but IP is not it is a protocol. IMO it is wrong to refer to a >> network while you mean a protocol, even though I know I may misunderstoo= d. >> I sugget that this SHOULD be explained clearly. I think every one seems = to >> understand that network-interface must include Data-Link-layer, therefor= e, >> RFC6130 or OLSRv2-draft should define well as you did. I thank you for >> your comment, >> >> >> >> Therefore I suggest to change OLSRv2-interface definition as Chris defin= ed >> it very clearly. I hope the draft can change the definition, >> >> >> >> Abdussalam >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + >> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) >> wrote: >> >> >> >> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) = is >> an IP interface, one which IP receives packets on, has one or more IP >> addresses etc. It has a data link layer below it, but OLSRv2 doesn=92t c= are >> about that. Your statement =93a MANET interface is a data link interface= =94 is >> wrong. >> >> >> >> -- >> >> 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 at baesystems.com | http://www.baesystems.com >> >> >> >> >> >> >> >> >> ******************************************************************** >> 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 ietf@thomasclausen.org Thu May 10 12:29: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 AA9FA11E80B0 for ; Thu, 10 May 2012 12:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.682 X-Spam-Level: X-Spam-Status: No, score=0.682 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=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 tMPUCbHjHK4o for ; Thu, 10 May 2012 12:29:35 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 241BF21F86D5 for ; Thu, 10 May 2012 12:29:35 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 0E18AA550F for ; Thu, 10 May 2012 12:29:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AF5F71C07E3; Thu, 10 May 2012 12:29:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.249] (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 D8D781C07D9; Thu, 10 May 2012 12:29:28 -0700 (PDT) References: <208504DC-6A9D-4DB5-B222-A8AA69BE19D4@thomasclausen.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPad Mail (9B176) From: Thomas Heide Clausen Date: Thu, 10 May 2012 21:29:52 +0200 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] Comments for OLSRv2-14 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, 10 May 2012 19:29:36 -0000 On 10 May 2012, at 20:21, Abdussalam Baryun wro= te: > Hi Thomas, >=20 > I did not reply your last mail to me because didn't have references > and don't want to argue, but I got now some references to you to give > you a picture of my understanding, please read below, >=20 > Abdussalam Baryun > University of Glamorgan, UK > ++++++++++++++++++++++++++ >=20 > In OLSRv2-draft [1] Page 7: OLSRv2 makes no assumptions about the > underlying link layer. OLSRv2, through its use of [RFC6130], may use > link layer information and notifications when available and > applicable. That is true. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This draft has a routing protocol that carries the word =E2=80=9CLink=E2=80= =9D but > still it is indicated in two different meanings in the document; first > as link-layer-state (e.g. BW), and second as hearing-existence between > neighbors for communication. Link-State is a fairly well established class of protocols; there is no cont= radiction, they are not "two different meanings". Look at how a link-state p= rotocol works, and what "link" in "link-state" means. > However, [1] states that this routing > protocol has no assumption about the underlying data link layer, but > it needs at least on olsrv2-interface. That is what [1] states, and that which is true. Your "However" indicates that you somehow see a contradiction ... there is n= o contradiction. > However, this draft uses the > definitions of RFC6130 [2] and refers to RFC2501 for MANET. The term > =E2=80=9CInterface=E2=80=9D was defined in RFC6130 [2] not consistent with= [4, 5, 6] [4] expired more than a decade ago, without being published by the IETF. [5,= 6] do not apply. See some of the issues in RFC5889 and the discussions surr= ounding that RFC to understand why. [1] and [2] are consistent, and apply to [MANET], so I still see no contradi= ction. > and RFC2501 indicates that manet-interface may be wireless interface > (as a link-layer interface), Which is not inconsistent with OLSRv2 or NHDP at all. > which can be understood from its > definition by [4]. [4] expired more than a decade ago, without being published by the IETF. > The words =E2=80=9Ccommunication medium=E2=80=9D was used in > RFC6130 to define interface,but if compared to [5], the words > =E2=80=9Ccommunication facility=E2=80=9D was added with =E2=80=9Cmedium=E2= =80=9D. I am sorry, I do not understand what you're saying in the above. [5] still d= oesn't apply. See some of the issues in RFC5889 and the discussions surround= ing that RFC to understand why. > In addition, the > RFC2501 [7] distinguishes between node identifier and interface > identifier, meaning that the network interfaces are in different layer > than routing protocol. I'm sorry, no, it doesn't follow at all that they are in different layers. I= do not understand why you would be lead to believe that they are. > In [1] the olsrv2-interface runs the NHDP[2], and some terms in [1] > are defined as in [2]: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > Interface: > A router=E2=80=99s attachment to a communications medium. An interface is > assigned one or more addresses. > MANET interface: > An interface participating in a MANET and using this neighborhood > discovery protocol. A router may have several MANET interfaces. > Link: > A link between two MANET interfaces exists if either can be heard by the o= ther. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > These above terms=E2=80=99 definitions are different than in [4, 5, and 6]= . See comment before regarding applicability of [4, 5, 6]. NHDP and OLSRv2 def= ine their interface expectations. > Therefore, the reviewer wanted to clarify the definitions in RFC6130 > [2], or to explain the olsrv2-interface in manet-olsrv2-14 [1]. Sorry, I do not understand what you are saying here. > The > reviewer was confused about the definition of RFC6130 for a =E2=80=9CLink=E2= =80=9D, > because it describes it as the existing of link/connection, That *is* the definition of link, though, in terms of routing-protocols. Aga= in, go look at what "link" in "link state" means. > not the > term meaning. ? > Furthermore, it was used in defining a link in [1, 2] > router=E2=80=99s attachment to, but in [4] it was node=E2=80=99s attachmen= t to, Again [4] was never published by the IETF and expired more than a decade ago= - and doesn't apply. > the > reviewer is not sure why authors ignored the host (destination) > connection within the network. This is precisely because neither of OLSRv2, NHDP nor [MANET] concerns _rou= ters_, and does specifically *NOT* concern _hosts_. > An interface was defined in [2] not > attachment to link, but attachment to communication medium. The > =E2=80=9Ccommunication medium=E2=80=9D was defined in [4] as free-space, c= able, or Again [4] was never published by the IETF and expired more than a decade ago= - and doesn't apply. > fiber, which means that in [1, 2] may make a misleading concept of > defining the term =E2=80=9Cinterface=E2=80=9D. >=20 No, it doesn't, as - again - [4] was never published by the IETF and expired= more than a decade ago - and doesn't apply. =20 Thomas > References: > =3D=3D=3D=3D=3D=3D=3D=3D=3D > 1- Clausen, T., Dearlove, C., Jacquet, P., Herberg, U., =E2=80=9CThe Optim= ized > Link State Routing Protocol version 2=E2=80=9D, work in progress, IETF, Ma= rch > 2012. > 2- Clausen, T., Dearlove, C., Dean, J., =E2=80=9CMobile Ad Hoc Network (MA= NET) > Neighborhood Discovery Protocol (NHDP)=E2=80=9D, RFC6130, IETF, April 2011= . > 3- Melia, T., Gundavelli, S., =E2=80=9CLogical Interface Support for > multi-mode IP Hosts=E2=80=9D, work in progress, IETF, April, 2012. > 4- Perkins, C.,=E2=80=9CMobile Ad Hoc Networking Terminology=E2=80=9D, wor= k in > progress, IETF, Nov. 1998. > 5- Narten, T., Nordmark, E., Simpson, W., Soliman, H., =E2=80=9CNeighbor > Discovery for IP version 6 (IPv6)=E2=80=9D, RFC4861, IETF, Sep. 2007. > 6- Blanchet, M., Seite, P., =E2=80=9CMultiple Interfaces and Provisioning > Domains Problem Statement=E2=80=9D, RFC6418, IETF, Nov. 2011. > 7- Corson, S., Macker, J., =E2=80=9CMobile Ad hoc Networking (MANET): Rout= ing > Protocol Performance Issues and Evaluation Considerations=E2=80=9D, RFC250= 1, > IETF, Jan. 1999. >=20 > ++++++++++++++++++++++++++ >=20 > On 5/1/12, Thomas Heide Clausen wrote: >>=20 >>=20 >> On 1 May 2012, at 14:31, Abdussalam Baryun >> wrote: >>=20 >>> Hi Chris >>>=20 >>> if it cannot be physical and cannot be in the underlying data-link layer= >>> (data link was mentioned in draft), >>=20 >> That was not at all what Chris wrote. >>=20 >>> then I don't care much for the change or addition, but if it can be all i= n >>> physical and logical, I beleive it must state both physical and logical a= s >>> long the draft states data link. >>=20 >> No, that doesn't follow either. >>=20 >> Thomas >>=20 >>> I am completely lost here, >>>=20 >>> I started to think to that I should wait for any other commenters before= >>> my last reply comments. >>>=20 >>> Abdussalam >>>=20 >>> On Tue, May 1, 2012 at 1:19 PM, Dearlove, Christopher (UK) >>> wrote: >>> I explicitly said it could be physical (but it doesn=E2=80=99t matter) i= n a >>> different email than the one you quoted. >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>>=20 >>> 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 >>>=20 >>> chris.dearlove@baesystems.com | http://www.baesystems.com >>>=20 >>> BAE Systems (Operations) Limited >>> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centr= e, >>> Farnborough, Hants, GU14 6YU, UK >>> Registered in England & Wales No: 1996687 >>>=20 >>>=20 >>>=20 >>> From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> Sent: 01 May 2012 12:41 >>> To: Ulrich Herberg; ietf@thomasclausen.org >>> Cc: manet; Dearlove, Christopher (UK) >>> Subject: Re: [manet] Comments for OLSRv2-14 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> *** WARNING *** >>>=20 >>> 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. >>>=20 >>> Herberg>so far, nobody else seemed to be confused on which layer OLSRv2 i= s >>> used (or how the interfaces are defined). >IMO, unless other people in t= he >>> WG see the same danger of confusion, I would not change it. >>>=20 >>> I have no problem with your reaction, so than wait until you get other >>> voices then (not sure how many you want), as long as the draft doesn't >>> care about each single review-comment it only follows majority agreement= >>> on comments. This type of review-system makes the document not include a= ll >>> readers level of knowledge, that means the document is for specific grou= p >>> which exclueds other readers or groups. However, I just will mention my >>> comments and do my work, I really don't care of the outcome decision, bu= t >>> I will care if I authored a reviewed document. >>>=20 >>> clausen>An OLSRv2 interface can be physical or virtual. Chris explained i= t >>> well, I suggest re-reading his email. >>>=20 >>>=20 >>>=20 >>> chris explained>An OLSRv2 interface (a special case of a MANET interface= , >>> see RFC 6130) is an IP interface, one which IP receives packets on, has >>> one or more IP addresses etc. It has a data link layer below it, but >>> OLSRv2 doesn=E2=80=99t care about that. Your statement =E2=80=9Ca MANET i= nterface is a >>> data link interface=E2=80=9D is wrong. >>>=20 >>> Ok, I read again. It does not mention that it may be physical. I >>> understand from him it never can be physical, so I needed that to be >>> clear, but now you mentioned that it can be physical. >>>=20 >>>=20 >>>=20 >>> Abdussalam Baryun >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++ >>>=20 >>>=20 >>>=20 >>> On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg >>> wrote: >>>=20 >>> Abdussalam, >>>=20 >>> so far, nobody else seemed to be confused on which layer OLSRv2 is used >>> (or how the interfaces are defined). IMO, unless other people in the WG >>> see the same danger of confusion, I would not change it. >>>=20 >>> Regards >>> Ulrich >>>=20 >>>=20 >>>=20 >>> On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Baryun >>> wrote: >>>=20 >>> Hi Herberg, >>>=20 >>>=20 >>>=20 >>> I am suggesting to clarify interfaces, I donot like to change if >>> unnecessary. Mentioning that an interface is in the layer 3, or its >>> logical, or even just explaining the way Chris defined to me, really mak= es >>> difference. My question is why is the draft not mentioning that >>> OLSRv2-interface is an IP-interface or a logical-interface? Does the >>> authors see that this information is not important? or even >>> MANET-interfaces are in layer 3. If we define protocols without >>> mentioning which layer it is located in, then how can we define such >>> protocol, its layer-location is more important than its functionality, >>> because each layer has its special interfaces, functions, services, and >>> messages. There are many documents that explain interface in the same >>> model that OLSRv2 is presenting so why didn't have confusion when I read= >>> them? >>>=20 >>>> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130)= >>>> is an IP interface, one which IP >receives packets on, has one or more >>>> IP addresses etc. It has a data link layer below it, but OLSRv2 doesn=E2= =80=99t >>>>> care about that. Your statement =E2=80=9Ca MANET interface is a data l= ink >>>> interface=E2=80=9D is wrong. >>>=20 >>>> I don't think there is any confusion. Chris has pointed out the >>>> relationship between MANET interface and OLSRv2 >interface clearly. I >>>> think that RFC6130/draft-ietf-manet-olsrv2 define the terminology >>>> correctly. If you would like to >change anything, please suggest >>>> concrete text to replace, so that I can better understand what you >>>> mean. >>>=20 >>> I disagree that there is no confusion. There are confusions in defining >>> terms in MANET WG, I have seen in the past a long discussion between man= y, >>> just arguing about defining host or router, and now l was confused of >>> interfaces in OLSRv2-draft. Maybe because I am not much familiar with >>> OLSR, or reading about network-interface in many papers, and I read >>> RFC2501 (it refers alot to wireless interface and communications) and >>> mentioned in RFC6130 for the interface as attach to communication medium= , >>> I thought it was a medium as physical medium. >>>=20 >>> I suggest to clarify by adding information in one of the following >>> explanation to the draft (even a line will do): >>>=20 >>>=20 >>>=20 >>> - Mentioning which layer(s) the OLSRv2-interface works or allowed to be a= t >>> by the protocol, or >>>=20 >>> - defining the MANET-interface as Chris defined (IP-interface, at layer 3= ) >>> in terminology, or >>>=20 >>> - mentioning that OLSRv2-interface is not a wireless interface, or >>>=20 >>> - defining MANET-interface as logical interface. >>>=20 >>>=20 >>> I am sorry to disturb, I actually still have many comments for >>> OLSRv2-draft and will try to submit, and let the WG to decide. However, I= >>> thank you and Chris to explain to me so at least my other comments will b= e >>> in understanding. >>>=20 >>> Abdussalam >>> ++++++++++++++++++ >>>=20 >>> On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg >>> wrote: >>>=20 >>> Abdussalam, >>>=20 >>> RFC6130 defines: >>>=20 >>>=20 >>>=20 >>> MANET interface: >>> An interface participating in a MANET and using this neighborhood >>> discovery protocol. A router may have several MANET interfaces. >>>=20 >>> And draft-ietf-manet-olsrv2 defines: >>>=20 >>>=20 >>> OLSRv2 interface: >>> A MANET interface running this protocol. A router running this >>> protocol MUST have at least one OLSRv2 interface. >>>=20 >>> In one of the last OLSRv2 revisions, we made sure that OLSRv2 >>> differentiates between neighbors running only NHDP and neighbors running= >>> also OLSRv2, and only the latter are used for MPR selection, etc. I do n= ot >>> understand what you would like to change in the OLSRv2 draft. >>>=20 >>> See comments below: >>>=20 >>> On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun >>> wrote: >>>=20 >>> Hi Henning, >>>=20 >>>=20 >>>=20 >>> Please note that I read the first pages of draft many times before posti= ng >>> any information. >>>=20 >>>=20 >>>=20 >>> HR>I would suggest reading the OLSRv2-draft again, especially section 2.= >>>=20 >>>=20 >>>=20 >>>> OLSRv2 interface: >>>> A MANET interface running this protocol. A router running this >>>> protocol MUST have at least one OLSRv2 interface. >>>=20 >>> HR>A routing protocol which does not run on any interface would be prett= y >>>> useless, right? >>>=20 >>> You reply to the second sentence not the first which has 'running this >>> protocol' relating it not to the router it is relating it to the >>> interface. I know that router must have at least a network-interface ( o= r >>> data-link-layer) or MANET interface, this is not what I commenting and t= he >>> draft is mentioning. We don't assume at least Data-Link because it is >>> obvious and we are following TCP/IP model in the internet, but not at >>> least a specific-interface called bla bla. >>>=20 >>>=20 >>>=20 >>> Why it defines the 'OLSRv2-interface' as a MANET-interface that RUNS thi= s >>> protocol (OLSRv2) this means there is some thing related to OLSRv2 in th= e >>> layer-2. You should read again another paragraph mentioning as if there i= s >>> difference between MANET-interface and OLSRv2-interface. >>>=20 >>>=20 >>>=20 >>> OLSRv2-14>p9> >>>=20 >>> Supports routers that each have one or more participating OLSRv2 >>>=20 >>> interfaces, which will consist of some or all of its MANET >>>=20 >>> interfaces using [RFC6130]. The set of a router=E2=80=99s OLSRv2 >>>=20 >>> interfaces, and the sets of its other MANET and non-MANET >>>=20 >>> interfaces, may change over time. Each interface may have one or >>>=20 >>> more network addresses (which may have prefix lengths), and these >>>=20 >>> may also be dynamically changing. >>>=20 >>>=20 >>>=20 >>> AB> it is clear from the above draft-page-9, that all MANET interfaces a= re >>> not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-interfaces.= >>> So we have to have in or node at least an OLSRv2-interface, not at least= >>> one MANET-interfac so the protocol to work correctly. >>>=20 >>>=20 >>>=20 >>> AB> The above page-9 mentions NHDP as well that interfaces need this >>> protocol. What if there is not NHDP, or if it is not working, what will >>> happen. The draft SHOULD explain these issues. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> AB> It may be that all OLSRv2 routers (as implementation point of >>> practice) only need at least one MANET interface. But the authors need t= o >>> change. therefore, we know that All routers need at least on interface, >>> but the draft-wording has a special OLSRv2-interface. Then we need to >>> change the draft wording to the right explaination. >>>=20 >>>=20 >>>=20 >>> Can you suggest what you would like to change? I don't understand your >>> point. >>>=20 >>> Best regards >>> Ulrich >>> +++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>>=20 >>>=20 >>> Hi Chris >>>=20 >>>=20 >>>=20 >>> ok then if it was simple to explain as a special interface as IP-interfa= ce >>> why we have OLSRv2_draft saying that it is network-interface as MANET is= a >>> network, but IP is not it is a protocol. IMO it is wrong to refer to a >>> network while you mean a protocol, even though I know I may misunderstoo= d. >>> I sugget that this SHOULD be explained clearly. I think every one seems t= o >>> understand that network-interface must include Data-Link-layer, therefor= e, >>> RFC6130 or OLSRv2-draft should define well as you did. I thank you for >>> your comment, >>>=20 >>>=20 >>>=20 >>> Therefore I suggest to change OLSRv2-interface definition as Chris defin= ed >>> it very clearly. I hope the draft can change the definition, >>>=20 >>>=20 >>>=20 >>> Abdussalam >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= + >>> On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, Christopher (UK) >>> wrote: >>>=20 >>>=20 >>>=20 >>> An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) i= s >>> an IP interface, one which IP receives packets on, has one or more IP >>> addresses etc. It has a data link layer below it, but OLSRv2 doesn=E2=80= =99t care >>> about that. Your statement =E2=80=9Ca MANET interface is a data link int= erface=E2=80=9D is >>> wrong. >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Christopher Dearlove >>>=20 >>> 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 >>>=20 >>> chris.dearlove at baesystems.com | http://www.baesystems.com >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=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 >>=20 From Chris.Dearlove@baesystems.com Fri May 11 03: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 5412021F8638 for ; Fri, 11 May 2012 03:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=0.6, 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 sCmcmHW4X25W for ; Fri, 11 May 2012 03:17:50 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id E233921F844D for ; Fri, 11 May 2012 03:17:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,570,1330905600"; d="scan'208";a="238017364" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 11 May 2012 11:17:46 +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 q4BAHjcw023701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 May 2012 11:17:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.2.151]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.01.0355.002; Fri, 11 May 2012 11:17:45 +0100 From: "Dearlove, Christopher (UK)" To: Thomas Heide Clausen , Abdussalam Baryun Thread-Topic: [manet] Comments for OLSRv2-14 Thread-Index: AQHNJxWqRtsKbTFEyEWXGg3Be+0nRpaz0Y8AgADuKoCAABseMP//8tGAgAAFbwCADoFugIAAExYAgAEGlFA= Date: Fri, 11 May 2012 10:17:44 +0000 Message-ID: References: <208504DC-6A9D-4DB5-B222-A8AA69BE19D4@thomasclausen.org> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: manet Subject: Re: [manet] Comments for OLSRv2-14 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, 11 May 2012 10:17:52 -0000 SSdsbCBhZGQgb25seSB0byBUaG9tYXMncyBjb21tZW50cyB0aGF0IGFsbCB0aGUgaW50ZXJmYWNl LCBsaW5rIGV0Yy4gZGVmaW5pdGlvbnMgdGhhdCBtYXR0ZXIgYXJlIGluIFJGQyA2MTMwLCB3aGlj aCB3YXMsIHF1aXRlIHJlY2VudGx5LCBhcHByb3ZlZCBieSB0aGUgSUVTRyBoYXZpbmcgcGFzc2Vk IGFsbCB0aGUgbnVtZXJvdXMgcmV2aWV3IHN0YWdlcyBiZWZvcmUgdGhlbi4gV2UgY291bGRuJ3Qg bW9kaWZ5IFJGQyA2MTMwIGlmIHdlIHdhbnRlZCB0bywgYW5kIHdlIGRvbid0LCBiZWNhdXNlIGl0 IHJlYWNoZWQgYWxsIHRoYXQgYWNjZXB0YW5jZS4NCg0KTm93IE9MU1J2MiBqdXN0IHNheXMgdGhh dCBldmVyeXRoaW5nIGlzIGxpa2UgNjEzMCwgZXhjZXB0IHRoYXQgd2UgcGljayBhIHN1YnNldCBv ZiBNQU5FVCBpbnRlcmZhY2VzIHdlIGFyZSBnb2luZyB0byB1c2UgZm9yIE9MU1J2Mi4gVGhlcmUn cyBubyBuZWVkIGZvciBhbiAgaW50cmluc2ljIHByb3BlcnR5IGRpZmZlcmVudGlhdGluZyB0aG9z ZSBpbnRlcmZhY2VzLCBPTFNSdjIgd2lsbCB3b3JrIGlmIHlvdSBwaWNrIGFueSBub24tZW1wdHkg c3Vic2V0IG9mIHlvdXIgTUFORVQgaW50ZXJmYWNlcyBhbmQgY2hvb3NlIHRvIHJ1biBPTFNydjIg b24gdGhvc2UgaW50ZXJmYWNlcy4gVGhhdCdzIGl0LiBTbyBsb2dpY2FsbHkgbm90aGluZyBuZWVk cyBhZGRpbmcgdG8gd2hhdCA2MTMwIHNheXMgb24gdGhpcyB0b3BpYy4gKFdlIHJlcGVhdCBhIGNv dXBsZSBvZiBjb21tZW50cyBmb3IgY2xhcml0eSwgYnV0IGFjdHVhbGx5IHRoYXQncyBub3QgbmVj ZXNzYXJ5LiBXZSBjZXJ0YWlubHkgc2hvdWxkbid0IGNoYW5nZSB0aGVtLCB0aGF0IHdvdWxkIHN1 Z2dlc3QgYSBkaWZmZXJlbmNlLiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlLikNCg0KLS0gDQpDaHJp c3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgQ29tbXVuaWNhdGlv bnMgR3JvdXANCkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2Fw YWJpbGl0eQ0KQkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUNCldlc3QgSGFu bmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNClRl bDogKzQ0IDEyNDUgMjQyMTk0wqB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KY2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQpSZWdpc3RlcmVkIE9mZmljZTogV2Fyd2ljayBIb3Vz ZSwgUE8gQm94IDg3LCBGYXJuYm9yb3VnaCBBZXJvc3BhY2UgQ2VudHJlLCBGYXJuYm9yb3VnaCwg SGFudHMsIEdVMTQgNllVLCBVSw0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDE5 OTY2ODcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFuZXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBU aG9tYXMgSGVpZGUgQ2xhdXNlbg0KU2VudDogMTAgTWF5IDIwMTIgMjA6MzANClRvOiBBYmR1c3Nh bGFtIEJhcnl1bg0KQ2M6IG1hbmV0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBDb21tZW50cyBmb3Ig T0xTUnYyLTE0DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9y Z2FuaXNhdGlvbiwNCmVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUg aW50ZXJuZXQuDQpLZWVwIHRoaXMgaW4gbWluZCBpZiB5b3UgYW5zd2VyIHRoaXMgbWVzc2FnZS4N CkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJz DQpmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2Vz Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KT24gMTAgTWF5IDIwMTIsIGF0IDIwOjIxLCBBYmR1c3NhbGFtIEJhcnl1biA8YWJkdXNz YWxhbWJhcnl1bkBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IEhpIFRob21hcywNCj4gDQo+IEkgZGlk IG5vdCByZXBseSB5b3VyIGxhc3QgbWFpbCB0byBtZSBiZWNhdXNlIGRpZG4ndCBoYXZlIHJlZmVy ZW5jZXMNCj4gYW5kIGRvbid0IHdhbnQgdG8gIGFyZ3VlLCBidXQgSSBnb3Qgbm93IHNvbWUgcmVm ZXJlbmNlcyB0byB5b3UgdG8gZ2l2ZQ0KPiB5b3UgYSBwaWN0dXJlIG9mIG15IHVuZGVyc3RhbmRp bmcsIHBsZWFzZSByZWFkIGJlbG93LA0KPiANCj4gQWJkdXNzYWxhbSBCYXJ5dW4NCj4gVW5pdmVy c2l0eSBvZiBHbGFtb3JnYW4sIFVLDQo+ICsrKysrKysrKysrKysrKysrKysrKysrKysrDQo+IA0K PiBJbiBPTFNSdjItZHJhZnQgWzFdIFBhZ2UgNzogT0xTUnYyIG1ha2VzIG5vIGFzc3VtcHRpb25z IGFib3V0IHRoZQ0KPiB1bmRlcmx5aW5nIGxpbmsgbGF5ZXIuIE9MU1J2MiwgdGhyb3VnaCBpdHMg dXNlIG9mIFtSRkM2MTMwXSwgbWF5IHVzZQ0KPiBsaW5rIGxheWVyIGluZm9ybWF0aW9uIGFuZCBu b3RpZmljYXRpb25zIHdoZW4gYXZhaWxhYmxlIGFuZA0KPiBhcHBsaWNhYmxlLg0KDQpUaGF0IGlz IHRydWUuDQoNCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ IFRoaXMgZHJhZnQgaGFzIGEgcm91dGluZyBwcm90b2NvbCB0aGF0IGNhcnJpZXMgdGhlIHdvcmQg 4oCcTGlua+KAnSBidXQNCj4gc3RpbGwgaXQgaXMgaW5kaWNhdGVkIGluIHR3byBkaWZmZXJlbnQg bWVhbmluZ3MgaW4gdGhlIGRvY3VtZW50OyBmaXJzdA0KPiBhcyBsaW5rLWxheWVyLXN0YXRlIChl LmcuIEJXKSwgYW5kIHNlY29uZCBhcyBoZWFyaW5nLWV4aXN0ZW5jZSBiZXR3ZWVuDQo+IG5laWdo Ym9ycyBmb3IgY29tbXVuaWNhdGlvbi4NCg0KTGluay1TdGF0ZSBpcyBhIGZhaXJseSB3ZWxsIGVz dGFibGlzaGVkIGNsYXNzIG9mIHByb3RvY29sczsgdGhlcmUgaXMgbm8gY29udHJhZGljdGlvbiwg dGhleSBhcmUgbm90ICJ0d28gZGlmZmVyZW50IG1lYW5pbmdzIi4gTG9vayBhdCBob3cgYSBsaW5r LXN0YXRlIHByb3RvY29sIHdvcmtzLCBhbmQgd2hhdCAibGluayIgaW4gImxpbmstc3RhdGUiIG1l YW5zLg0KDQo+IEhvd2V2ZXIsIFsxXSBzdGF0ZXMgdGhhdCB0aGlzIHJvdXRpbmcNCj4gcHJvdG9j b2wgaGFzIG5vIGFzc3VtcHRpb24gYWJvdXQgdGhlIHVuZGVybHlpbmcgZGF0YSBsaW5rIGxheWVy LCBidXQNCj4gaXQgbmVlZHMgYXQgbGVhc3Qgb24gb2xzcnYyLWludGVyZmFjZS4NCg0KVGhhdCBp cyB3aGF0IFsxXSBzdGF0ZXMsIGFuZCB0aGF0IHdoaWNoIGlzIHRydWUuDQoNCllvdXIgIkhvd2V2 ZXIiIGluZGljYXRlcyB0aGF0IHlvdSBzb21laG93IHNlZSBhIGNvbnRyYWRpY3Rpb24gLi4uICB0 aGVyZSBpcyBubyBjb250cmFkaWN0aW9uLg0KDQo+IEhvd2V2ZXIsIHRoaXMgZHJhZnQgdXNlcyB0 aGUNCj4gZGVmaW5pdGlvbnMgb2YgUkZDNjEzMCBbMl0gYW5kIHJlZmVycyB0byBSRkMyNTAxIGZv ciBNQU5FVC4gVGhlIHRlcm0NCj4g4oCcSW50ZXJmYWNl4oCdIHdhcyBkZWZpbmVkIGluIFJGQzYx MzAgWzJdIG5vdCBjb25zaXN0ZW50IHdpdGggWzQsIDUsIDZdDQoNCls0XSBleHBpcmVkIG1vcmUg dGhhbiBhIGRlY2FkZSBhZ28sIHdpdGhvdXQgYmVpbmcgcHVibGlzaGVkIGJ5IHRoZSBJRVRGLiBb NSwgNl0gZG8gbm90IGFwcGx5LiBTZWUgc29tZSBvZiB0aGUgaXNzdWVzIGluIFJGQzU4ODkgYW5k IHRoZSBkaXNjdXNzaW9ucyBzdXJyb3VuZGluZyB0aGF0IFJGQyB0byB1bmRlcnN0YW5kIHdoeS4N Cg0KWzFdIGFuZCBbMl0gYXJlIGNvbnNpc3RlbnQsIGFuZCBhcHBseSB0byBbTUFORVRdLCBzbyBJ IHN0aWxsIHNlZSBubyBjb250cmFkaWN0aW9uLg0KDQo+IGFuZCBSRkMyNTAxIGluZGljYXRlcyB0 aGF0IG1hbmV0LWludGVyZmFjZSBtYXkgYmUgd2lyZWxlc3MgaW50ZXJmYWNlDQo+IChhcyBhIGxp bmstbGF5ZXIgaW50ZXJmYWNlKSwNCg0KV2hpY2ggaXMgbm90IGluY29uc2lzdGVudCB3aXRoIE9M U1J2MiBvciBOSERQIGF0IGFsbC4NCg0KPiB3aGljaCBjYW4gYmUgdW5kZXJzdG9vZCBmcm9tIGl0 cw0KPiBkZWZpbml0aW9uIGJ5IFs0XS4NCg0KWzRdIGV4cGlyZWQgbW9yZSB0aGFuIGEgZGVjYWRl IGFnbywgd2l0aG91dCBiZWluZyBwdWJsaXNoZWQgYnkgdGhlIElFVEYuDQoNCj4gVGhlIHdvcmRz IOKAnGNvbW11bmljYXRpb24gbWVkaXVt4oCdIHdhcyB1c2VkIGluDQo+IFJGQzYxMzAgdG8gZGVm aW5lIGludGVyZmFjZSxidXQgaWYgY29tcGFyZWQgdG8gWzVdLCB0aGUgd29yZHMNCg0KPiDigJxj b21tdW5pY2F0aW9uIGZhY2lsaXR54oCdIHdhcyBhZGRlZCB3aXRoIOKAnG1lZGl1beKAnS4NCg0K SSBhbSBzb3JyeSwgSSBkbyBub3QgdW5kZXJzdGFuZCB3aGF0IHlvdSdyZSBzYXlpbmcgaW4gdGhl IGFib3ZlLiBbNV0gc3RpbGwgZG9lc24ndCBhcHBseS4gU2VlIHNvbWUgb2YgdGhlIGlzc3VlcyBp biBSRkM1ODg5IGFuZCB0aGUgZGlzY3Vzc2lvbnMgc3Vycm91bmRpbmcgdGhhdCBSRkMgdG8gdW5k ZXJzdGFuZCB3aHkuDQoNCj4gSW4gYWRkaXRpb24sIHRoZQ0KPiBSRkMyNTAxIFs3XSBkaXN0aW5n dWlzaGVzIGJldHdlZW4gbm9kZSBpZGVudGlmaWVyIGFuZCBpbnRlcmZhY2UNCj4gaWRlbnRpZmll ciwgbWVhbmluZyB0aGF0IHRoZSBuZXR3b3JrIGludGVyZmFjZXMgYXJlIGluIGRpZmZlcmVudCBs YXllcg0KPiB0aGFuIHJvdXRpbmcgcHJvdG9jb2wuDQoNCkknbSBzb3JyeSwgbm8sIGl0IGRvZXNu J3QgZm9sbG93IGF0IGFsbCB0aGF0IHRoZXkgYXJlIGluIGRpZmZlcmVudCBsYXllcnMuIEkgZG8g bm90IHVuZGVyc3RhbmQgd2h5IHlvdSB3b3VsZCBiZSBsZWFkIHRvIGJlbGlldmUgdGhhdCB0aGV5 IGFyZS4NCg0KPiBJbiBbMV0gdGhlIG9sc3J2Mi1pbnRlcmZhY2UgcnVucyB0aGUgTkhEUFsyXSwg YW5kIHNvbWUgdGVybXMgaW4gWzFdDQo+IGFyZSBkZWZpbmVkIGFzIGluIFsyXToNCj4gPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBJ bnRlcmZhY2U6DQo+IEEgcm91dGVy4oCZcyBhdHRhY2htZW50IHRvIGEgY29tbXVuaWNhdGlvbnMg bWVkaXVtLiBBbiBpbnRlcmZhY2UgaXMNCj4gYXNzaWduZWQgb25lIG9yIG1vcmUgYWRkcmVzc2Vz Lg0KPiBNQU5FVCBpbnRlcmZhY2U6DQo+IEFuIGludGVyZmFjZSBwYXJ0aWNpcGF0aW5nIGluIGEg TUFORVQgYW5kIHVzaW5nIHRoaXMgbmVpZ2hib3Job29kDQo+IGRpc2NvdmVyeSBwcm90b2NvbC4g QSByb3V0ZXIgbWF5IGhhdmUgc2V2ZXJhbCBNQU5FVCBpbnRlcmZhY2VzLg0KPiBMaW5rOg0KPiBB IGxpbmsgYmV0d2VlbiB0d28gTUFORVQgaW50ZXJmYWNlcyBleGlzdHMgaWYgZWl0aGVyIGNhbiBi ZSBoZWFyZCBieSB0aGUgb3RoZXIuDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gVGhlc2UgYWJvdmUgdGVybXPigJkgZGVmaW5p dGlvbnMgYXJlIGRpZmZlcmVudCB0aGFuIGluIFs0LCA1LCBhbmQgNl0uDQoNClNlZSBjb21tZW50 IGJlZm9yZSByZWdhcmRpbmcgYXBwbGljYWJpbGl0eSBvZiBbNCwgNSwgNl0uIE5IRFAgYW5kIE9M U1J2MiBkZWZpbmUgdGhlaXIgaW50ZXJmYWNlIGV4cGVjdGF0aW9ucy4NCg0KPiBUaGVyZWZvcmUs IHRoZSByZXZpZXdlciB3YW50ZWQgdG8gY2xhcmlmeSB0aGUgZGVmaW5pdGlvbnMgaW4gUkZDNjEz MA0KPiBbMl0sIG9yIHRvIGV4cGxhaW4gdGhlIG9sc3J2Mi1pbnRlcmZhY2UgaW4gbWFuZXQtb2xz cnYyLTE0IFsxXS4NCg0KU29ycnksIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCB5b3UgYXJlIHNh eWluZyBoZXJlLg0KDQo+IFRoZQ0KPiByZXZpZXdlciB3YXMgY29uZnVzZWQgYWJvdXQgdGhlIGRl ZmluaXRpb24gb2YgUkZDNjEzMCBmb3IgYSDigJxMaW5r4oCdLA0KPiBiZWNhdXNlIGl0IGRlc2Ny aWJlcyBpdCBhcyB0aGUgZXhpc3Rpbmcgb2YgbGluay9jb25uZWN0aW9uLA0KDQpUaGF0ICppcyog dGhlIGRlZmluaXRpb24gb2YgbGluaywgdGhvdWdoLCBpbiB0ZXJtcyBvZiByb3V0aW5nLXByb3Rv Y29scy4gQWdhaW4sIGdvIGxvb2sgYXQgd2hhdCAibGluayIgaW4gImxpbmsgc3RhdGUiIG1lYW5z Lg0KDQo+IG5vdCB0aGUNCj4gdGVybSBtZWFuaW5nLg0KDQo/DQoNCj4gIEZ1cnRoZXJtb3JlLCBp dCB3YXMgdXNlZCBpbiBkZWZpbmluZyBhIGxpbmsgaW4gWzEsIDJdDQo+IHJvdXRlcuKAmXMgYXR0 YWNobWVudCB0bywgYnV0IGluIFs0XSBpdCB3YXMgbm9kZeKAmXMgYXR0YWNobWVudCB0bywNCg0K QWdhaW4gWzRdIHdhcyBuZXZlciBwdWJsaXNoZWQgYnkgdGhlIElFVEYgYW5kIGV4cGlyZWQgbW9y ZSB0aGFuIGEgZGVjYWRlIGFnbyAtIGFuZCBkb2Vzbid0IGFwcGx5Lg0KDQo+IHRoZQ0KPiByZXZp ZXdlciBpcyBub3Qgc3VyZSB3aHkgYXV0aG9ycyBpZ25vcmVkIHRoZSBob3N0IChkZXN0aW5hdGlv bikNCj4gY29ubmVjdGlvbiB3aXRoaW4gdGhlIG5ldHdvcmsuDQoNClRoaXMgaXMgcHJlY2lzZWx5 IGJlY2F1c2UgbmVpdGhlciBvZiBPTFNSdjIsIE5IRFAgbm9yIFtNQU5FVF0gIGNvbmNlcm5zIF9y b3V0ZXJzXywgYW5kIGRvZXMgc3BlY2lmaWNhbGx5ICpOT1QqIGNvbmNlcm4gX2hvc3RzXy4NCg0K PiBBbiBpbnRlcmZhY2Ugd2FzIGRlZmluZWQgaW4gWzJdIG5vdA0KPiBhdHRhY2htZW50IHRvIGxp bmssIGJ1dCBhdHRhY2htZW50IHRvIGNvbW11bmljYXRpb24gbWVkaXVtLiBUaGUNCj4g4oCcY29t bXVuaWNhdGlvbiBtZWRpdW3igJ0gd2FzIGRlZmluZWQgaW4gWzRdIGFzIGZyZWUtc3BhY2UsIGNh YmxlLCBvcg0KDQpBZ2FpbiBbNF0gd2FzIG5ldmVyIHB1Ymxpc2hlZCBieSB0aGUgSUVURiBhbmQg ZXhwaXJlZCBtb3JlIHRoYW4gYSBkZWNhZGUgYWdvIC0gYW5kIGRvZXNuJ3QgYXBwbHkuDQoNCj4g ZmliZXIsIHdoaWNoIG1lYW5zIHRoYXQgaW4gWzEsIDJdIG1heSBtYWtlIGEgbWlzbGVhZGluZyBj b25jZXB0IG9mDQo+IGRlZmluaW5nIHRoZSB0ZXJtIOKAnGludGVyZmFjZeKAnS4NCj4gDQoNCk5v LCBpdCBkb2Vzbid0LCBhcyAtIGFnYWluIC0gWzRdIHdhcyBuZXZlciBwdWJsaXNoZWQgYnkgdGhl IElFVEYgYW5kIGV4cGlyZWQgbW9yZSB0aGFuIGEgZGVjYWRlIGFnbyAtIGFuZCBkb2Vzbid0IGFw cGx5Lg0KIA0KVGhvbWFzDQoNCj4gUmVmZXJlbmNlczoNCj4gPT09PT09PT09DQo+IDEtIENsYXVz ZW4sIFQuLCBEZWFybG92ZSwgQy4sIEphY3F1ZXQsIFAuLCBIZXJiZXJnLCBVLiwg4oCcVGhlIE9w dGltaXplZA0KPiBMaW5rIFN0YXRlIFJvdXRpbmcgUHJvdG9jb2wgdmVyc2lvbiAy4oCdLCB3b3Jr IGluIHByb2dyZXNzLCBJRVRGLCBNYXJjaA0KPiAyMDEyLg0KPiAyLSBDbGF1c2VuLCBULiwgRGVh cmxvdmUsIEMuLCBEZWFuLCBKLiwg4oCcTW9iaWxlIEFkIEhvYyBOZXR3b3JrIChNQU5FVCkNCj4g TmVpZ2hib3Job29kIERpc2NvdmVyeSBQcm90b2NvbCAoTkhEUCnigJ0sIFJGQzYxMzAsIElFVEYs IEFwcmlsIDIwMTEuDQo+IDMtICBNZWxpYSwgVC4sIEd1bmRhdmVsbGksIFMuLCDigJxMb2dpY2Fs IEludGVyZmFjZSBTdXBwb3J0IGZvcg0KPiBtdWx0aS1tb2RlIElQIEhvc3Rz4oCdLCB3b3JrIGlu IHByb2dyZXNzLCBJRVRGLCBBcHJpbCwgMjAxMi4NCj4gNC0gUGVya2lucywgQy4s4oCcTW9iaWxl IEFkIEhvYyBOZXR3b3JraW5nIFRlcm1pbm9sb2d54oCdLCB3b3JrIGluDQo+IHByb2dyZXNzLCBJ RVRGLCBOb3YuIDE5OTguDQo+IDUtIE5hcnRlbiwgVC4sIE5vcmRtYXJrLCBFLiwgU2ltcHNvbiwg Vy4sIFNvbGltYW4sIEguLCDigJxOZWlnaGJvcg0KPiBEaXNjb3ZlcnkgZm9yIElQIHZlcnNpb24g NiAoSVB2NinigJ0sIFJGQzQ4NjEsIElFVEYsIFNlcC4gMjAwNy4NCj4gNi0gQmxhbmNoZXQsIE0u LCBTZWl0ZSwgUC4sIOKAnE11bHRpcGxlIEludGVyZmFjZXMgYW5kIFByb3Zpc2lvbmluZw0KPiBE b21haW5zIFByb2JsZW0gU3RhdGVtZW504oCdLCBSRkM2NDE4LCBJRVRGLCBOb3YuIDIwMTEuDQo+ IDctIENvcnNvbiwgUy4sIE1hY2tlciwgSi4sIOKAnE1vYmlsZSBBZCBob2MgTmV0d29ya2luZyAo TUFORVQpOiBSb3V0aW5nDQo+IFByb3RvY29sIFBlcmZvcm1hbmNlIElzc3VlcyBhbmQgRXZhbHVh dGlvbiBDb25zaWRlcmF0aW9uc+KAnSwgUkZDMjUwMSwNCj4gSUVURiwgSmFuLiAxOTk5Lg0KPiAN Cj4gKysrKysrKysrKysrKysrKysrKysrKysrKysNCj4gDQo+IE9uIDUvMS8xMiwgVGhvbWFzIEhl aWRlIENsYXVzZW4gPGlldGZAdGhvbWFzY2xhdXNlbi5vcmc+IHdyb3RlOg0KPj4gDQo+PiANCj4+ IE9uIDEgTWF5IDIwMTIsIGF0IDE0OjMxLCBBYmR1c3NhbGFtIEJhcnl1biA8YWJkdXNzYWxhbWJh cnl1bkBnbWFpbC5jb20+DQo+PiB3cm90ZToNCj4+IA0KPj4+IEhpIENocmlzDQo+Pj4gDQo+Pj4g aWYgaXQgY2Fubm90IGJlIHBoeXNpY2FsIGFuZCBjYW5ub3QgYmUgaW4gdGhlIHVuZGVybHlpbmcg ZGF0YS1saW5rIGxheWVyDQo+Pj4gKGRhdGEgbGluayB3YXMgbWVudGlvbmVkIGluIGRyYWZ0KSwN Cj4+IA0KPj4gVGhhdCB3YXMgbm90IGF0IGFsbCB3aGF0IENocmlzIHdyb3RlLg0KPj4gDQo+Pj4g dGhlbiBJIGRvbid0IGNhcmUgbXVjaCBmb3IgdGhlIGNoYW5nZSBvciBhZGRpdGlvbiwgYnV0IGlm IGl0IGNhbiBiZSBhbGwgaW4NCj4+PiBwaHlzaWNhbCBhbmQgbG9naWNhbCwgSSBiZWxlaXZlIGl0 IG11c3Qgc3RhdGUgYm90aCBwaHlzaWNhbCBhbmQgbG9naWNhbCBhcw0KPj4+IGxvbmcgdGhlIGRy YWZ0IHN0YXRlcyBkYXRhIGxpbmsuDQo+PiANCj4+IE5vLCB0aGF0IGRvZXNuJ3QgZm9sbG93IGVp dGhlci4NCj4+IA0KPj4gVGhvbWFzDQo+PiANCj4+PiBJIGFtIGNvbXBsZXRlbHkgbG9zdCBoZXJl LA0KPj4+IA0KPj4+IEkgc3RhcnRlZCB0byB0aGluayB0byB0aGF0IEkgc2hvdWxkIHdhaXQgZm9y IGFueSBvdGhlciBjb21tZW50ZXJzIGJlZm9yZQ0KPj4+IG15IGxhc3QgcmVwbHkgY29tbWVudHMu DQo+Pj4gDQo+Pj4gQWJkdXNzYWxhbQ0KPj4+IA0KPj4+IE9uIFR1ZSwgTWF5IDEsIDIwMTIgYXQg MToxOSBQTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCj4+PiA8Q2hyaXMuRGVhcmxvdmVA YmFlc3lzdGVtcy5jb20+IHdyb3RlOg0KPj4+IEkgZXhwbGljaXRseSBzYWlkIGl0IGNvdWxkIGJl IHBoeXNpY2FsIChidXQgaXQgZG9lc27igJl0IG1hdHRlcikgaW4gYQ0KPj4+IGRpZmZlcmVudCBl bWFpbCB0aGFuIHRoZSBvbmUgeW91IHF1b3RlZC4NCj4+PiANCj4+PiANCj4+PiANCj4+PiAtLQ0K Pj4+IA0KPj4+IENocmlzdG9waGVyIERlYXJsb3ZlDQo+Pj4gDQo+Pj4gU2VuaW9yIFByaW5jaXBh bCBFbmdpbmVlciwgQ29tbXVuaWNhdGlvbnMgR3JvdXANCj4+PiBDb21tdW5pY2F0aW9ucywgTmV0 d29ya3MgYW5kIEltYWdlIEFuYWx5c2lzIENhcGFiaWxpdHkNCj4+PiBCQUUgU3lzdGVtcyBBZHZh bmNlZCBUZWNobm9sb2d5IENlbnRyZQ0KPj4+IFdlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0 IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsNCj4+PiBUZWw6ICs0NCAxMjQ1IDI0MjE5 NCB8ICBGYXg6ICs0NCAxMjQ1IDI0MjEyNA0KPj4+IA0KPj4+IGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tIHwgaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbQ0KPj4+IA0KPj4+IEJBRSBTeXN0 ZW1zIChPcGVyYXRpb25zKSBMaW1pdGVkDQo+Pj4gUmVnaXN0ZXJlZCBPZmZpY2U6IFdhcndpY2sg SG91c2UsIFBPIEJveCA4NywgRmFybmJvcm91Z2ggQWVyb3NwYWNlIENlbnRyZSwNCj4+PiBGYXJu Ym9yb3VnaCwgSGFudHMsIEdVMTQgNllVLCBVSw0KPj4+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAm IFdhbGVzIE5vOiAxOTk2Njg3DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gRnJvbTogQWJkdXNzYWxh bSBCYXJ5dW4gW21haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbV0NCj4+PiBTZW50OiAw MSBNYXkgMjAxMiAxMjo0MQ0KPj4+IFRvOiBVbHJpY2ggSGVyYmVyZzsgaWV0ZkB0aG9tYXNjbGF1 c2VuLm9yZw0KPj4+IENjOiBtYW5ldDsgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykNCj4+PiBT dWJqZWN0OiBSZTogW21hbmV0XSBDb21tZW50cyBmb3IgT0xTUnYyLTE0DQo+Pj4gDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gKioqIFdBUk5JTkcgKioqDQo+Pj4gDQo+Pj4gVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuDQo+Pj4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQo+Pj4gS2VlcCB0aGlz IGluIG1pbmQgaWYgeW91IGFuc3dlciB0aGlzIG1lc3NhZ2UuDQo+Pj4gUGxlYXNlIHNlZSB0aGlz IHByb2Nlc3Mgb24gaG93IHRvIGRlYWwgd2l0aCBzdXNwaWNpb3VzIGVtYWlscy4NCj4+PiANCj4+ PiBIZXJiZXJnPnNvIGZhciwgbm9ib2R5IGVsc2Ugc2VlbWVkIHRvIGJlIGNvbmZ1c2VkIG9uIHdo aWNoIGxheWVyIE9MU1J2MiBpcw0KPj4+IHVzZWQgKG9yIGhvdyB0aGUgaW50ZXJmYWNlcyBhcmUg ZGVmaW5lZCkuID5JTU8sIHVubGVzcyBvdGhlciBwZW9wbGUgaW4gdGhlDQo+Pj4gV0cgc2VlIHRo ZSBzYW1lIGRhbmdlciBvZiBjb25mdXNpb24sIEkgd291bGQgbm90IGNoYW5nZSBpdC4NCj4+PiAN Cj4+PiBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIHlvdXIgcmVhY3Rpb24sIHNvIHRoYW4gd2FpdCB1 bnRpbCB5b3UgZ2V0IG90aGVyDQo+Pj4gdm9pY2VzIHRoZW4gKG5vdCBzdXJlIGhvdyBtYW55IHlv dSB3YW50KSwgYXMgbG9uZyBhcyB0aGUgZHJhZnQgZG9lc24ndA0KPj4+IGNhcmUgYWJvdXQgZWFj aCBzaW5nbGUgcmV2aWV3LWNvbW1lbnQgaXQgb25seSBmb2xsb3dzIG1ham9yaXR5IGFncmVlbWVu dA0KPj4+IG9uIGNvbW1lbnRzLiBUaGlzIHR5cGUgb2YgcmV2aWV3LXN5c3RlbSBtYWtlcyB0aGUg ZG9jdW1lbnQgbm90IGluY2x1ZGUgYWxsDQo+Pj4gcmVhZGVycyBsZXZlbCBvZiBrbm93bGVkZ2Us IHRoYXQgbWVhbnMgdGhlIGRvY3VtZW50IGlzIGZvciBzcGVjaWZpYyBncm91cA0KPj4+IHdoaWNo IGV4Y2x1ZWRzIG90aGVyIHJlYWRlcnMgb3IgZ3JvdXBzLiBIb3dldmVyLCBJIGp1c3Qgd2lsbCBt ZW50aW9uIG15DQo+Pj4gY29tbWVudHMgYW5kIGRvIG15IHdvcmssIEkgcmVhbGx5IGRvbid0IGNh cmUgb2YgdGhlIG91dGNvbWUgZGVjaXNpb24sIGJ1dA0KPj4+IEkgd2lsbCBjYXJlIGlmIEkgYXV0 aG9yZWQgYSByZXZpZXdlZCBkb2N1bWVudC4NCj4+PiANCj4+PiBjbGF1c2VuPkFuIE9MU1J2MiBp bnRlcmZhY2UgY2FuIGJlIHBoeXNpY2FsIG9yIHZpcnR1YWwuIENocmlzIGV4cGxhaW5lZCBpdA0K Pj4+IHdlbGwsIEkgc3VnZ2VzdCByZS1yZWFkaW5nIGhpcyBlbWFpbC4NCj4+PiANCj4+PiANCj4+ PiANCj4+PiBjaHJpcyBleHBsYWluZWQ+QW4gT0xTUnYyIGludGVyZmFjZSAoYSBzcGVjaWFsIGNh c2Ugb2YgYSBNQU5FVCBpbnRlcmZhY2UsDQo+Pj4gc2VlIFJGQyA2MTMwKSBpcyBhbiBJUCBpbnRl cmZhY2UsIG9uZSB3aGljaCBJUCByZWNlaXZlcyBwYWNrZXRzIG9uLCBoYXMNCj4+PiBvbmUgb3Ig bW9yZSBJUCBhZGRyZXNzZXMgZXRjLiBJdCBoYXMgYSBkYXRhIGxpbmsgbGF5ZXIgYmVsb3cgaXQs IGJ1dA0KPj4+IE9MU1J2MiBkb2VzbuKAmXQgY2FyZSBhYm91dCB0aGF0LiBZb3VyIHN0YXRlbWVu dCDigJxhIE1BTkVUIGludGVyZmFjZSBpcyBhDQo+Pj4gZGF0YSBsaW5rIGludGVyZmFjZeKAnSBp cyB3cm9uZy4NCj4+PiANCj4+PiBPaywgSSByZWFkIGFnYWluLiBJdCBkb2VzIG5vdCBtZW50aW9u IHRoYXQgaXQgbWF5IGJlIHBoeXNpY2FsLiBJDQo+Pj4gdW5kZXJzdGFuZCBmcm9tIGhpbSBpdCBu ZXZlciBjYW4gYmUgcGh5c2ljYWwsIHNvIEkgbmVlZGVkIHRoYXQgdG8gYmUNCj4+PiBjbGVhciwg YnV0IG5vdyB5b3UgbWVudGlvbmVkIHRoYXQgaXQgY2FuIGJlIHBoeXNpY2FsLg0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IEFiZHVzc2FsYW0gQmFyeXVuDQo+Pj4gDQo+Pj4gKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysNCj4+PiANCj4+PiANCj4+PiANCj4+PiBPbiBNb24sIEFwciAzMCwgMjAxMiBhdCAxMDoy OCBQTSwgVWxyaWNoIEhlcmJlcmcgPHVscmljaEBoZXJiZXJnLm5hbWU+DQo+Pj4gd3JvdGU6DQo+ Pj4gDQo+Pj4gQWJkdXNzYWxhbSwNCj4+PiANCj4+PiBzbyBmYXIsIG5vYm9keSBlbHNlIHNlZW1l ZCB0byBiZSBjb25mdXNlZCBvbiB3aGljaCBsYXllciBPTFNSdjIgaXMgdXNlZA0KPj4+IChvciBo b3cgdGhlIGludGVyZmFjZXMgYXJlIGRlZmluZWQpLiBJTU8sIHVubGVzcyBvdGhlciBwZW9wbGUg aW4gdGhlIFdHDQo+Pj4gc2VlIHRoZSBzYW1lIGRhbmdlciBvZiBjb25mdXNpb24sIEkgd291bGQg bm90IGNoYW5nZSBpdC4NCj4+PiANCj4+PiBSZWdhcmRzDQo+Pj4gVWxyaWNoDQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gT24gTW9uLCBBcHIgMzAsIDIwMTIgYXQgMjoxMCBQTSwgQWJkdXNzYWxhbSBC YXJ5dW4NCj4+PiA8YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+ IEhpIEhlcmJlcmcsDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gSSBhbSBzdWdnZXN0aW5nIHRvIGNs YXJpZnkgaW50ZXJmYWNlcywgSSBkb25vdCBsaWtlIHRvIGNoYW5nZSBpZg0KPj4+IHVubmVjZXNz YXJ5LiBNZW50aW9uaW5nIHRoYXQgYW4gaW50ZXJmYWNlIGlzIGluIHRoZSBsYXllciAzLCBvciBp dHMNCj4+PiBsb2dpY2FsLCBvciBldmVuIGp1c3QgZXhwbGFpbmluZyB0aGUgd2F5IENocmlzIGRl ZmluZWQgdG8gbWUsIHJlYWxseSBtYWtlcw0KPj4+IGRpZmZlcmVuY2UuIE15IHF1ZXN0aW9uIGlz IHdoeSBpcyB0aGUgZHJhZnQgbm90IG1lbnRpb25pbmcgdGhhdA0KPj4+IE9MU1J2Mi1pbnRlcmZh Y2UgaXMgYW4gSVAtaW50ZXJmYWNlIG9yIGEgbG9naWNhbC1pbnRlcmZhY2U/IERvZXMgdGhlDQo+ Pj4gYXV0aG9ycyBzZWUgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbXBvcnRhbnQ/IG9y IGV2ZW4NCj4+PiBNQU5FVC1pbnRlcmZhY2VzIGFyZSBpbiBsYXllciAzLiAgSWYgd2UgZGVmaW5l IHByb3RvY29scyB3aXRob3V0DQo+Pj4gbWVudGlvbmluZyB3aGljaCBsYXllciBpdCBpcyBsb2Nh dGVkIGluLCB0aGVuIGhvdyBjYW4gd2UgZGVmaW5lIHN1Y2gNCj4+PiBwcm90b2NvbCwgaXRzIGxh eWVyLWxvY2F0aW9uIGlzIG1vcmUgaW1wb3J0YW50IHRoYW4gaXRzIGZ1bmN0aW9uYWxpdHksDQo+ Pj4gYmVjYXVzZSBlYWNoIGxheWVyIGhhcyBpdHMgc3BlY2lhbCBpbnRlcmZhY2VzLCBmdW5jdGlv bnMsIHNlcnZpY2VzLCBhbmQNCj4+PiBtZXNzYWdlcy4gVGhlcmUgYXJlIG1hbnkgZG9jdW1lbnRz IHRoYXQgZXhwbGFpbiBpbnRlcmZhY2UgaW4gdGhlIHNhbWUNCj4+PiBtb2RlbCB0aGF0IE9MU1J2 MiBpcyBwcmVzZW50aW5nIHNvIHdoeSBkaWRuJ3QgaGF2ZSBjb25mdXNpb24gd2hlbiBJIHJlYWQN Cj4+PiB0aGVtPw0KPj4+IA0KPj4+PiBBbiBPTFNSdjIgaW50ZXJmYWNlIChhIHNwZWNpYWwgY2Fz ZSBvZiBhIE1BTkVUIGludGVyZmFjZSwgc2VlIFJGQyA2MTMwKQ0KPj4+PiBpcyBhbiBJUCBpbnRl cmZhY2UsIG9uZSB3aGljaCBJUCA+cmVjZWl2ZXMgcGFja2V0cyBvbiwgaGFzIG9uZSBvciBtb3Jl DQo+Pj4+IElQIGFkZHJlc3NlcyBldGMuIEl0IGhhcyBhIGRhdGEgbGluayBsYXllciBiZWxvdyBp dCwgYnV0IE9MU1J2MiBkb2VzbuKAmXQNCj4+Pj4+IGNhcmUgYWJvdXQgdGhhdC4gWW91ciBzdGF0 ZW1lbnQg4oCcYSBNQU5FVCBpbnRlcmZhY2UgaXMgYSBkYXRhIGxpbmsNCj4+Pj4gaW50ZXJmYWNl 4oCdIGlzIHdyb25nLg0KPj4+IA0KPj4+PiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBjb25m dXNpb24uIENocmlzIGhhcyBwb2ludGVkIG91dCB0aGUNCj4+Pj4gcmVsYXRpb25zaGlwIGJldHdl ZW4gTUFORVQgaW50ZXJmYWNlIGFuZCBPTFNSdjIgPmludGVyZmFjZSBjbGVhcmx5LiBJDQo+Pj4+ IHRoaW5rIHRoYXQgUkZDNjEzMC9kcmFmdC1pZXRmLW1hbmV0LW9sc3J2MiBkZWZpbmUgdGhlIHRl cm1pbm9sb2d5DQo+Pj4+IGNvcnJlY3RseS4gSWYgeW91IHdvdWxkIGxpa2UgdG8gPmNoYW5nZSBh bnl0aGluZywgcGxlYXNlIHN1Z2dlc3QNCj4+Pj4gY29uY3JldGUgdGV4dCB0byByZXBsYWNlLCBz byB0aGF0IEkgY2FuIGJldHRlciB1bmRlcnN0YW5kIHdoYXQgeW91DQo+Pj4+IG1lYW4uDQo+Pj4g DQo+Pj4gSSBkaXNhZ3JlZSB0aGF0IHRoZXJlIGlzIG5vIGNvbmZ1c2lvbi4gVGhlcmUgYXJlIGNv bmZ1c2lvbnMgaW4gZGVmaW5pbmcNCj4+PiB0ZXJtcyBpbiBNQU5FVCBXRywgSSBoYXZlIHNlZW4g aW4gdGhlIHBhc3QgYSBsb25nIGRpc2N1c3Npb24gYmV0d2VlbiBtYW55LA0KPj4+IGp1c3QgYXJn dWluZyBhYm91dCBkZWZpbmluZyBob3N0IG9yIHJvdXRlciwgYW5kIG5vdyBsIHdhcyBjb25mdXNl ZCBvZg0KPj4+IGludGVyZmFjZXMgaW4gT0xTUnYyLWRyYWZ0LiBNYXliZSBiZWNhdXNlIEkgYW0g bm90IG11Y2ggZmFtaWxpYXIgd2l0aA0KPj4+IE9MU1IsIG9yIHJlYWRpbmcgYWJvdXQgbmV0d29y ay1pbnRlcmZhY2UgaW4gbWFueSBwYXBlcnMsIGFuZCBJIHJlYWQNCj4+PiBSRkMyNTAxIChpdCBy ZWZlcnMgYWxvdCB0byB3aXJlbGVzcyBpbnRlcmZhY2UgYW5kIGNvbW11bmljYXRpb25zKSBhbmQN Cj4+PiBtZW50aW9uZWQgaW4gUkZDNjEzMCBmb3IgdGhlIGludGVyZmFjZSBhcyBhdHRhY2ggdG8g Y29tbXVuaWNhdGlvbiBtZWRpdW0sDQo+Pj4gSSB0aG91Z2h0IGl0IHdhcyBhIG1lZGl1bSBhcyBw aHlzaWNhbCBtZWRpdW0uDQo+Pj4gDQo+Pj4gSSBzdWdnZXN0IHRvIGNsYXJpZnkgYnkgYWRkaW5n IGluZm9ybWF0aW9uIGluIG9uZSBvZiB0aGUgZm9sbG93aW5nDQo+Pj4gZXhwbGFuYXRpb24gdG8g dGhlIGRyYWZ0IChldmVuIGEgbGluZSB3aWxsIGRvKToNCj4+PiANCj4+PiANCj4+PiANCj4+PiAt IE1lbnRpb25pbmcgd2hpY2ggbGF5ZXIocykgdGhlIE9MU1J2Mi1pbnRlcmZhY2Ugd29ya3Mgb3Ig YWxsb3dlZCB0byBiZSBhdA0KPj4+IGJ5IHRoZSBwcm90b2NvbCwgb3INCj4+PiANCj4+PiAtIGRl ZmluaW5nIHRoZSBNQU5FVC1pbnRlcmZhY2UgYXMgQ2hyaXMgZGVmaW5lZCAoSVAtaW50ZXJmYWNl LCBhdCBsYXllciAzKQ0KPj4+IGluIHRlcm1pbm9sb2d5LCBvcg0KPj4+IA0KPj4+IC0gbWVudGlv bmluZyB0aGF0IE9MU1J2Mi1pbnRlcmZhY2UgaXMgbm90IGEgd2lyZWxlc3MgaW50ZXJmYWNlLCBv cg0KPj4+IA0KPj4+IC0gZGVmaW5pbmcgTUFORVQtaW50ZXJmYWNlIGFzIGxvZ2ljYWwgaW50ZXJm YWNlLg0KPj4+IA0KPj4+IA0KPj4+IEkgYW0gc29ycnkgdG8gZGlzdHVyYiwgSSBhY3R1YWxseSBz dGlsbCBoYXZlIG1hbnkgY29tbWVudHMgZm9yDQo+Pj4gT0xTUnYyLWRyYWZ0IGFuZCB3aWxsIHRy eSB0byBzdWJtaXQsIGFuZCBsZXQgdGhlIFdHIHRvIGRlY2lkZS4gSG93ZXZlciwgSQ0KPj4+IHRo YW5rIHlvdSBhbmQgQ2hyaXMgdG8gZXhwbGFpbiB0byBtZSBzbyBhdCBsZWFzdCBteSBvdGhlciBj b21tZW50cyB3aWxsIGJlDQo+Pj4gaW4gdW5kZXJzdGFuZGluZy4NCj4+PiANCj4+PiBBYmR1c3Nh bGFtDQo+Pj4gKysrKysrKysrKysrKysrKysrDQo+Pj4gDQo+Pj4gT24gTW9uLCBBcHIgMzAsIDIw MTIgYXQgNTo0NSBQTSwgVWxyaWNoIEhlcmJlcmcgPHVscmljaEBoZXJiZXJnLm5hbWU+DQo+Pj4g d3JvdGU6DQo+Pj4gDQo+Pj4gQWJkdXNzYWxhbSwNCj4+PiANCj4+PiBSRkM2MTMwIGRlZmluZXM6 DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gTUFORVQgaW50ZXJmYWNlOg0KPj4+IEFuIGludGVyZmFj ZSBwYXJ0aWNpcGF0aW5nIGluIGEgTUFORVQgYW5kIHVzaW5nIHRoaXMgbmVpZ2hib3Job29kDQo+ Pj4gICAgICBkaXNjb3ZlcnkgcHJvdG9jb2wuICBBIHJvdXRlciBtYXkgaGF2ZSBzZXZlcmFsIE1B TkVUIGludGVyZmFjZXMuDQo+Pj4gDQo+Pj4gQW5kIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyIGRl ZmluZXM6DQo+Pj4gDQo+Pj4gDQo+Pj4gT0xTUnYyIGludGVyZmFjZToNCj4+PiAgICAgIEEgTUFO RVQgaW50ZXJmYWNlIHJ1bm5pbmcgdGhpcyBwcm90b2NvbC4gIEEgcm91dGVyIHJ1bm5pbmcgdGhp cw0KPj4+ICAgICAgcHJvdG9jb2wgTVVTVCBoYXZlIGF0IGxlYXN0IG9uZSBPTFNSdjIgaW50ZXJm YWNlLg0KPj4+IA0KPj4+IEluIG9uZSBvZiB0aGUgbGFzdCBPTFNSdjIgcmV2aXNpb25zLCB3ZSBt YWRlIHN1cmUgdGhhdCBPTFNSdjINCj4+PiBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIG5laWdoYm9y cyBydW5uaW5nIG9ubHkgTkhEUCBhbmQgbmVpZ2hib3JzIHJ1bm5pbmcNCj4+PiBhbHNvIE9MU1J2 MiwgYW5kIG9ubHkgdGhlIGxhdHRlciBhcmUgdXNlZCBmb3IgTVBSIHNlbGVjdGlvbiwgZXRjLiBJ IGRvIG5vdA0KPj4+IHVuZGVyc3RhbmQgd2hhdCB5b3Ugd291bGQgbGlrZSB0byBjaGFuZ2UgaW4g dGhlIE9MU1J2MiBkcmFmdC4NCj4+PiANCj4+PiBTZWUgY29tbWVudHMgYmVsb3c6DQo+Pj4gDQo+ Pj4gT24gTW9uLCBBcHIgMzAsIDIwMTIgYXQgODoyNCBBTSwgQWJkdXNzYWxhbSBCYXJ5dW4NCj4+ PiA8YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIEhlbm5p bmcsDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gUGxlYXNlIG5vdGUgdGhhdCBJIHJlYWQgdGhlIGZp cnN0IHBhZ2VzIG9mIGRyYWZ0IG1hbnkgdGltZXMgYmVmb3JlIHBvc3RpbmcNCj4+PiBhbnkgaW5m b3JtYXRpb24uDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gSFI+SSB3b3VsZCBzdWdnZXN0IHJlYWRp bmcgdGhlIE9MU1J2Mi1kcmFmdCBhZ2FpbiwgZXNwZWNpYWxseSBzZWN0aW9uIDIuDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4+IE9MU1J2MiBpbnRlcmZhY2U6DQo+Pj4+IEEgTUFORVQgaW50ZXJmYWNl IHJ1bm5pbmcgdGhpcyBwcm90b2NvbC4gIEEgcm91dGVyIHJ1bm5pbmcgdGhpcw0KPj4+PiBwcm90 b2NvbCBNVVNUIGhhdmUgYXQgbGVhc3Qgb25lIE9MU1J2MiBpbnRlcmZhY2UuDQo+Pj4gDQo+Pj4g SFI+QSByb3V0aW5nIHByb3RvY29sIHdoaWNoIGRvZXMgbm90IHJ1biBvbiBhbnkgaW50ZXJmYWNl IHdvdWxkIGJlIHByZXR0eQ0KPj4+PiB1c2VsZXNzLCByaWdodD8NCj4+PiANCj4+PiBZb3UgcmVw bHkgdG8gdGhlIHNlY29uZCBzZW50ZW5jZSBub3QgdGhlIGZpcnN0IHdoaWNoIGhhcyAncnVubmlu ZyB0aGlzDQo+Pj4gcHJvdG9jb2wnIHJlbGF0aW5nIGl0IG5vdCB0byB0aGUgcm91dGVyIGl0IGlz IHJlbGF0aW5nIGl0IHRvIHRoZQ0KPj4+IGludGVyZmFjZS4gSSBrbm93IHRoYXQgcm91dGVyIG11 c3QgaGF2ZSBhdCBsZWFzdCBhIG5ldHdvcmstaW50ZXJmYWNlICggb3INCj4+PiBkYXRhLWxpbmst bGF5ZXIpIG9yIE1BTkVUIGludGVyZmFjZSwgdGhpcyBpcyBub3Qgd2hhdCBJIGNvbW1lbnRpbmcg YW5kIHRoZQ0KPj4+IGRyYWZ0IGlzIG1lbnRpb25pbmcuIFdlIGRvbid0IGFzc3VtZSBhdCBsZWFz dCBEYXRhLUxpbmsgYmVjYXVzZSBpdCBpcw0KPj4+IG9idmlvdXMgYW5kIHdlIGFyZSBmb2xsb3dp bmcgVENQL0lQIG1vZGVsIGluIHRoZSBpbnRlcm5ldCwgYnV0IG5vdCBhdA0KPj4+IGxlYXN0IGEg c3BlY2lmaWMtaW50ZXJmYWNlIGNhbGxlZCBibGEgYmxhLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+ IFdoeSBpdCBkZWZpbmVzIHRoZSAnT0xTUnYyLWludGVyZmFjZScgYXMgYSBNQU5FVC1pbnRlcmZh Y2UgdGhhdCBSVU5TIHRoaXMNCj4+PiBwcm90b2NvbCAoT0xTUnYyKSB0aGlzIG1lYW5zIHRoZXJl IGlzIHNvbWUgdGhpbmcgcmVsYXRlZCB0byBPTFNSdjIgaW4gdGhlDQo+Pj4gbGF5ZXItMi4gWW91 IHNob3VsZCByZWFkIGFnYWluIGFub3RoZXIgcGFyYWdyYXBoIG1lbnRpb25pbmcgYXMgaWYgdGhl cmUgaXMNCj4+PiBkaWZmZXJlbmNlIGJldHdlZW4gTUFORVQtaW50ZXJmYWNlIGFuZCBPTFNSdjIt aW50ZXJmYWNlLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IE9MU1J2Mi0xND5wOT4NCj4+PiANCj4+ PiBTdXBwb3J0cyByb3V0ZXJzIHRoYXQgZWFjaCBoYXZlIG9uZSBvciBtb3JlIHBhcnRpY2lwYXRp bmcgT0xTUnYyDQo+Pj4gDQo+Pj4gaW50ZXJmYWNlcywgd2hpY2ggd2lsbCBjb25zaXN0IG9mIHNv bWUgb3IgYWxsIG9mIGl0cyBNQU5FVA0KPj4+IA0KPj4+IGludGVyZmFjZXMgdXNpbmcgW1JGQzYx MzBdLiBUaGUgc2V0IG9mIGEgcm91dGVy4oCZcyBPTFNSdjINCj4+PiANCj4+PiBpbnRlcmZhY2Vz LCBhbmQgdGhlIHNldHMgb2YgaXRzIG90aGVyIE1BTkVUIGFuZCBub24tTUFORVQNCj4+PiANCj4+ PiBpbnRlcmZhY2VzLCBtYXkgY2hhbmdlIG92ZXIgdGltZS4gRWFjaCBpbnRlcmZhY2UgbWF5IGhh dmUgb25lIG9yDQo+Pj4gDQo+Pj4gbW9yZSBuZXR3b3JrIGFkZHJlc3NlcyAod2hpY2ggbWF5IGhh dmUgcHJlZml4IGxlbmd0aHMpLCBhbmQgdGhlc2UNCj4+PiANCj4+PiBtYXkgYWxzbyBiZSBkeW5h bWljYWxseSBjaGFuZ2luZy4NCj4+PiANCj4+PiANCj4+PiANCj4+PiBBQj4gaXQgaXMgY2xlYXIg ZnJvbSB0aGUgYWJvdmUgZHJhZnQtcGFnZS05LCB0aGF0IGFsbCBNQU5FVCBpbnRlcmZhY2VzIGFy ZQ0KPj4+IG5vdCBhbiBPTFNSdjItaW50ZXJmYWNlLCBidXQgQWxsIE9MU1J2MiBpbnRlcmZhY2Vz IGFyZSBNQU5FVC1pbnRlcmZhY2VzLg0KPj4+IFNvIHdlIGhhdmUgdG8gaGF2ZSBpbiBvciBub2Rl IGF0IGxlYXN0IGFuIE9MU1J2Mi1pbnRlcmZhY2UsIG5vdCBhdCBsZWFzdA0KPj4+IG9uZSBNQU5F VC1pbnRlcmZhYyBzbyB0aGUgcHJvdG9jb2wgdG8gd29yayBjb3JyZWN0bHkuDQo+Pj4gDQo+Pj4g DQo+Pj4gDQo+Pj4gQUI+IFRoZSBhYm92ZSBwYWdlLTkgbWVudGlvbnMgTkhEUCBhcyB3ZWxsIHRo YXQgaW50ZXJmYWNlcyBuZWVkIHRoaXMNCj4+PiBwcm90b2NvbC4gV2hhdCBpZiB0aGVyZSBpcyBu b3QgTkhEUCwgb3IgaWYgaXQgaXMgbm90IHdvcmtpbmcsIHdoYXQgd2lsbA0KPj4+IGhhcHBlbi4g VGhlIGRyYWZ0IFNIT1VMRCBleHBsYWluIHRoZXNlIGlzc3Vlcy4NCj4+PiANCj4+PiANCj4+PiAN Cj4+PiANCj4+PiANCj4+PiBBQj4gSXQgbWF5IGJlIHRoYXQgYWxsIE9MU1J2MiByb3V0ZXJzIChh cyBpbXBsZW1lbnRhdGlvbiBwb2ludCBvZg0KPj4+IHByYWN0aWNlKSBvbmx5IG5lZWQgYXQgbGVh c3Qgb25lIE1BTkVUIGludGVyZmFjZS4gQnV0IHRoZSBhdXRob3JzIG5lZWQgdG8NCj4+PiBjaGFu Z2UuIHRoZXJlZm9yZSwgd2Uga25vdyB0aGF0IEFsbCByb3V0ZXJzIG5lZWQgYXQgbGVhc3Qgb24g aW50ZXJmYWNlLA0KPj4+IGJ1dCB0aGUgZHJhZnQtd29yZGluZyBoYXMgYSBzcGVjaWFsIE9MU1J2 Mi1pbnRlcmZhY2UuIFRoZW4gd2UgbmVlZCB0bw0KPj4+IGNoYW5nZSB0aGUgZHJhZnQgd29yZGlu ZyB0byB0aGUgcmlnaHQgZXhwbGFpbmF0aW9uLg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IENhbiB5 b3Ugc3VnZ2VzdCB3aGF0IHlvdSB3b3VsZCBsaWtlIHRvIGNoYW5nZT8gSSBkb24ndCB1bmRlcnN0 YW5kIHlvdXINCj4+PiBwb2ludC4NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMNCj4+PiBVbHJpY2gN Cj4+PiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrDQo+Pj4gDQo+ Pj4gDQo+Pj4gDQo+Pj4gSGkgQ2hyaXMNCj4+PiANCj4+PiANCj4+PiANCj4+PiBvayB0aGVuIGlm IGl0IHdhcyBzaW1wbGUgdG8gZXhwbGFpbiBhcyBhIHNwZWNpYWwgaW50ZXJmYWNlIGFzIElQLWlu dGVyZmFjZQ0KPj4+IHdoeSB3ZSBoYXZlIE9MU1J2Ml9kcmFmdCBzYXlpbmcgdGhhdCBpdCBpcyBu ZXR3b3JrLWludGVyZmFjZSBhcyBNQU5FVCBpcyBhDQo+Pj4gbmV0d29yaywgYnV0IElQIGlzIG5v dCBpdCBpcyBhIHByb3RvY29sLiBJTU8gaXQgaXMgd3JvbmcgdG8gcmVmZXIgdG8gYQ0KPj4+IG5l dHdvcmsgd2hpbGUgeW91IG1lYW4gYSBwcm90b2NvbCwgZXZlbiB0aG91Z2ggSSBrbm93IEkgbWF5 IG1pc3VuZGVyc3Rvb2QuDQo+Pj4gSSBzdWdnZXQgdGhhdCB0aGlzIFNIT1VMRCBiZSBleHBsYWlu ZWQgY2xlYXJseS4gSSB0aGluayBldmVyeSBvbmUgc2VlbXMgdG8NCj4+PiB1bmRlcnN0YW5kIHRo YXQgbmV0d29yay1pbnRlcmZhY2UgbXVzdCBpbmNsdWRlIERhdGEtTGluay1sYXllciwgdGhlcmVm b3JlLA0KPj4+IFJGQzYxMzAgb3IgT0xTUnYyLWRyYWZ0IHNob3VsZCBkZWZpbmUgd2VsbCBhcyB5 b3UgZGlkLiBJIHRoYW5rIHlvdSBmb3INCj4+PiB5b3VyIGNvbW1lbnQsDQo+Pj4gDQo+Pj4gDQo+ Pj4gDQo+Pj4gVGhlcmVmb3JlIEkgc3VnZ2VzdCB0byBjaGFuZ2UgT0xTUnYyLWludGVyZmFjZSBk ZWZpbml0aW9uIGFzIENocmlzIGRlZmluZWQNCj4+PiBpdCB2ZXJ5IGNsZWFybHkuIEkgaG9wZSB0 aGUgZHJhZnQgY2FuIGNoYW5nZSB0aGUgZGVmaW5pdGlvbiwNCj4+PiANCj4+PiANCj4+PiANCj4+ PiBBYmR1c3NhbGFtDQo+Pj4gDQo+Pj4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKw0KPj4+IE9uIE1vbiwgQXBy IDMwLCAyMDEyIGF0IDQ6MjUgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQo+Pj4gPENo cmlzLkRlYXJsb3ZlIGF0IGJhZXN5c3RlbXMuY29tPiB3cm90ZToNCj4+PiANCj4+PiANCj4+PiAN Cj4+PiBBbiBPTFNSdjIgaW50ZXJmYWNlIChhIHNwZWNpYWwgY2FzZSBvZiBhIE1BTkVUIGludGVy ZmFjZSwgc2VlIFJGQyA2MTMwKSBpcw0KPj4+IGFuIElQIGludGVyZmFjZSwgb25lIHdoaWNoIElQ IHJlY2VpdmVzIHBhY2tldHMgb24sIGhhcyBvbmUgb3IgbW9yZSBJUA0KPj4+IGFkZHJlc3NlcyBl dGMuIEl0IGhhcyBhIGRhdGEgbGluayBsYXllciBiZWxvdyBpdCwgYnV0IE9MU1J2MiBkb2VzbuKA mXQgY2FyZQ0KPj4+IGFib3V0IHRoYXQuIFlvdXIgc3RhdGVtZW50IOKAnGEgTUFORVQgaW50ZXJm YWNlIGlzIGEgZGF0YSBsaW5rIGludGVyZmFjZeKAnSBpcw0KPj4+IHdyb25nLg0KPj4+IA0KPj4+ IA0KPj4+IA0KPj4+IC0tDQo+Pj4gDQo+Pj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4+PiANCj4+ PiBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyLCBDb21tdW5pY2F0aW9ucyBHcm91cA0KPj4+IENv bW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0eQ0KPj4+ IEJBRSBTeXN0ZW1zIEFkdmFuY2VkIFRlY2hub2xvZ3kgQ2VudHJlDQo+Pj4gV2VzdCBIYW5uaW5n ZmllbGQgUm9hZCwgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBDTTIgOEhOLCBVSw0KPj4+IFRl bDogKzQ0IDEyNDUgMjQyMTk0IHwgIEZheDogKzQ0IDEyNDUgMjQyMTI0DQo+Pj4gDQo+Pj4gY2hy aXMuZGVhcmxvdmUgYXQgYmFlc3lzdGVtcy5jb20gfCBodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29t DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioNCj4+PiBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVu dGlhbCB0byB0aGUgaW50ZW5kZWQNCj4+PiByZWNpcGllbnQgYW5kIG1heSBhbHNvIGJlIHByaXZp bGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPj4+IHJlY2lwaWVudCBwbGVhc2Ug ZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KPj4+IFlv dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv c2Ugb3INCj4+PiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLg0K Pj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqDQo+Pj4gDQo+Pj4gDQo+PiANCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQo= From internet-drafts@ietf.org Fri May 11 14:41: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 60CC621F86E1; Fri, 11 May 2012 14:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, 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 t7ovEJePvGCZ; Fri, 11 May 2012 14:41:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7CA21F86C7; Fri, 11 May 2012 14:41:17 -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: <20120511214117.11628.53234.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 14:41:17 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-04.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, 11 May 2012 21:41:18 -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 Optimized Link St= ate Routing Protocol version 2 Author(s) : Ulrich Herberg Robert G. Cole Thomas Heide Clausen Filename : draft-ietf-manet-olsrv2-mib-04.txt Pages : 68 Date : 2012-05-11 This document defines the Management Information Base (MIB) module for configuring and managing the Optimized Link State Routing protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured into state information, performance metrics, and notifications. This additional state and performance information is useful to troubleshoot problems and performance issues of the routing protocol. Different levels of compliance allow implementers to use smaller subsets of all defined objects, allowing for this MIB module to be deployed on more constrained routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-mib-04.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-olsrv2-mib-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ From ulrich@herberg.name Fri May 11 14:45: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 57E0F21F866E for ; Fri, 11 May 2012 14:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.875 X-Spam-Level: X-Spam-Status: No, score=-2.875 tagged_above=-999 required=5 tests=[AWL=0.101, 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 R0jSC9ZDEiVu for ; Fri, 11 May 2012 14:45:35 -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 6058A21F8666 for ; Fri, 11 May 2012 14:45:35 -0700 (PDT) Received: by qabj40 with SMTP id j40so2205009qab.15 for ; Fri, 11 May 2012 14:45:35 -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 :content-type; bh=cqamEiEquVbcscpJ2ibZjIfLPsxOF1xUUDfT/cnIQxo=; b=Y73IQbEsM5WavV1kf2KN6i+BboXpEs0Nv4hW2omiZ2esmjdF2SgwCY5quIsoAXvp4Q Ol8ktuJbqAwh4QiSXwnswoUZ2WyVCrLSB4NVk3ep1REanrr4eKneX8L/s+aZI/b7gKZN 4ZhZjW3D1cFFZiKQ3h9ECJ2Azxd8VVuUq/Q1Y= 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 :content-type:x-gm-message-state; bh=cqamEiEquVbcscpJ2ibZjIfLPsxOF1xUUDfT/cnIQxo=; b=Uj/TQkspkxKZ3Mw0SvOK66NLuD+a01DQ5caJnM9T8/9w5uDKL7vYTYQIVvBn7Ezq8i wTycstFOMtiwGTE895tYyYvKrdRigMKaN6XV8G4tjoKm20dewKm+CAMasJgRd+opwkzN yymcEpl5+uDNYPkeGi6KUo3/1MQuvtJrSv2G8TiviTDpmjq/4W+GrLaHulDNRh50YO2i TwQe1aHyxbVTT8hXin4q/1VkaaRmroGF+GAzz1gR9WQ3b/y/djonNvUIz7tEC15XKMuc Sxs4NQM35IObw3kjpCv02IeHqF2w5+YBHMlFwCmJ9LAzYV+IByxF/A1RY06zu+bMpZaY 3Rlw== MIME-Version: 1.0 Received: by 10.224.220.204 with SMTP id hz12mr7464066qab.65.1336772734887; Fri, 11 May 2012 14:45:34 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Fri, 11 May 2012 14:45:34 -0700 (PDT) In-Reply-To: <20120511214117.11628.53234.idtracker@ietfa.amsl.com> References: <20120511214117.11628.53234.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 14:45:34 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: multipart/alternative; boundary=20cf3071d1dc0226c504bfc9a88e X-Gm-Message-State: ALoCoQlMtxr1RXwL78OHj8ykeVvHofPM9VWHPadyQTeRty92GayluBU7ZoAyDtPThsTvHUYqBoXW Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-mib-04.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, 11 May 2012 21:45:36 -0000 --20cf3071d1dc0226c504bfc9a88e Content-Type: text/plain; charset=ISO-8859-1 Hi, I have revived the OLSRv2 MIB and updated it quite a lot in the same way we updated the NHDP-MIB. I also included the new fields from OLSRv2 that have been added since the metrics have been folded in. Note that the indexing between the Link/2-hop set from OLSRv2 to NHDP still needs to be fixed in the next revision. A thorough read-through from us will follow, once the NHDP-MIB is (hopefully) approved by the IESG. Regards Ulrich On Fri, May 11, 2012 at 2:41 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Mobile Ad-hoc Networks > Working Group of the IETF. > > Title : Definition of Managed Objects for the Optimized > Link State Routing Protocol version 2 > Author(s) : Ulrich Herberg > Robert G. Cole > Thomas Heide Clausen > Filename : draft-ietf-manet-olsrv2-mib-04.txt > Pages : 68 > Date : 2012-05-11 > > This document defines the Management Information Base (MIB) module > for configuring and managing the Optimized Link State Routing > protocol version 2 (OLSRv2). The OLSRv2-MIB module is structured > into state information, performance metrics, and notifications. This > additional state and performance information is useful to > troubleshoot problems and performance issues of the routing protocol. > Different levels of compliance allow implementers to use smaller > subsets of all defined objects, allowing for this MIB module to be > deployed on more constrained routers. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-mib-04.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-olsrv2-mib-04.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-mib/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --20cf3071d1dc0226c504bfc9a88e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have revived the OLSRv2 MIB and updated it quite a lot in the = same way we updated the NHDP-MIB. I also included the new fields from OLSRv= 2 that have been added since the metrics have been folded in.
Note that = the indexing between the Link/2-hop set from OLSRv2 to NHDP still needs to = be fixed in the next revision. A thorough read-through from us will follow,= once the NHDP-MIB is (hopefully) approved by the IESG.

Regards
Ulrich

On Fri, May 11, 201= 2 at 2:41 PM, <internet-drafts@ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Definition of Managed Objects f= or the =A0Optimized Link State Routing Protocol version 2
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ulrich Herberg
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Robert G. Cole
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thomas Heide Clausen =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-manet-olsrv2-mib-04.tx= t
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 68
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-05-11

=A0 This document defines the Management Information Base (MIB) module
=A0 for configuring and managing the Optimized Link State Routing
=A0 protocol version 2 (OLSRv2). =A0The OLSRv2-MIB module is structured =A0 into state information, performance metrics, and notifications. =A0Thi= s
=A0 additional state and performance information is useful to
=A0 troubleshoot problems and performance issues of the routing protocol.<= br> =A0 Different levels of compliance allow implementers to use smaller
=A0 subsets of all defined objects, allowing for this MIB module to be
=A0 deployed on more constrained routers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ma= net-olsrv2-mib-04.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-mane= t-olsrv2-mib-04.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-m= ib/

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

--20cf3071d1dc0226c504bfc9a88e-- From okaytion@gmail.com Sun May 13 11:39: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 643BF21F8546 for ; Sun, 13 May 2012 11:39:32 -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, 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 7nlLr37rRzVX for ; Sun, 13 May 2012 11:39: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 D930621F8539 for ; Sun, 13 May 2012 11:39:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5156544vbb.31 for ; Sun, 13 May 2012 11:39:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version; bh=S4mpyi+owDxttvzOUoCqsRKBgxGSuWP2K+Onibu77J8=; b=thbtphSDKPt4+Tjq3Z2ja7TO0OIXEvYytwY9K14T6AU/mZCzDs3IRk2AB3ww9rkLol EOGnvOl2VpI45kedFfzcdgydKxMwbbPsHn1nyEeBmCAztY5rrjHh44iK8wTkJxKSgZ1F 8KRcS6yewDWRKQ03sVzViQsx7h+Hl55yLGkz9jJKKiwhYiMUAm+7Tg3ElbOEz2mf+C+n D6Wf/FBcm9Azt8B8bcFeGL/qA3dV0/h2fng4C3jSwm35ItBFSuetft0tbVkman6fTe0c Q2JTkPyxVMN65UApEKW7y7g/ITsBK/AVEkBXWnVeT3d1DfiDF6ku/NbKI92m8z6OmOsb T/NQ== Received: by 10.221.13.201 with SMTP id pn9mr3499534vcb.70.1336934371269; Sun, 13 May 2012 11:39:31 -0700 (PDT) Received: from [192.168.2.18] (fctnnbsc30w-156034228166.dhcp-dynamic.FibreOp.nb.bellaliant.net. [156.34.228.166]) by mx.google.com with ESMTPS id bv19sm19275114vdc.19.2012.05.13.11.39.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 13 May 2012 11:39:30 -0700 (PDT) From: Okaytion Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9A405) Message-Id: <6DFE6C1A-8210-449F-9A4F-94C5FCB53123@gmail.com> Date: Sun, 13 May 2012 15:39:27 -0300 To: "manet@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: [manet] Manet node movement 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, 13 May 2012 18:45:57 -0000 How can I calculate the next node movement in ns2 based on the state of a no= de i.e maybe distance ? Transmission rate ? Range ?? Position ? Any clue Thanks Sent from Al's iPhone= From cpetrioli@gmail.com Mon May 14 04:30: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 1445821F86D3 for ; Mon, 14 May 2012 04:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, 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 251+t5R9wRSh for ; Mon, 14 May 2012 04:30:14 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1283921F86CB for ; Mon, 14 May 2012 04:30:13 -0700 (PDT) Received: by yhgm50 with SMTP id m50so5243897yhg.13 for ; Mon, 14 May 2012 04:30: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; bh=xrxCHn3IBmQoXBk7irkpb+koh6rIurzHvdUT2M3PNoE=; b=GPxGL5EbThQ85igdtUcuIyeO+suhQdDkm2ulvOL9m6Lz6TnmxToi0lhvPzwn+fpunL Ju6x7BeqThSP9Jir/3fIw6p7qB3bR1sEC5hzgaqksQy+gquxXTcMH3O32DjAHZNIgQIE S2sE76yIqgmoUTMVmCOL3QjxnUCiNrpuJCCnsB6zybP67NfLo/tUhjFOCCk2oF8mYwOO eSavaV/DrXYA+FRYt5/4YqMQyJ56TBhAB1qe1yRSFdn1rrSZBMaW6vowTFZTjpljs8z4 +BjYqm0RBGKjsx5XCpvnut7vRx3eMPwe/umHXSaHsF5LzC6Dru0kyFbEwXOY5f0sN829 g9Cg== MIME-Version: 1.0 Received: by 10.50.187.228 with SMTP id fv4mr4512355igc.10.1336995013391; Mon, 14 May 2012 04:30:13 -0700 (PDT) Received: by 10.42.169.4 with HTTP; Mon, 14 May 2012 04:30:13 -0700 (PDT) Date: Mon, 14 May 2012 13:30:13 +0200 Message-ID: From: Chiara Petrioli To: manet@ietfa.amsl.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] SUNSET (open source framework for underwater sensor networks) 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, 14 May 2012 11:32:07 -0000 I confirm this message. I have actually subscribed today even from this e-mail address Best Regards Chiara -- --- Dr. Chiara Petrioli Associate Professor Computer Science Department University of Rome La Sapienza Via Salaria 113, 00198 Roma Italy E-mail: petrioli@di.uniroma1.it From petrioli@di.uniroma1.it Mon May 14 07:42: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 2C36921F850C for ; Mon, 14 May 2012 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 Y3j6il6ewk9W for ; Mon, 14 May 2012 07:42:28 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4361921F84FE for ; Mon, 14 May 2012 07:42:27 -0700 (PDT) Received: by lagv3 with SMTP id v3so2401193lag.31 for ; Mon, 14 May 2012 07:42:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=h6RcW5RGVyDwjZ50ZvfaNq7SsiR5lRYoHuZGJ+H5I1w=; b=EGGhesViumtJfkSfYQD3MqCqF8XW+2NwTEvmwfiNYTFuTJtCDK+FI4ewCX3vE3bkoX vWx2H6fgxF5tsWmRGYhU3maTMaHP0444tp+McY/GTj+rEQBmy8DcjvL/nhFvrzADB4hD ml1oDWBN9xy2rgly3N4/qgeIOHJ51IesK2G/8GG2g7nJqsPSe6EQVMI9NFItDkjcDlOO 2wX89Kk4E19TpaJ/KqmxaJDRYqSt1yAc46kLljO+nluOed3VN/rxVG85avOZHFRADr51 2rtolJs/ffmUBjdO2p12Yuq+z7bcW3+7dnxX0x5MwtC7mKTnvBedgcdn4Wuh++yryLhK jSPg== MIME-Version: 1.0 Received: by 10.112.101.169 with SMTP id fh9mr3871621lbb.18.1337006545974; Mon, 14 May 2012 07:42:25 -0700 (PDT) Received: by 10.112.86.40 with HTTP; Mon, 14 May 2012 07:42:25 -0700 (PDT) Date: Mon, 14 May 2012 16:42:25 +0200 Message-ID: From: Chiara Petrioli To: manet@ietf.org Content-Type: multipart/alternative; boundary=f46d04016ae13c360704c0001819 X-Gm-Message-State: ALoCoQlMpTHO18g3Jlt75MCdxyJ1QhCG4qfKY9mcGxejuAO0kFHJvaAA4qWyKTVoVwZjuO8IuETh Subject: [manet] SUNSET (open source framework for underwater sensor networks) 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, 14 May 2012 14:42:29 -0000 --f46d04016ae13c360704c0001819 Content-Type: text/plain; charset=ISO-8859-1 Dear colleagues, We are releasing SUNSET (La Sapienza University Networking framework for underwater Simulation Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test at sea novel communication protocols for underwater communications. We have extensively used it for in field tests for two years, and we are now releasing it to the research community believing it can speed up significantly research in the field of underwater sensor networks. It allows to seamlessy use the same code for simulating, emulating and experimenting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here Underwater wireless sensor network group: http://reti.dsi.uniroma1.it/UWSN_Group/ SENSES laboratory: http://reti.dsi.uniroma1.it/SENSES_lab/ Best Regards Prof. Chiara Petrioli Director, SENSES lab Computer Science Department University of Rome La Sapienza E-mail: petrioli@di.uniroma1.it --f46d04016ae13c360704c0001819 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Dear colleagues,

=A0

We are releasing SUNSET=A0 (La Sapienza University Networking framework for underwater Simulati= on Emulation and real-life Testing). SUNSET is a new open source solution, developed by the UWSN SENSES Lab Group, to seamlessly simulate (using ns2), emulate and test=A0 at sea novel communication protocols for underwater communications.

=A0

We have extensively used it for in field tests for t= wo years, and we are now releasing it to the research community believing it c= an speed up significantly=A0 research in the field of underwater sensor networks.=A0=A0 It allows to seamlessy use the same code for simulating, emulating and experim= enting at sea solutions for UWSNs. You can find information on SUNSET and on our activities here

=A0

Underwater wireless sensor network group:

http://reti.dsi.uniroma1.it/UWSN_Group/

=A0

SENSES laboratory:

http://reti.dsi.uniroma1.it/SENSES_lab/

=A0

Best Regards

Prof. Chiara Petrioli

Director, SENSES lab

Computer Science Department

University of Rome La Sapienza

E-mail: petrioli@di.uniroma1.it

--f46d04016ae13c360704c0001819-- From wwwrun@rfc-editor.org Mon May 14 17:04: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 92A1A21F8971; Mon, 14 May 2012 17:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 f9vR2zn0Lc-8; Mon, 14 May 2012 17:04:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6721F8973; Mon, 14 May 2012 17:04:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8AC04B1E010; Mon, 14 May 2012 17:01:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120515000118.8AC04B1E010@rfc-editor.org> Date: Mon, 14 May 2012 17:01:16 -0700 (PDT) Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 6622 on Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) 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, 15 May 2012 00:04:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6622 Title: Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs) Author: U. Herberg, T. Clausen Status: Standards Track Stream: IETF Date: May 2012 Mailbox: ulrich@herberg.name, T.Clausen@computer.org Pages: 21 Characters: 48083 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-packetbb-sec-09.txt URL: http://www.rfc-editor.org/rfc/rfc6622.txt This document describes general and flexible TLVs for representing cryptographic Integrity Check Values (ICVs) (i.e., digital signatures or Message Authentication Codes (MACs)) as well as timestamps, using the generalized Mobile Ad Hoc Network (MANET) packet/message format defined in RFC 5444. It defines two Packet TLVs, two Message TLVs, and two Address Block TLVs for affixing ICVs and timestamps to a packet, a message, and an address, respectively. [STANDARDS-TRACK] This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From charliep@computer.org Mon May 14 22:02: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 A25A721F850C for ; Mon, 14 May 2012 22:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, J_CHICKENPOX_210=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_92=0.6, J_CHICKENPOX_93=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 UBzU6Zl9JaeK for ; Mon, 14 May 2012 22:02:25 -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 1B8C121F84DE for ; Mon, 14 May 2012 22:02:23 -0700 (PDT) Received: from [63.133.138.10] (helo=[10.71.9.232]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SU9tv-0008Gn-8d; Tue, 15 May 2012 01:02:23 -0400 Message-ID: <4FB1E35F.6000903@computer.org> Date: Mon, 14 May 2012 22:02:23 -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: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864f61269ec15c59d95241d77bb0b42f17350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 63.133.138.10 Cc: manet 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: Tue, 15 May 2012 05:02:27 -0000 Hello Abdul, I am catching up on things after a long delay (many reasons!!) On 5/3/2012 1:15 PM, Abdussalam Baryun wrote: > Hi Ian Chakeres, > > i have completed my work for commenting on AODVv2, I hope you can > answer my questions. thanking you, > > Abdussalam Baryun (AB) > University of Glamorgan, UK > ======================== > > AB>Overall> The dymo-22 draft is well organized and represents the > protocol operations, operation location, and messages (when initiating > its process, its conditions, and how processed) in section-by-section > basis. However, it was difficult to read because I think the concept > of version 2 and because the introduction and presentation was not > representing the new issues added to the old version and even not seen > the DSR-idea use in this version as mentioned.The draft lacks > explanations of the relationship between AODV and AODVv2, because both > protocols carry the similar name it is preferable to give more details > to avoid misunderstanding. The similar name may indicate that both > protocols can work together, or that AODVv2 router understands > correctly AODV router, or they may be integrated in some network > solutions. Point noted. In fact, AODVv2 is a transitional document and the continuing transition should as you mention include text to better motivate the changes. > > AB> Suggesting> that section 3 put before section 2 to clarify the > definition of some items of the protocol introduction presentation. > > AB>I read>In the manet discussion Chakeres to Baker (C2B), dated July > 26 2010, sub:dymo-21: > C2B>The nets do not have to be mobile, and DYMO may be applicable in low power > C2B>lossy sensor networks. Without lots of details about a particular network > C2B>deployment and application traffic, it is very hard to make > C2B>generalizations in MANET. > > AB> suggest> Preferable to be mentioned in overview this discussion explanation. > AB> suggest> If this protocol is able to be used in LLN nets as well > as MANET, it is important to clarify it (LLN was only mentioned in > acknowledgement section) and its relation with LLN information > exchange requirements, because the protocol applicable to other nodes > (e.g. LLN node) including MANET nodes. It is intended that AODVv2 should be useful in LLNs but by no means restricted to only LLNs. For some networks (perhaps with larger populations) additional mechanisms may be desirable, which should be specified in other documents. The mechanism for intermediate RREP fits in this category, probably along with expanding rings multicast. > AB>thought and questions>The word “node” was used without indicating > that it is MANET node, which its node may be a router. In addition, > Originating Node (OrigNode) in the terminology is not defined to be a > MANET node (e.g. if we compare with AODV RFC3561). So could it be a > MANET node or it could not? This makes the network architecture used > not clear. Are all nodes in this network architecture, MANET nodes? If > all messages/packets are MANET-units as RFC5444 therefore, all nodes > are MANET. Moreover, the draft has some indirect indications that > there MAY be more than one routing protocol (other than AODVv2) per > net-interface in some nodes which is preferable to be mentioned. Here, "Originating Node" is always an AODVv2 node. The reliance on RFC 5444 is still under discussion, I reckon. Also, we cannot restrict nodes from running other protocols in addition to AODVv2. If there is some additional state introduced that affects the operation of AODVv2, that needs to be handled. > > AB>thought and questions>Is the protocol a specific purpose or general > purpose or both, this should be specified. All MANET routing protocols > need the purpose statement that specifies clearly its location in > practical situation. AODVv2 is intended to be quite general purpose. > > AB>thought and questions>The draft has not categorized the network’s > devices/nodes (using only the word routing instead of nodes). The > draft does not make explaination of the protocol’s interaction with ad > hoc hosts (i.e. only ad hoc routers are mentioned as AODVv2 router). To be completely accurate in answering this question, one must first answer the question if a node becomes a router when it acquires a single additional host route. It is perhaps an ambiguity which should not impair understanding of the actual operation of the protocol. > > AB> The draft had some paragraph that not followed the RFC2119, but > some amended as (there may be other, that needs to be amended): > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > AB>page-10>required> A RteMsg REQUIRES the following information: > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-25>required> If no UnreachableNode addresses remain in the > RERR, no other handling is REQUIRED and the RERR is discarded. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-27>required> In table title: “REQUIRED Administratively > Configured Parameters” > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-27>should> Similarly, AODVv2 routers SHOULD subscribe to > LL-MANET-Routers on all their AODVv2 interfaces. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>page-32>must> Note that if multicast is used, any confidentiality > and integrity algorithms used MUST permit multiple receivers to handle > the message. > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > #Abstract > >> The Dynamic MANET On-demand (AODVv2) routing protocol is intended for >> use by mobile routers in wireless, multihop networks. AODVv2 >> determines unicast routes among AODVv2 routers within the network in >> an on-demand fashion, offering on-demand convergence in dynamic >> topologies. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest change> “The Dynamic MANET On-demand (AODVv2)”, to be > changed to “The Dynamic MANET On-demand Distance Vector (D-AODVv2)”, > because the term “AODVv2” has letter “A” which is presented in the > second letter of the abbreviation word MANET, but AODVv2 has the D and > V letters which is the abbreviation of Distance Vector. Regarding the > word Dynamic an abbriviation “D” preferable to be added. The “v2” may > be left to indicate its origin protocol source-idea RFC3561 AODV, > however, this can be explained in the overview. > > AB>general comment> AODVv2 is a routing protocol that determines > unicast routes within the mobile routers. > > AB> due to mentioning the protocol route-determination and on-demand, > It is useful to specify in abstract, to mention the protocol special > method/technique (e.g. its name or what it uses) used for this > determination and/or the convergence (i.e. to differentiate it from > other reactive protocols for summary or future purposes). > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > #In (Content) > >> 4.2.2. Routing Message (RteMsg) - RREQ and RREP . . . . . . . 10 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> Routing Messages. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Thanks for these observations. I will make the appropriate changes. > #In section (1. Overview) > >> Route discovery is performed when an AODVv2 router receives a packet from a >> node under its responsibility to a destination for which it does not have a >> route. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>idea not clear> which kind of node under responsibility of another? > An ad hoc node responsible for another ad hoc node, IMO may mean that > the node gets its routing information from another! (dependent-node). If an AODVv2 node is routing for a subnet, it has responsibility for the nodes on that subnet. > > AB>Statements seen after, in section-2, page-5> “other nodes, attached > via participating or non-participating interfaces”. > This was not described well, and not sure if it has relation with the > shared address among routers mentioned later in section-2, page-5. > > AB> does it mean that it only performs discovery when . . . , as if > the router itself cannot be a source of demand. But the router can indeed be the source of demand. I'll think of some wordsmithing. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> During route discovery, the originator’s AODVv2 router initiates >> dissemination of a Route Request (RREQ) throughout the network to >> find a route to a particular destination, via the AODVv2 router >> responsible for this destination. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>not clear> originator; what did this node originate? Do we mean the > router’s responsible for one, and it request for a connection to > destination (as the responsibility is at destination or at source > side. > > AB>suggest adding words> “Route Request message (RREQ)”. O.K. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> During this hop-by-hop dissemination process, each intermediate AODVv2 >> router records a route to the originator. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> During the hop-by-hop dissemination process, > each intermediate AODVv2 router receiving the RREQ message records a > route to the originator. > AB> the target also should records a route to the originator.. O.K. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> AODVv2 uses sequence numbers to ensure loop freedom [Perkins99]. >> Sequence numbers enable AODVv2 routers to determine the temporal >> order of AODVv2 route discovery messages, thereby avoiding use of >> stale routing information. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> “AODVv2 uses routers’ sequence numbers”. > Or > AB>suggest amendments> “AODVv2 uses routers’ AODVv2 sequence numbers (SeqNum)”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ O.K. > > #In section (2. Applicability Statement) > >> AODVv2 handles a wide variety of mobility patterns by dynamically >> determining routes on-demand. AODVv2 also handles a wide variety of traffic >> patterns. In networks with a large number of routers, AODVv2 is best suited >> for sparse traffic scenarios where routers forward packets to only a small >> portion of the other AODVv2 routers, due to the on-demand nature of route >> discovery and route maintenance. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>idea not clear> the word “other” confused, one side large and > another side small of MANET network. I'm not sure what is wrong here -- do you have suggested text? > > AB>maybe because> where the large number (portion) of AODVv2 routers > forward packets to other small portion (number) of AODVv2 routers, > > AB>idea not clear> “due to the on-demand nature of route discovery and > route maintenance”, what is the problem with both on-demand(discovery) > or reactive(maintenance) nature? Do both create the different portion > sides of routes? > > AB>discussion> Does the reason of the protocol suitability include > traffic pattern and network density? Yes, both are important. > Even though the paragraph claims > AODVv2 handles them as mentioned. In the paragraph there is no clear > relation between traffic and on-demand nature, even though on-demand > is traffic oriented, so it seems positive to use an on-demand (the > negative is not clear). Also for the route maintenance is related with > route changes, which is positive. > > It is preferable to change the paragraph to describe both ideas; what > AODVv2 cannot handle more suitable, with mentioning what it is best > suitable. However, mentioning the reactive nature suitability will > relate/reflect to all MANET Reactive Protocols not just AODVv2. This > can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. I'm not yet clear on how to improve this. If you can suggest text, that would be helpful... > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AODVv2 is applicable to memory constrained devices, since little >> routing state is maintained in each AODVv2 router. Only routing >> information related to active sources and destinations is maintained, >> in contrast to most proactive routing protocols that require routing >> information to all routers within the routing region be maintained. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> “information related routes to active sources > and to destinations is maintained”. > AB>suggest replace> “proactive routing protocols” with “MANET > Proactive Routing protocols (MPRs)” > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ O.K. but I probably won't use that abbreviation since it seriously collides with another use. > >> At any time within an AODVv2 routing region, only one AODVv2 router >> SHOULD be responsible for, i.e. "own", any particular address. >> Coordination among multiple AODVv2 routers to distribute routing >> information correctly for a shared address (i.e. an address that is >> advertised and can be reached via multiple AODVv2 routers) is not >> described in this document. The router behavior for shifting >> responsibility for an address from one AODVv2 router to another is >> mentioned in Appendix C. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> At all times within an AODVv2 routing region, > only one AODVv2 router SHOULD be responsible for (i.e. the > routing-address region owner) any particular address. The coordination > among multiple AODVv2 routers to distribute routing information > correctly for a shared address (i.e. an address that is advertised and > can be reached via multiple AODVv2 routers) is not described in this > document. The AODVv2 router operation of shifting > responsibility for an address from one AODVv2 router to another is > mentioned in Appendix C. O.K. > > AB>not sure question> Is router behavior responsible for the address > or for the address assignment? Not sure. The router is NOT necessarily responsible for the address assignment, although it could be. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > AB>RFC2119> “Otherwise, persistent packet loss MAY occur”. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> AODVv2 only utilizes bidirectional links. In the case of possible >> unidirectional links, either blacklists (see Section 7.2) or other >> means (e.g. adjacency establishment with only neighboring routers >> that have bidirectional communication as indicated by NHDP >> [I-D.ietf-manet-nhdp]) of ensuring and monitoring bi-directionality >> is recommended. Otherwise, persistent packet loss may occur. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>not clear> How does it not utilize unidirectional links, while > mentioned, or who does this blacklisting, is it another protocol? Not > sure why mention in this protocol draft while it is not clear what > operates the blacklisting. This was not clear even in section 7.2. > Usually some routing protocols operate the blacklisting, so does this > mean that any/some AODVv2 router(s) in such situation may use > blacklisting which does not affect the network’s routings. I'll look to see how to make this more clear. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >> The routing algorithm in AODVv2 may be operated at layers other than >> the network layer, using layer-appropriate addresses. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> The MANET routing algorithm of AODVv2 MAY be > operated at another layer than the network layer, using the layer’s > appropriate addresses. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > #In section (3. Terminology) > >> AODVv2 Sequence Number (SeqNum) >> An AODVv2 Sequence Number is maintained by each AODVv2 router >> process. This sequence number is used by other AODVv2 routers to >> identify the temporal order of routing information generated and >> ensure loop-free routes. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > AB>suggest amendments> An AODVv2 Sequence Number is maintained by each > AODVv2 router process. The AODVv2 router’s sequence number is used by > other AODVv2 routers to identify the temporal order of routing > information generated and > ensure loop-free routes. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Check. More later -- it's way too late here. Regards, Charlie P. From internet-drafts@ietf.org Tue May 15 07:33: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 322FC21F885E; Tue, 15 May 2012 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 UDdPU0Y+W60j; Tue, 15 May 2012 07:33:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51BE21F8778; Tue, 15 May 2012 07:33:34 -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: <20120515143334.2573.82826.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 07:33:34 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Tue, 15 May 2012 14:33:35 -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 : The Optimized Link State Routing Protocol version 2 Author(s) : Thomas Heide Clausen Christopher Dearlove Philippe Jacquet Ulrich Herberg Filename : draft-ietf-manet-olsrv2-15.txt Pages : 106 Date : 2012-05-15 This specification describes version 2 of the Optimized Link State Routing (OLSRv2) protocol for Mobile Ad hoc NETworks (MANETs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-15.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-olsrv2-15.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2/ From ietf@jiaziyi.com Tue May 15 14:35: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 312B521F865B for ; Tue, 15 May 2012 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.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 ahqon3DhQaMY for ; Tue, 15 May 2012 14:35:19 -0700 (PDT) Received: from mx1000.mochahost.com (unknown [50.31.147.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4B57D21F8659 for ; Tue, 15 May 2012 14:35:19 -0700 (PDT) Received: from mocha3004.mochahost.com ([50.31.147.60]:44637) by mx1000.mochahost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SUPjN-00258A-4S for manet@ietf.org; Tue, 15 May 2012 17:56:33 -0400 Received: from vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr ([89.87.201.6]:55655 helo=jy-mac-pro.home) by mocha3004.mochahost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SUPOo-000DTX-1z for manet@ietf.org; Tue, 15 May 2012 17:35:18 -0400 From: Jiazi Yi Content-Type: multipart/alternative; boundary="Apple-Mail=_1FC1B093-3412-4021-ACC6-31BB909B8660" Date: Tue, 15 May 2012 23:35:11 +0200 Message-Id: <799B8C71-12B0-45B0-8347-292883FB3F53@jiaziyi.com> To: manet@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mx1000.mochahost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jiaziyi.com Subject: [manet] On the scope of NHDP-sec-threats 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, 15 May 2012 21:35:20 -0000 --Apple-Mail=_1FC1B093-3412-4021-ACC6-31BB909B8660 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi dear all, In the Paris IETF, we had lots of valuable comments on the = nhdp-sec-threats document, and it was adopted as wg document.=20 In the discussion, the issue concerned most is the scope of the = document: should we include the common attacks for networks, and the = interaction with protocols using NHDP (OLSRv2, SMF, ...).=20 Regarding the common attacks, the idea is that it's necessary to include = the common threats in wireless networks that are remarkable in MANET = neighbor discovery procedure. It's inevitable to have some overlaps with = other threat documents, but we think it's worth to emphasize those = critical threats for NHDP.=20 Currently, we have the jamming and eavesdropping in the document. For = jamming, it is an important attack vector in this kind of decentralized = environment because of restricted resource, especially when the HELLO = message can be triggered by state change of the network - which is = further discussion in the "indirect jamming" section. For = eavesdropping, it provides network information required for enabling = other attacks, such as link/node spoofing, which are introduced in later = sections.=20 The current revision of the document also includes a section for the = impacts on protocols using NHDP. The rationale is that, as a neighbor = discovery protocol, NHDP is used in combination with other protocols = most of the time. Therefore, the document describes how the those = protocols might be disrupted by the misbehavior of NHDP (in common = sense, such as MPR calculation, data sinkhole, etc. ). If we are going = to produce more threats documents in the future, there is no need to = worry about those common ones in NHDP (for example, we probably don't = want to discuss the threats in MPR selection in both SMF-threats and = OLSRv2-threats).=20 Of course, we are also looking for more comments on the vulnerabilities = proposed in the documents, and new possible attacks.=20 best YI Jiazi http://www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex France --Apple-Mail=_1FC1B093-3412-4021-ACC6-31BB909B8660 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi dear all,

In = the Paris IETF, we had lots of valuable comments on the nhdp-sec-threats = document, and it was adopted as wg document. 
In the = discussion, the issue concerned most is the scope of the document: = should we include the common attacks for networks, and the interaction = with protocols using NHDP (OLSRv2, SMF, = ...). 

Regarding the common attacks, = the idea is that it's necessary to include the common threats in = wireless networks that are remarkable in MANET neighbor discovery = procedure. It's inevitable to have some overlaps with other threat = documents, but we think it's worth to emphasize those critical threats = for NHDP. 
Currently, we have the jamming and = eavesdropping in the document. For jamming, it is an important = attack vector in this kind of decentralized environment because of = restricted resource, especially when the HELLO message can be triggered = by state change of the network - which is further discussion in the = "indirect jamming" section.  For eavesdropping, it provides network = information required for enabling other attacks, such as link/node = spoofing, which are introduced in later = sections. 

The current revision of the = document also includes a section for the impacts on protocols using = NHDP. The rationale is that, as a neighbor discovery protocol, NHDP is = used in combination with other protocols most of the time. Therefore, = the document describes how the those protocols might be disrupted by the = misbehavior of NHDP (in common sense, such as MPR calculation, data = sinkhole, etc. ). If we are going to produce more threats documents in = the future, there is no need to worry about those common ones in NHDP = (for example, we probably don't want to discuss the threats in MPR = selection in both SMF-threats and OLSRv2-threats). 

Of course, we are also looking for more = comments on the vulnerabilities proposed in the documents, and new = possible = attacks. 

best


YI = Jiazi

Hiper= com@LIX, Ecole Polytechnique
Route de Saclay 91128 = Palaiseau Cedex France



= --Apple-Mail=_1FC1B093-3412-4021-ACC6-31BB909B8660-- From aaron@lo-res.org Wed May 16 04:25: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 B768821F86AB for ; Wed, 16 May 2012 04:25: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 xuVAC5VxrarY for ; Wed, 16 May 2012 04:25:15 -0700 (PDT) Received: from mute.lo-res.org (mail.lo-res.org [IPv6:2a02:60:1:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 2595F21F8661 for ; Wed, 16 May 2012 04:25:14 -0700 (PDT) Received: from homeostasis.lan (nat.labs.nic.at [83.136.33.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id 2FE829BC4FF; Wed, 16 May 2012 13:25:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_CEA852E5-C13D-480A-8085-EC8A2E95B8FB"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "L. Aaron Kaplan" In-Reply-To: <22EF9D49-8468-4EBD-AE80-2D362B4453F1@thomasclausen.org> Date: Wed, 16 May 2012 13:25:05 +0200 Message-Id: References: <4FAB679A.1060205@fkie.fraunhofer.de> <22EF9D49-8468-4EBD-AE80-2D362B4453F1@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Question about OLSRv2 link metric implementation 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, 16 May 2012 11:25:15 -0000 --Apple-Mail=_CEA852E5-C13D-480A-8085-EC8A2E95B8FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On May 10, 2012, at 12:04 PM, Thomas Heide Clausen wrote: > I do agree with Chris - I've got about 5 other I-Ds taking cycles = right now, so I do not have a good idea - but will think about it once = they're out the door. >=20 > That said, I do think that it is a good initiative, Henning, and I = would encourage (and offer assistance on) production of an ETX metric = for OLSRv2. >=20 > I also would very much encourage documenting "The FunkFeuer = Exeperience" in an informational RFC; I believe that as you guys have an = operational, large and long-standing MANET running, it'd be valuable = information for others deploying such networks. Thus, 100% support from = me on that also. >=20 Hi Thomas, this is a job which has been waiting to be scheduled for a long time. I'll bump up its priority level. July looks good for sitting down and finally writing it. I'd be happy to have some reviewers. Aaron. --Apple-Mail=_CEA852E5-C13D-480A-8085-EC8A2E95B8FB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk+zjpUACgkQxEgyMttZ8YxUVACguPOkkog2snuC970v53oFGlZ2 pLoAnjC4mz0L1AQ+HzGl3t5s7AadcurG =5/tN -----END PGP SIGNATURE----- --Apple-Mail=_CEA852E5-C13D-480A-8085-EC8A2E95B8FB-- From abdussalambaryun@gmail.com Wed May 16 04:59: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 4ED4221F8700 for ; Wed, 16 May 2012 04:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.461 X-Spam-Level: X-Spam-Status: No, score=-3.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 GAjbtt22bQN3 for ; Wed, 16 May 2012 04:59:31 -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 B377821F86FD for ; Wed, 16 May 2012 04:59:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so733403vbb.31 for ; Wed, 16 May 2012 04:59:31 -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=ZbDvozfBPsz9e4ZJHc0iy0LmYlVRxJ+f3udKsgcMazQ=; b=i34F6qua+4lD1NbaxbLN56NU7pSr/rFbba1rh7K69M0sw36Yjb28UmzZrddctlokW5 KiUylbtkI/D1yoYQ0MutSv7UItfXp/4Vr0bA77RaiaaPcEvv+PDHssIsQiXp6+3lVogg 9e1yMpCVdW6j++KyX+x3SqZGM+XrTGwuKfV9lXp/vwaC97cGD30Qot8TGFdqTkNwOK4e U2uKyNmQCWjHxKd+0iZgBgqOw5+YKghiCXgyAhAJhq5H4kz/4TblhtAUUh4sPRJPERIi oojP2NOq8YSE1cqDtH+lG0rZh6YC5kMMtr+75vBMkzZ1nSVwhdrLzIiQvnqHMVIoE+on TM/A== MIME-Version: 1.0 Received: by 10.220.155.197 with SMTP id t5mr2178749vcw.6.1337169571221; Wed, 16 May 2012 04:59:31 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Wed, 16 May 2012 04:59:31 -0700 (PDT) Date: Wed, 16 May 2012 13:59:31 +0200 Message-ID: From: Abdussalam Baryun To: ietf@jiaziyi.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet Subject: Re: [manet] On the scope of NHDP-sec-threats 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, 16 May 2012 11:59:32 -0000 Hi >In the Paris IETF, we had lots of valuable comments on the nhdp-sec-threat= s >document, and it was adopted as wg document. >In the discussion, the issue concerned most is the scope of the document: = should >we include the common attacks for networks, and the interaction wit= h protocols >using NHDP (OLSRv2, SMF, ...). In general, both common and interaction attacks need to be documented per protocol, it is more useful to have the scope of protocol's vulnerability without excluding common network attacks and issues. Any additional attacks should be considered, otherwise the document scope section should specify if it excludes something. >The current revision of the document also includes a section for the impac= ts on >protocols using NHDP. The rationale is that, as a neighbor discovery= protocol, >NHDP is used in combination with other protocols most of the ti= me. Therefore, the >document describes how the those protocols might be dis= rupted by the >misbehavior of NHDP (in common sense, such as MPR calculatio= n, data sinkhole, >etc. ). If we are going to produce more threats document= s in the future, there is no >need to worry about those common ones in NHDP= (for example, we probably don't >want to discuss the threats in MPR select= ion in both SMF-threats and OLSRv2->threats). Maybe you mean only threats-documents that use NHDP, so they need to refer to this NHDP-sec-threats document, but if a protocol is not using NHDP, it is important that its threat document scope includes all attacks/threats possibilities. Abdussalam Baryun University of Glamorgan, UK. From ietf@thomasclausen.org Wed May 16 05:09: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 6713621F86D3 for ; Wed, 16 May 2012 05:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 C7H0amnZiXWO for ; Wed, 16 May 2012 05:09:30 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A921F8663 for ; Wed, 16 May 2012 05:09:30 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 0024A558182 for ; Wed, 16 May 2012 05:09:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D41651BD368F; Wed, 16 May 2012 05:09:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 207F41BD2161; Wed, 16 May 2012 05:09:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: Date: Wed, 16 May 2012 14:09:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAB679A.1060205@fkie.fraunhofer.de> <22EF9D49-8468-4EBD-AE80-2D362B4453F1@thomasclausen.org> To: "L. Aaron Kaplan" X-Mailer: Apple Mail (2.1257) Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] Question about OLSRv2 link metric implementation 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, 16 May 2012 12:09:30 -0000 Hi Aaron, July looks good indeed. I look forward to it - count me in. Thomas On May 16, 2012, at 13:25 , L. Aaron Kaplan wrote: >=20 > On May 10, 2012, at 12:04 PM, Thomas Heide Clausen wrote: >=20 >> I do agree with Chris - I've got about 5 other I-Ds taking cycles = right now, so I do not have a good idea - but will think about it once = they're out the door. >>=20 >> That said, I do think that it is a good initiative, Henning, and I = would encourage (and offer assistance on) production of an ETX metric = for OLSRv2. >>=20 >> I also would very much encourage documenting "The FunkFeuer = Exeperience" in an informational RFC; I believe that as you guys have an = operational, large and long-standing MANET running, it'd be valuable = information for others deploying such networks. Thus, 100% support from = me on that also. >>=20 >=20 > Hi Thomas, >=20 > this is a job which has been waiting to be scheduled for a long time. > I'll bump up its priority level. >=20 > July looks good for sitting down and finally writing it. > I'd be happy to have some reviewers. >=20 > Aaron. >=20 From abdussalambaryun@gmail.com Wed May 16 05:28: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 18DA521F86A8 for ; Wed, 16 May 2012 05:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_92=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 KfRFssky7ATF for ; Wed, 16 May 2012 05:28:13 -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 4459021F85D3 for ; Wed, 16 May 2012 05:28:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so764250vbb.31 for ; Wed, 16 May 2012 05:28:12 -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=QCB2DD+GqXZE1LIWtK/oZ+CjgvuqgdbnLwKYWAXHtVQ=; b=J98Cz0z/95pT/uTgdD+liQu7mat56A2FOtx8r2PYXgbxBqfpXw1bj+47R9sL33/4fh 3pZsWtQuQRfTnv2wbpIvIW1e30EVX4EIXQc6ODo8MxJVlTcDhhRfUx0fl6kPOS3BEkQr DUvvFaInVjz8QitRCTRXCyJ79L/Xo5yvZMUhp70//EcsvJwYmtTMTZrks7lNtkFBQJ/C 7MR72UXuiT3nfpHFR6aBE5qFvNCOONYWtiTfq1dzwDKC81Uk81/bIweoP7y1Ex+IBaJF UnSIolZOw8rZFZ+vEw85uMLeCzrjKJ36xtnT1vu0Adr/Ang0aAqPkDbX1p5naJqJApi5 eupQ== MIME-Version: 1.0 Received: by 10.52.21.174 with SMTP id w14mr1841227vde.24.1337171292791; Wed, 16 May 2012 05:28:12 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Wed, 16 May 2012 05:28:12 -0700 (PDT) In-Reply-To: <4FB1E35F.6000903@computer.org> References: <4FB1E35F.6000903@computer.org> Date: Wed, 16 May 2012 14:28:12 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: manet 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: Wed, 16 May 2012 12:28:14 -0000 Hi Charlie, On 5/15/12, Charles E. Perkins wrote: > > Hello Abdul, > > I am catching up on things after a long delay (many reasons!!) > > Here, "Originating Node" is always an AODVv2 node. > As in the below definition in the terminology it does not mention that this node is always AODVv2 node, I got a feeling while review that there is a possibility that originating nodes MAY become AODVv2 or MAY not, and this can be seen in the below definition because the source may be a device that is a responsibility of AODVv2 router. Originating Node (OrigNode): The originating node is the source, its AODVv2 router creates a AODVv2 control message on its behalf in an effort to disseminate some routing information. The originating node is also referred to as a particular message=92s originator. > The reliance on RFC 5444 is still under discussion, I reckon. > Also, we cannot restrict nodes from running other protocols in > addition to AODVv2. If there is some additional state introduced > that affects the operation of AODVv2, that needs to be handled. I suggest not to use 5444 packet, but AODVv2 uses its technique, so it may be coupled with it or use it in the future. IMO 5444 is more suitable for proactive routing protocols, but not sure because not proved yet. >> AB>thought and questions>Is the protocol a specific purpose or general >> purpose or both, this should be specified. All MANET routing protocols >> need the purpose statement that specifies clearly its location in >> practical situation. > > AODVv2 is intended to be quite general purpose. > is it possible to mention in the document, otherwise I am not sure if we should specify this in each document, but I prefer to declare that per document. >> #In section (2. Applicability Statement) >> >>> AODVv2 handles a wide variety of mobility patterns by dynamically >>> determining routes on-demand. AODVv2 also handles a wide variety of >>> traffic >>> patterns. In networks with a large number of routers, AODVv2 is best >>> suited >>> for sparse traffic scenarios where routers forward packets to only a >>> small >>> portion of the other AODVv2 routers, due to the on-demand nature of >>> route >>> discovery and route maintenance. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>idea not clear> the word =93other=94 confused, one side large and >> another side small of MANET network. > > I'm not sure what is wrong here -- do you have suggested text? > AB>I don=92t mean something is wrong, but something is not clear to read, the meaning of =93other AODVv2 routers=94 , these other routers are smaller portion than a larger, what is the issue here? I understand that this scenario of traffic from large portion to small routers portion the AODVv2 is best. Why it is best suited, the draft reason is because AODVv2 is on-demand but there are also other protocols, what is special here for AODVv2? >> >> AB>maybe because> where the large number (portion) of AODVv2 routers >> forward packets to other small portion (number) of AODVv2 routers, >> >> AB>idea not clear> =93due to the on-demand nature of route discovery an= d >> route maintenance=94, what is the problem with both on-demand(discovery) >> or reactive(maintenance) nature? Do both create the different portion >> sides of routes? >> >> AB>discussion> Does the reason of the protocol suitability include >> traffic pattern and network density? > > Yes, both are important. > >> Even though the paragraph claims >> AODVv2 handles them as mentioned. In the paragraph there is no clear >> relation between traffic and on-demand nature, even though on-demand >> is traffic oriented, so it seems positive to use an on-demand (the >> negative is not clear). Also for the route maintenance is related with >> route changes, which is positive. >> >> It is preferable to change the paragraph to describe both ideas; what >> AODVv2 cannot handle more suitable, with mentioning what it is best >> suitable. However, mentioning the reactive nature suitability will >> relate/reflect to all MANET Reactive Protocols not just AODVv2. This >> can be clear if using words like RECOMMENDED and/or NOT RECOMMENDED. > > I'm not yet clear on how to improve this. If you can suggest text, that > would be > helpful... I am not sure if I am able to suggest a correct paragraph replacing that, because I may missunderstood, however, I will use what I understood: AB> suggest replace to> Due to the on-demand nature of route discovery and route maintenance many MANET reactive protocols are not suited for high density routers and/or traffic load. AODVv2 handles a wide variety of mobility patterns and of traffic patterns. In networks with a large number of routers, and sparse traffic scenarios the AODVv2 is best suited because routers forward packets to only a small portion of other AODVv2 routers. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> AB>suggest amendments> =93information related routes to active sources >> and to destinations is maintained=94. >> AB>suggest replace> =93proactive routing protocols=94 with =93MANET >> Proactive Routing protocols (MPRs)=94 >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++> > O.K. but I probably won't use that abbreviation since it seriously > collides with > another use. yes your right, thanks, >> AB>not sure question> Is router behavior responsible for the address >> or for the address assignment? Not sure. > > The router is NOT necessarily responsible for the address assignment, > although it could be. > This information is important if mentioned and will delet many of my dought= s, +++++++ Thanking you for your reply on the comments, Abdussalam Baryun University of Glamorgan, UK From abdussalambaryun@gmail.com Wed May 16 09:03: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 326CE21F86A1; Wed, 16 May 2012 09:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 o5jRoZsPogU5; Wed, 16 May 2012 09:03:31 -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 86AC921F8625; Wed, 16 May 2012 09:03:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1013919vbb.31 for ; Wed, 16 May 2012 09:03:31 -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=l1AEVPiHJOBetTRh230OTFztlyc0fWKCdc5aKULpj0c=; b=MpWYS2r30INrfRLCd1nbdPDlV7I+XfQWNOhyhieghp9dHH8f0I3HROsqGJfEvxeB7e utR+Whra35gB2hxUwjC5LJyMWtK//EKkdl87bEII0a06bE6LsZd0EKAGZGFuvRIoon3g v9QvfAYG5E9nur/Y3iNJvHVkH+31SwtHtYPAcBPPkkWhQ3nMCo3atvC18aiPXSZIHEwA UgOABAiQBXPDSUGnoDjKTmdTViRHrpSqOSxx+jiI/2gLQtJ+KeOo2bsR2E9eYOZMBMEn A+9gHZZmN11eLikvRGzSXS9PI63+ZQ8P54wMP+tWlJVrJt/s514F9tm1+9sAw+ZJFipk k47g== MIME-Version: 1.0 Received: by 10.52.21.174 with SMTP id w14mr2298443vde.24.1337184210945; Wed, 16 May 2012 09:03:30 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Wed, 16 May 2012 09:03:30 -0700 (PDT) Date: Wed, 16 May 2012 18:03:30 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: jpmacker@gmail.com, manet , internet-drafts@ietf.org, sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Wed, 16 May 2012 16:03:32 -0000 Hi Herberg, I had some comments on OLSRv2-14 and I was informed that there will be no change only if rough consensus. Now I received a new draft OLSRv2-15 announced, does this mean that suggestions (to add explainations) as in the discussion had no rough consensus so no change is needed? or does it mean that no one has responded to the confusion observed so it was with no value? Please note that I need to know the outcome decision of the MANET-WG, so I can know how to review OLSRv2-15, or I wait for the decision result to the suggestion of adding explainations in the previous draft 14. Thanking you, Abdussalam Baryun, University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Abdussalam, so far, nobody else seemed to be confused on which layer OLSRv2 is used (or how the interfaces are defined). IMO, unless other people in the WG see the same danger of confusion, I would not change it. Regards Ulrich +++++++++++++++++++++++++++++++++++++++++++++++++++++++ The IETF does not work by means of "majority" (which is not even possible since there is no formal membership), but by rough consensus (and running code). And every individual can (and should!) review a document and give suggestions, which can help to improve a document. I just don't see how your suggestions about the MANET/OLSRv2 interfaces would improve the OLSRv2 draft (for the reasons that Chris, Thomas and I have pointed out). Regards Ulrich From ulrich@herberg.name Wed May 16 10:16:17 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 B46B421F86A6 for ; Wed, 16 May 2012 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=0.012, 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 0NW1LswVLoQX for ; Wed, 16 May 2012 10:16:16 -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 1C30721F861B for ; Wed, 16 May 2012 10:16:15 -0700 (PDT) Received: by qabj40 with SMTP id j40so1041596qab.15 for ; Wed, 16 May 2012 10:16:15 -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=Y/pqCuByxA0avPZrfjX+X39MJC7yzKMm+EoFpSivHes=; b=gxHlvz5FfAQafLjRCFwflcoyRurfDZOH3DAmMjiNCQ4N/enX9I/Ss79oE8EMWeGnyY pMYUDfxChl01YpBn/wKxB0Y4jeNACBlhO+pMDVTQ97YL71sp/vseXpBdmhIIPvcrYyVn h0LdkmkDc++AroNirLTqrzHfrif+hwy3TAepc= 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=Y/pqCuByxA0avPZrfjX+X39MJC7yzKMm+EoFpSivHes=; b=Dm10WLzhM+VNmegEa9p1MceQyfJWJO9o3AEhmUQRuOGMwNE0NsUh6FQH/JDtaH3Z8L a40QPcsLOUlPxo2IB6ExTaRepdiBYmUm8U4Cloxh3qW9dMNeU5kkkwrrS0TrjmruV3ap BA8NyxsSb67jajtovQfapsMQH5QdLtHay+GIFvgi+hqYWtt9c8T42mJRu7RvYFChN7Cn vPxj6xyDm5l6Fb0USbKOGAg+jGyoWDKzMQdFi/zxCWYdYMcm99HNimCpDfa0C+CWMtCD x3hEesuKJxlGjkd/ZQ0f6GKdyF2ABAKtUSOwxxxyPPcfbqfNuAgXixiDl+8E4cQEnt9n IwaQ== MIME-Version: 1.0 Received: by 10.229.136.129 with SMTP id r1mr1881776qct.45.1337188575278; Wed, 16 May 2012 10:16:15 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Wed, 16 May 2012 10:16:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 May 2012 10:16:14 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=00248c768f5a06f76c04c02a7a6f X-Gm-Message-State: ALoCoQkZZRhddn8xEhM3wa3DH4EBGR7bB7ThiuDWjSH6upuXEYoziodcvfFD8DdxRtn5yqbQ3lg9 Cc: jpmacker@gmail.com, manet , internet-drafts@ietf.org, sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Wed, 16 May 2012 17:16:17 -0000 --00248c768f5a06f76c04c02a7a6f Content-Type: text/plain; charset=ISO-8859-1 Abdusallam, OLSRv2-15 only contains some minor editorial updates (spelling mistakes and grammatical errors) and no change to the specification. Best regards Ulrich On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Herberg, > > I had some comments on OLSRv2-14 and I was informed that there will be > no change only if rough consensus. Now I received a new draft > OLSRv2-15 announced, does this mean that suggestions (to add > explainations) as in the discussion had no rough consensus so no > change is needed? or does it mean that no one has responded to the > confusion observed so it was with no value? > > Please note that I need to know the outcome decision of the MANET-WG, > so I can know how to review OLSRv2-15, or I wait for the decision > result to the suggestion of adding explainations in the previous draft > 14. Thanking you, > > Abdussalam Baryun, > University of Glamorgan, UK > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Abdussalam, > > so far, nobody else seemed to be confused on which layer OLSRv2 is > used (or how the interfaces are defined). IMO, unless other people in > the WG see the same danger of confusion, I would not change it. > > Regards > Ulrich > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > The IETF does not work by means of "majority" (which is not even > possible since there is no formal membership), but by rough consensus > (and running code). And every individual can (and should!) review a > document and give suggestions, which can help to improve a document. I > just don't see how your suggestions about the MANET/OLSRv2 interfaces > would improve the OLSRv2 draft (for the reasons that Chris, Thomas and > I have pointed out). > > Regards > Ulrich > --00248c768f5a06f76c04c02a7a6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Abdusallam,

OLSRv2-15 only contains some minor editorial updates (sp= elling mistakes and grammatical errors) and no change to the specification.=

Best regards
Ulrich

On Wed, Ma= y 16, 2012 at 9:03 AM, Abdussalam Baryun <abdussalambaryun@gmail.= com> wrote:
Hi Herberg,

I had some comments on OLSRv2-14 and I was informed that there will be
no change only if rough consensus. Now I received a new draft
OLSRv2-15 announced, does this mean that suggestions (to add
explainations) as in the discussion had no rough consensus so no
change is needed? or does it mean that no one has responded to the
confusion observed so it was with no value?

Please note that I need to know the outcome decision of the MANET-WG,
so I can know how to review OLSRv2-15, or I wait for the decision
result to the suggestion of adding explainations in the previous draft
14. Thanking you,

Abdussalam Baryun,
University of Glamorgan, UK

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

Abdussalam,

so far, nobody else seemed to be confused on which layer OLSRv2 is
used (or how the interfaces are defined). IMO, unless other people in
the WG see the same danger of confusion, I would not change it.

Regards
Ulrich

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

The IETF does not work by means of "majority" (which is not even<= br> possible since there is no formal membership), but by rough consensus
(and running code). And every individual can (and should!) review a
document and give suggestions, which can help to improve a document. I
just don't see how your suggestions about the MANET/OLSRv2 interfaces would improve the OLSRv2 draft (for the reasons that Chris, Thomas and
I have pointed out).

Regards
Ulrich

--00248c768f5a06f76c04c02a7a6f-- From sratliff@cisco.com Wed May 16 11:00: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 9043521F8659; Wed, 16 May 2012 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.594 X-Spam-Level: X-Spam-Status: No, score=-10.594 tagged_above=-999 required=5 tests=[AWL=0.004, 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 8FcboY8VTw6x; Wed, 16 May 2012 11:00:53 -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 5FD5121F8653; Wed, 16 May 2012 11:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=5881; q=dns/txt; s=iport; t=1337191253; x=1338400853; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=IV3NxRT75y7/k4Cz0eT7Phl74949Xl1039LiyU+kUeM=; b=TVIV0rV+6mPHfmtASu15iB+hZ2u/yTiJI1u8V/JtOBiraVHHkKIhc6+S oKswTK/vneZlJIT1ayuD/saQ0YlFqMRjgZg5wRTsqjh9GoWpWRdXlL6vo DP9d+/7dcBWAWLLD/0Dv1pYnYwLZCpHAma2pDQvUY8EJtHo0XoBwIiUVB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIvTs0+tJV2b/2dsb2JhbABEtAuBB4IVAQEBAwESAWYFCwsEFC4hNgYTIodeAwYFmyOWJQ2JU4okb4RzYgOVeos9gxqBaYMF X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208,217";a="83856269" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 16 May 2012 18:00:53 +0000 Received: from dhcp-64-102-54-110.cisco.com (dhcp-64-102-54-110.cisco.com [64.102.54.110]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4GI0qXf025362; Wed, 16 May 2012 18:00:52 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6059F2E4-48E8-4ECB-8427-96D10112631F" From: Stan Ratliff In-Reply-To: Date: Wed, 16 May 2012 14:00:52 -0400 Message-Id: <08CCA4C4-50E5-401A-A091-47037BD9B15E@cisco.com> References: To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) Cc: jpmacker@gmail.com, manet , internet-drafts@ietf.org, Abdussalam Baryun Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Wed, 16 May 2012 18:00:54 -0000 --Apple-Mail=_6059F2E4-48E8-4ECB-8427-96D10112631F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Abdusallam,=20 I would add - the Working Group Last Call (WGLC) period for this = document has expired. OLSRv2-15 is intended to be sent forward to the = area directors and the IESG for their review, and ultimately, = publication as a standards track RFC. Your comments on this draft are = welcome on the list, but don't expect anything to change - unless, of = course, you've found a "doomsday scenario" where OLSRv2 completely = breaks down=85 ;-) Regards, Stan On May 16, 2012, at 1:16 PM, Ulrich Herberg wrote: > Abdusallam, >=20 > OLSRv2-15 only contains some minor editorial updates (spelling = mistakes and grammatical errors) and no change to the specification. >=20 > Best regards > Ulrich >=20 > On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun = wrote: > Hi Herberg, >=20 > I had some comments on OLSRv2-14 and I was informed that there will be > no change only if rough consensus. Now I received a new draft > OLSRv2-15 announced, does this mean that suggestions (to add > explainations) as in the discussion had no rough consensus so no > change is needed? or does it mean that no one has responded to the > confusion observed so it was with no value? >=20 > Please note that I need to know the outcome decision of the MANET-WG, > so I can know how to review OLSRv2-15, or I wait for the decision > result to the suggestion of adding explainations in the previous draft > 14. Thanking you, >=20 > Abdussalam Baryun, > University of Glamorgan, UK >=20 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 > Abdussalam, >=20 > so far, nobody else seemed to be confused on which layer OLSRv2 is > used (or how the interfaces are defined). IMO, unless other people in > the WG see the same danger of confusion, I would not change it. >=20 > Regards > Ulrich >=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >=20 > The IETF does not work by means of "majority" (which is not even > possible since there is no formal membership), but by rough consensus > (and running code). And every individual can (and should!) review a > document and give suggestions, which can help to improve a document. I > just don't see how your suggestions about the MANET/OLSRv2 interfaces > would improve the OLSRv2 draft (for the reasons that Chris, Thomas and > I have pointed out). >=20 > Regards > Ulrich >=20 --Apple-Mail=_6059F2E4-48E8-4ECB-8427-96D10112631F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Regards,
Stan

On May 16, 2012, at 1:16 PM, Ulrich Herberg wrote:

Abdusallam,

OLSRv2-15 only contains some minor = editorial updates (spelling mistakes and grammatical errors) and no = change to the specification.

Best regards
Ulrich

On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun = <abdussalambaryun@gmail.com> wrote:
Hi Herberg,

I had some comments on OLSRv2-14 and I was informed that there will = be
no change only if rough consensus. Now I received a new draft
OLSRv2-15 announced, does this mean that suggestions (to add
explainations) as in the discussion had no rough consensus so no
change is needed? or does it mean that no one has responded to the
confusion observed so it was with no value?

Please note that I need to know the outcome decision of the = MANET-WG,
so I can know how to review OLSRv2-15, or I wait for the decision
result to the suggestion of adding explainations in the previous = draft
14. Thanking you,

Abdussalam Baryun,
University of Glamorgan, UK

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

Abdussalam,

so far, nobody else seemed to be confused on which layer OLSRv2 is
used (or how the interfaces are defined). IMO, unless other people = in
the WG see the same danger of confusion, I would not change it.

Regards
Ulrich

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

The IETF does not work by means of "majority" (which is not even
possible since there is no formal membership), but by rough = consensus
(and running code). And every individual can (and should!) review a
document and give suggestions, which can help to improve a document. = I
just don't see how your suggestions about the MANET/OLSRv2 = interfaces
would improve the OLSRv2 draft (for the reasons that Chris, Thomas = and
I have pointed out).

Regards
Ulrich


= --Apple-Mail=_6059F2E4-48E8-4ECB-8427-96D10112631F-- From valerio.arnaboldi@iit.cnr.it Wed May 16 23:07: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 D371A21F858F for ; Wed, 16 May 2012 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[AWL=2.518, 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 XLysZkUlHTph for ; Wed, 16 May 2012 23:07:34 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1924421F858E for ; Wed, 16 May 2012 23:07:33 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id B5CC73D8238; Thu, 17 May 2012 08:07:01 +0200 (CEST) Date: Thu, 17 May 2012 08:07:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4fb49585.JzBb/r9L2ZT57EGk%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 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, 17 May 2012 06:07:35 -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 Thu May 17 12:14: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 6439721F8783; Thu, 17 May 2012 12:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 3XS0eWI12CvW; Thu, 17 May 2012 12:14:01 -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 3D70221F8771; Thu, 17 May 2012 12:14:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2372252vbb.31 for ; Thu, 17 May 2012 12:14:00 -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=RPzL6sgLGSYwO3nQWEvKrVKB8LIRAwAeHQ6Da023+Yg=; b=O40cPPH+eG7mNVE7qSyWVEQv7H1OJ5zqUj/TGTVBuCdiA7PgAcsLfPQtlv+1bB3vPj i6DFXmwb1gkAuoE0sijnmAgnaBPawtGBjefTvoEb7/UuIaTkAqC4hjBqzK3uCpO4ORB8 qFZsmhJRYpKHSBSJGkUsdeoPBa0CKPleorkoc55gm2H9pbXM3XCekd3MS73iT/rCwPSP uFBVpbCrp6fdrYRGalq4NftS1F1NDhKgasgMAl5KOVvtdHnfMTDE7HqR2f5iouvT80tC I8m/+IjmS0rSG9by7rwxwhiixbxOLH3JNIbQ5F4d6NK1mpv6A5LOD8NGknu49qT3RyHg KMJw== MIME-Version: 1.0 Received: by 10.220.156.10 with SMTP id u10mr5493820vcw.20.1337282040515; Thu, 17 May 2012 12:14:00 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Thu, 17 May 2012 12:14:00 -0700 (PDT) In-Reply-To: <08CCA4C4-50E5-401A-A091-47037BD9B15E@cisco.com> References: <08CCA4C4-50E5-401A-A091-47037BD9B15E@cisco.com> Date: Thu, 17 May 2012 21:14:00 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: jpmacker@gmail.com, manet , internet-drafts@ietf.org Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Thu, 17 May 2012 19:14:02 -0000 Hi Stan, I thought that for olsrv2-14 the last call expires on 10.05.2012 (my suggestion submitted before 10 May), but then I received the notice of olsrv2-15 on 15.05.2012. I did not expect changes, but I expected to know the outcome of the WG decision regarding suggestions. I just expect a respond from WG to my input. The authors' decision or respond was received, but not the group's. However, I understand from your reply that the decision of the WG is: there is no need for updates to the OLSRv2-14 and OLSRv2-15 documents. Thanking you, Abdussalam Baryun, University of Glamorgan, UK +++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/16/12, Stan Ratliff wrote: > Abdusallam, > > I would add - the Working Group Last Call (WGLC) period for this document > has expired. OLSRv2-15 is intended to be sent forward to the area directo= rs > and the IESG for their review, and ultimately, publication as a standards > track RFC. Your comments on this draft are welcome on the list, but don't > expect anything to change - unless, of course, you've found a "doomsday > scenario" where OLSRv2 completely breaks down=85 ;-) > > Regards, > Stan > > On May 16, 2012, at 1:16 PM, Ulrich Herberg wrote: > >> Abdusallam, >> >> OLSRv2-15 only contains some minor editorial updates (spelling mistakes >> and grammatical errors) and no change to the specification. >> >> Best regards >> Ulrich >> >> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun >> wrote: >> Hi Herberg, >> >> I had some comments on OLSRv2-14 and I was informed that there will be >> no change only if rough consensus. Now I received a new draft >> OLSRv2-15 announced, does this mean that suggestions (to add >> explainations) as in the discussion had no rough consensus so no >> change is needed? or does it mean that no one has responded to the >> confusion observed so it was with no value? >> >> Please note that I need to know the outcome decision of the MANET-WG, >> so I can know how to review OLSRv2-15, or I wait for the decision >> result to the suggestion of adding explainations in the previous draft >> 14. Thanking you, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Abdussalam, >> >> so far, nobody else seemed to be confused on which layer OLSRv2 is >> used (or how the interfaces are defined). IMO, unless other people in >> the WG see the same danger of confusion, I would not change it. >> >> Regards >> Ulrich >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> The IETF does not work by means of "majority" (which is not even >> possible since there is no formal membership), but by rough consensus >> (and running code). And every individual can (and should!) review a >> document and give suggestions, which can help to improve a document. I >> just don't see how your suggestions about the MANET/OLSRv2 interfaces >> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >> I have pointed out). >> >> Regards >> Ulrich >> > > From abdussalambaryun@gmail.com Thu May 17 12:45: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 6E37D21F87DD; Thu, 17 May 2012 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 AbnmvdEZjbKK; Thu, 17 May 2012 12:45: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 74F1A21F8783; Thu, 17 May 2012 12:45:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2400991vbb.31 for ; Thu, 17 May 2012 12:45: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; bh=YM2AT7WrxfeQEXAYbFVZcP9IQxC99SUjEsqe+yYB/LU=; b=RcZWfF+1gjDNpm3F9whlzr8WMsbhseaHBD+t6fliJK2PTw0nf9IPHKht1uGvX2soWk S3+0mcWQ4DDajw5JE6npGFk/cgbRUtzs2GkZSPK1UQqqzQYmklurSpRpUr2sWD+2VDj4 EwHPekqOjz0yRsOo5UNunXIwLqxqr7l1vSS8jhs4maBdALs+mgYN9Ow1plXzNFYdkBVv PlIPjXUFPMjfWukn2u/f/iar6Oddqb+YAVN/81xXeXhqbHzKxWHxh7YGw2VFVr617sZm sTQ9WPdW7IrKuQO30rmBvXcZ7nEZCVmqGMY+zgUi/rdjmQGPJEspwRDPq5zPtOSsfBgN t+Pg== MIME-Version: 1.0 Received: by 10.52.31.137 with SMTP id a9mr4381564vdi.51.1337283942904; Thu, 17 May 2012 12:45:42 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Thu, 17 May 2012 12:45:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 May 2012 21:45:42 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: jpmacker@gmail.com, manet , internet-drafts@ietf.org, sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Thu, 17 May 2012 19:45:44 -0000 Hi Ulrich, It was suggested adding information for clarification without touching specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not minor grammer error, but minor words/sentences replacings or delets. Regards Abdussalam ============ On 5/16/12, Ulrich Herberg wrote: > Abdusallam, > > OLSRv2-15 only contains some minor editorial updates (spelling mistakes and > grammatical errors) and no change to the specification. > > Best regards > Ulrich > > On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < > abdussalambaryun@gmail.com> wrote: > >> Hi Herberg, >> >> I had some comments on OLSRv2-14 and I was informed that there will be >> no change only if rough consensus. Now I received a new draft >> OLSRv2-15 announced, does this mean that suggestions (to add >> explainations) as in the discussion had no rough consensus so no >> change is needed? or does it mean that no one has responded to the >> confusion observed so it was with no value? >> >> Please note that I need to know the outcome decision of the MANET-WG, >> so I can know how to review OLSRv2-15, or I wait for the decision >> result to the suggestion of adding explainations in the previous draft >> 14. Thanking you, >> >> Abdussalam Baryun, >> University of Glamorgan, UK >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> Abdussalam, >> >> so far, nobody else seemed to be confused on which layer OLSRv2 is >> used (or how the interfaces are defined). IMO, unless other people in >> the WG see the same danger of confusion, I would not change it. >> >> Regards >> Ulrich >> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> The IETF does not work by means of "majority" (which is not even >> possible since there is no formal membership), but by rough consensus >> (and running code). And every individual can (and should!) review a >> document and give suggestions, which can help to improve a document. I >> just don't see how your suggestions about the MANET/OLSRv2 interfaces >> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >> I have pointed out). >> >> Regards >> Ulrich >> > From ulrich@herberg.name Thu May 17 13:26: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 AF50721F87FF for ; Thu, 17 May 2012 13:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 nbBZ2ZukF5KJ for ; Thu, 17 May 2012 13:26:08 -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 A529421F87FE for ; Thu, 17 May 2012 13:26:08 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1870943qcs.31 for ; Thu, 17 May 2012 13:26:08 -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=euvKlk+7mTUEryi9wK1qiQHvxf6ENqvby5zinRn+sRA=; b=WhXcMcy1+HGiegbWA1oqebO7GifF0Kp32NHA+1rOTGFA76B/HNfhRzqY1QMPAkxrua s5PM2XlMpSzaDkV9bXQZY80Xgk4kJau8Pi67Z0Xds+W0k5tWp9Qhx20i9M7s7tEW9r0G +hWvYA9x2kTP0hiXGFEe6wX5rKEEUTWbX7XE0= 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=euvKlk+7mTUEryi9wK1qiQHvxf6ENqvby5zinRn+sRA=; b=dQkxv+hCCADk6iuo56ibJK7NsRLC49CJMdq2lFhoDwc6+tB/8/60Xgyu3dOH2nB/C1 acqA8VCLO9BIETXWVNJ63lLB2Ad1Mk0kUC0fefWE/1LxFXlc4DXVJ4/YqHeb/XAYAioU dCeit0Sb8RmLQz/xPI4VosY2mbXeWPEkdSF8njp5nGmmD+9uqSJyYhx7H3JFMSqWdLUT bKtge4aL6ybUQdInv7qhBftvjKw68iO29RIUvgRXpxIxne3SxAvJFE/kIkXDd2nyqG0f klNTvAApNep9vp7DyuA230bbaLWhtDHy/A0dZ3jlnWBGoqXD1pK1LbunHAU6ZtRPlFrS lH7w== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr4206743qct.86.1337286368068; Thu, 17 May 2012 13:26:08 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Thu, 17 May 2012 13:26:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 May 2012 13:26:07 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkQAPOKsEAu9D6j5Pf/flEOGN0UxlxFFUw9bSJsxLzCr1rOSk8FKhfEyetDyUdsnZ6HLnbK Cc: jpmacker@gmail.com, manet , sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Thu, 17 May 2012 20:26:09 -0000 Abdussalam, I am not quite sure what you request. Your comments during the WGLC have been heard, and the authors replied to your emails, arguing why we believe that the current terminology is fine. There did not seem to be any WG consensus that there should be changes like you suggested. Best regards Ulrich On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun wrote: > Hi Ulrich, > > It was suggested adding information for clarification without touching > specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not > minor grammer error, but minor words/sentences replacings or delets. > > Regards > Abdussalam > ============ > On 5/16/12, Ulrich Herberg wrote: >> Abdusallam, >> >> OLSRv2-15 only contains some minor editorial updates (spelling mistakes and >> grammatical errors) and no change to the specification. >> >> Best regards >> Ulrich >> >> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >> abdussalambaryun@gmail.com> wrote: >> >>> Hi Herberg, >>> >>> I had some comments on OLSRv2-14 and I was informed that there will be >>> no change only if rough consensus. Now I received a new draft >>> OLSRv2-15 announced, does this mean that suggestions (to add >>> explainations) as in the discussion had no rough consensus so no >>> change is needed? or does it mean that no one has responded to the >>> confusion observed so it was with no value? >>> >>> Please note that I need to know the outcome decision of the MANET-WG, >>> so I can know how to review OLSRv2-15, or I wait for the decision >>> result to the suggestion of adding explainations in the previous draft >>> 14. Thanking you, >>> >>> Abdussalam Baryun, >>> University of Glamorgan, UK >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> Abdussalam, >>> >>> so far, nobody else seemed to be confused on which layer OLSRv2 is >>> used (or how the interfaces are defined). IMO, unless other people in >>> the WG see the same danger of confusion, I would not change it. >>> >>> Regards >>> Ulrich >>> >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> The IETF does not work by means of "majority" (which is not even >>> possible since there is no formal membership), but by rough consensus >>> (and running code). And every individual can (and should!) review a >>> document and give suggestions, which can help to improve a document. I >>> just don't see how your suggestions about the MANET/OLSRv2 interfaces >>> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >>> I have pointed out). >>> >>> Regards >>> Ulrich >>> >> From abdussalambaryun@gmail.com Fri May 18 00:00: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 D71E721F86CF for ; Fri, 18 May 2012 00:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 W3P1kArkeCP9 for ; Fri, 18 May 2012 00:00:37 -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 4327421F86CA for ; Fri, 18 May 2012 00:00:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2802319vbb.31 for ; Fri, 18 May 2012 00:00: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=kX9LiNVj50+pfmjwXyANbzSwZHht4kuBHDSipzMtJyQ=; b=DbDznJZp3kOW2Nq4pRVYJYiVfkDxQbBI/9e4NOXawX0yUWr7qARULyo8xYDeg/noOF jxz8tHgf/YQddo6pRWyNL8xDZwsyaIe6v89hrCKJNEtwrjzPHXov2y4LI51ScYCaSEqk BucDMlvibzJ3EvhPbmi13YaIN63BQVj2jX5uDMTID0lj/3KPGAX+CrHyQZNf8fz33wkL qzzivsdbxIpoe2Fn5Aw0NiImE2UrJanSd0VYK2gJixP5utnpp9AYXE4ZeK0dXDygDUX9 uhmubYVG70hVwJaQRCuw+sKiAUHXyfYMqGUptk6p0WTrzSheJPgdkLrqJY3xN3yb5hsN rgOA== MIME-Version: 1.0 Received: by 10.52.21.174 with SMTP id w14mr5120865vde.24.1337324435728; Fri, 18 May 2012 00:00:35 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Fri, 18 May 2012 00:00:35 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 May 2012 09:00:35 +0200 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 Cc: jpmacker@gmail.com, manet , sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 07:00:38 -0000 Ulrich, I did not request first it was a respond to the call. I received the request/call of drafts olsrv2-14 and now olsrv2-15, so I responded suggestions, and for last-call-olsrv2-14 (expirs 10.05.2012) I requested before the expiry to adding information to the document to avoid confusions, because I while reading it was confused. I discussed with authors and they didn't agree to add information. Then I requested a respond from the WG to my input, so we can have progress in the review process or WG process. Then I received the chair respond which I will understand is the WG respond to the suggestions. If I received a respond from the WG to the suggestion (i.e. it was the only respond to the last call request of olsrv2-14) I would not have send a request of wg respond. It is in the procedure for working group process RFC2418. Best Regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++ On 5/17/12, Ulrich Herberg wrote: > Abdussalam, > > I am not quite sure what you request. Your comments during the WGLC > have been heard, and the authors replied to your emails, arguing why > we believe that the current terminology is fine. There did not seem to > be any WG consensus that there should be changes like you suggested. > > > Best regards > Ulrich > > On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun > wrote: >> Hi Ulrich, >> >> It was suggested adding information for clarification without touching >> specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not >> minor grammer error, but minor words/sentences replacings or delets. >> >> Regards >> Abdussalam >> ============ >> On 5/16/12, Ulrich Herberg wrote: >>> Abdusallam, >>> >>> OLSRv2-15 only contains some minor editorial updates (spelling mistakes >>> and >>> grammatical errors) and no change to the specification. >>> >>> Best regards >>> Ulrich >>> >>> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> Hi Herberg, >>>> >>>> I had some comments on OLSRv2-14 and I was informed that there will be >>>> no change only if rough consensus. Now I received a new draft >>>> OLSRv2-15 announced, does this mean that suggestions (to add >>>> explainations) as in the discussion had no rough consensus so no >>>> change is needed? or does it mean that no one has responded to the >>>> confusion observed so it was with no value? >>>> >>>> Please note that I need to know the outcome decision of the MANET-WG, >>>> so I can know how to review OLSRv2-15, or I wait for the decision >>>> result to the suggestion of adding explainations in the previous draft >>>> 14. Thanking you, >>>> >>>> Abdussalam Baryun, >>>> University of Glamorgan, UK >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> Abdussalam, >>>> >>>> so far, nobody else seemed to be confused on which layer OLSRv2 is >>>> used (or how the interfaces are defined). IMO, unless other people in >>>> the WG see the same danger of confusion, I would not change it. >>>> >>>> Regards >>>> Ulrich >>>> >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> The IETF does not work by means of "majority" (which is not even >>>> possible since there is no formal membership), but by rough consensus >>>> (and running code). And every individual can (and should!) review a >>>> document and give suggestions, which can help to improve a document. I >>>> just don't see how your suggestions about the MANET/OLSRv2 interfaces >>>> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >>>> I have pointed out). >>>> >>>> Regards >>>> Ulrich >>>> >>> > From marius@itee.uq.edu.au Fri May 18 00:28: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 9C49D21F8636 for ; Fri, 18 May 2012 00:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, 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 5q88IFw6+HC1 for ; Fri, 18 May 2012 00:28:58 -0700 (PDT) Received: from mailhub3.uq.edu.au (mailhub3.uq.edu.au [130.102.148.131]) by ietfa.amsl.com (Postfix) with ESMTP id D21D021F8603 for ; Fri, 18 May 2012 00:28:56 -0700 (PDT) Received: from smtp4.uq.edu.au (smtp4.uq.edu.au [130.102.128.19]) by mailhub3.uq.edu.au (8.13.8/8.13.8) with ESMTP id q4I7SriW009932; Fri, 18 May 2012 17:28:55 +1000 Received: from UQEXET02.soe.uq.edu.au (uqexet02.soe.uq.edu.au [130.102.6.3]) by smtp4.uq.edu.au (8.13.8/8.13.8) with ESMTP id q4I7Sr6p010693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 18 May 2012 17:28:53 +1000 Received: from UQEXHT2.soe.uq.edu.au (130.102.129.71) by UQEXET02.soe.uq.edu.au (130.102.6.3) with Microsoft SMTP Server (TLS) id 8.2.247.2; Fri, 18 May 2012 17:28:53 +1000 Received: from UQEXMDA1.soe.uq.edu.au ([169.254.1.98]) by UQEXHT2.soe.uq.edu.au ([130.102.129.71]) with mapi id 14.01.0355.002; Fri, 18 May 2012 17:28:53 +1000 From: Marius Portmann To: "'draft-ietf-manet-dymo@tools.ietf.org'" Thread-Topic: draft-ietf-manet-dymo Intermediate RREP handling in AODVv2 Thread-Index: Ac00xjXYZ+Ui9xskQyGnhO4+on4bnQ== Date: Fri, 18 May 2012 07:28:52 +0000 Message-ID: <55276FFE1B06A541A659C0B360E8066F0E1BF5@UQEXMDA1.soe.uq.edu.au> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.102.64.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-UQ-FilterTime: 1337326135 X-Scanned-By: MIMEDefang 2.58 on UQ Mailhub on 130.102.148.131 Cc: manet Subject: [manet] draft-ietf-manet-dymo Intermediate RREP handling in AODVv2 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, 18 May 2012 07:28:58 -0000 Dear Charlie, Ian, We have been working on modelling AODV and verifying key protocol propertie= s (e.g. loop freedom) using Formal Methods techniques such as Process Algeb= ra [1] and Model Checking [2]. We have recently also adapted our formal description of AODV to DYMO, based= on draft version 21.=20 We would like to update our model to be consistent with the latest version = of DYMO/AODVv2 (draft 22). However, while draft 21 was self-contained, version 22 (in Appendix A) refe= rs to other, new documents for the description of some protocol features, i= n particular the handling of intermediate RREPs. In order to formally model and reason about AODVv2 protocol behaviour, it w= ould be important for us to have a complete description of the protocol. Is there a timeline for the additional new document outlining the handling = of iRREPs to become available? Also, is the new iRREP behaviour expected to be significantly different to = draft version 21? [1] A. Fehnker et al., A process algebra for wireless mesh networks. In E= uropean Symposium on Programming (ESOP'12)=20 [2] A. Fehnker et al., Automated analysis of AODV using UPPAAL. In Tools a= nd Algorithms for the Construction and Analysis of Systems (TACAS'12)=20 cheers marius ---------------------------------------------------------------------- Dr Marius Portmann School of ITEE The University of Queensland Brisbane 4072, Australia CRICOS Provider No: 00025B Tel: +61 7 3300 8561, Fax: +61 7 3365 4999 ---------------------------------------------------------------------- From valerio.arnaboldi@iit.cnr.it Fri May 18 02:12: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 8112321F8542 for ; Fri, 18 May 2012 02:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.96 X-Spam-Level: X-Spam-Status: No, score=0.96 tagged_above=-999 required=5 tests=[AWL=1.679, 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 JKIFVBGockio for ; Fri, 18 May 2012 02:12:34 -0700 (PDT) Received: from irina.iit.cnr.it (irina.iit.cnr.it [146.48.98.243]) by ietfa.amsl.com (Postfix) with ESMTP id A695B21F853E for ; Fri, 18 May 2012 02:12:34 -0700 (PDT) Received: by irina.iit.cnr.it (Postfix, from userid 1001) id 8478F3D8238; Fri, 18 May 2012 11:12:01 +0200 (CEST) Date: Fri, 18 May 2012 11:12:01 +0200 From: Valerio Arnaboldi To: manet@ietf.org Message-ID: <4fb61261.LRpOot7Dmdb3yELu%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 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, 18 May 2012 09:12:35 -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 SUBMISSION DEADLINE: June 11, 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 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 From Chris.Dearlove@baesystems.com Fri May 18 02:17:34 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 E3E8821F8565 for ; Fri, 18 May 2012 02:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 3TM1snNmRX0f for ; Fri, 18 May 2012 02:17:34 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5BA21F855F for ; Fri, 18 May 2012 02:17:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,616,1330905600"; d="scan'208";a="239707501" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 18 May 2012 10:17:32 +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 q4I9HVKP008920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 May 2012 10:17:31 +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, 18 May 2012 10:17:31 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , Ulrich Herberg Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt Thread-Index: AQHNM31vV/vjdL4iTEuYM8ojiWsbA5bMl3MAgAG8FwCAAAtLgIAAsUWAgAAyVOA= Date: Fri, 18 May 2012 09:17:31 +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: "jpmacker@gmail.com" , manet , "sratliff@cisco.com" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 09:17:35 -0000 The was a WGLC on OLSRv2, which happened to be at -14. Typical practice aft= er a WGLC concludes is to produce a revised document incorporating any chan= ges, which in this case happens to be -15. Note that -15 didn't appear unti= l after WGLC had closed, so it is not relevant to the submission of comment= s in response to that call. This sort of upissue does not re-open a WGLC un= less in the opinion of the WG chairs, responsible AD etc. the changes are s= ignificant and require that. I don't speak for those people, but their acti= ons go along with that, and the authors would have been surprised otherwise= . The changes made mostly represent nits that the authors (who also reviewe= d the document) found. Most aren't actually errors but just the usual edito= rial process of tightening wording. I see nothing that contradicts RFC 2418= , and I've now seen this process happen five times for a document I'm an au= thor of, all similarly. Within the WGLC the authors responded to your comments. No one else chose t= o support them, and hence there was clearly no consensus (and probably a co= nsensus against) making those changes. --=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: 18 May 2012 08:01 To: Ulrich Herberg Cc: jpmacker@gmail.com; manet; sratliff@cisco.com Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt ----------------------! 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. -------------------------------------------------------- Ulrich, I did not request first it was a respond to the call. I received the request/call of drafts olsrv2-14 and now olsrv2-15, so I responded suggestions, and for last-call-olsrv2-14 (expirs 10.05.2012) I requested before the expiry to adding information to the document to avoid confusions, because I while reading it was confused. I discussed with authors and they didn't agree to add information. Then I requested a respond from the WG to my input, so we can have progress in the review process or WG process. Then I received the chair respond which I will understand is the WG respond to the suggestions. If I received a respond from the WG to the suggestion (i.e. it was the only respond to the last call request of olsrv2-14) I would not have send a request of wg respond. It is in the procedure for working group process RFC2418. Best Regards Abdussalam Baryun University of Glamorgan, UK +++++++++++++++++++++++++++++++++ On 5/17/12, Ulrich Herberg wrote: > Abdussalam, > > I am not quite sure what you request. Your comments during the WGLC > have been heard, and the authors replied to your emails, arguing why > we believe that the current terminology is fine. There did not seem to > be any WG consensus that there should be changes like you suggested. > > > Best regards > Ulrich > > On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun > wrote: >> Hi Ulrich, >> >> It was suggested adding information for clarification without touching >> specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not >> minor grammer error, but minor words/sentences replacings or delets. >> >> Regards >> Abdussalam >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> On 5/16/12, Ulrich Herberg wrote: >>> Abdusallam, >>> >>> OLSRv2-15 only contains some minor editorial updates (spelling mistakes >>> and >>> grammatical errors) and no change to the specification. >>> >>> Best regards >>> Ulrich >>> >>> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >>> abdussalambaryun@gmail.com> wrote: >>> >>>> Hi Herberg, >>>> >>>> I had some comments on OLSRv2-14 and I was informed that there will be >>>> no change only if rough consensus. Now I received a new draft >>>> OLSRv2-15 announced, does this mean that suggestions (to add >>>> explainations) as in the discussion had no rough consensus so no >>>> change is needed? or does it mean that no one has responded to the >>>> confusion observed so it was with no value? >>>> >>>> Please note that I need to know the outcome decision of the MANET-WG, >>>> so I can know how to review OLSRv2-15, or I wait for the decision >>>> result to the suggestion of adding explainations in the previous draft >>>> 14. Thanking you, >>>> >>>> Abdussalam Baryun, >>>> University of Glamorgan, UK >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> Abdussalam, >>>> >>>> so far, nobody else seemed to be confused on which layer OLSRv2 is >>>> used (or how the interfaces are defined). IMO, unless other people in >>>> the WG see the same danger of confusion, I would not change it. >>>> >>>> Regards >>>> Ulrich >>>> >>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> The IETF does not work by means of "majority" (which is not even >>>> possible since there is no formal membership), but by rough consensus >>>> (and running code). And every individual can (and should!) review a >>>> document and give suggestions, which can help to improve a document. I >>>> just don't see how your suggestions about the MANET/OLSRv2 interfaces >>>> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >>>> I have pointed out). >>>> >>>> Regards >>>> Ulrich >>>> >>> > _______________________________________________ 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 May 18 05:03: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 E41FC21F865D for ; Fri, 18 May 2012 05:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, 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 YNxCetNESc1J for ; Fri, 18 May 2012 05:03: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 988F121F85AD for ; Fri, 18 May 2012 05:03:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3010757vbb.31 for ; Fri, 18 May 2012 05: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 :cc:content-type; bh=ZgtEAAzACSX/Cy+di9+XToFiAZ/2Qf0+SH6jr+ccfIA=; b=URGh9U0wVfPHRUktCs483OZKbL2VKSpIoCAg09WGPTBaiwtg7xTT3pma0AWwkQCy15 TMzbLjNNcZkX9jnXuEJPeo4iwuPO0r7Evi36QHZJv8LNSIq9Az7vdMCFof103ZCQgyuo V5FYxALDQphs4ueAeOQ/JEjTuD91PHO8XjZitJl1NXl/Kwt2Kv1wFINS0nWGa6h2Mrx9 5LTRjogKXK2q6lx+LQa+ryvEVhgnm9i5q6SmaEb1tM/Cq4XPoSGu8iO+ApA4Z81TJWnt KsmYpYfmoUFsI9xZbmby9w4ONRhWnocqZ/aVR6SpO78kD3xoful8/sdeOv3quN47wvP4 dr8Q== MIME-Version: 1.0 Received: by 10.52.23.81 with SMTP id k17mr5406606vdf.103.1337342636033; Fri, 18 May 2012 05:03:56 -0700 (PDT) Received: by 10.220.187.203 with HTTP; Fri, 18 May 2012 05:03:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 May 2012 14:03:55 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "jpmacker@gmail.com" , manet , "sratliff@cisco.com" Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 12:03:58 -0000 Hi Chris, On 5/18/12, Dearlove, Christopher (UK) wrote: > The was a WGLC on OLSRv2, which happened to be at -14. Typical practice > after a WGLC concludes is to produce a revised document incorporating any > changes, which in this case happens to be -15. Note that -15 didn't appear > until after WGLC had closed, so it is not relevant to the submission of > comments in response to that call. This sort of upissue does not re-open a > WGLC unless in the opinion of the WG chairs, responsible AD etc. the changes > are significant and require that. I don't speak for those people, but their > actions go along with that, and the authors would have been surprised > otherwise. I have no problem with the issue 15 after closing WGLC, but was expecting to see result of my input to the last call of draft-14. It is reasonable for reviewers to see the response (WG respond and decision if they don't agree with authors) to their comments on 14 before receiving the 15. IMHO it is good for the process, if the group thinks that things are not required it informs who thinks it is required. > The changes made mostly represent nits that the authors (who also > reviewed the document) found. Most aren't actually errors but just the usual > editorial process of tightening wording. I see nothing that contradicts RFC > 2418, and I've now seen this process happen five times for a document I'm an > author of, all similarly. > I have read once in RFC2418 that means if a suggestion required, the group concensus can be collected. My comments reported a confusion in reply to the last call, and I wanted to see the process reaction to this input. Therefore, I needed a response from the group. However, I received from the group chair the response after the 15 issue, that 14 was intended to sent forward. If I knew that I will not make an input for 14, and not sure why we have last call not mentioning this important information? In addition, the issue of suggestion of big change or minor change I don't read it in 2418, I think any suggestion is respected the same value. > Within the WGLC the authors responded to your comments. No one else chose to > support them, and hence there was clearly no consensus (and probably a > consensus against) making those changes. > I agree with you, authors were helpful to address their position which I am not confused any more after the discussion. Other readers in the future may have the same, however, their was no one other than authors responded infavour nor against, and that is why I replied when I received the announcement of 15 (i.e. the subject title). I thank you for your reply, Abdussalam Baryun University of Glamorgan, UK > -- > 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: 18 May 2012 08:01 > To: Ulrich Herberg > Cc: jpmacker@gmail.com; manet; sratliff@cisco.com > Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt > > ----------------------! 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. > -------------------------------------------------------- > > Ulrich, > > I did not request first it was a respond to the call. I received the > request/call of drafts olsrv2-14 and now olsrv2-15, so I responded > suggestions, and for last-call-olsrv2-14 (expirs 10.05.2012) I > requested before the expiry to adding information to the document to > avoid confusions, because I while reading it was confused. I discussed > with authors and they didn't agree to add information. Then I > requested a respond from the WG to my input, so we can have progress > in the review process or WG process. Then I received the chair respond > which I will understand is the WG respond to the suggestions. > > If I received a respond from the WG to the suggestion (i.e. it was > the only respond to the last call request of olsrv2-14) I would not > have send a request of wg respond. It is in the procedure for working > group process RFC2418. > > Best Regards > > Abdussalam Baryun > University of Glamorgan, UK > +++++++++++++++++++++++++++++++++ > > On 5/17/12, Ulrich Herberg wrote: >> Abdussalam, >> >> I am not quite sure what you request. Your comments during the WGLC >> have been heard, and the authors replied to your emails, arguing why >> we believe that the current terminology is fine. There did not seem to >> be any WG consensus that there should be changes like you suggested. >> >> >> Best regards >> Ulrich >> >> On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun >> wrote: >>> Hi Ulrich, >>> >>> It was suggested adding information for clarification without touching >>> specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not >>> minor grammer error, but minor words/sentences replacings or delets. >>> >>> Regards >>> Abdussalam >>> ============ >>> On 5/16/12, Ulrich Herberg wrote: >>>> Abdusallam, >>>> >>>> OLSRv2-15 only contains some minor editorial updates (spelling mistakes >>>> and >>>> grammatical errors) and no change to the specification. >>>> >>>> Best regards >>>> Ulrich >>>> >>>> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >>>> abdussalambaryun@gmail.com> wrote: >>>> >>>>> Hi Herberg, >>>>> >>>>> I had some comments on OLSRv2-14 and I was informed that there will be >>>>> no change only if rough consensus. Now I received a new draft >>>>> OLSRv2-15 announced, does this mean that suggestions (to add >>>>> explainations) as in the discussion had no rough consensus so no >>>>> change is needed? or does it mean that no one has responded to the >>>>> confusion observed so it was with no value? >>>>> >>>>> Please note that I need to know the outcome decision of the MANET-WG, >>>>> so I can know how to review OLSRv2-15, or I wait for the decision >>>>> result to the suggestion of adding explainations in the previous draft >>>>> 14. Thanking you, >>>>> >>>>> Abdussalam Baryun, >>>>> University of Glamorgan, UK >>>>> >>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> Abdussalam, >>>>> >>>>> so far, nobody else seemed to be confused on which layer OLSRv2 is >>>>> used (or how the interfaces are defined). IMO, unless other people in >>>>> the WG see the same danger of confusion, I would not change it. >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>> >>>>> The IETF does not work by means of "majority" (which is not even >>>>> possible since there is no formal membership), but by rough consensus >>>>> (and running code). And every individual can (and should!) review a >>>>> document and give suggestions, which can help to improve a document. I >>>>> just don't see how your suggestions about the MANET/OLSRv2 interfaces >>>>> would improve the OLSRv2 draft (for the reasons that Chris, Thomas and >>>>> I have pointed out). >>>>> >>>>> Regards >>>>> Ulrich >>>>> >>>> >> > _______________________________________________ > 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 May 18 07:14: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 F132E21F86B7 for ; Fri, 18 May 2012 07:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-2.200, BAYES_00=-2.599, GB_SUMOF=5, 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 JFeI80SrnHgD for ; Fri, 18 May 2012 07:14: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 39C4C21F86BA for ; Fri, 18 May 2012 07:14:32 -0700 (PDT) Received: by werb13 with SMTP id b13so630099wer.31 for ; Fri, 18 May 2012 07:14:29 -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=OrlT2xMc3P7KNnPbm9uDKiTTPi7gG9jC9hh40fjajlk=; b=efPOM1jGULDamDOz5MnCIohuzpg8UauVrtgXBfRbuZAY3bgk16twiLVq6cAKHjFtXO GSFs6CeGdyKixcU//9K7OeksZhq4vQ6fgXPSLGMRcZHkCQHBIi8+g+JONvLhtGW5fxto VNt0HygVY/PwBAYdU3QzjlwkzGWizR84H/K1qrRvXCWxqwwRnrhGuHwnvcSCaw2Z4sFb gMBsqg6XDsRBc3Qhci5rlPN5QHHm3iTzYiO1UW426oVBeCsDS+6t1YYJ9NV2d6xtgDY1 CW81F1RACuH1mETyg/LHh1TrUpQ0fLditWS69M0JTnkSToNjdcFSitiCvwEd6JZFQSQh /EPQ== MIME-Version: 1.0 Received: by 10.180.84.4 with SMTP id u4mr2105712wiy.2.1337350469586; Fri, 18 May 2012 07:14:29 -0700 (PDT) Received: by 10.180.100.10 with HTTP; Fri, 18 May 2012 07:14:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 May 2012 16:14:29 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 14:14:33 -0000 Hi I beleive that olsrv2-15 has important sentences changes which change few previous information meanings (which I agree on). If undertood correctly the changes were made by authors revision decision. I want to know why were the below changes made, because the explanation will help the WG in better understanding of the minor amendments or of the new issue 15? OLSRv2-15 Deleted the below paragraph: Enables source routing, i.e., each router can use its local information provided by this protocol to specify the complete path for a packet. (This will require the retention of additional information during the Routing Set evaluation.) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In OLSRv2-14: OLSRv2, as defined in this specification, allows links to have a metric (also known as a cost). Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are minimum length routes, where the length of a route is defined as the sum of the metrics of the links in that route. In OLSRv2-15 Replaced above by: OLSRv2, as defined in this specification, supports metric-based routing, i.e., it allows links to each have a chosen metric. Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are those with the minimum sum of the link metrics along that route. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In OLSRv2-14: R_local_iface_addr is the network address of the local OLSRv2 interface over which an IP packet MUST be sent to reach the destination by the selected path. In OLSRv2-15 Replaced by: R_local_iface_addr is an address of the local interface over which an IP packet MUST be sent to reach the destination by the selected path. Thanking you, Abdussalam Baryun University of Glamorgan, UK From Chris.Dearlove@baesystems.com Fri May 18 07:37: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 646AB21F864C for ; Fri, 18 May 2012 07:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.017 X-Spam-Level: X-Spam-Status: No, score=-4.017 tagged_above=-999 required=5 tests=[AWL=-2.418, BAYES_00=-2.599, GB_SUMOF=5, 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 EZElmQEPMi+f for ; Fri, 18 May 2012 07:37:43 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54721F864D for ; Fri, 18 May 2012 07:37:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="239818881" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 18 May 2012 15:37:42 +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 q4IEbgO6026505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 May 2012 15:37:42 +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; Fri, 18 May 2012 15:37:41 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun , manet Thread-Topic: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt Thread-Index: AQHNM31vV/vjdL4iTEuYM8ojiWsbA5bMl3MAgAG8FwCAAAtLgIAAsUWAgAAyVOCAACJsgIAAJHqAgAAVA0A= Date: Fri, 18 May 2012 14:37:41 +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] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 14:37:44 -0000 Nothing here is significant. The source routing point (which is purely explanatory, it has no effect on = the protocol) removed a late added observation that actually there's been n= o demand for, and had a technical problem that source routing would only pr= ogress to external gateways, not beyond them. It seemed pointless to retain= it, as all it did was point out you could do something, but not how to do = it. The second point is entirely editorial, simplifying text to just use the te= rm metric. The third point essentially corrected from "the" address to "an" address, b= ecause an interface can have more than one address, and then cleaned up wor= ding. Anyone with an implementation of OLSRv2 would not have to change even a com= ment in that code, let alone any function. --=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: 18 May 2012 15:14 To: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt ----------------------! 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 I beleive that olsrv2-15 has important sentences changes which change few previous information meanings (which I agree on). If undertood correctly the changes were made by authors revision decision. I want to know why were the below changes made, because the explanation will help the WG in better understanding of the minor amendments or of the new issue 15? OLSRv2-15 Deleted the below paragraph: Enables source routing, i.e., each router can use its local information provided by this protocol to specify the complete path for a packet. (This will require the retention of additional information during the Routing Set evaluation.) +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In OLSRv2-14: OLSRv2, as defined in this specification, allows links to have a metric (also known as a cost). Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are minimum length routes, where the length of a route is defined as the sum of the metrics of the links in that route. In OLSRv2-15 Replaced above by: OLSRv2, as defined in this specification, supports metric-based routing, i.e., it allows links to each have a chosen metric. Link metrics as defined in OLSRv2 are additive, and the routes that are to be created are those with the minimum sum of the link metrics along that route. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ In OLSRv2-14: R_local_iface_addr is the network address of the local OLSRv2 interface over which an IP packet MUST be sent to reach the destination by the selected path. In OLSRv2-15 Replaced by: R_local_iface_addr is an address of the local interface over which an IP packet MUST be sent to reach the destination by the selected path. Thanking you, 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 Fri May 18 07:51: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 1EF8E21F864A for ; Fri, 18 May 2012 07:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.595 X-Spam-Level: X-Spam-Status: No, score=-10.595 tagged_above=-999 required=5 tests=[AWL=0.004, 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 E0EJe-2kyDUy for ; Fri, 18 May 2012 07:51:51 -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 AA6D921F864E for ; Fri, 18 May 2012 07:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=10434; q=dns/txt; s=iport; t=1337352711; x=1338562311; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=6ahZESLiyV0atK5nkb43Dct2H1ma+K9te4N0Co758lI=; b=WBiB/2Bbu2BOVMebvd/LllLpfBtd6uWoY6Ww+ibF9Gu123Lz2qIB33np 05J2x+JdEffiuEAmHIrPlofjBFvPZH5hC3qX+cSIBQRyRbZZ4fj33k8vG x/LjvcbI/EMkNJhccksY0+0ihzCvw5LCtvml1tqkXwgrZYLmfS73FOUmK Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALJhtk+tJXG+/2dsb2JhbABFs22BB4IVAQEBAwEBAQEPAScbGQMIBQcECxEEAQEBJwchBh8JCAYTIodeAwYFC5xAliMNiVKKEm0TEIRBYgOVIIp8gxWBZIMFgToHAg X-IronPort-AV: E=Sophos;i="4.75,617,1330905600"; d="scan'208";a="84495437" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 18 May 2012 14:51:51 +0000 Received: from dhcp-64-102-54-110.cisco.com (dhcp-64-102-54-110.cisco.com [64.102.54.110]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4IEpoes011434; Fri, 18 May 2012 14:51:50 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Fri, 18 May 2012 10:51:50 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <93927B40-64CD-472E-A84E-A3C2C2E45ECC@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , "jpmacker@gmail.com" , manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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, 18 May 2012 14:51:53 -0000 On May 18, 2012, at 8:03 AM, Abdussalam Baryun wrote: > Hi Chris, >=20 > On 5/18/12, Dearlove, Christopher (UK) = wrote: >> The was a WGLC on OLSRv2, which happened to be at -14. Typical = practice >> after a WGLC concludes is to produce a revised document incorporating = any >> changes, which in this case happens to be -15. Note that -15 didn't = appear >> until after WGLC had closed, so it is not relevant to the submission = of >> comments in response to that call. This sort of upissue does not = re-open a >> WGLC unless in the opinion of the WG chairs, responsible AD etc. the = changes >> are significant and require that. I don't speak for those people, but = their >> actions go along with that, and the authors would have been surprised >> otherwise. >=20 > I have no problem with the issue 15 after closing WGLC, but was > expecting to see result of my input to the last call of draft-14. It > is reasonable for reviewers to see the response (WG respond and > decision if they don't agree with authors) to their comments on 14 > before receiving the 15. IMHO it is good for the process, if the group > thinks that things are not required it informs who thinks it is > required. It has never been the process (at least in the MANET working group) to = formally track each and every comment coming in on a draft and actively = notify/dispose of said items. This is rooted in the notion that the IETF = is a volunteer organization; as such, we've all got "day jobs", and do = the best we can. Another reason for this (slightly informal) process = model is to keep the group from spinning ad-nauseum, generating vast = amounts of email on trivial topics. This discussion is a reasonably good = example of that very thing.=20 You made some comments/suggestions on OLSRv2. They were considered by = the authors, and by the working group members. The authors didn't agree = with you in all cases, and the working group, via its silence, indicated = *they* didn't agree with you either. And now, apparently, you want to = re-litigate all or part of that. I for one am not interested.=20 My opinion is that OSLRv2-15 has cleared WGLC, and will be forwarded to = the AD's/IESG for review and publication. If the working group members = *DO NOT* agree with me, then let the fire-storm of emails commence. Regards, Stan >=20 >> The changes made mostly represent nits that the authors (who also >> reviewed the document) found. Most aren't actually errors but just = the usual >> editorial process of tightening wording. I see nothing that = contradicts RFC >> 2418, and I've now seen this process happen five times for a document = I'm an >> author of, all similarly. >>=20 >=20 > I have read once in RFC2418 that means if a suggestion required, the > group concensus can be collected. My comments reported a confusion in > reply to the last call, and I wanted to see the process reaction to > this input. Therefore, I needed a response from the group. However, I > received from the group chair the response after the 15 issue, that 14 > was intended to sent forward. If I knew that I will not make an input > for 14, and not sure why we have last call not mentioning this > important information? In addition, the issue of suggestion of big > change or minor change I don't read it in 2418, I think any suggestion > is respected the same value. >=20 >> Within the WGLC the authors responded to your comments. No one else = chose to >> support them, and hence there was clearly no consensus (and probably = a >> consensus against) making those changes. >>=20 > I agree with you, authors were helpful to address their position which > I am not confused any more after the discussion. Other readers in the > future may have the same, however, their was no one other than authors > responded infavour nor against, and that is why I replied when I > received the announcement of 15 (i.e. the subject title). >=20 > I thank you for your reply, >=20 > Abdussalam Baryun > University of Glamorgan, UK >=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: 18 May 2012 08:01 >> To: Ulrich Herberg >> Cc: jpmacker@gmail.com; manet; sratliff@cisco.com >> Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt >>=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 >> Ulrich, >>=20 >> I did not request first it was a respond to the call. I received the >> request/call of drafts olsrv2-14 and now olsrv2-15, so I responded >> suggestions, and for last-call-olsrv2-14 (expirs 10.05.2012) I >> requested before the expiry to adding information to the document to >> avoid confusions, because I while reading it was confused. I = discussed >> with authors and they didn't agree to add information. Then I >> requested a respond from the WG to my input, so we can have progress >> in the review process or WG process. Then I received the chair = respond >> which I will understand is the WG respond to the suggestions. >>=20 >> If I received a respond from the WG to the suggestion (i.e. it was >> the only respond to the last call request of olsrv2-14) I would not >> have send a request of wg respond. It is in the procedure for working >> group process RFC2418. >>=20 >> Best Regards >>=20 >> Abdussalam Baryun >> University of Glamorgan, UK >> +++++++++++++++++++++++++++++++++ >>=20 >> On 5/17/12, Ulrich Herberg wrote: >>> Abdussalam, >>>=20 >>> I am not quite sure what you request. Your comments during the WGLC >>> have been heard, and the authors replied to your emails, arguing why >>> we believe that the current terminology is fine. There did not seem = to >>> be any WG consensus that there should be changes like you suggested. >>>=20 >>>=20 >>> Best regards >>> Ulrich >>>=20 >>> On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun >>> wrote: >>>> Hi Ulrich, >>>>=20 >>>> It was suggested adding information for clarification without = touching >>>> specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems = not >>>> minor grammer error, but minor words/sentences replacings or = delets. >>>>=20 >>>> Regards >>>> Abdussalam >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> On 5/16/12, Ulrich Herberg wrote: >>>>> Abdusallam, >>>>>=20 >>>>> OLSRv2-15 only contains some minor editorial updates (spelling = mistakes >>>>> and >>>>> grammatical errors) and no change to the specification. >>>>>=20 >>>>> Best regards >>>>> Ulrich >>>>>=20 >>>>> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >>>>> abdussalambaryun@gmail.com> wrote: >>>>>=20 >>>>>> Hi Herberg, >>>>>>=20 >>>>>> I had some comments on OLSRv2-14 and I was informed that there = will be >>>>>> no change only if rough consensus. Now I received a new draft >>>>>> OLSRv2-15 announced, does this mean that suggestions (to add >>>>>> explainations) as in the discussion had no rough consensus so no >>>>>> change is needed? or does it mean that no one has responded to = the >>>>>> confusion observed so it was with no value? >>>>>>=20 >>>>>> Please note that I need to know the outcome decision of the = MANET-WG, >>>>>> so I can know how to review OLSRv2-15, or I wait for the decision >>>>>> result to the suggestion of adding explainations in the previous = draft >>>>>> 14. Thanking you, >>>>>>=20 >>>>>> Abdussalam Baryun, >>>>>> University of Glamorgan, UK >>>>>>=20 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>=20 >>>>>> Abdussalam, >>>>>>=20 >>>>>> so far, nobody else seemed to be confused on which layer OLSRv2 = is >>>>>> used (or how the interfaces are defined). IMO, unless other = people in >>>>>> the WG see the same danger of confusion, I would not change it. >>>>>>=20 >>>>>> Regards >>>>>> Ulrich >>>>>>=20 >>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>=20 >>>>>> The IETF does not work by means of "majority" (which is not even >>>>>> possible since there is no formal membership), but by rough = consensus >>>>>> (and running code). And every individual can (and should!) review = a >>>>>> document and give suggestions, which can help to improve a = document. I >>>>>> just don't see how your suggestions about the MANET/OLSRv2 = interfaces >>>>>> would improve the OLSRv2 draft (for the reasons that Chris, = Thomas and >>>>>> I have pointed out). >>>>>>=20 >>>>>> Regards >>>>>> Ulrich >>>>>>=20 >>>>>=20 >>>=20 >> _______________________________________________ >> 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 wwwrun@rfc-editor.org Fri May 18 10:29: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 CC69221F8620; Fri, 18 May 2012 10:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.404 X-Spam-Level: X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Zjj3IKT1P4fZ; Fri, 18 May 2012 10:29:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5179C21F861E; Fri, 18 May 2012 10:29:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 06EFD621A0; Fri, 18 May 2012 10:27:00 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120518172705.06EFD621A0@rfc-editor.org> Date: Fri, 18 May 2012 10:27:00 -0700 (PDT) Cc: manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] RFC 6621 on Simplified Multicast Forwarding 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, 18 May 2012 17:29:55 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6621 Title: Simplified Multicast Forwarding Author: J. Macker, Ed. Status: Experimental Stream: IETF Date: May 2012 Mailbox: macker@itd.nrl.navy.mil Pages: 55 Characters: 139674 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-manet-smf-14.txt URL: http://www.rfc-editor.org/rfc/rfc6621.txt This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic Internet Protocol (IP) multicast forwarding suitable for limited wireless mesh and mobile ad hoc network (MANET) use. It is mainly applicable in situations where efficient flooding represents an acceptable engineering design trade-off. It defines techniques for multicast duplicate packet detection (DPD), to be applied in the forwarding process, for both IPv4 and IPv6 protocol use. This document also specifies optional mechanisms for using reduced relay sets to achieve more efficient multicast data distribution within a mesh topology as compared to Classic Flooding. Interactions with other protocols, such as use of information provided by concurrently running unicast routing protocols or interaction with other multicast protocols, as well as multiple deployment approaches are also described. Distributed algorithms for selecting reduced relay sets and related discussion are provided in the appendices. Basic issues relating to the operation of multicast MANET border routers are discussed, but ongoing work remains in this area and is beyond the scope of this document. This document defines an Experimental Protocol for the Internet community. This document is a product of the Mobile Ad-hoc Networks Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ulrich@herberg.name Fri May 18 10:41: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 4DF1121F8575 for ; Fri, 18 May 2012 10:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[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 tu0Rzn2o5jdJ for ; Fri, 18 May 2012 10:41:29 -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 CEB9021F8495 for ; Fri, 18 May 2012 10:40:23 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2611153qcs.31 for ; Fri, 18 May 2012 10:40:02 -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=U4YnXgnBOLbeagUrs7F8QjnbGp7MAEOtc8yRxMJZGto=; b=UkzAA7EBS2BzBgfwRr8V1TmX8pq9rS012QDhYuXn7cUs9Ryl5KDWn77oHYhejSP+lN 6zkIVS/rauhkTh4YIxpyEKoX6niKOri68m+z/SBY0riOcM++nBv1GKDVTySTCcHVQPCN MaVuazfTf9C0MakuNEW+THbIW6h71Fn5ptzOE= 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=U4YnXgnBOLbeagUrs7F8QjnbGp7MAEOtc8yRxMJZGto=; b=Bm/0YB4NnY27EL1IsoG21TSy1maKiKqmTPR/DdhW8oaMnXBRC/rWzYJGuUb11gt/RN K4o0h89dehxSZvcIWs8AzJmquWCZcx1WQ+ZAOOVhcfQJVpym5+NLUcFQQP3SW4jhkOUJ IUrTalg5zQziuK6UEgy8aOnQE3Mt/wZ1E04uW89DkZk3U/ql1K21M4tSfM2lC5oIV/Jb GwZOw1bU/nThcmdmHZ1kYy2SNJg/DY+dbBDKeZetf3lr45NROdM5g1AGaSVHrY9okeLE JKdGFvaAb+Q6RyH2d1kXZlm17ziIQjKbmKgBW2MU74eSY+4IrAsWGdoEc1YpX0BaRXAP ogMQ== MIME-Version: 1.0 Received: by 10.224.191.3 with SMTP id dk3mr24360634qab.99.1337362802001; Fri, 18 May 2012 10:40:02 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Fri, 18 May 2012 10:40:01 -0700 (PDT) In-Reply-To: <20120518172705.06EFD621A0@rfc-editor.org> References: <20120518172705.06EFD621A0@rfc-editor.org> Date: Fri, 18 May 2012 10:40:01 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm35V8tPql520VKkz6WHC15p2LZ5pF3wtQwy9DNi9JW7rYU8662zjYMmM83fNSmCgExLihl Cc: Joe Macker Subject: Re: [manet] RFC 6621 on Simplified Multicast Forwarding 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, 18 May 2012 17:41:30 -0000 Congratulations! If we keep up the rate of "one RFC per week" in MANET, we'll keep the RFC editor and the IESG busy ;-) Best Ulrich On Fri, May 18, 2012 at 10:27 AM, wrote: > > A new Request for Comments is now available in online RFC libraries. > > > =A0 =A0 =A0 =A0RFC 6621 > > =A0 =A0 =A0 =A0Title: =A0 =A0 =A0Simplified Multicast Forwarding > =A0 =A0 =A0 =A0Author: =A0 =A0 J. Macker, Ed. > =A0 =A0 =A0 =A0Status: =A0 =A0 Experimental > =A0 =A0 =A0 =A0Stream: =A0 =A0 IETF > =A0 =A0 =A0 =A0Date: =A0 =A0 =A0 May 2012 > =A0 =A0 =A0 =A0Mailbox: =A0 =A0macker@itd.nrl.navy.mil > =A0 =A0 =A0 =A0Pages: =A0 =A0 =A055 > =A0 =A0 =A0 =A0Characters: 139674 > =A0 =A0 =A0 =A0Updates/Obsoletes/SeeAlso: =A0 None > > =A0 =A0 =A0 =A0I-D Tag: =A0 =A0draft-ietf-manet-smf-14.txt > > =A0 =A0 =A0 =A0URL: =A0 =A0 =A0 =A0http://www.rfc-editor.org/rfc/rfc6621.= txt > > This document describes a Simplified Multicast Forwarding (SMF) > mechanism that provides basic Internet Protocol (IP) multicast > forwarding suitable for limited wireless mesh and mobile ad hoc > network (MANET) use. =A0It is mainly applicable in situations where > efficient flooding represents an acceptable engineering design trade-off. > It defines techniques for multicast duplicate packet detection > (DPD), to be applied in the forwarding process, for both IPv4 and > IPv6 protocol use. =A0This document also specifies optional mechanisms > for using reduced relay sets to achieve more efficient multicast data > distribution within a mesh topology as compared to Classic Flooding. > Interactions with other protocols, such as use of information > provided by concurrently running unicast routing protocols or > interaction with other multicast protocols, as well as multiple > deployment approaches are also described. =A0Distributed algorithms for > selecting reduced relay sets and related discussion are provided in > the appendices. =A0Basic issues relating to the operation of multicast > MANET border routers are discussed, but ongoing work remains in this > area and is beyond the scope of this document. =A0This document defines a= n > Experimental Protocol for the Internet community. > > This document is a product of the Mobile Ad-hoc Networks Working Group of= the IETF. > > > EXPERIMENTAL: This memo defines an Experimental Protocol for the > Internet community. =A0It does not specify an Internet standard of any > kind. Discussion and suggestions for improvement are requested. > Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > =A0http://www.ietf.org/mailman/listinfo/ietf-announce > =A0http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.htm= l. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. =A0Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From thomas@thomasclausen.org Fri May 18 12:13: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 5F75821F85D5 for ; Fri, 18 May 2012 12:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.153 X-Spam-Level: ** X-Spam-Status: No, score=2.153 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.819] 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 DJRiT6v8Bde9 for ; Fri, 18 May 2012 12:13:43 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7208C21F85C3 for ; Fri, 18 May 2012 12:13:43 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 3B06355800F for ; Fri, 18 May 2012 12:13:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1067E82012; Fri, 18 May 2012 12:13:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.249] (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 mailc2.tigertech.net (Postfix) with ESMTPSA id 9861982010; Fri, 18 May 2012 12:13:42 -0700 (PDT) References: <20120518172705.06EFD621A0@rfc-editor.org> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0AFCEE18-B08E-4E17-84F8-1CC991C4127F@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 18 May 2012 21:14:15 +0200 To: Ulrich Herberg Cc: Joe Macker , "manet@ietf.org" Subject: Re: [manet] RFC 6621 on Simplified Multicast Forwarding 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, 18 May 2012 19:13:44 -0000 Yup - great work, Joe (with editor hat on), I know it wasn't easy but this i= s a milestone for the WG! --=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 18 May 2012, at 19:40, Ulrich Herberg wrote: > Congratulations! If we keep up the rate of "one RFC per week" in > MANET, we'll keep the RFC editor and the IESG busy ;-) >=20 > Best > Ulrich >=20 > On Fri, May 18, 2012 at 10:27 AM, wrote: >>=20 >> A new Request for Comments is now available in online RFC libraries. >>=20 >>=20 >> RFC 6621 >>=20 >> Title: Simplified Multicast Forwarding >> Author: J. Macker, Ed. >> Status: Experimental >> Stream: IETF >> Date: May 2012 >> Mailbox: macker@itd.nrl.navy.mil >> Pages: 55 >> Characters: 139674 >> Updates/Obsoletes/SeeAlso: None >>=20 >> I-D Tag: draft-ietf-manet-smf-14.txt >>=20 >> URL: http://www.rfc-editor.org/rfc/rfc6621.txt >>=20 >> This document describes a Simplified Multicast Forwarding (SMF) >> mechanism that provides basic Internet Protocol (IP) multicast >> forwarding suitable for limited wireless mesh and mobile ad hoc >> network (MANET) use. It is mainly applicable in situations where >> efficient flooding represents an acceptable engineering design trade-off.= >> It defines techniques for multicast duplicate packet detection >> (DPD), to be applied in the forwarding process, for both IPv4 and >> IPv6 protocol use. This document also specifies optional mechanisms >> for using reduced relay sets to achieve more efficient multicast data >> distribution within a mesh topology as compared to Classic Flooding. >> Interactions with other protocols, such as use of information >> provided by concurrently running unicast routing protocols or >> interaction with other multicast protocols, as well as multiple >> deployment approaches are also described. Distributed algorithms for >> selecting reduced relay sets and related discussion are provided in >> the appendices. Basic issues relating to the operation of multicast >> MANET border routers are discussed, but ongoing work remains in this >> area and is beyond the scope of this document. This document defines an >> Experimental Protocol for the Internet community. >>=20 >> This document is a product of the Mobile Ad-hoc Networks Working Group of= the IETF. >>=20 >>=20 >> EXPERIMENTAL: This memo defines an Experimental Protocol for the >> Internet community. It does not specify an Internet standard of any >> kind. Discussion and suggestions for improvement are requested. >> Distribution of this memo is unlimited. >>=20 >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> http://www.ietf.org/mailman/listinfo/ietf-announce >> http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >>=20 >> For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.htm= l. >> For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >>=20 >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >>=20 >>=20 >> The RFC Editor Team >> Association Management Solutions, LLC >>=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 abdussalambaryun@gmail.com Sat May 19 00:41: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 4AC7221F8631 for ; Sat, 19 May 2012 00:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_UNSUB30=0.351] 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 u9o0xCt-ibPK for ; Sat, 19 May 2012 00:41: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 A4BB421F8611 for ; Sat, 19 May 2012 00:41:34 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2387373wgb.13 for ; Sat, 19 May 2012 00:41:33 -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=Z7MDYq69PS/QQqkbNZ8Ti4Gz9m+OaxoT74jbYKoJz/Q=; b=sa/i/+1O2Oncy9ES7bCXyLh+yBhEAimlpMM/uS2MPCwKts8c0rzxb/658g9ndw4CAU Fv49ZfacW6i620PIGT6u3GLedP9o2IEU2tGDTbwwx/tmglgWk2QCywOwpUTG55+kYCB3 OBt8Bgk8Y3tG8gzIMZD5nuhI9pIMA06BYHBibAM6mXelUEFLhRmUGc0qr+tI2g/epFsy sUscEn1b4Vn71xrrp6BVM2wg2+qOAmN/kDnc3PboNMpxeOt0IaDZF478baor45WoZI+N lhNLexeYfM8QnZE8OuMPAwUJeyCw1+faAoBpz89u4b4NuhwTTxR+o/cnOT7Aohe4Ozy6 9WWQ== MIME-Version: 1.0 Received: by 10.180.105.194 with SMTP id go2mr8368843wib.22.1337413293581; Sat, 19 May 2012 00:41:33 -0700 (PDT) Received: by 10.180.100.10 with HTTP; Sat, 19 May 2012 00:41:33 -0700 (PDT) In-Reply-To: <93927B40-64CD-472E-A84E-A3C2C2E45ECC@cisco.com> References: <93927B40-64CD-472E-A84E-A3C2C2E45ECC@cisco.com> Date: Sat, 19 May 2012 09:41:33 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "jpmacker@gmail.com" , Stan Ratliff Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.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: Sat, 19 May 2012 07:41:36 -0000 Dear All, I beleive that we are all informally equal in terms of rights and responsibilities, but in organisations we have formal responsibilities and rights to make work-processes progress to the direction of the aim and objectives of the organisation, not in the direction of some individuals decisions. I beleive the best practice for IETF groups is in RFC2418 and RFC3934. On 5/18/12, Stan Ratliff wrote: > It has never been the process (at least in the MANET working group) to > formally track each and every comment coming in on a draft and actively > notify/dispose of said items. This is rooted in the notion that the IETF is > a volunteer organization; as such, we've all got "day jobs", and do the best > we can. Another reason for this (slightly informal) process model is to keep > the group from spinning ad-nauseum, generating vast amounts of email on > trivial topics. This discussion is a reasonably good example of that very > thing. The process for MANET WG SHOULD follow the RFC2418. IMHO the IETF is a formal organisation, and yes it is structured of volunteering members, but it is not informal organisation. Please note that number of emails SHOULD not be restricted, but the content of messages MAY be restricted. Yes our relationships are RECOMMENDED to be friendly and informally social to inhance the group activities. All informal models give chances of more power to organisation managers. I don't agree with the informal-process model, but agree with RFC2418-process model. > > You made some comments/suggestions on OLSRv2. They were considered by the > authors, and by the working group members. The authors didn't agree with you > in all cases, and the working group, via its silence, indicated *they* > didn't agree with you either. And now, apparently, you want to re-litigate > all or part of that. I for one am not interested. > Silence is not a reaction (e.g. not an indication), because as you mentioned we are volunteers and we have jobs, therefore, silence most possibility means I am bussy, not meaning I agree nor disagree. > My opinion is that OSLRv2-15 has cleared WGLC, and will be forwarded to the > AD's/IESG for review and publication. If the working group members *DO NOT* > agree with me, then let the fire-storm of emails commence. > I reply to this call that I *DO NOT* agree to give forward to OLSRv2-14 or OLSRv2-15 until I comment on it, or only after concensus collected for the decision (i.e. it is easy to collect electronically, as in RFC2418 does not have to be face-to-face collecting). Regarding the OLSRv2-15 draft it is better than OLSRv2-14 because it reduced my confusions, but I will need some time to review OLSRv2-15 and comment on it as well. Regarding fire-storm emails, it seems it will not be happening in MANET WG, maybe active memebrs are about 60, not sure. In conclusion, from the group chair last message, I understand that there was no concensus collected for OLSRv2 to go forward, so the MANET-WG still didn't make last decision yet. I am sorry if I made any disturbing to any. In the end of all processes I am interested in understanding and participating in IETF. If the group or group chairs decides that I stop emailing in MANET, I will stop without any complains to higher levels, and go to another IETF group. Thanking you, Best Regards, Abdussalam +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Regards, > Stan > > >> >>> The changes made mostly represent nits that the authors (who also >>> reviewed the document) found. Most aren't actually errors but just the >>> usual >>> editorial process of tightening wording. I see nothing that contradicts >>> RFC >>> 2418, and I've now seen this process happen five times for a document I'm >>> an >>> author of, all similarly. >>> >> >> I have read once in RFC2418 that means if a suggestion required, the >> group concensus can be collected. My comments reported a confusion in >> reply to the last call, and I wanted to see the process reaction to >> this input. Therefore, I needed a response from the group. However, I >> received from the group chair the response after the 15 issue, that 14 >> was intended to sent forward. If I knew that I will not make an input >> for 14, and not sure why we have last call not mentioning this >> important information? In addition, the issue of suggestion of big >> change or minor change I don't read it in 2418, I think any suggestion >> is respected the same value. >> >>> Within the WGLC the authors responded to your comments. No one else chose >>> to >>> support them, and hence there was clearly no consensus (and probably a >>> consensus against) making those changes. >>> >> I agree with you, authors were helpful to address their position which >> I am not confused any more after the discussion. Other readers in the >> future may have the same, however, their was no one other than authors >> responded infavour nor against, and that is why I replied when I >> received the announcement of 15 (i.e. the subject title). >> >> I thank you for your reply, >> >> Abdussalam Baryun >> University of Glamorgan, UK >> >>> -- >>> 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: 18 May 2012 08:01 >>> To: Ulrich Herberg >>> Cc: jpmacker@gmail.com; manet; sratliff@cisco.com >>> Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-15.txt >>> >>> ----------------------! 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. >>> -------------------------------------------------------- >>> >>> Ulrich, >>> >>> I did not request first it was a respond to the call. I received the >>> request/call of drafts olsrv2-14 and now olsrv2-15, so I responded >>> suggestions, and for last-call-olsrv2-14 (expirs 10.05.2012) I >>> requested before the expiry to adding information to the document to >>> avoid confusions, because I while reading it was confused. I discussed >>> with authors and they didn't agree to add information. Then I >>> requested a respond from the WG to my input, so we can have progress >>> in the review process or WG process. Then I received the chair respond >>> which I will understand is the WG respond to the suggestions. >>> >>> If I received a respond from the WG to the suggestion (i.e. it was >>> the only respond to the last call request of olsrv2-14) I would not >>> have send a request of wg respond. It is in the procedure for working >>> group process RFC2418. >>> >>> Best Regards >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK >>> +++++++++++++++++++++++++++++++++ >>> >>> On 5/17/12, Ulrich Herberg wrote: >>>> Abdussalam, >>>> >>>> I am not quite sure what you request. Your comments during the WGLC >>>> have been heard, and the authors replied to your emails, arguing why >>>> we believe that the current terminology is fine. There did not seem to >>>> be any WG consensus that there should be changes like you suggested. >>>> >>>> >>>> Best regards >>>> Ulrich >>>> >>>> On Thu, May 17, 2012 at 12:45 PM, Abdussalam Baryun >>>> wrote: >>>>> Hi Ulrich, >>>>> >>>>> It was suggested adding information for clarification without touching >>>>> specification. however, comparing OLSRv2-14 to OLSRv2-15 it seems not >>>>> minor grammer error, but minor words/sentences replacings or delets. >>>>> >>>>> Regards >>>>> Abdussalam >>>>> ============ >>>>> On 5/16/12, Ulrich Herberg wrote: >>>>>> Abdusallam, >>>>>> >>>>>> OLSRv2-15 only contains some minor editorial updates (spelling >>>>>> mistakes >>>>>> and >>>>>> grammatical errors) and no change to the specification. >>>>>> >>>>>> Best regards >>>>>> Ulrich >>>>>> >>>>>> On Wed, May 16, 2012 at 9:03 AM, Abdussalam Baryun < >>>>>> abdussalambaryun@gmail.com> wrote: >>>>>> >>>>>>> Hi Herberg, >>>>>>> >>>>>>> I had some comments on OLSRv2-14 and I was informed that there will >>>>>>> be >>>>>>> no change only if rough consensus. Now I received a new draft >>>>>>> OLSRv2-15 announced, does this mean that suggestions (to add >>>>>>> explainations) as in the discussion had no rough consensus so no >>>>>>> change is needed? or does it mean that no one has responded to the >>>>>>> confusion observed so it was with no value? >>>>>>> >>>>>>> Please note that I need to know the outcome decision of the >>>>>>> MANET-WG, >>>>>>> so I can know how to review OLSRv2-15, or I wait for the decision >>>>>>> result to the suggestion of adding explainations in the previous >>>>>>> draft >>>>>>> 14. Thanking you, >>>>>>> >>>>>>> Abdussalam Baryun, >>>>>>> University of Glamorgan, UK >>>>>>> >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> >>>>>>> Abdussalam, >>>>>>> >>>>>>> so far, nobody else seemed to be confused on which layer OLSRv2 is >>>>>>> used (or how the interfaces are defined). IMO, unless other people >>>>>>> in >>>>>>> the WG see the same danger of confusion, I would not change it. >>>>>>> >>>>>>> Regards >>>>>>> Ulrich >>>>>>> >>>>>>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>>>>> >>>>>>> The IETF does not work by means of "majority" (which is not even >>>>>>> possible since there is no formal membership), but by rough >>>>>>> consensus >>>>>>> (and running code). And every individual can (and should!) review a >>>>>>> document and give suggestions, which can help to improve a document. >>>>>>> I >>>>>>> just don't see how your suggestions about the MANET/OLSRv2 >>>>>>> interfaces >>>>>>> would improve the OLSRv2 draft (for the reasons that Chris, Thomas >>>>>>> and >>>>>>> I have pointed out). >>>>>>> >>>>>>> Regards >>>>>>> Ulrich >>>>>>> >>>>>> >>>> >>> _______________________________________________ >>> 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 internet-drafts@ietf.org Mon May 28 12:47:47 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 0D5F421F86A1; Mon, 28 May 2012 12:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 QY-hxcRw9V4g; Mon, 28 May 2012 12:47:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67EA421F8669; Mon, 28 May 2012 12:47:46 -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: <20120528194746.3721.87878.idtracker@ietfa.amsl.com> Date: Mon, 28 May 2012 12:47:46 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-04.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: Mon, 28 May 2012 19:47:47 -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 Manet Simplified M= ulticast Framework Relay Set Process Author(s) : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-04.txt Pages : 56 Date : 2012-05-28 This memo 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 aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-04.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-smf-mib-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ From aaron@lo-res.org Mon May 28 07:37: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 D385B21F85CF for ; Mon, 28 May 2012 07:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, J_CHICKENPOX_24=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 P+Q+Ng5+8RPt for ; Mon, 28 May 2012 07:37:09 -0700 (PDT) Received: from mute.lo-res.org (mail.lo-res.org [IPv6:2a02:60:1:1::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3E46721F85CC for ; Mon, 28 May 2012 07:37:08 -0700 (PDT) Received: from [10.71.8.16] (vpn.lo-res.org [193.238.157.40]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mute.lo-res.org (Postfix) with ESMTPSA id 55DCD9BC502 for ; Mon, 28 May 2012 16:37:05 +0200 (CEST) From: L. Aaron Kaplan Content-Type: multipart/signed; boundary="Apple-Mail=_20F93BA1-EC30-457F-9F41-C612AC593F72"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 28 May 2012 16:37:01 +0200 References: <34C0CDC9-5CDC-40D3-BC05-C276A4470AB6@lo-res.org> To: "manet@ietf.org IETF" Message-Id: <6A14B259-C284-4EAC-A705-C86D42E4199E@lo-res.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Mon, 28 May 2012 14:34:03 -0700 Subject: [manet] IS4CWN, wirelesssummit.org CFP 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, 28 May 2012 14:37:10 -0000 --Apple-Mail=_20F93BA1-EC30-457F-9F41-C612AC593F72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi! (Dreadfully sorry for x-posting. You might receive multiple copies of = this mail. But the deadline is approaching rapidly. I'd rather annoy = some individuals by x-posting than exclude many. The summit really is a = super cool chance for all of us and all who believe in self-governed = community networks). What? -------- The wireless summit (www.wirelesssummit.org, "IS4CWN") is the only = truly international event where community wireless networks from every = continent of this earth (except for maybe Antarctica) come together = every couple of years. Some have referred to the IS4CWNs as the "UN of = community wireless networks" . More details below. The last one took place in Vienna in 2010, this time it is going to take = place in Barcelona. Here is the current call for proposals. Please re-tweet and = re-distribute this mail in your respective communities and mailing = lists! Thanks very much. Aaron. PS: for the academics amongst us: the conference is just before the IEEE = WiMob 2012 conference (http://conferences.computer.org/wimob2012/). It = might make sense to piggyback the that one too (and enjoy beautiful = Barcelona a bit longer ). ---------- Forwarded message ---------- From: faith swords Date: Tue, Apr 10, 2012 at 8:41 AM Subject: IS4CWN 2012: Call for Proposals To: International Summit for Community Wireless Networks Participant = E-mail List CALL FOR PROPOSALS =97 Deadline May 31, 2012. International Summit for Community Wireless Networks October 4-7, 2012 Barcelona, Spain The International Summit for Community Wireless Networks (IS4CWN) brings = together leading technology experts, policy analysts, on-the-ground = specialists, and university researchers working on state-of-the-art = community broadband projects. Since the first Summit in 2004, tens of = thousands of community and municipal broadband networks have been = deployed around the globe. The 2012 IS4CWN in Barcelona, Spain, offers = panelists the opportunity to shape the direction of this thriving global = movement.=20 Arab Spring and the revolutions in Tunisia, Egypt, and Libya have = brought the importance of mesh wireless to the forefront of global = political consciousness. As a result, we have seen an explosion in the = development of and enthusiasm for community networks and mobile mesh. = 2012 is a critical year to catalyze the explosion of community = networking organizations and create shared technology, policy, and = public education goals. Over the course of the Summit, the meetings and = workshops at IS4CWN help participants formulate strategic plans, = implement new development roadmaps, and coordinate implementation and = R&D efforts. =20 Interested presenters should propose panels and workshops focusing on = the three themes for the Summit: technology, policy, and implementation. = Proposals can include demonstrations of software innovation, success = stories of network deployment, presentations of ongoing research and = discussion of municipal and governmental collaboration on both the = national and transnational levels, or additional related topics. = Panelists are encouraged to convene panels that look at specific issues = from multiple angles and perspectives. Past panels can be reviewed at = http://wirelesssummit.org. Panel ideas will be accepted on a rolling basis and must be received no = later than May 31, 2012. Please send panel proposals of 250 words or = less to: coordination@wirelesssummit.org. =20 Travel stipends are available for speakers with financial need. If you = would like to request travel support, please be sure to mention so in = your proposal -- panels are accepted on a need-blind basis. As ever, = please feel free to contact me with any questions you may have. Cheers, Faith and the rest of the IS4CWN 2012 organizing team-- --Apple-Mail=_20F93BA1-EC30-457F-9F41-C612AC593F72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk/DjZEACgkQxEgyMttZ8YxkFQCgncgGNlI1JFAX7ycugVDNrHKH OQEAoJe3Vc3E9jEVvBFGKObV3PDY6dXm =p5Ok -----END PGP SIGNATURE----- --Apple-Mail=_20F93BA1-EC30-457F-9F41-C612AC593F72-- From robert.g.cole.civ@mail.mil Mon May 28 16:15: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 D63B821F86DD for ; Mon, 28 May 2012 16:15:54 -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 ZlgdvpZjZk5F for ; Mon, 28 May 2012 16:15:54 -0700 (PDT) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4121F86DA for ; Mon, 28 May 2012 16:15:53 -0700 (PDT) Received: from UCOLHP3D.easf.csd.disa.mil (131.64.100.143) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.1.339.1; Mon, 28 May 2012 23:15:45 +0000 Received: from UCOLHP4J.easf.csd.disa.mil ([169.254.8.252]) by UCOLHP3D.easf.csd.disa.mil ([131.64.100.143]) with mapi id 14.02.0283.003; Mon, 28 May 2012 23:15:44 +0000 From: "Cole, Robert G CIV USARMY CERDEC (US)" To: "'manet@ietf.org'" Thread-Topic: [manet] I-D Action: draft-ietf-manet-smf-mib-04.txt Thread-Index: AQHNPQrTPGrydf4ht02UcdQd3fbGgZbf1ahj Date: Mon, 28 May 2012 23:15:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.64.77.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [manet] Fw: I-D Action: draft-ietf-manet-smf-mib-04.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: Mon, 28 May 2012 23:15:55 -0000 To all: We have posted version 04 of the SMF-MIB. Now that SMF is out as RFC 6621,= we'd like to push for completing the SMF-MIB module. We hope we can move = it to WG Last Call by Vancouver. =20 Thanks, Bob Cole =20 ----- Original Message ----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, May 28, 2012 07:47 PM=0A= To: i-d-announce@ietf.org Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-smf-mib-04.txt 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 Manet Simplified M= ulticast Framework Relay Set Process Author(s) : Robert G. Cole Joseph Macker Brian Adamson Filename : draft-ietf-manet-smf-mib-04.txt Pages : 56 Date : 2012-05-28 This memo 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 aspects of the Simplified Multicast Forwarding (SMF) process for Mobile Ad-Hoc Networks (MANETs). The SMF-MIB also reports state information, performance metrics, and notifications. In addition to configuration, the additional state and performance information is useful to operators troubleshooting multicast forwarding problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-mib-04.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-smf-mib-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-smf-mib/ _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue May 29 03:59: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 9164821F8627 for ; Tue, 29 May 2012 03:59: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=[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 jrnnHEoL1qLP for ; Tue, 29 May 2012 03:59: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 E972D21F8625 for ; Tue, 29 May 2012 03:59:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2824405vbb.31 for ; Tue, 29 May 2012 03:59: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=TIOefAYd1WJixQ2gH0NMQ43fheOMTdP1ClIp7tqNWbc=; b=Zi9vTTXgZmnM1YQxtvKsveYCCSzrjVODC1KcCw8PJFHEwSbVwITjh6p9maiwVVpAD4 YyV2XKbACVSJ2S/M83K7/Id3kcWbuJbYjqXmDfn6asOh+o67FtWr+iD236uKXvN5BGHC nyfAedtay0hUQpvI0+z+dWJPpKeYN4oS81YGIkvZSxsGmzuni/7cqSjyKPTixQHNS9aU 8t5UPAZ5KummNcujJg2HnilIIjOXwjr+3l3tlfcg6AK/ZKH2hJIh9GgcVvVHMQawjHHl RwxqOpMUDJtYcBWEniBzOmeRJv6mh29LH57HCKQAoVOGkYvh6v8sfZwW0b4b0yBjgs/e tZ4w== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr10108482vds.117.1338289194378; Tue, 29 May 2012 03:59:54 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 29 May 2012 03:59:54 -0700 (PDT) Date: Tue, 29 May 2012 12:59:54 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Subject: [manet] Discussing LOADng suggestions 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, 29 May 2012 10:59:55 -0000 Hi I think at the WG 83 meeting, regarding LOADng to be discussed, and that the suggestions were either of the following: 1- to accommodate LOADng for MANET WG, ( some prefered to see LOADng possibly adapted to the MANET working group as reactive protocol with RFC5444 compliance), or 2- to leave LOADng for LLN group to look at it, other than MANET WG, or 3- to join LOADng authors with DYMO authors in one work. IMO it is interesting to have a reactive MANET protocol using RFC5444. There is motivation to use RFC5444 for interoperability between routers and security purposes. However, LOADng is for lossy ad-hoc networks more than mobile ad-hoc nets. If authors decide LOADng is for LLN then they should take it to LLN groups, but if the protocol and document is modified it can be an alternative MANET reactive protocol that differs from DYMO. So I agree to option-1 more than 2 depending on the LOADng-authors' thoughts. It was mentioned in the meeting that DYMO and LOADng are close. I do not see that that LOADng and AODVv2 are close (someone mentioned in 83 meeting), but LOADng is a RFC5444-based reactive protocol that is derived from AODV [RFC3561], it focuses on low power and lossy nets, but DYMO is derived from DSR and AODV, and so far does not fully use RFC5444. The suggestion option 3 maybe not interesting in this stage, because usually it is better decided by the authors if they like the join their drafts to one, but it is interesting to the WG to have alternatives and that DYMO and LOADng are not similar functions. So I disagree with option-3. IMHO that AODVv2 does not involve/use similar of LOADng, but it can use RFC5444 differently from LOADng, or use only RFC5444 techniques. Also LOADng does not use much of AODV-RFC3561, but it can use its reactive technique adding to it energy efficiency techniques. LOADng is for low power routers, but while reading it I am not sure how it solves the power-problem. Furthermore, LOADng can be pushed to focus on low-power MANET instead of LLN, it may only have lossy links, not a lossy network. I suggest to replace 'LLN' in the protocol name to ' Low-power' without lossy-net, and to make its functions consider network energy consumptions. Abdussalam Baryun University of Glamorgan, UK. From henning.rogge@fkie.fraunhofer.de Tue May 29 04:09: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 2C74621F87D5 for ; Tue, 29 May 2012 04:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[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 XsrcCHFJYmgx for ; Tue, 29 May 2012 04:09:28 -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 10C9B21F8793 for ; Tue, 29 May 2012 04:09:28 -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 1SZKIo-0007Vh-LD for manet@ietf.org; Tue, 29 May 2012 13:09:26 +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 1SZKIo-00006w-Ib for manet@ietf.org; Tue, 29 May 2012 13:09:26 +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, 29 May 2012 13:09:26 +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, 29 May 2012 13:09:26 +0200 Message-ID: <4FC4AE24.50105@fkie.fraunhofer.de> Date: Tue, 29 May 2012 13:08:20 +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: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010301050802080803090700" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 29 May 2012 11:09:26.0412 (UTC) FILETIME=[829454C0:01CD3D8B] X-Virus-Scanned: yes (ClamAV 0.97.3/14973/Mon May 28 21:09:19 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] Discussing LOADng suggestions 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, 29 May 2012 11:09:29 -0000 --------------ms010301050802080803090700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 05/29/2012 12:59 PM, Abdussalam Baryun wrote: > Hi > > I think at the WG 83 meeting, regarding LOADng to be discussed, and > that the suggestions were either of the following: > > 1- to accommodate LOADng for MANET WG, > ( some prefered to see LOADng possibly adapted to the MANET working > group as reactive protocol with RFC5444 compliance), or > 2- to leave LOADng for LLN group to look at it, other than MANET WG, or= > 3- to join LOADng authors with DYMO authors in one work. > > IMO it is interesting to have a reactive MANET protocol using RFC5444. > There is motivation to use RFC5444 for interoperability between > routers and security purposes. Yes. > However, LOADng is for lossy ad-hoc > networks more than mobile ad-hoc nets. This distinction does not make sense. Adhoc networks deal with link that can fluctuate quite a lot. For most=20 protocols and routing metrics it doesn't matter if this happens because=20 of the metric, the radio environment or movement (exception are=20 protocols/metrics that incorporate explicit algorithms for exploiting=20 knowledge about movement or even terrain). 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 --------------ms010301050802080803090700 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 Fw0xMjA1MjkxMTA4MjNaMCMGCSqGSIb3DQEJBDEWBBQFQFsTGag2dDg7M+9vjopw2HZ+PDBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBqvWFvAZE4A/MtGCis/gMNsHjb00VcD1Ha2JYt0dkExTmLzHIlSGeZoexnPwKI /pRgg0l1HMeQdEh3E1H/EUenv1v4cxKF/lOs9fFPNu1GKxnJkJVyGgxqteu1uoxzRIsLJTwE 6hPf5yH0C+RyNleN/9eODPJi7RGS0OfMRKPGyykJQnBzweNqeiU/xBVFJhO+KQaEiglT7GXf bz3XGsQ72eu51dkW56Alz+8vt9Y1/Z6uDgfOjca5tPOGqUj9RizfJc3YBSn8OGsE2P41fjFJ XoNxV/T+z7bvIIYyNDguRf2ksg77A6/OdYp+S/aNAE1zVamwZl5KkY8LTw7U3n3lAAAAAAAA --------------ms010301050802080803090700-- From jpv@cisco.com Tue May 29 05:21: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 626B721F87D5 for ; Tue, 29 May 2012 05:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 GjQtY5YPI65X for ; Tue, 29 May 2012 05:21:30 -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 8522621F87CF for ; Tue, 29 May 2012 05:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1831; q=dns/txt; s=iport; t=1338294090; x=1339503690; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=wImXL6s/jQcbGZQAJLUddnp/VE/geyXzvVvr1JBZCfQ=; b=C5vgqPIk9ebRzLRZIFbVYx6jd0nJIxWr+yFelcEtFC44GGl/YwlBHiRC 6+xrEqlDAPWjuC1s0RRfrDuK7ckl4H8UdhU/5Lpt/+ahlcWt99duLSS3t Nk13MHX7xqlHGcj2lkh2nMQsJ61gqujrjwpGDIRNdTPGxNjVXq/q1O783 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMi+xE+rRDoH/2dsb2JhbABEtVuBB4IXAQEBAwEBAQEPAVsLBQsLGCcHJx8RBhMih2QEAQuYZZ9TiwOEUWADiD+MWI4MgWWDAA X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208";a="46690132" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 29 May 2012 12:21:30 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4TCLTps017918; Tue, 29 May 2012 12:21:29 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 05:21:29 -0700 Received: from sjc-vpn4-451.cisco.com ([10.21.81.195]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 05:21:21 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: JP Vasseur In-Reply-To: <4FC4AE24.50105@fkie.fraunhofer.de> Date: Tue, 29 May 2012 05:21:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6928532B-F7CE-45E1-BAB6-D4F4077042AA@cisco.com> References: <4FC4AE24.50105@fkie.fraunhofer.de> To: Henning Rogge X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 29 May 2012 12:21:21.0509 (UTC) FILETIME=[8E93E150:01CD3D95] Cc: manet@ietf.org Subject: Re: [manet] Discussing LOADng suggestions 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, 29 May 2012 12:21:31 -0000 +1=20 On May 29, 2012, at 4:08 AM, Henning Rogge wrote: > On 05/29/2012 12:59 PM, Abdussalam Baryun wrote: >> Hi >>=20 >> I think at the WG 83 meeting, regarding LOADng to be discussed, and >> that the suggestions were either of the following: >>=20 >> 1- to accommodate LOADng for MANET WG, >> ( some prefered to see LOADng possibly adapted to the MANET working >> group as reactive protocol with RFC5444 compliance), or >> 2- to leave LOADng for LLN group to look at it, other than MANET WG, = or >> 3- to join LOADng authors with DYMO authors in one work. >>=20 >> IMO it is interesting to have a reactive MANET protocol using = RFC5444. >> There is motivation to use RFC5444 for interoperability between >> routers and security purposes. >=20 > Yes. >=20 >> However, LOADng is for lossy ad-hoc >> networks more than mobile ad-hoc nets. >=20 > This distinction does not make sense. >=20 > Adhoc networks deal with link that can fluctuate quite a lot. For most = protocols and routing metrics it doesn't matter if this happens because = of the metric, the radio environment or movement (exception are = protocols/metrics that incorporate explicit algorithms for exploiting = knowledge about movement or even terrain). >=20 > Henning Rogge >=20 > --=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 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Tue May 29 06:07: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 CC5A021F8754 for ; Tue, 29 May 2012 06:07:49 -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 SnArlLkVmzOA for ; Tue, 29 May 2012 06:07: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 3F15C21F8748 for ; Tue, 29 May 2012 06:07:48 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2405676vcq.31 for ; Tue, 29 May 2012 06:07: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=Th1fmmIS/FVtpOqnl2H2pVDKTszut4GhtDgfDJjf8ZM=; b=iOfqz33EwOKbakLQe1zPB8fFBzd26zm2MVQzqpGQ9eus5Z7k3b1bJv77MW2iLSjLdI Zx0CtiiBY8DP6UbKMjUt/dWg/1EGUPBjoFfAVDGaVB5WQDG92HwykiVJIfxPCJsxxLHl OqAaw2kSZGcAJQU9x0+UQkrlL1sQPGMjGRy1Fx/zuYeCUwpqSG2oQL7Jab2qDqLw9VRw JusSCBI/ctTdiGhYfbWKDkSKpsSC5oHKEKAHfLhAeQckhMBi3a3FA0K+acGRCfGhLGZ+ 3o0Ylet4/5CbPYca137vnw+MocIeJc8r1JRQYZEosSPEFt9nZNVG/iRx+pEH2m19ZzAQ 8ncw== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr10851234vdb.10.1338296867566; Tue, 29 May 2012 06:07:47 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 29 May 2012 06:07:46 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 15:07:46 +0200 Message-ID: From: Abdussalam Baryun To: charliep@computer.org Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 29 May 2012 13:07:49 -0000 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. > 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. Abdussalam Baryun ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Subject: [manet] A view on packet-BB From: "Charles E. Perkins" Date: Thu, 29 Mar 2012 07:31:06 -0700 > Hello folks, > > I have not participated very much in any discussions about > packet-BB other than to encourage header size reduction and > offer a few suggestions about how to achieve it. During that > time, it was claimed that for many networks of interest, the > use of packet-BB would *decrease* header size, perhaps > especially for proactive protocols. This is a question > very suitable for resolution by way of simulation. > > If, as I suspect, packet-BB does (on average) introduce > header enlargement on some networks that cannot afford it, > I would be in favor to introduce the option to run AODV > (or OLSR, for that matter) with some sort of "reduced" > header. This should only be deployed in networks where > otherwise there would be no feasible deployment of an > ad-hoc networking protocol. From that perspective, it's > almost a no brainer -- either deploy the standard stripped- > down version, or deploy something else nonstandard that > looks exactly like the stripped-down version. > > In summary, if there are cases where the [manet] protocols > can only be deployed without packet-BB header overhead, > then I think we should provide a solution for those cases. > > To be clear, I am happy either way, whether or not packet-BB > headers are mandates in all cases. > > Also, 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. > > Regards, > Charlie P. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Subject: Re: [manet] OLSRv2: which node defines link metric From: "Charles E. Perkins" Date: Mon, 28 Nov 2011 15:28:17 -0800 Hello folks, I'd given up on the link metric discussion a long time ago, and maybe some things have changed that escaped my notice. I had argued for the inclusion of a "type" field for the metric -- e.g., "delay", "cost", "ETX", "least occupancy", "throughput", bit-error rate, ... This would not be a short list of types, but it would be manageable. Without knowing the type, it is possible to have some seriously bad effects. For instance, suppose there are three metrics of interest, and three disjoint paths between source and destination. If each node advertises whatever metric value it chooses, without coordination or type, it is possible for the source to always pick the _worst_ path for any of the three metrics. The degree of "worstness" can be arbitrarily large. I'm certain this can be extended to always picking the _worst_ path for any of N possible metrics, and also to many different topologies -- not just disjoint paths. I am not sure if the topology can be completely arbitrary, or how to characterize the methods by which node advertisements can produce this terrible behavior. It's no doubt an interesting research problem. I was assured in several conversations that this was not an issue and that including a type for the metric was a non-starter. At that point, I really had to surrender. At least the metrics as defined do not lead to routing loops. If this has been solved, please send me a URL for the document so I can read about it, and accept my apology for the distraction. Regards, Charlie P. ++++++++++++++++++++++++++++++++++++++++++++++++++ From abdussalambaryun@gmail.com Tue May 29 06:21: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 76C7021F85C3 for ; Tue, 29 May 2012 06:21:11 -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 6NAvgHVcOqPF for ; Tue, 29 May 2012 06:21: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 847F921F845C for ; Tue, 29 May 2012 06:21:10 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2923681vbb.31 for ; Tue, 29 May 2012 06:21:09 -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=mMx0hS4M5Ruitv39XuGpKElObc+rl+Xc4/DZFUPYCME=; b=1E7/uZ69vwj0QMXR8q9jRXTEqjEjMZ5rOQoTuYZRPDfH/Atw1s6Ink2GLfi23vsZSe w05xVs1H0nvdiCUdq5XBVc7sPMZV5FpHcNlq/AqJ1jSZ1oooKUF+8AXKRqaZjA04YVPq n8xc0dz+P0xpcwz322xuI7mwyfAYcrPjAFRSKMf5LZEp+cYWxob2Hwa27P7mfbP/2XfS 5Mm3Q1sS0zG1kNLh0k6r0foC5xAuTrXRLKBOe0S6Lpq4Y4iOuymjzWIryftMIwl7C8Zz Ulg1aVkYNpdaegtManN1zPV1twocLsKQm+TlaD1aTFtcOQGFNt1vDRZDW3zcMM1ei9mr qsiQ== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr10528965vds.117.1338297669910; Tue, 29 May 2012 06:21:09 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 29 May 2012 06:21:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 May 2012 15:21:08 +0200 Message-ID: From: Abdussalam Baryun To: Henning Rogge , manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Discussing LOADng suggestions 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, 29 May 2012 13:21:11 -0000 I do not know why you think there is no difference between LLN and MANET in a protocol's perspective, so do you think we should not have different WGs in IETF? I did not understand your refering to movment without mentioning that LOADng-draft specifies that it is for LLN (I do not see in draft any reference to movement in LOADng!) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ This distinction does not make sense. Adhoc networks deal with link that can fluctuate quite a lot. For most protocols and routing metrics it doesn't matter if this happens because of the metric, the radio environment or movement (exception are protocols/metrics that incorporate explicit algorithms for exploiting knowledge about movement or even terrain). Henning Rogge ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/29/12, Abdussalam Baryun wrote: > Hi > > I think at the WG 83 meeting, regarding LOADng to be discussed, and > that the suggestions were either of the following: > > 1- to accommodate LOADng for MANET WG, > ( some prefered to see LOADng possibly adapted to the MANET working > group as reactive protocol with RFC5444 compliance), or > 2- to leave LOADng for LLN group to look at it, other than MANET WG, or > 3- to join LOADng authors with DYMO authors in one work. > > IMO it is interesting to have a reactive MANET protocol using RFC5444. > There is motivation to use RFC5444 for interoperability between > routers and security purposes. However, LOADng is for lossy ad-hoc > networks more than mobile ad-hoc nets. If authors decide LOADng is for > LLN then they should take it to LLN groups, but if the protocol and > document is modified it can be an alternative MANET reactive protocol > that differs from DYMO. So I agree to option-1 more than 2 depending > on the LOADng-authors' thoughts. > > It was mentioned in the meeting that DYMO and LOADng are close. I do > not see that that LOADng and AODVv2 are close (someone mentioned in 83 > meeting), but LOADng is a RFC5444-based reactive protocol that is > derived from AODV [RFC3561], it focuses on low power and lossy nets, > but DYMO is derived from DSR and AODV, and so far does not fully use > RFC5444. > > The suggestion option 3 maybe not interesting in this stage, because > usually it is better decided by the authors if they like the join > their drafts to one, but it is interesting to the WG to have > alternatives and that DYMO and LOADng are not similar functions. So I > disagree with option-3. > > IMHO that AODVv2 does not involve/use similar of LOADng, but it can > use RFC5444 differently from LOADng, or use only RFC5444 techniques. > Also LOADng does not use much of AODV-RFC3561, but it can use its > reactive technique adding to it energy efficiency techniques. LOADng > is for low power routers, but while reading it I am not sure how it > solves the power-problem. Furthermore, LOADng can be pushed to focus > on low-power MANET instead of LLN, it may only have lossy links, not a > lossy network. I suggest to replace 'LLN' in the protocol name to ' > Low-power' without lossy-net, and to make its functions consider > network energy consumptions. > > Abdussalam Baryun > University of Glamorgan, UK. > From jpv@cisco.com Tue May 29 06:23: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 006E921F85CC for ; Tue, 29 May 2012 06:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 jxLNhKk1EfVJ for ; Tue, 29 May 2012 06:23:24 -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 5A74721F85C3 for ; Tue, 29 May 2012 06:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3666; q=dns/txt; s=iport; t=1338297804; x=1339507404; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lQAwS+4fZjeRtL2FcmWSYRtffoNRVUgZtg6q23dTLFY=; b=DpSu8Pj4g8UsRdr2ogorv5TK2VwlhqmqzoGRpZ1z9ObtmIEGp5y34Cc2 zBiuYJsZj/IvgSuWvrgBKQemSAeMy1eCv4mDro6Hxc3JtZVmYChKHo6yb R6YN1xFSkgqvi9CF+ufLLFCLcAVKA/zYRiao8UtTDr5sGBxAhobqOgLr/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKfNxE+rRDoG/2dsb2JhbABEtTWBB4IXAQEBAwEBAQEPASc0BgUFCwsYLiEGMAYTIodbAwYEAQuYZpV6DYlKBIohYhuENmADiD+MWIp3gxWBZYMA X-IronPort-AV: E=Sophos;i="4.75,677,1330905600"; d="scan'208";a="44206805" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 29 May 2012 13:23:23 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q4TDNMvS015011; Tue, 29 May 2012 13:23:22 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 06:23:22 -0700 Received: from sjc-vpn4-451.cisco.com ([10.21.81.195]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 May 2012 06:23:22 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Tue, 29 May 2012 06:23:22 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 29 May 2012 13:23:22.0411 (UTC) FILETIME=[386877B0:01CD3D9E] Cc: manet Subject: Re: [manet] Discussing LOADng suggestions 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, 29 May 2012 13:23:25 -0000 On May 29, 2012, at 6:21 AM, Abdussalam Baryun wrote: > I do not know why you think there is no difference between LLN and > MANET in a protocol's perspective, so do you think we should not have > different WGs in IETF? We already have two different WG: MANET and ROLL. > I did not understand your refering to movment without mentioning that > LOADng-draft specifies that it is for LLN (I do not see in draft any > reference to movement in LOADng!) > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > This distinction does not make sense. > > > Adhoc networks deal with link that can fluctuate quite a lot. For most > protocols and routing metrics it doesn't matter if this happens > because of the metric, the radio environment or movement (exception > are protocols/metrics that incorporate explicit algorithms for > exploiting knowledge about movement or even terrain). > > Henning Rogge > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > On 5/29/12, Abdussalam Baryun wrote: >> Hi >> >> I think at the WG 83 meeting, regarding LOADng to be discussed, and >> that the suggestions were either of the following: >> >> 1- to accommodate LOADng for MANET WG, >> ( some prefered to see LOADng possibly adapted to the MANET working >> group as reactive protocol with RFC5444 compliance), or >> 2- to leave LOADng for LLN group to look at it, other than MANET WG, or >> 3- to join LOADng authors with DYMO authors in one work. >> >> IMO it is interesting to have a reactive MANET protocol using RFC5444. >> There is motivation to use RFC5444 for interoperability between >> routers and security purposes. However, LOADng is for lossy ad-hoc >> networks more than mobile ad-hoc nets. If authors decide LOADng is for >> LLN then they should take it to LLN groups, but if the protocol and >> document is modified it can be an alternative MANET reactive protocol >> that differs from DYMO. So I agree to option-1 more than 2 depending >> on the LOADng-authors' thoughts. >> >> It was mentioned in the meeting that DYMO and LOADng are close. I do >> not see that that LOADng and AODVv2 are close (someone mentioned in 83 >> meeting), but LOADng is a RFC5444-based reactive protocol that is >> derived from AODV [RFC3561], it focuses on low power and lossy nets, >> but DYMO is derived from DSR and AODV, and so far does not fully use >> RFC5444. >> >> The suggestion option 3 maybe not interesting in this stage, because >> usually it is better decided by the authors if they like the join >> their drafts to one, but it is interesting to the WG to have >> alternatives and that DYMO and LOADng are not similar functions. So I >> disagree with option-3. >> >> IMHO that AODVv2 does not involve/use similar of LOADng, but it can >> use RFC5444 differently from LOADng, or use only RFC5444 techniques. >> Also LOADng does not use much of AODV-RFC3561, but it can use its >> reactive technique adding to it energy efficiency techniques. LOADng >> is for low power routers, but while reading it I am not sure how it >> solves the power-problem. Furthermore, LOADng can be pushed to focus >> on low-power MANET instead of LLN, it may only have lossy links, not a >> lossy network. I suggest to replace 'LLN' in the protocol name to ' >> Low-power' without lossy-net, and to make its functions consider >> network energy consumptions. >> >> Abdussalam Baryun >> University of Glamorgan, UK. >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From ulrich@herberg.name Tue May 29 10:19: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 45B8411E80F7 for ; Tue, 29 May 2012 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.595, 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 N-sZmTImpqdn for ; Tue, 29 May 2012 10:19:34 -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 7888B11E80E5 for ; Tue, 29 May 2012 10:19:34 -0700 (PDT) Received: by qcsq13 with SMTP id q13so2571892qcs.31 for ; Tue, 29 May 2012 10:19:33 -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=LiAkbZXXTTIG7kBZJMtxc/+J7uhgAd0DHXJh+20dzBU=; b=vwy3hhcKmlgbFPjr8NNPwdy1PZb90LhbdFgjTcSQOe+ngNI/NscDy8XPqchf0fS6Dm 2uRMj2ZMlo50z5f5yPrLYmfPkGiRuyGrKfz2Y6ImpPOe6gTPfr96OwSF8XqhSSqNdRTb Y3WQ0PxEcqWFZ/xO0/UHw47bjgde3NMoWjTM8= 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=LiAkbZXXTTIG7kBZJMtxc/+J7uhgAd0DHXJh+20dzBU=; b=BK/JoS886vrXm7GX/1mgQeSy2o1uhB40sd83ntgeSodMSB5nl6hP3Nw9htjUIToiPq oTIwWwY+HxFhgTozQOs263xgwkXVVMKK1sD4Ap7Dze6oiDE6SXuikUb4/5St/4HdfFhu 7d9oVrKl394QHikw/38sgeTgphFvk/U8ezIWiEH6YeBJ1r+SFIeeaDdayFbtBQZy5Dlv 7mIO9AUF+XP0utfD0gXDpqaVcRi0pu3v7DEfruL0CmZAPTtE3cnrMzCvoI5StNCZ6YuX Y/IsXTGcIW8PrFk97Z4ej8eHzUxfo4jnlOGtFpvBaADYW+COgggIXIghYpGNojvpbZzh iGSg== MIME-Version: 1.0 Received: by 10.224.184.72 with SMTP id cj8mr5143421qab.23.1338311973372; Tue, 29 May 2012 10:19:33 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Tue, 29 May 2012 10:19:33 -0700 (PDT) In-Reply-To: <4FC4AE24.50105@fkie.fraunhofer.de> References: <4FC4AE24.50105@fkie.fraunhofer.de> Date: Tue, 29 May 2012 10:19:33 -0700 Message-ID: From: Ulrich Herberg To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnn1xqFgNPEuwY6hnPOiHZWwiNtiQDYW19ddEP3i9jBhyafncZ4NBUFknkT8TRHFDDuAW4A Cc: manet@ietf.org Subject: Re: [manet] Discussing LOADng suggestions 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, 29 May 2012 17:19:35 -0000 I agree with Henning. The reactive protocol the MANET WG is tasked to produce should be RFC5444 compliant. And as JP pointed out, there are two different WGs with different charters. MANET is tasked, amongst other, to publish a reactive routing protocol. Ulrich On Tue, May 29, 2012 at 4:08 AM, Henning Rogge wrote: > On 05/29/2012 12:59 PM, Abdussalam Baryun wrote: >> >> Hi >> >> I think at the WG 83 meeting, regarding LOADng to be discussed, and >> that the suggestions were either of the following: >> >> 1- to accommodate LOADng for MANET WG, >> ( some prefered to see LOADng possibly adapted to the MANET working >> group as reactive protocol with RFC5444 compliance), or >> 2- to leave LOADng for LLN group to look at it, other than MANET WG, or >> 3- to join LOADng authors with DYMO authors in one work. >> >> IMO it is interesting to have a reactive MANET protocol using RFC5444. >> There is motivation to use RFC5444 for interoperability between >> routers and security purposes. > > > Yes. > > >> However, LOADng is for lossy ad-hoc >> networks more than mobile ad-hoc nets. > > > This distinction does not make sense. > > Adhoc networks deal with link that can fluctuate quite a lot. For most > protocols and routing metrics it doesn't matter if this happens because o= f > the metric, the radio environment or movement (exception are > protocols/metrics that incorporate explicit algorithms for exploiting > knowledge about movement or even terrain). > > Henning Rogge > > -- > 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, =A0 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 > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From internet-drafts@ietf.org Tue May 29 17:04: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 A355011E817E; Tue, 29 May 2012 17:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 ZKCHETjgTzSU; Tue, 29 May 2012 17:04:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3178311E8125; Tue, 29 May 2012 17:04:25 -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: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2012 17:04:25 -0700 Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.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: Wed, 30 May 2012 00:04:25 -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 : Using Integrity Check Values and Timestamps For Router A= dmittance in NHDP Author(s) : Ulrich Herberg Thomas Heide Clausen Filename : draft-ietf-manet-nhdp-sec-02.txt Pages : 12 Date : 2012-05-29 This document specifies a security extension to the MANET Neighborhood Discovery Protocol (NHDP). The extension introduces the use of Integrity Check Values (ICVs) and Timestamps in HELLO messages in order to provide a router admittance mechanism, and therefore to counter a selection of security threats to NHDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.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-sec-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ From mohdnaseem.mca@gmail.com Wed May 30 03: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 95CAE21F86DE for ; Wed, 30 May 2012 03:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 qIVZeizoeU2D for ; Wed, 30 May 2012 03:03:58 -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 3625021F86DD for ; Wed, 30 May 2012 03:03:58 -0700 (PDT) Received: by dacx6 with SMTP id x6so6709500dac.31 for ; Wed, 30 May 2012 03:03:58 -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=WpbgUPKjXsih+xnv6Jj34wesY+Dzh4/dcUe3rDtbj3Q=; b=q6PRcobwv+sZRANJ1SDz7CaJL9D0dvWeGQ5nKC6u6bAS9G0uJJfWZFCZrQhqyjjC5z v8vLwiE0QxJRcMZBU02ASLu7K7n5UHcloQysvdy302uP60WH/+FuP99+pbKmbjaxAxum wkhYECfOPgkZIgPTGTenrw+BfenjBbsKuj4s0es5U9Yiyr/JpH41LFHXixjh8J3bkQR2 kZ+OGBCwL6UVe7RsEBSf1/EYe2C0U3frYOgrWzrtL3k3EAIASoUJ+XClMKjYSi8SeSqz hbWX9kC5Ua4sG/phLwWfAtU7F/hIClf8KmU0Cn2UZMihtmeBNtvHiBEt3X3Y1LP2+Hw9 VOjg== MIME-Version: 1.0 Received: by 10.68.129.167 with SMTP id nx7mr11721568pbb.80.1338372237907; Wed, 30 May 2012 03:03:57 -0700 (PDT) Received: by 10.68.47.33 with HTTP; Wed, 30 May 2012 03:03:57 -0700 (PDT) Date: Wed, 30 May 2012 15:33:57 +0530 Message-ID: From: mohd naseem To: manet@ietf.org Content-Type: multipart/alternative; boundary=047d7b10cee9d155a904c13e1147 Subject: [manet] something about ad hoc routers 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, 30 May 2012 10:03:58 -0000 --047d7b10cee9d155a904c13e1147 Content-Type: text/plain; charset=ISO-8859-1 sir, i want to implement my work on ad hoc network, for this i have to buy ad hoc devices. please tell what i have to do? name of device? --047d7b10cee9d155a904c13e1147 Content-Type: text/html; charset=ISO-8859-1

sir, i want to implement my work on ad hoc network, for this i have to buy ad hoc devices. please tell what i have to do? name of device? --047d7b10cee9d155a904c13e1147-- From abdussalambaryun@gmail.com Wed May 30 03:45: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 808DB21F867B for ; Wed, 30 May 2012 03:45: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=[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 wx7eJ+dkzhFT for ; Wed, 30 May 2012 03:45:14 -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 AF03921F864D for ; Wed, 30 May 2012 03:45:14 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3171943vcq.31 for ; Wed, 30 May 2012 03:45: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 :cc:content-type; bh=kttpl0FMhswrnz5W+b+YbesEIwSPKG9XlCp9oZbZvqk=; b=fCRoHp7LYyLmj3JyEVLB3f2TovFq3wMqjiinKuvecuoKYUPW1r6EnVc/+FyOCwmFyg he0bjGsBKU/5iBhBuIUKi8kzPYdLZrmCaeoET1kOOIXfehKWWFSw374hmDKm5QoTftVo m14P8OYrTtM5tMCR4UiWhHVbzoPIyh2AWQc9QMvtqwGOtxtucNmCKE3nac/EZbrVX4UG HUcWn2QNYEc1tDYwaGZ/NpH3ppw9Ea9i90xKjmdy3Vqbtfr8p2NQoUGdSe7EFkmtXcmA OXISeSMVQc4kDkW36jK0yzoP7WAVE/nUoD/9EeJRiAFudfkw/04reryrLGS5eRH667SM gAMw== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr16442519vcv.12.1338374713442; Wed, 30 May 2012 03:45:13 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 30 May 2012 03:45:12 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 May 2012 12:45:12 +0200 Message-ID: From: Abdussalam Baryun To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] Discussing LOADng suggestions 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, 30 May 2012 10:45:15 -0000 On 5/29/12, JP Vasseur wrote: > > We already have two different WG: MANET and ROLL. > Yes we know. That is why LOADng authors should choose either to serve LLN that is considered by ROLL WG or they choose serving MANET, and it is considered by MANET WG. But the question is which suggestion option do you think is better for LOADng-draft? >MANET is tasked, amongst other, to publish a reactive >routing protocol. MANET is tasked to publish routing protocols that serve the MANET network. IMO, MANET-WG is not tasked to publish protocols serving only LLN just because the protocol is reactive. Please note that LOADng protocol does not even mention MANET nor mobile routers in its draft, which confuses its purpose, the authors should look into that. Abdussalam Baryun ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> I did not understand your refering to movment without mentioning that >> LOADng-draft specifies that it is for LLN (I do not see in draft any >> reference to movement in LOADng!) >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> This distinction does not make sense. >> >> >> Adhoc networks deal with link that can fluctuate quite a lot. For most >> protocols and routing metrics it doesn't matter if this happens >> because of the metric, the radio environment or movement (exception >> are protocols/metrics that incorporate explicit algorithms for >> exploiting knowledge about movement or even terrain). >> >> Henning Rogge >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> On 5/29/12, Abdussalam Baryun wrote: >>> Hi >>> >>> I think at the WG 83 meeting, regarding LOADng to be discussed, and >>> that the suggestions were either of the following: >>> >>> 1- to accommodate LOADng for MANET WG, >>> ( some prefered to see LOADng possibly adapted to the MANET working >>> group as reactive protocol with RFC5444 compliance), or >>> 2- to leave LOADng for LLN group to look at it, other than MANET WG, or >>> 3- to join LOADng authors with DYMO authors in one work. >>> >>> IMO it is interesting to have a reactive MANET protocol using RFC5444. >>> There is motivation to use RFC5444 for interoperability between >>> routers and security purposes. However, LOADng is for lossy ad-hoc >>> networks more than mobile ad-hoc nets. If authors decide LOADng is for >>> LLN then they should take it to LLN groups, but if the protocol and >>> document is modified it can be an alternative MANET reactive protocol >>> that differs from DYMO. So I agree to option-1 more than 2 depending >>> on the LOADng-authors' thoughts. >>> >>> It was mentioned in the meeting that DYMO and LOADng are close. I do >>> not see that that LOADng and AODVv2 are close (someone mentioned in 83 >>> meeting), but LOADng is a RFC5444-based reactive protocol that is >>> derived from AODV [RFC3561], it focuses on low power and lossy nets, >>> but DYMO is derived from DSR and AODV, and so far does not fully use >>> RFC5444. >>> >>> The suggestion option 3 maybe not interesting in this stage, because >>> usually it is better decided by the authors if they like the join >>> their drafts to one, but it is interesting to the WG to have >>> alternatives and that DYMO and LOADng are not similar functions. So I >>> disagree with option-3. >>> >>> IMHO that AODVv2 does not involve/use similar of LOADng, but it can >>> use RFC5444 differently from LOADng, or use only RFC5444 techniques. >>> Also LOADng does not use much of AODV-RFC3561, but it can use its >>> reactive technique adding to it energy efficiency techniques. LOADng >>> is for low power routers, but while reading it I am not sure how it >>> solves the power-problem. Furthermore, LOADng can be pushed to focus >>> on low-power MANET instead of LLN, it may only have lossy links, not a >>> lossy network. I suggest to replace 'LLN' in the protocol name to ' >>> Low-power' without lossy-net, and to make its functions consider >>> network energy consumptions. >>> >>> Abdussalam Baryun >>> University of Glamorgan, UK. >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From jpv@cisco.com Wed May 30 05:59: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 076FC21F86AF for ; Wed, 30 May 2012 05:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 1xwLh8FJSN-U for ; Wed, 30 May 2012 05:59:28 -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 438B121F85BE for ; Wed, 30 May 2012 05:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4835; q=dns/txt; s=iport; t=1338382768; x=1339592368; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=FAGZ9yv1XpT8ixvNGCogrSMQHPvG/Itg+dhX2tx7GzY=; b=C+tDY+bmWBF2GzRhyFAzctfGlyjGlQxuKSVswHQgAnX+d7E2hHaFreo2 iR2q33MDb6+/TtuHuHtRrBN/hE5BAFNgS9/iYO7xPqir5unbsN9lpqnRz hqsTqnyOpUyZBcqGgEc1EQjmeyCRO+sRnEYKj9nhcG8OhZLJKr+dgB+CA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAM8Yxk+rRDoH/2dsb2JhbABEgx2wcIEHghcBAQEDAQEBAQ8BJzQGBQULCxguIQYwBhMih1sDBgQMmRqWOA2JSgSKJGEbhEdgA4hAjFiFT4UpgxWBZoMA X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="46849256" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 30 May 2012 12:59:27 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4UCxRrZ025328; Wed, 30 May 2012 12:59:27 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 05:59:27 -0700 Received: from [10.154.200.21] ([10.154.200.21]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 05:59:27 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Wed, 30 May 2012 05:21:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2041E83D-4099-4475-8E9E-B54865D68A34@cisco.com> References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 30 May 2012 12:59:27.0228 (UTC) FILETIME=[0B62ABC0:01CD3E64] Cc: manet Subject: Re: [manet] Discussing LOADng suggestions 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, 30 May 2012 12:59:29 -0000 On May 30, 2012, at 3:45 AM, Abdussalam Baryun wrote: > On 5/29/12, JP Vasseur wrote: >>=20 >> We already have two different WG: MANET and ROLL. >>=20 >=20 > Yes we know. That is why LOADng authors should choose either to serve > LLN that is considered by ROLL WG or they choose serving MANET, and it > is considered by MANET WG. But the question is which suggestion option > do you think is better for LOADng-draft? >=20 >> MANET is tasked, amongst other, to publish a reactive >> routing protocol. >=20 > MANET is tasked to publish routing protocols that serve the MANET > network. IMO, MANET-WG is not tasked to publish protocols serving only > LLN just because the protocol is reactive. JP> I am completely sharing your view, but this is up to the MANET's WG = chairs of course. > Please note that LOADng > protocol does not even mention MANET nor mobile routers in its draft, > which confuses its purpose, the authors should look into that. >=20 > Abdussalam Baryun > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> I did not understand your refering to movment without mentioning = that >>> LOADng-draft specifies that it is for LLN (I do not see in draft any >>> reference to movement in LOADng!) >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> This distinction does not make sense. >>>=20 >>>=20 >>> Adhoc networks deal with link that can fluctuate quite a lot. For = most >>> protocols and routing metrics it doesn't matter if this happens >>> because of the metric, the radio environment or movement (exception >>> are protocols/metrics that incorporate explicit algorithms for >>> exploiting knowledge about movement or even terrain). >>>=20 >>> Henning Rogge >>>=20 >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>=20 >>> On 5/29/12, Abdussalam Baryun wrote: >>>> Hi >>>>=20 >>>> I think at the WG 83 meeting, regarding LOADng to be discussed, and >>>> that the suggestions were either of the following: >>>>=20 >>>> 1- to accommodate LOADng for MANET WG, >>>> ( some prefered to see LOADng possibly adapted to the MANET working >>>> group as reactive protocol with RFC5444 compliance), or >>>> 2- to leave LOADng for LLN group to look at it, other than MANET = WG, or >>>> 3- to join LOADng authors with DYMO authors in one work. >>>>=20 >>>> IMO it is interesting to have a reactive MANET protocol using = RFC5444. >>>> There is motivation to use RFC5444 for interoperability between >>>> routers and security purposes. However, LOADng is for lossy ad-hoc >>>> networks more than mobile ad-hoc nets. If authors decide LOADng is = for >>>> LLN then they should take it to LLN groups, but if the protocol and >>>> document is modified it can be an alternative MANET reactive = protocol >>>> that differs from DYMO. So I agree to option-1 more than 2 = depending >>>> on the LOADng-authors' thoughts. >>>>=20 >>>> It was mentioned in the meeting that DYMO and LOADng are close. I = do >>>> not see that that LOADng and AODVv2 are close (someone mentioned in = 83 >>>> meeting), but LOADng is a RFC5444-based reactive protocol that is >>>> derived from AODV [RFC3561], it focuses on low power and lossy = nets, >>>> but DYMO is derived from DSR and AODV, and so far does not fully = use >>>> RFC5444. >>>>=20 >>>> The suggestion option 3 maybe not interesting in this stage, = because >>>> usually it is better decided by the authors if they like the join >>>> their drafts to one, but it is interesting to the WG to have >>>> alternatives and that DYMO and LOADng are not similar functions. So = I >>>> disagree with option-3. >>>>=20 >>>> IMHO that AODVv2 does not involve/use similar of LOADng, but it can >>>> use RFC5444 differently from LOADng, or use only RFC5444 = techniques. >>>> Also LOADng does not use much of AODV-RFC3561, but it can use its >>>> reactive technique adding to it energy efficiency techniques. = LOADng >>>> is for low power routers, but while reading it I am not sure how it >>>> solves the power-problem. Furthermore, LOADng can be pushed to = focus >>>> on low-power MANET instead of LLN, it may only have lossy links, = not a >>>> lossy network. I suggest to replace 'LLN' in the protocol name to ' >>>> Low-power' without lossy-net, and to make its functions consider >>>> network energy consumptions. >>>>=20 >>>> Abdussalam Baryun >>>> University of Glamorgan, UK. >>>>=20 >>> _______________________________________________ >>> 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 Chris.Dearlove@baesystems.com Wed May 30 06:06: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 6EC6C21F86A3 for ; Wed, 30 May 2012 06:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 fxLkkxZH9kvp for ; Wed, 30 May 2012 06:06:35 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8A51A21F86AF for ; Wed, 30 May 2012 06:06:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="242509364" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 May 2012 14:06:31 +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 q4UD6UW4002013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 May 2012 14:06:31 +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, 30 May 2012 14:06:30 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: AQHNPffqWR5Mj5fN8UWXIbVshjhLd5biSEBQ Date: Wed, 30 May 2012 13:06:29 +0000 Message-ID: References: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> In-Reply-To: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> 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: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.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: Wed, 30 May 2012 13:06:39 -0000 --=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 i= nternet-drafts@ietf.org Sent: 30 May 2012 01:04 To: i-d-announce@ietf.org Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt As I read it, this draft is proposing using the RFC 6622 mechanism to sign = HELLO messages. RFC 6622 actually allows for signing packets as well as sig= ning messages (both, either, or neither to be used as required). There isn'= t a major difference when considering HELLO messages, as few if any packets= will contain more than one HELLO message, and the packet and the message w= ill be signed by the same party. However NHDP doesn't exist in a vacuum, in particular it is used by OLSRv2.= Any security mechanism that is described in what will be an RFC for NHDP m= ust also be what's right for NHDP as used by OLSRv2. OLSRv2 also has TC mes= sages to consider, and they don't satisfy the points noted above (on number= or on who signs them). And one option for OLSRv2 is to sign all packets, n= ot messages. This can be a sensible decision there, for several reasons, in= some real circumstances. Consequently, I don't believe that this draft should describe only signing = HELLO messages as the correct thing to do, that it should also allow signin= g packets as an equal status option. If someone wants to raise the possibil= ity of signing (possibly by methods with different properties) both at the = message and packet level, that may have its use cases too. Incidentally, even within the limited framework of just NHDP, it is possibl= e that packets need protection. If an NHDP implementation chooses to use pa= cket sequence number as part of its link quality mechanism, as it may, then= an unprotected packet header is a vulnerability. (For the sake of completeness, RFC 6622 also allows address block signature= s. I don't have a reason to suggest using this within NHDP or OLSRv2.) ----------------------! 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. -------------------------------------------------------- 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. =09Title : Using Integrity Check Values and Timestamps For Router= Admittance in NHDP =09Author(s) : Ulrich Herberg Thomas Heide Clausen =09Filename : draft-ietf-manet-nhdp-sec-02.txt =09Pages : 12 =09Date : 2012-05-29 This document specifies a security extension to the MANET Neighborhood Discovery Protocol (NHDP). The extension introduces the use of Integrity Check Values (ICVs) and Timestamps in HELLO messages in order to provide a router admittance mechanism, and therefore to counter a selection of security threats to NHDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.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-sec-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ _______________________________________________ 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 Wed May 30 06:21:50 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 8FBF021F8670 for ; Wed, 30 May 2012 06:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2VYRDmYr8SEI for ; Wed, 30 May 2012 06:21:48 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 60FE321F865A for ; Wed, 30 May 2012 06:21:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="242515498" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 30 May 2012 14:21:47 +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 q4UDLlVN013242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 May 2012 14:21:47 +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, 30 May 2012 14:21:46 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.txt Thread-Index: AQHNPffqWR5Mj5fN8UWXIbVshjhLd5biSEBQgAAIObA= Date: Wed, 30 May 2012 13:21:46 +0000 Message-ID: References: <20120530000425.31759.46618.idtracker@ietfa.amsl.com> 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: "Thomas Heide Clausen \(thomas@thomasclausen.org\)" Subject: Re: [manet] I-D Action: draft-ietf-manet-nhdp-sec-02.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: Wed, 30 May 2012 13:21:51 -0000 (Sending again, to sort out the formatting problem with the last attempt.) As I read it, this draft is proposing using the RFC 6622 mechanism to sign = HELLO messages. RFC 6622 actually allows for signing packets as well as sig= ning messages (both, either, or neither to be used as required). There isn'= t a major difference when considering HELLO messages, as few if any packets= will contain more than one HELLO message, and the packet and the message w= ill be signed by the same party. However NHDP doesn't exist in a vacuum, in particular it is used by OLSRv2.= Any security mechanism that is described in what will be an RFC for NHDP m= ust also be what's right for NHDP as used by OLSRv2. OLSRv2 also has TC mes= sages to consider, and they don't satisfy the points noted above (on number= or on who signs them). And one option for OLSRv2 is to sign all packets, n= ot messages. This can be a sensible decision there, for several reasons, in= some real circumstances. Consequently, I don't believe that this draft should describe only signing = HELLO messages as the correct thing to do, that it should also allow signin= g packets as an equal status option. If someone wants to raise the possibil= ity of signing (possibly by methods with different properties) both at the = message and packet level, that may have its use cases too. Incidentally, even within the limited framework of just NHDP, it is possibl= e that packets need protection. If an NHDP implementation chooses to use pa= cket sequence number as part of its link quality mechanism, as it may, then= an unprotected packet header is a vulnerability. (For the sake of completeness, RFC 6622 also allows address block signature= s. I don't have a reason to suggest using this within NHDP or OLSRv2.) --=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 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. =09Title : Using Integrity Check Values and Timestamps For Router= Admittance in NHDP =09Author(s) : Ulrich Herberg Thomas Heide Clausen =09Filename : draft-ietf-manet-nhdp-sec-02.txt =09Pages : 12 =09Date : 2012-05-29 This document specifies a security extension to the MANET Neighborhood Discovery Protocol (NHDP). The extension introduces the use of Integrity Check Values (ICVs) and Timestamps in HELLO messages in order to provide a router admittance mechanism, and therefore to counter a selection of security threats to NHDP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-nhdp-sec-02.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-sec-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-nhdp-sec/ _______________________________________________ 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 Wed May 30 07:09: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 0E3FD21F86B1 for ; Wed, 30 May 2012 07:09:13 -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 H8z+DTPsJjFf for ; Wed, 30 May 2012 07:09: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 142A421F86A0 for ; Wed, 30 May 2012 07:09:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3814621vbb.31 for ; Wed, 30 May 2012 07:09:11 -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=3n+paBFZ0uEsdNeM8K/78OFjBsIXxFOCaG1GdMZ+8jI=; b=g9FEu/q9ecaGwmrvLXnQrXfqP36J9OcEvbNGlxS2hobjJQOVQeGvBVAiQxwyF7i6hi +MyoRd+cCUwmk8NLWG+5uiwzCBzKMwtf/4yAym2FwjygtAYwS+XIlyt8jnLrNLNMFnlo DbPjYrRo+tyx2WGzsALzw9VpN6G/rLAlPm8GooiHpx+9vDc43o0MFDC+Y2Zy+BObrBsC RkmN7ooYfc/mmoEflVAd/bZMNQj0Os78UZa2Lu8tl+IxwoaxfGj6tBEFSb45Kz9okuPL MaUqtcUzGMyw84V9PJ3XqhddAI8CQ/t5ZqBlaCuMfzGVLYPa2jFaoMxOXdJctZE8Du39 boQg== MIME-Version: 1.0 Received: by 10.52.23.81 with SMTP id k17mr14257738vdf.103.1338386951476; Wed, 30 May 2012 07:09:11 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 30 May 2012 07:09:08 -0700 (PDT) In-Reply-To: <2041E83D-4099-4475-8E9E-B54865D68A34@cisco.com> References: <2041E83D-4099-4475-8E9E-B54865D68A34@cisco.com> Date: Wed, 30 May 2012 16:09:08 +0200 Message-ID: From: Abdussalam Baryun To: JP Vasseur , manet Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [manet] Discussing LOADng suggestions 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, 30 May 2012 14:09:13 -0000 Hi Thanks for your reply. however, it was stated by WG-Chairs in the 83-meeting, that the chairs have no decision or no horse in the proposal of LOADng. They wanted the discussions on the WG list, not in the companies chatting out of MANET-IETF. In summery, so far I didn't see LOADng-authors/contributors interested to discuss their proposal on the list, or their effort to adapt to MANET purposes. Could any one give me a hint on a good paper or I want to see performance documents published of the tests on the 1000 nodes running LOADng (was mentioned in the meeting)? Abdussalam Baryun University of Glamorgan, UK ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/30/12, JP Vasseur wrote: > > On May 30, 2012, at 3:45 AM, Abdussalam Baryun wrote: > >> On 5/29/12, JP Vasseur wrote: >>> >>> We already have two different WG: MANET and ROLL. >>> >> >> Yes we know. That is why LOADng authors should choose either to serve >> LLN that is considered by ROLL WG or they choose serving MANET, and it >> is considered by MANET WG. But the question is which suggestion option >> do you think is better for LOADng-draft? >> >>> MANET is tasked, amongst other, to publish a reactive >>> routing protocol. >> >> MANET is tasked to publish routing protocols that serve the MANET >> network. IMO, MANET-WG is not tasked to publish protocols serving only >> LLN just because the protocol is reactive. > > JP> I am completely sharing your view, but this is up to the MANET's WG > chairs of course. > >> Please note that LOADng >> protocol does not even mention MANET nor mobile routers in its draft, >> which confuses its purpose, the authors should look into that. >> >> Abdussalam Baryun >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> I did not understand your refering to movment without mentioning that >>>> LOADng-draft specifies that it is for LLN (I do not see in draft any >>>> reference to movement in LOADng!) >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> This distinction does not make sense. >>>> >>>> >>>> Adhoc networks deal with link that can fluctuate quite a lot. For most >>>> protocols and routing metrics it doesn't matter if this happens >>>> because of the metric, the radio environment or movement (exception >>>> are protocols/metrics that incorporate explicit algorithms for >>>> exploiting knowledge about movement or even terrain). >>>> >>>> Henning Rogge >>>> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>>> >>>> On 5/29/12, Abdussalam Baryun wrote: >>>>> Hi >>>>> >>>>> I think at the WG 83 meeting, regarding LOADng to be discussed, and >>>>> that the suggestions were either of the following: >>>>> >>>>> 1- to accommodate LOADng for MANET WG, >>>>> ( some prefered to see LOADng possibly adapted to the MANET working >>>>> group as reactive protocol with RFC5444 compliance), or >>>>> 2- to leave LOADng for LLN group to look at it, other than MANET WG, >>>>> or >>>>> 3- to join LOADng authors with DYMO authors in one work. >>>>> >>>>> IMO it is interesting to have a reactive MANET protocol using RFC5444. >>>>> There is motivation to use RFC5444 for interoperability between >>>>> routers and security purposes. However, LOADng is for lossy ad-hoc >>>>> networks more than mobile ad-hoc nets. If authors decide LOADng is for >>>>> LLN then they should take it to LLN groups, but if the protocol and >>>>> document is modified it can be an alternative MANET reactive protocol >>>>> that differs from DYMO. So I agree to option-1 more than 2 depending >>>>> on the LOADng-authors' thoughts. >>>>> >>>>> It was mentioned in the meeting that DYMO and LOADng are close. I do >>>>> not see that that LOADng and AODVv2 are close (someone mentioned in 83 >>>>> meeting), but LOADng is a RFC5444-based reactive protocol that is >>>>> derived from AODV [RFC3561], it focuses on low power and lossy nets, >>>>> but DYMO is derived from DSR and AODV, and so far does not fully use >>>>> RFC5444. >>>>> >>>>> The suggestion option 3 maybe not interesting in this stage, because >>>>> usually it is better decided by the authors if they like the join >>>>> their drafts to one, but it is interesting to the WG to have >>>>> alternatives and that DYMO and LOADng are not similar functions. So I >>>>> disagree with option-3. >>>>> >>>>> IMHO that AODVv2 does not involve/use similar of LOADng, but it can >>>>> use RFC5444 differently from LOADng, or use only RFC5444 techniques. >>>>> Also LOADng does not use much of AODV-RFC3561, but it can use its >>>>> reactive technique adding to it energy efficiency techniques. LOADng >>>>> is for low power routers, but while reading it I am not sure how it >>>>> solves the power-problem. Furthermore, LOADng can be pushed to focus >>>>> on low-power MANET instead of LLN, it may only have lossy links, not a >>>>> lossy network. I suggest to replace 'LLN' in the protocol name to ' >>>>> Low-power' without lossy-net, and to make its functions consider >>>>> network energy consumptions. >>>>> >>>>> Abdussalam Baryun >>>>> University of Glamorgan, UK. >>>>> >>>> _______________________________________________ >>>> 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 mlibca@yahoo.ca Wed May 30 08: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 1282711E8083 for ; Wed, 30 May 2012 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897, UNPARSEABLE_RELAY=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 IZtLPuFlDoII for ; Wed, 30 May 2012 08:27:00 -0700 (PDT) Received: from nm27-vm0.bullet.mail.sp2.yahoo.com (nm27-vm0.bullet.mail.sp2.yahoo.com [98.139.91.232]) by ietfa.amsl.com (Postfix) with SMTP id 91FA311E8080 for ; Wed, 30 May 2012 08:27:00 -0700 (PDT) Received: from [98.139.91.69] by nm27.bullet.mail.sp2.yahoo.com with NNFMP; 30 May 2012 15:26:57 -0000 Received: from [209.191.107.117] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 30 May 2012 15:26:57 -0000 Received: from [127.0.0.1] by smtp134.mail.mud.yahoo.com with NNFMP; 30 May 2012 15:26:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1338391617; bh=T58uyeN9PDTDzD/ssxqsGr6MqA0B6zu7K5mymrnI75E=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:Subject:Message-ID:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lachtN2QkKiwNTtBHXU5+BSQK0nfPa/6EwRtlKcATi9/91OeVfATVF8g7SRu70ZQg5oOWI/3qvrYO3/p4EWqyTNcgrNnInjEYGsovznBGiLwE0DHT078hcdYG1TSsia0HH3yOoy5JCirQ8aNqdrVAAtsSYeKzr0oDiYLqZXq3dU= X-Yahoo-Newman-Id: 556722.62711.bm@smtp134.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NeZ4VGoVM1lcARBxT4xVS6WyYBJXWhnTdCKrwmhXlDy6cKF FqIN_OcBYjCpoq1YjkcI97KfIPCyYQPRqv0_imGrUsqmYAlRgU_hKPT48Sni ZQ1VwSQXrj8cbuXKVo2ssfbQfjPyC_hRZbinQA8yD1MxhHtD0rhIKNEH2Ny2 c4dPulwUzdBRRoWXX5RJ0y0dtIriftAnPhMzZUJnifpGu1SW73DiongiHQfq t5KJF1JkBcR0wzs0TlZRB7KXbkcSHYYd2LzRaTv4buTFpTs4A.kZoiY3akIp YcVLgWwjdakXu4irYLjO6uM94VvSdeJzefGgLlc2gcRk4keubOyL2hxQgyl. Pfa.fXydDXFrapfRvWSWp0zEe4oMa3QrAaGRemDLG22hXq3LVuYJs7IpUjV_ 1coe5a8XmIkhu.ej6eEdxha9Xl9Mx1ts8JrYxVjdBGYQGG6Pm.5eKMaJ.nD8 4MO0BgB93IkhHvisRc4.KiJF4XKLxeUklEpi_pHX1V2duVR1nLusIa6cRyEJ RI_vOUqYqZKNxqeZMJbN8HxFfKp79MCGYj6Vi2g3YPDaVjXRMjPKkRipvCRK 6Wsuc X-Yahoo-SMTP: IdcBgVqswBD8fvUHW1Iehz0xYQ-- Received: from localhost (mlibca@70.79.250.18 with plain) by smtp134.mail.mud.yahoo.com with SMTP; 30 May 2012 08:26:56 -0700 PDT Date: Thu, 31 May 2012 08:25:58 +0800 Message-ID: From: M Li To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [manet] manet Digest, Vol 96, Issue 27 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, 30 May 2012 15:27:02 -0000 CgptYW5ldC1yZXF1ZXN0QGlldGYub3JnIHdyb3RlOgoKPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZGlnZXN0IHdpdGhvdXQgYWxsIHRoZSBpbmRpdmlkdWFsIG1lc3NhZ2UKPmF0dGFjaG1lbnRz IHlvdSB3aWxsIG5lZWQgdG8gdXBkYXRlIHlvdXIgZGlnZXN0IG9wdGlvbnMgaW4geW91ciBsaXN0 Cj5zdWJzY3JpcHRpb24uICBUbyBkbyBzbywgZ28gdG8gCj4KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWFuZXQKPgo+Q2xpY2sgdGhlICdVbnN1YnNjcmliZSBvciBlZGl0 IG9wdGlvbnMnIGJ1dHRvbiwgbG9nIGluLCBhbmQgc2V0ICJHZXQKPk1JTUUgb3IgUGxhaW4gVGV4 dCBEaWdlc3RzPyIgdG8gTUlNRS4gIFlvdSBjYW4gc2V0IHRoaXMgb3B0aW9uCj5nbG9iYWxseSBm b3IgYWxsIHRoZSBsaXN0IGRpZ2VzdHMgeW91IHJlY2VpdmUgYXQgdGhpcyBwb2ludC4KPgo+Cj4K PlNlbmQgbWFuZXQgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvCj4JbWFuZXRAaWV0Zi5vcmcK Pgo+VG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZp c2l0Cj4JaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldAo+b3IsIHZp YSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRvCj4J bWFuZXQtcmVxdWVzdEBpZXRmLm9yZwo+Cj5Zb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdp bmcgdGhlIGxpc3QgYXQKPgltYW5ldC1vd25lckBpZXRmLm9yZwo+Cj5XaGVuIHJlcGx5aW5nLCBw bGVhc2UgZWRpdCB5b3VyIFN1YmplY3QgbGluZSBzbyBpdCBpcyBtb3JlIHNwZWNpZmljCj50aGFu ICJSZTogQ29udGVudHMgb2YgbWFuZXQgZGlnZXN0Li4uIgo+Cj4KPlRvZGF5J3MgVG9waWNzOgo+ Cj4gICAxLiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dAo+ICAg ICAgKGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZykKPiAgIDIuIHNvbWV0aGluZyBhYm91dCBhZCBo b2Mgcm91dGVycyAobW9oZCBuYXNlZW0pCj4gICAzLiBSZTogRGlzY3Vzc2luZyBMT0FEbmcgc3Vn Z2VzdGlvbnMgKEFiZHVzc2FsYW0gQmFyeXVuKQo+ICAgNC4gUmU6IERpc2N1c3NpbmcgTE9BRG5n IHN1Z2dlc3Rpb25zIChKUCBWYXNzZXVyKQo+ICAgNS4gUmU6IEktRCBBY3Rpb246IGRyYWZ0LWll dGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0Cj4gICAgICAoRGVhcmxvdmUsIENocmlzdG9waGVyIChV SykpCj4gICA2LiBSZTogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLXNlYy0wMi50 eHQKPiAgICAgIChEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSkKPgo+Cj4tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4KPk1lc3NhZ2U6IDEKPkRhdGU6IFR1ZSwgMjkgTWF5IDIwMTIgMTc6MDQ6MjUgLTA3MDAKPkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZwo+VG86IGktZC1hbm5vdW5jZUBpZXRmLm9yZwo+ Q2M6IG1hbmV0QGlldGYub3JnCj5TdWJqZWN0OiBbbWFuZXRdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0Cj5NZXNzYWdlLUlEOiA8MjAxMjA1MzAwMDA0MjUuMzE3 NTkuNDY2MTguaWR0cmFja2VyQGlldGZhLmFtc2wuY29tPgo+Q29udGVudC1UeXBlOiB0ZXh0L3Bs YWluOyBjaGFyc2V0PSJ1dGYtOCIKPgo+Cj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJh ZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgV29ya2luZyBH cm91cCBvZiB0aGUgSUVURi4KPgo+CVRpdGxlICAgICAgICAgICA6IFVzaW5nIEludGVncml0eSBD aGVjayBWYWx1ZXMgYW5kIFRpbWVzdGFtcHMgRm9yIFJvdXRlciBBZG1pdHRhbmNlIGluIE5IRFAK PglBdXRob3IocykgICAgICAgOiBVbHJpY2ggSGVyYmVyZwo+ICAgICAgICAgICAgICAgICAgICAg ICAgICBUaG9tYXMgSGVpZGUgQ2xhdXNlbgo+CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt bWFuZXQtbmhkcC1zZWMtMDIudHh0Cj4JUGFnZXMgICAgICAgICAgIDogMTIKPglEYXRlICAgICAg ICAgICAgOiAyMDEyLTA1LTI5Cj4KPiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgc2VjdXJp dHkgZXh0ZW5zaW9uIHRvIHRoZSBNQU5FVAo+ICAgTmVpZ2hib3Job29kIERpc2NvdmVyeSBQcm90 b2NvbCAoTkhEUCkuICBUaGUgZXh0ZW5zaW9uIGludHJvZHVjZXMgdGhlCj4gICB1c2Ugb2YgSW50 ZWdyaXR5IENoZWNrIFZhbHVlcyAoSUNWcykgYW5kIFRpbWVzdGFtcHMgaW4gSEVMTE8gbWVzc2Fn ZXMKPiAgIGluIG9yZGVyIHRvIHByb3ZpZGUgYSByb3V0ZXIgYWRtaXR0YW5jZSBtZWNoYW5pc20s IGFuZCB0aGVyZWZvcmUgdG8KPiAgIGNvdW50ZXIgYSBzZWxlY3Rpb24gb2Ygc2VjdXJpdHkgdGhy ZWF0cyB0byBOSERQLgo+Cj4KPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOgo+aHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLXNl Yy0wMi50eHQKPgo+SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Ogo+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8KPgo+VGhpcyBJ bnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0Ogo+ZnRwOi8vZnRwLmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dAo+Cj5UaGUgSUVU RiBkYXRhdHJhY2tlciBwYWdlIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOgo+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tYW5ldC1uaGRwLXNlYy8KPgo+Cj4K Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiAyCj5EYXRlOiBXZWQs IDMwIE1heSAyMDEyIDE1OjMzOjU3ICswNTMwCj5Gcm9tOiBtb2hkIG5hc2VlbSA8bW9oZG5hc2Vl bS5tY2FAZ21haWwuY29tPgo+VG86IG1hbmV0QGlldGYub3JnCj5TdWJqZWN0OiBbbWFuZXRdIHNv bWV0aGluZyBhYm91dCBhZCBob2Mgcm91dGVycwo+TWVzc2FnZS1JRDoKPgk8Q0FBSGRWWlQ1S0dl MkJBSGQ4aW91Y0dQK3JaSlJDM19iQ2JvcTdVVi1CaFM2Wm8weHJnQG1haWwuZ21haWwuY29tPgo+ Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSJpc28tODg1OS0xIgo+Cj5zaXIsIGkg d2FudCB0byBpbXBsZW1lbnQgbXkgd29yayBvbiBhZCBob2MgbmV0d29yaywgZm9yIHRoaXMgaSBo YXZlIHRvIGJ1eQo+YWQgaG9jIGRldmljZXMuIHBsZWFzZSB0ZWxsIHdoYXQgaSBoYXZlIHRvIGRv PyBuYW1lIG9mIGRldmljZT8KPi0tLS0tLS0tLS0tLS0tIG5leHQgcGFydCAtLS0tLS0tLS0tLS0t LQo+QW4gSFRNTCBhdHRhY2htZW50IHdhcyBzY3J1YmJlZC4uLgo+VVJMOiA8aHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hbmV0L2F0dGFjaG1lbnRzLzIwMTIwNTMwLzdlZGU3 NzYyL2F0dGFjaG1lbnQuaHRtPgo+Cj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+ TWVzc2FnZTogMwo+RGF0ZTogV2VkLCAzMCBNYXkgMjAxMiAxMjo0NToxMiArMDIwMAo+RnJvbTog QWJkdXNzYWxhbSBCYXJ5dW4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPgo+VG86IEpQIFZh c3NldXIgPGpwdkBjaXNjby5jb20+Cj5DYzogbWFuZXQgPG1hbmV0QGlldGYub3JnPgo+U3ViamVj dDogUmU6IFttYW5ldF0gRGlzY3Vzc2luZyBMT0FEbmcgc3VnZ2VzdGlvbnMKPk1lc3NhZ2UtSUQ6 Cj4JPENBRG5EWjgtWWdoZmRVQ1JMZi1GM2E5Qks1cTI1ZG5RUFpMX1pNX0d2Z1Roa0tXZGN6Z0Bt YWlsLmdtYWlsLmNvbT4KPkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1JU08tODg1 OS0xCj4KPk9uIDUvMjkvMTIsIEpQIFZhc3NldXIgPGpwdkBjaXNjby5jb20+IHdyb3RlOgo+Pgo+ PiBXZSBhbHJlYWR5IGhhdmUgdHdvIGRpZmZlcmVudCBXRzogTUFORVQgYW5kIFJPTEwuCj4+Cj4K PlllcyB3ZSBrbm93LiBUaGF0IGlzIHdoeSBMT0FEbmcgYXV0aG9ycyBzaG91bGQgY2hvb3NlIGVp dGhlciB0byBzZXJ2ZQo+TExOIHRoYXQgaXMgY29uc2lkZXJlZCBieSBST0xMIFdHIG9yIHRoZXkg Y2hvb3NlIHNlcnZpbmcgTUFORVQsIGFuZCBpdAo+aXMgY29uc2lkZXJlZCBieSBNQU5FVCBXRy4g QnV0IHRoZSBxdWVzdGlvbiBpcyB3aGljaCBzdWdnZXN0aW9uIG9wdGlvbgo+ZG8geW91IHRoaW5r IGlzIGJldHRlciBmb3IgTE9BRG5nLWRyYWZ0Pwo+Cj4+TUFORVQgaXMgdGFza2VkLCBhbW9uZ3N0 IG90aGVyLCB0byBwdWJsaXNoIGEgcmVhY3RpdmUKPj5yb3V0aW5nIHByb3RvY29sLgo+Cj5NQU5F VCBpcyB0YXNrZWQgdG8gcHVibGlzaCByb3V0aW5nIHByb3RvY29scyB0aGF0IHNlcnZlIHRoZSBN QU5FVAo+bmV0d29yay4gSU1PLCBNQU5FVC1XRyBpcyBub3QgdGFza2VkIHRvIHB1Ymxpc2ggcHJv dG9jb2xzIHNlcnZpbmcgb25seQo+TExOIGp1c3QgYmVjYXVzZSB0aGUgcHJvdG9jb2wgaXMgcmVh Y3RpdmUuIFBsZWFzZSBub3RlIHRoYXQgTE9BRG5nCj5wcm90b2NvbCBkb2VzIG5vdCBldmVuIG1l bnRpb24gTUFORVQgbm9yIG1vYmlsZSByb3V0ZXJzIGluIGl0cyBkcmFmdCwKPndoaWNoIGNvbmZ1 c2VzIGl0cyBwdXJwb3NlLCB0aGUgYXV0aG9ycyBzaG91bGQgbG9vayBpbnRvIHRoYXQuCj4KPkFi ZHVzc2FsYW0gQmFyeXVuCj4rKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrCj4+PiBJIGRpZCBub3QgdW5kZXJzdGFuZCB5b3VyIHJlZmVyaW5n IHRvIG1vdm1lbnQgd2l0aG91dCBtZW50aW9uaW5nIHRoYXQKPj4+IExPQURuZy1kcmFmdCBzcGVj aWZpZXMgdGhhdCBpdCBpcyBmb3IgTExOIChJIGRvIG5vdCBzZWUgaW4gZHJhZnQgYW55Cj4+PiBy ZWZlcmVuY2UgdG8gbW92ZW1lbnQgaW4gTE9BRG5nISkKPj4+Cj4+PiArKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+Pj4gVGhpcyBkaXN0aW5j dGlvbiBkb2VzIG5vdCBtYWtlIHNlbnNlLgo+Pj4KPj4+Cj4+PiBBZGhvYyBuZXR3b3JrcyBkZWFs IHdpdGggbGluayB0aGF0IGNhbiBmbHVjdHVhdGUgcXVpdGUgYSBsb3QuIEZvciBtb3N0Cj4+PiBw cm90b2NvbHMgYW5kIHJvdXRpbmcgbWV0cmljcyBpdCBkb2Vzbid0IG1hdHRlciBpZiB0aGlzIGhh cHBlbnMKPj4+IGJlY2F1c2Ugb2YgdGhlIG1ldHJpYywgdGhlIHJhZGlvIGVudmlyb25tZW50IG9y IG1vdmVtZW50IChleGNlcHRpb24KPj4+IGFyZSBwcm90b2NvbHMvbWV0cmljcyB0aGF0IGluY29y cG9yYXRlIGV4cGxpY2l0IGFsZ29yaXRobXMgZm9yCj4+PiBleHBsb2l0aW5nIGtub3dsZWRnZSBh Ym91dCBtb3ZlbWVudCBvciBldmVuIHRlcnJhaW4pLgo+Pj4KPj4+IEhlbm5pbmcgUm9nZ2UKPj4+ Cj4+PiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrCj4+Pgo+Pj4gT24gNS8yOS8xMiwgQWJkdXNzYWxhbSBCYXJ5dW4gPGFiZHVzc2FsYW1i YXJ5dW5AZ21haWwuY29tPiB3cm90ZToKPj4+PiBIaQo+Pj4+Cj4+Pj4gSSB0aGluayBhdCB0aGUg V0cgODMgbWVldGluZywgcmVnYXJkaW5nIExPQURuZyB0byBiZSBkaXNjdXNzZWQsIGFuZAo+Pj4+ IHRoYXQgdGhlIHN1Z2dlc3Rpb25zIHdlcmUgZWl0aGVyIG9mIHRoZSBmb2xsb3dpbmc6Cj4+Pj4K Pj4+PiAxLSB0byBhY2NvbW1vZGF0ZSBMT0FEbmcgZm9yIE1BTkVUIFdHLAo+Pj4+ICggc29tZSBw cmVmZXJlZCB0byBzZWUgTE9BRG5nIHBvc3NpYmx5IGFkYXB0ZWQgdG8gdGhlIE1BTkVUIHdvcmtp bmcKPj4+PiBncm91cCBhcyByZWFjdGl2ZSBwcm90b2NvbCB3aXRoIFJGQzU0NDQgY29tcGxpYW5j ZSksIG9yCj4+Pj4gMi0gdG8gbGVhdmUgTE9BRG5nIGZvciBMTE4gZ3JvdXAgdG8gbG9vayBhdCBp dCwgb3RoZXIgdGhhbiBNQU5FVCBXRywgb3IKPj4+PiAzLSB0byBqb2luIExPQURuZyBhdXRob3Jz IHdpdGggRFlNTyBhdXRob3JzIGluIG9uZSB3b3JrLgo+Pj4+Cj4+Pj4gSU1PIGl0IGlzIGludGVy ZXN0aW5nIHRvIGhhdmUgYSByZWFjdGl2ZSBNQU5FVCBwcm90b2NvbCB1c2luZyBSRkM1NDQ0Lgo+ Pj4+IFRoZXJlIGlzIG1vdGl2YXRpb24gdG8gdXNlIFJGQzU0NDQgZm9yIGludGVyb3BlcmFiaWxp dHkgYmV0d2Vlbgo+Pj4+IHJvdXRlcnMgYW5kIHNlY3VyaXR5IHB1cnBvc2VzLiBIb3dldmVyLCBM T0FEbmcgaXMgZm9yIGxvc3N5IGFkLWhvYwo+Pj4+IG5ldHdvcmtzIG1vcmUgdGhhbiBtb2JpbGUg YWQtaG9jIG5ldHMuIElmIGF1dGhvcnMgZGVjaWRlIExPQURuZyBpcyBmb3IKPj4+PiBMTE4gdGhl biB0aGV5IHNob3VsZCB0YWtlIGl0IHRvIExMTiBncm91cHMsIGJ1dCBpZiB0aGUgcHJvdG9jb2wg YW5kCj4+Pj4gZG9jdW1lbnQgaXMgbW9kaWZpZWQgaXQgY2FuIGJlIGFuIGFsdGVybmF0aXZlIE1B TkVUIHJlYWN0aXZlIHByb3RvY29sCj4+Pj4gdGhhdCBkaWZmZXJzIGZyb20gRFlNTy4gU28gSSBh Z3JlZSB0byBvcHRpb24tMSBtb3JlIHRoYW4gMiBkZXBlbmRpbmcKPj4+PiBvbiB0aGUgTE9BRG5n LWF1dGhvcnMnIHRob3VnaHRzLgo+Pj4+Cj4+Pj4gSXQgd2FzIG1lbnRpb25lZCBpbiB0aGUgbWVl dGluZyB0aGF0IERZTU8gYW5kIExPQURuZyBhcmUgY2xvc2UuIEkgZG8KPj4+PiBub3Qgc2VlIHRo YXQgdGhhdCBMT0FEbmcgYW5kIEFPRFZ2MiBhcmUgY2xvc2UgKHNvbWVvbmUgbWVudGlvbmVkIGlu IDgzCj4+Pj4gbWVldGluZyksIGJ1dCBMT0FEbmcgaXMgYSBSRkM1NDQ0LWJhc2VkIHJlYWN0aXZl IHByb3RvY29sIHRoYXQgaXMKPj4+PiBkZXJpdmVkIGZyb20gQU9EViBbUkZDMzU2MV0sIGl0IGZv Y3VzZXMgb24gbG93IHBvd2VyIGFuZCBsb3NzeSBuZXRzLAo+Pj4+IGJ1dCBEWU1PIGlzIGRlcml2 ZWQgZnJvbSBEU1IgYW5kIEFPRFYsIGFuZCBzbyBmYXIgZG9lcyBub3QgZnVsbHkgdXNlCj4+Pj4g UkZDNTQ0NC4KPj4+Pgo+Pj4+IFRoZSBzdWdnZXN0aW9uIG9wdGlvbiAzIG1heWJlIG5vdCBpbnRl cmVzdGluZyBpbiB0aGlzIHN0YWdlLCBiZWNhdXNlCj4+Pj4gdXN1YWxseSBpdCBpcyBiZXR0ZXIg ZGVjaWRlZCBieSB0aGUgYXV0aG9ycyBpZiB0aGV5IGxpa2UgdGhlIGpvaW4KPj4+PiB0aGVpciBk cmFmdHMgdG8gb25lLCBidXQgaXQgaXMgaW50ZXJlc3RpbmcgdG8gdGhlIFdHIHRvIGhhdmUKPj4+ PiBhbHRlcm5hdGl2ZXMgYW5kIHRoYXQgRFlNTyBhbmQgTE9BRG5nIGFyZSBub3Qgc2ltaWxhciBm dW5jdGlvbnMuIFNvIEkKPj4+PiBkaXNhZ3JlZSB3aXRoIG9wdGlvbi0zLgo+Pj4+Cj4+Pj4gSU1I TyB0aGF0IEFPRFZ2MiBkb2VzIG5vdCBpbnZvbHZlL3VzZSBzaW1pbGFyIG9mIExPQURuZywgYnV0 IGl0IGNhbgo+Pj4+IHVzZSBSRkM1NDQ0IGRpZmZlcmVudGx5IGZyb20gTE9BRG5nLCBvciB1c2Ug b25seSBSRkM1NDQ0IHRlY2huaXF1ZXMuCj4+Pj4gQWxzbyBMT0FEbmcgZG9lcyBub3QgdXNlIG11 Y2ggb2YgQU9EVi1SRkMzNTYxLCBidXQgaXQgY2FuIHVzZSBpdHMKPj4+PiByZWFjdGl2ZSB0ZWNo bmlxdWUgYWRkaW5nIHRvIGl0IGVuZXJneSBlZmZpY2llbmN5IHRlY2huaXF1ZXMuIExPQURuZwo+ Pj4+IGlzIGZvciBsb3cgcG93ZXIgcm91dGVycywgYnV0IHdoaWxlIHJlYWRpbmcgaXQgSSBhbSBu b3Qgc3VyZSBob3cgaXQKPj4+PiBzb2x2ZXMgdGhlIHBvd2VyLXByb2JsZW0uIEZ1cnRoZXJtb3Jl LCBMT0FEbmcgY2FuIGJlIHB1c2hlZCB0byBmb2N1cwo+Pj4+IG9uIGxvdy1wb3dlciBNQU5FVCBp bnN0ZWFkIG9mIExMTiwgaXQgbWF5IG9ubHkgaGF2ZSBsb3NzeSBsaW5rcywgbm90IGEKPj4+PiBs b3NzeSBuZXR3b3JrLiBJIHN1Z2dlc3QgdG8gcmVwbGFjZSAnTExOJyBpbiB0aGUgcHJvdG9jb2wg bmFtZSB0byAnCj4+Pj4gTG93LXBvd2VyJyB3aXRob3V0IGxvc3N5LW5ldCwgYW5kIHRvIG1ha2Ug aXRzIGZ1bmN0aW9ucyBjb25zaWRlcgo+Pj4+IG5ldHdvcmsgZW5lcmd5IGNvbnN1bXB0aW9ucy4K Pj4+Pgo+Pj4+IEFiZHVzc2FsYW0gQmFyeXVuCj4+Pj4gVW5pdmVyc2l0eSBvZiBHbGFtb3JnYW4s IFVLLgo+Pj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwo+Pj4gbWFuZXQgbWFpbGluZyBsaXN0Cj4+PiBtYW5ldEBpZXRmLm9yZwo+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldAo+Pgo+Pgo+Cj4KPi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj5NZXNzYWdlOiA0Cj5EYXRlOiBXZWQsIDMwIE1heSAy MDEyIDA1OjIxOjQwIC0wNzAwCj5Gcm9tOiBKUCBWYXNzZXVyIDxqcHZAY2lzY28uY29tPgo+VG86 IEFiZHVzc2FsYW0gQmFyeXVuIDxhYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT4KPkNjOiBtYW5l dCA8bWFuZXRAaWV0Zi5vcmc+Cj5TdWJqZWN0OiBSZTogW21hbmV0XSBEaXNjdXNzaW5nIExPQURu ZyBzdWdnZXN0aW9ucwo+TWVzc2FnZS1JRDogPDIwNDFFODNELTQwOTktNDQ3NS04RTlFLUI1NDg2 NUQ2OEEzNEBjaXNjby5jb20+Cj5Db250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMt YXNjaWkKPgo+Cj5PbiBNYXkgMzAsIDIwMTIsIGF0IDM6NDUgQU0sIEFiZHVzc2FsYW0gQmFyeXVu IHdyb3RlOgo+Cj4+IE9uIDUvMjkvMTIsIEpQIFZhc3NldXIgPGpwdkBjaXNjby5jb20+IHdyb3Rl Ogo+Pj4gCj4+PiBXZSBhbHJlYWR5IGhhdmUgdHdvIGRpZmZlcmVudCBXRzogTUFORVQgYW5kIFJP TEwuCj4+PiAKPj4gCj4+IFllcyB3ZSBrbm93LiBUaGF0IGlzIHdoeSBMT0FEbmcgYXV0aG9ycyBz aG91bGQgY2hvb3NlIGVpdGhlciB0byBzZXJ2ZQo+PiBMTE4gdGhhdCBpcyBjb25zaWRlcmVkIGJ5 IFJPTEwgV0cgb3IgdGhleSBjaG9vc2Ugc2VydmluZyBNQU5FVCwgYW5kIGl0Cj4+IGlzIGNvbnNp ZGVyZWQgYnkgTUFORVQgV0cuIEJ1dCB0aGUgcXVlc3Rpb24gaXMgd2hpY2ggc3VnZ2VzdGlvbiBv cHRpb24KPj4gZG8geW91IHRoaW5rIGlzIGJldHRlciBmb3IgTE9BRG5nLWRyYWZ0Pwo+PiAKPj4+ IE1BTkVUIGlzIHRhc2tlZCwgYW1vbmdzdCBvdGhlciwgdG8gcHVibGlzaCBhIHJlYWN0aXZlCj4+ PiByb3V0aW5nIHByb3RvY29sLgo+PiAKPj4gTUFORVQgaXMgdGFza2VkIHRvIHB1Ymxpc2ggcm91 dGluZyBwcm90b2NvbHMgdGhhdCBzZXJ2ZSB0aGUgTUFORVQKPj4gbmV0d29yay4gSU1PLCBNQU5F VC1XRyBpcyBub3QgdGFza2VkIHRvIHB1Ymxpc2ggcHJvdG9jb2xzIHNlcnZpbmcgb25seQo+PiBM TE4ganVzdCBiZWNhdXNlIHRoZSBwcm90b2NvbCBpcyByZWFjdGl2ZS4KPgo+SlA+IEkgYW0gY29t cGxldGVseSBzaGFyaW5nIHlvdXIgdmlldywgYnV0IHRoaXMgaXMgdXAgdG8gdGhlIE1BTkVUJ3Mg V0cgY2hhaXJzIG9mIGNvdXJzZS4KPgo+PiBQbGVhc2Ugbm90ZSB0aGF0IExPQURuZwo+PiBwcm90 b2NvbCBkb2VzIG5vdCBldmVuIG1lbnRpb24gTUFORVQgbm9yIG1vYmlsZSByb3V0ZXJzIGluIGl0 cyBkcmFmdCwKPj4gd2hpY2ggY29uZnVzZXMgaXRzIHB1cnBvc2UsIHRoZSBhdXRob3JzIHNob3Vs ZCBsb29rIGludG8gdGhhdC4KPj4gCj4+IEFiZHVzc2FsYW0gQmFyeXVuCj4+ICsrKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPj4+PiBJIGRp ZCBub3QgdW5kZXJzdGFuZCB5b3VyIHJlZmVyaW5nIHRvIG1vdm1lbnQgd2l0aG91dCBtZW50aW9u aW5nIHRoYXQKPj4+PiBMT0FEbmctZHJhZnQgc3BlY2lmaWVzIHRoYXQgaXQgaXMgZm9yIExMTiAo SSBkbyBub3Qgc2VlIGluIGRyYWZ0IGFueQo+Pj4+IHJlZmVyZW5jZSB0byBtb3ZlbWVudCBpbiBM T0FEbmchKQo+Pj4+IAo+Pj4+ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKysrKysrKysrKysrKysrCj4+Pj4gVGhpcyBkaXN0aW5jdGlvbiBkb2VzIG5vdCBtYWtlIHNl bnNlLgo+Pj4+IAo+Pj4+IAo+Pj4+IEFkaG9jIG5ldHdvcmtzIGRlYWwgd2l0aCBsaW5rIHRoYXQg Y2FuIGZsdWN0dWF0ZSBxdWl0ZSBhIGxvdC4gRm9yIG1vc3QKPj4+PiBwcm90b2NvbHMgYW5kIHJv dXRpbmcgbWV0cmljcyBpdCBkb2Vzbid0IG1hdHRlciBpZiB0aGlzIGhhcHBlbnMKPj4+PiBiZWNh dXNlIG9mIHRoZSBtZXRyaWMsIHRoZSByYWRpbyBlbnZpcm9ubWVudCBvciBtb3ZlbWVudCAoZXhj ZXB0aW9uCj4+Pj4gYXJlIHByb3RvY29scy9tZXRyaWNzIHRoYXQgaW5jb3Jwb3JhdGUgZXhwbGlj aXQgYWxnb3JpdGhtcyBmb3IKPj4+PiBleHBsb2l0aW5nIGtub3dsZWRnZSBhYm91dCBtb3ZlbWVu dCBvciBldmVuIHRlcnJhaW4pLgo+Pj4+IAo+Pj4+IEhlbm5pbmcgUm9nZ2UKPj4+PiAKPj4+PiAr KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr Cj4+Pj4gCj4+Pj4gT24gNS8yOS8xMiwgQWJkdXNzYWxhbSBCYXJ5dW4gPGFiZHVzc2FsYW1iYXJ5 dW5AZ21haWwuY29tPiB3cm90ZToKPj4+Pj4gSGkKPj4+Pj4gCj4+Pj4+IEkgdGhpbmsgYXQgdGhl IFdHIDgzIG1lZXRpbmcsIHJlZ2FyZGluZyBMT0FEbmcgdG8gYmUgZGlzY3Vzc2VkLCBhbmQKPj4+ Pj4gdGhhdCB0aGUgc3VnZ2VzdGlvbnMgd2VyZSBlaXRoZXIgb2YgdGhlIGZvbGxvd2luZzoKPj4+ Pj4gCj4+Pj4+IDEtIHRvIGFjY29tbW9kYXRlIExPQURuZyBmb3IgTUFORVQgV0csCj4+Pj4+ICgg c29tZSBwcmVmZXJlZCB0byBzZWUgTE9BRG5nIHBvc3NpYmx5IGFkYXB0ZWQgdG8gdGhlIE1BTkVU IHdvcmtpbmcKPj4+Pj4gZ3JvdXAgYXMgcmVhY3RpdmUgcHJvdG9jb2wgd2l0aCBSRkM1NDQ0IGNv bXBsaWFuY2UpLCBvcgo+Pj4+PiAyLSB0byBsZWF2ZSBMT0FEbmcgZm9yIExMTiBncm91cCB0byBs b29rIGF0IGl0LCBvdGhlciB0aGFuIE1BTkVUIFdHLCBvcgo+Pj4+PiAzLSB0byBqb2luIExPQURu ZyBhdXRob3JzIHdpdGggRFlNTyBhdXRob3JzIGluIG9uZSB3b3JrLgo+Pj4+PiAKPj4+Pj4gSU1P IGl0IGlzIGludGVyZXN0aW5nIHRvIGhhdmUgYSByZWFjdGl2ZSBNQU5FVCBwcm90b2NvbCB1c2lu ZyBSRkM1NDQ0Lgo+Pj4+PiBUaGVyZSBpcyBtb3RpdmF0aW9uIHRvIHVzZSBSRkM1NDQ0IGZvciBp bnRlcm9wZXJhYmlsaXR5IGJldHdlZW4KPj4+Pj4gcm91dGVycyBhbmQgc2VjdXJpdHkgcHVycG9z ZXMuIEhvd2V2ZXIsIExPQURuZyBpcyBmb3IgbG9zc3kgYWQtaG9jCj4+Pj4+IG5ldHdvcmtzIG1v cmUgdGhhbiBtb2JpbGUgYWQtaG9jIG5ldHMuIElmIGF1dGhvcnMgZGVjaWRlIExPQURuZyBpcyBm b3IKPj4+Pj4gTExOIHRoZW4gdGhleSBzaG91bGQgdGFrZSBpdCB0byBMTE4gZ3JvdXBzLCBidXQg aWYgdGhlIHByb3RvY29sIGFuZAo+Pj4+PiBkb2N1bWVudCBpcyBtb2RpZmllZCBpdCBjYW4gYmUg YW4gYWx0ZXJuYXRpdmUgTUFORVQgcmVhY3RpdmUgcHJvdG9jb2wKPj4+Pj4gdGhhdCBkaWZmZXJz IGZyb20gRFlNTy4gU28gSSBhZ3JlZSB0byBvcHRpb24tMSBtb3JlIHRoYW4gMiBkZXBlbmRpbmcK Pj4+Pj4gb24gdGhlIExPQURuZy1hdXRob3JzJyB0aG91Z2h0cy4KPj4+Pj4gCj4+Pj4+IEl0IHdh cyBtZW50aW9uZWQgaW4gdGhlIG1lZXRpbmcgdGhhdCBEWU1PIGFuZCBMT0FEbmcgYXJlIGNsb3Nl LiBJIGRvCj4+Pj4+IG5vdCBzZWUgdGhhdCB0aGF0IExPQURuZyBhbmQgQU9EVnYyIGFyZSBjbG9z ZSAoc29tZW9uZSBtZW50aW9uZWQgaW4gODMKPj4+Pj4gbWVldGluZyksIGJ1dCBMT0FEbmcgaXMg YSBSRkM1NDQ0LWJhc2VkIHJlYWN0aXZlIHByb3RvY29sIHRoYXQgaXMKPj4+Pj4gZGVyaXZlZCBm cm9tIEFPRFYgW1JGQzM1NjFdLCBpdCBmb2N1c2VzIG9uIGxvdyBwb3dlciBhbmQgbG9zc3kgbmV0 cywKPj4+Pj4gYnV0IERZTU8gaXMgZGVyaXZlZCBmcm9tIERTUiBhbmQgQU9EViwgYW5kIHNvIGZh ciBkb2VzIG5vdCBmdWxseSB1c2UKPj4+Pj4gUkZDNTQ0NC4KPj4+Pj4gCj4+Pj4+IFRoZSBzdWdn ZXN0aW9uIG9wdGlvbiAzIG1heWJlIG5vdCBpbnRlcmVzdGluZyBpbiB0aGlzIHN0YWdlLCBiZWNh dXNlCj4+Pj4+IHVzdWFsbHkgaXQgaXMgYmV0dGVyIGRlY2lkZWQgYnkgdGhlIGF1dGhvcnMgaWYg dGhleSBsaWtlIHRoZSBqb2luCj4+Pj4+IHRoZWlyIGRyYWZ0cyB0byBvbmUsIGJ1dCBpdCBpcyBp bnRlcmVzdGluZyB0byB0aGUgV0cgdG8gaGF2ZQo+Pj4+PiBhbHRlcm5hdGl2ZXMgYW5kIHRoYXQg RFlNTyBhbmQgTE9BRG5nIGFyZSBub3Qgc2ltaWxhciBmdW5jdGlvbnMuIFNvIEkKPj4+Pj4gZGlz YWdyZWUgd2l0aCBvcHRpb24tMy4KPj4+Pj4gCj4+Pj4+IElNSE8gdGhhdCBBT0RWdjIgZG9lcyBu b3QgaW52b2x2ZS91c2Ugc2ltaWxhciBvZiBMT0FEbmcsIGJ1dCBpdCBjYW4KPj4+Pj4gdXNlIFJG QzU0NDQgZGlmZmVyZW50bHkgZnJvbSBMT0FEbmcsIG9yIHVzZSBvbmx5IFJGQzU0NDQgdGVjaG5p cXVlcy4KPj4+Pj4gQWxzbyBMT0FEbmcgZG9lcyBub3QgdXNlIG11Y2ggb2YgQU9EVi1SRkMzNTYx LCBidXQgaXQgY2FuIHVzZSBpdHMKPj4+Pj4gcmVhY3RpdmUgdGVjaG5pcXVlIGFkZGluZyB0byBp dCBlbmVyZ3kgZWZmaWNpZW5jeSB0ZWNobmlxdWVzLiBMT0FEbmcKPj4+Pj4gaXMgZm9yIGxvdyBw b3dlciByb3V0ZXJzLCBidXQgd2hpbGUgcmVhZGluZyBpdCBJIGFtIG5vdCBzdXJlIGhvdyBpdAo+ Pj4+PiBzb2x2ZXMgdGhlIHBvd2VyLXByb2JsZW0uIEZ1cnRoZXJtb3JlLCBMT0FEbmcgY2FuIGJl IHB1c2hlZCB0byBmb2N1cwo+Pj4+PiBvbiBsb3ctcG93ZXIgTUFORVQgaW5zdGVhZCBvZiBMTE4s IGl0IG1heSBvbmx5IGhhdmUgbG9zc3kgbGlua3MsIG5vdCBhCj4+Pj4+IGxvc3N5IG5ldHdvcmsu IEkgc3VnZ2VzdCB0byByZXBsYWNlICdMTE4nIGluIHRoZSBwcm90b2NvbCBuYW1lIHRvICcKPj4+ Pj4gTG93LXBvd2VyJyB3aXRob3V0IGxvc3N5LW5ldCwgYW5kIHRvIG1ha2UgaXRzIGZ1bmN0aW9u cyBjb25zaWRlcgo+Pj4+PiBuZXR3b3JrIGVuZXJneSBjb25zdW1wdGlvbnMuCj4+Pj4+IAo+Pj4+ PiBBYmR1c3NhbGFtIEJhcnl1bgo+Pj4+PiBVbml2ZXJzaXR5IG9mIEdsYW1vcmdhbiwgVUsuCj4+ Pj4+IAo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4+Pj4gbWFuZXQgbWFpbGluZyBsaXN0Cj4+Pj4gbWFuZXRAaWV0Zi5vcmcKPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Cj4+PiAKPj4+IAo+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+PiBtYW5ldCBtYWlsaW5n IGxpc3QKPj4gbWFuZXRAaWV0Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9tYW5ldAo+Cj4KPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPk1l c3NhZ2U6IDUKPkRhdGU6IFdlZCwgMzAgTWF5IDIwMTIgMTM6MDY6MjkgKzAwMDAKPkZyb206ICJE ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSIgPENocmlzLkRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t Pgo+VG86ICJtYW5ldEBpZXRmLm9yZyIgPG1hbmV0QGlldGYub3JnPgo+Q2M6ICJUaG9tYXMJSGVp ZGUgQ2xhdXNlbiBcKHRob21hc0B0aG9tYXNjbGF1c2VuLm9yZ1wpIgo+CTx0aG9tYXNAdGhvbWFz Y2xhdXNlbi5vcmc+Cj5TdWJqZWN0OiBSZTogW21hbmV0XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LW1hbmV0LW5oZHAtc2VjLTAyLnR4dAo+TWVzc2FnZS1JRDoKPgk8QjMxRUVERERCOEVEN0U0QTkz RkRGMTJBNEVFQ0QzMEQxMkNFM0VAR0xLWE0wMDAyVi5HUkVFTkxOSy5uZXQ+Cj5Db250ZW50LVR5 cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9aXNvLTg4NTktMQo+Cj4KPgo+LS0gCj5DaHJpc3RvcGhl ciBEZWFybG92ZQo+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwgQ29tbXVuaWNhdGlvbnMgR3Jv dXAKPkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2UgQW5hbHlzaXMgQ2FwYWJpbGl0 eQo+QkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50cmUKPldlc3QgSGFubmluZ2Zp ZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00yIDhITiwgVUsKPlRlbDogKzQ0 IDEyNDUgMjQyMTk0P3wgIEZheDogKzQ0IDEyNDUgMjQyMTI0Cj5jaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20KPgo+QkFFIFN5c3RlbXMgKE9w ZXJhdGlvbnMpIExpbWl0ZWQKPlJlZ2lzdGVyZWQgT2ZmaWNlOiBXYXJ3aWNrIEhvdXNlLCBQTyBC b3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZhcm5ib3JvdWdoLCBIYW50cywg R1UxNCA2WVUsIFVLCj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMTk5NjY4Nwo+ Cj4KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj5Gcm9tOiBtYW5ldC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZwo+U2VudDogMzAgTWF5IDIwMTIgMDE6MDQKPlRvOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcKPkNjOiBtYW5ldEBpZXRmLm9yZwo+U3ViamVjdDogW21hbmV0XSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dAo+QXMgSSByZWFkIGl0LCB0aGlz IGRyYWZ0IGlzIHByb3Bvc2luZyB1c2luZyB0aGUgUkZDIDY2MjIgbWVjaGFuaXNtIHRvIHNpZ24g SEVMTE8gbWVzc2FnZXMuIFJGQyA2NjIyIGFjdHVhbGx5IGFsbG93cyBmb3Igc2lnbmluZyBwYWNr ZXRzIGFzIHdlbGwgYXMgc2lnbmluZyBtZXNzYWdlcyAoYm90aCwgZWl0aGVyLCBvciBuZWl0aGVy IHRvIGJlIHVzZWQgYXMgcmVxdWlyZWQpLiBUaGVyZSBpc24ndCBhIG1ham9yIGRpZmZlcmVuY2Ug d2hlbiBjb25zaWRlcmluZyBIRUxMTyBtZXNzYWdlcywgYXMgZmV3IGlmIGFueSBwYWNrZXRzIHdp bGwgY29udGFpbiBtb3JlIHRoYW4gb25lIEhFTExPIG1lc3NhZ2UsIGFuZCB0aGUgcGFja2V0IGFu ZCB0aGUgbWVzc2FnZSB3aWxsIGJlIHNpZ25lZCBieSB0aGUgc2FtZSBwYXJ0eS4KPgo+SG93ZXZl ciBOSERQIGRvZXNuJ3QgZXhpc3QgaW4gYSB2YWN1dW0sIGluIHBhcnRpY3VsYXIgaXQgaXMgdXNl ZCBieSBPTFNSdjIuIEFueSBzZWN1cml0eSBtZWNoYW5pc20gdGhhdCBpcyBkZXNjcmliZWQgaW4g d2hhdCB3aWxsIGJlIGFuIFJGQyBmb3IgTkhEUCBtdXN0IGFsc28gYmUgd2hhdCdzIHJpZ2h0IGZv ciBOSERQIGFzIHVzZWQgYnkgT0xTUnYyLiBPTFNSdjIgYWxzbyBoYXMgVEMgbWVzc2FnZXMgdG8g Y29uc2lkZXIsIGFuZCB0aGV5IGRvbid0IHNhdGlzZnkgdGhlIHBvaW50cyBub3RlZCBhYm92ZSAo b24gbnVtYmVyIG9yIG9uIHdobyBzaWducyB0aGVtKS4gQW5kIG9uZSBvcHRpb24gZm9yIE9MU1J2 MiBpcyB0byBzaWduIGFsbCBwYWNrZXRzLCBub3QgbWVzc2FnZXMuIFRoaXMgY2FuIGJlIGEgc2Vu c2libGUgZGVjaXNpb24gdGhlcmUsIGZvciBzZXZlcmFsIHJlYXNvbnMsIGluIHNvbWUgcmVhbCBj aXJjdW1zdGFuY2VzLgo+Cj5Db25zZXF1ZW50bHksIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoaXMg ZHJhZnQgc2hvdWxkIGRlc2NyaWJlIG9ubHkgc2lnbmluZyBIRUxMTyBtZXNzYWdlcyBhcyB0aGUg Y29ycmVjdCB0aGluZyB0byBkbywgdGhhdCBpdCBzaG91bGQgYWxzbyBhbGxvdyBzaWduaW5nIHBh Y2tldHMgYXMgYW4gZXF1YWwgc3RhdHVzIG9wdGlvbi4gSWYgc29tZW9uZSB3YW50cyB0byByYWlz ZSB0aGUgcG9zc2liaWxpdHkgb2Ygc2lnbmluZyAocG9zc2libHkgYnkgbWV0aG9kcyB3aXRoIGRp ZmZlcmVudCBwcm9wZXJ0aWVzKSBib3RoIGF0IHRoZSBtZXNzYWdlIGFuZCBwYWNrZXQgbGV2ZWws IHRoYXQgbWF5IGhhdmUgaXRzIHVzZSBjYXNlcyB0b28uCj4KPkluY2lkZW50YWxseSwgZXZlbiB3 aXRoaW4gdGhlIGxpbWl0ZWQgZnJhbWV3b3JrIG9mIGp1c3QgTkhEUCwgaXQgaXMgcG9zc2libGUg dGhhdCBwYWNrZXRzIG5lZWQgcHJvdGVjdGlvbi4gSWYgYW4gTkhEUCBpbXBsZW1lbnRhdGlvbiBj aG9vc2VzIHRvIHVzZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIGFzIHBhcnQgb2YgaXRzIGxpbmsg cXVhbGl0eSBtZWNoYW5pc20sIGFzIGl0IG1heSwgdGhlbiBhbiB1bnByb3RlY3RlZCBwYWNrZXQg aGVhZGVyIGlzIGEgdnVsbmVyYWJpbGl0eS4KPgo+KEZvciB0aGUgc2FrZSBvZiBjb21wbGV0ZW5l c3MsIFJGQyA2NjIyIGFsc28gYWxsb3dzIGFkZHJlc3MgYmxvY2sgc2lnbmF0dXJlcy4gSSBkb24n dCBoYXZlIGEgcmVhc29uIHRvIHN1Z2dlc3QgdXNpbmcgdGhpcyB3aXRoaW4gTkhEUCBvciBPTFNS djIuKQo+Cj4KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tCj5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2Fu aXNhdGlvbiwKPmVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50 ZXJuZXQuCj5LZWVwIHRoaXMgaW4gbWluZCBpZiB5b3UgYW5zd2VyIHRoaXMgbWVzc2FnZS4KPkZv bGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzCj5m b3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLgo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pgo+QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBNb2JpbGUgQWQtaG9jIE5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuCj4KPglU aXRsZSAgICAgICAgICAgOiBVc2luZyBJbnRlZ3JpdHkgQ2hlY2sgVmFsdWVzIGFuZCBUaW1lc3Rh bXBzIEZvciBSb3V0ZXIgQWRtaXR0YW5jZSBpbiBOSERQCj4JQXV0aG9yKHMpICAgICAgIDogVWxy aWNoIEhlcmJlcmcKPiAgICAgICAgICAgICAgICAgICAgICAgICAgVGhvbWFzIEhlaWRlIENsYXVz ZW4KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAyLnR4dAo+ CVBhZ2VzICAgICAgICAgICA6IDEyCj4JRGF0ZSAgICAgICAgICAgIDogMjAxMi0wNS0yOQo+Cj4g ICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHNlY3VyaXR5IGV4dGVuc2lvbiB0byB0aGUgTUFO RVQKPiAgIE5laWdoYm9yaG9vZCBEaXNjb3ZlcnkgUHJvdG9jb2wgKE5IRFApLiAgVGhlIGV4dGVu c2lvbiBpbnRyb2R1Y2VzIHRoZQo+ICAgdXNlIG9mIEludGVncml0eSBDaGVjayBWYWx1ZXMgKElD VnMpIGFuZCBUaW1lc3RhbXBzIGluIEhFTExPIG1lc3NhZ2VzCj4gICBpbiBvcmRlciB0byBwcm92 aWRlIGEgcm91dGVyIGFkbWl0dGFuY2UgbWVjaGFuaXNtLCBhbmQgdGhlcmVmb3JlIHRvCj4gICBj b3VudGVyIGEgc2VsZWN0aW9uIG9mIHNlY3VyaXR5IHRocmVhdHMgdG8gTkhEUC4KPgo+Cj5BIFVS TCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoKPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0Cj4KPkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoKPmZ0cDovL2Z0cC5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4KPlRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJl dHJpZXZlZCBhdDoKPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0 Zi1tYW5ldC1uaGRwLXNlYy0wMi50eHQKPgo+VGhlIElFVEYgZGF0YXRyYWNrZXIgcGFnZSBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczoKPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMvCj4KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj5tYW5ldCBtYWlsaW5nIGxpc3QKPm1hbmV0QGlldGYub3Jn Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0Cj4KPgo+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKPlRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRv IHRoZSBpbnRlbmRlZAo+cmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKPnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20g eW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgo+WW91IHNob3VsZCBub3QgY29weSBp dCBvciB1c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcgo+ZGlzdHJpYnV0ZSBp dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KPioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCj4KPgo+Cj4tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+TWVzc2FnZTogNgo+RGF0ZTogV2VkLCAzMCBN YXkgMjAxMiAxMzoyMTo0NiArMDAwMAo+RnJvbTogIkRlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp IiA8Q2hyaXMuRGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+Cj5UbzogIm1hbmV0QGlldGYub3JnIiA8 bWFuZXRAaWV0Zi5vcmc+Cj5DYzogIlRob21hcwlIZWlkZSBDbGF1c2VuIFwodGhvbWFzQHRob21h c2NsYXVzZW4ub3JnXCkiCj4JPHRob21hc0B0aG9tYXNjbGF1c2VuLm9yZz4KPlN1YmplY3Q6IFJl OiBbbWFuZXRdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0Cj5N ZXNzYWdlLUlEOgo+CTxCMzFFRUREREI4RUQ3RTRBOTNGREYxMkE0RUVDRDMwRDEyQ0U3M0BHTEtY TTAwMDJWLkdSRUVOTE5LLm5ldD4KPkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD1p c28tODg1OS0xCj4KPihTZW5kaW5nIGFnYWluLCB0byBzb3J0IG91dCB0aGUgZm9ybWF0dGluZyBw cm9ibGVtIHdpdGggdGhlIGxhc3QgYXR0ZW1wdC4pCj4KPkFzIEkgcmVhZCBpdCwgdGhpcyBkcmFm dCBpcyBwcm9wb3NpbmcgdXNpbmcgdGhlIFJGQyA2NjIyIG1lY2hhbmlzbSB0byBzaWduIEhFTExP IG1lc3NhZ2VzLiBSRkMgNjYyMiBhY3R1YWxseSBhbGxvd3MgZm9yIHNpZ25pbmcgcGFja2V0cyBh cyB3ZWxsIGFzIHNpZ25pbmcgbWVzc2FnZXMgKGJvdGgsIGVpdGhlciwgb3IgbmVpdGhlciB0byBi ZSB1c2VkIGFzIHJlcXVpcmVkKS4gVGhlcmUgaXNuJ3QgYSBtYWpvciBkaWZmZXJlbmNlIHdoZW4g Y29uc2lkZXJpbmcgSEVMTE8gbWVzc2FnZXMsIGFzIGZldyBpZiBhbnkgcGFja2V0cyB3aWxsIGNv bnRhaW4gbW9yZSB0aGFuIG9uZSBIRUxMTyBtZXNzYWdlLCBhbmQgdGhlIHBhY2tldCBhbmQgdGhl IG1lc3NhZ2Ugd2lsbCBiZSBzaWduZWQgYnkgdGhlIHNhbWUgcGFydHkuCj4KPkhvd2V2ZXIgTkhE UCBkb2Vzbid0IGV4aXN0IGluIGEgdmFjdXVtLCBpbiBwYXJ0aWN1bGFyIGl0IGlzIHVzZWQgYnkg T0xTUnYyLiBBbnkgc2VjdXJpdHkgbWVjaGFuaXNtIHRoYXQgaXMgZGVzY3JpYmVkIGluIHdoYXQg d2lsbCBiZSBhbiBSRkMgZm9yIE5IRFAgbXVzdCBhbHNvIGJlIHdoYXQncyByaWdodCBmb3IgTkhE UCBhcyB1c2VkIGJ5IE9MU1J2Mi4gT0xTUnYyIGFsc28gaGFzIFRDIG1lc3NhZ2VzIHRvIGNvbnNp ZGVyLCBhbmQgdGhleSBkb24ndCBzYXRpc2Z5IHRoZSBwb2ludHMgbm90ZWQgYWJvdmUgKG9uIG51 bWJlciBvciBvbiB3aG8gc2lnbnMgdGhlbSkuIEFuZCBvbmUgb3B0aW9uIGZvciBPTFNSdjIgaXMg dG8gc2lnbiBhbGwgcGFja2V0cywgbm90IG1lc3NhZ2VzLiBUaGlzIGNhbiBiZSBhIHNlbnNpYmxl IGRlY2lzaW9uIHRoZXJlLCBmb3Igc2V2ZXJhbCByZWFzb25zLCBpbiBzb21lIHJlYWwgY2lyY3Vt c3RhbmNlcy4KPgo+Q29uc2VxdWVudGx5LCBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGlzIGRyYWZ0 IHNob3VsZCBkZXNjcmliZSBvbmx5IHNpZ25pbmcgSEVMTE8gbWVzc2FnZXMgYXMgdGhlIGNvcnJl Y3QgdGhpbmcgdG8gZG8sIHRoYXQgaXQgc2hvdWxkIGFsc28gYWxsb3cgc2lnbmluZyBwYWNrZXRz IGFzIGFuIGVxdWFsIHN0YXR1cyBvcHRpb24uIElmIHNvbWVvbmUgd2FudHMgdG8gcmFpc2UgdGhl IHBvc3NpYmlsaXR5IG9mIHNpZ25pbmcgKHBvc3NpYmx5IGJ5IG1ldGhvZHMgd2l0aCBkaWZmZXJl bnQgcHJvcGVydGllcykgYm90aCBhdCB0aGUgbWVzc2FnZSBhbmQgcGFja2V0IGxldmVsLCB0aGF0 IG1heSBoYXZlIGl0cyB1c2UgY2FzZXMgdG9vLgo+Cj5JbmNpZGVudGFsbHksIGV2ZW4gd2l0aGlu IHRoZSBsaW1pdGVkIGZyYW1ld29yayBvZiBqdXN0IE5IRFAsIGl0IGlzIHBvc3NpYmxlIHRoYXQg cGFja2V0cyBuZWVkIHByb3RlY3Rpb24uIElmIGFuIE5IRFAgaW1wbGVtZW50YXRpb24gY2hvb3Nl cyB0byB1c2UgcGFja2V0IHNlcXVlbmNlIG51bWJlciBhcyBwYXJ0IG9mIGl0cyBsaW5rIHF1YWxp dHkgbWVjaGFuaXNtLCBhcyBpdCBtYXksIHRoZW4gYW4gdW5wcm90ZWN0ZWQgcGFja2V0IGhlYWRl ciBpcyBhIHZ1bG5lcmFiaWxpdHkuCj4KPihGb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzLCBS RkMgNjYyMiBhbHNvIGFsbG93cyBhZGRyZXNzIGJsb2NrIHNpZ25hdHVyZXMuIEkgZG9uJ3QgaGF2 ZSBhIHJlYXNvbiB0byBzdWdnZXN0IHVzaW5nIHRoaXMgd2l0aGluIE5IRFAgb3IgT0xTUnYyLikK Pgo+LS0gCj5DaHJpc3RvcGhlciBEZWFybG92ZQo+U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlciwg Q29tbXVuaWNhdGlvbnMgR3JvdXAKPkNvbW11bmljYXRpb25zLCBOZXR3b3JrcyBhbmQgSW1hZ2Ug QW5hbHlzaXMgQ2FwYWJpbGl0eQo+QkFFIFN5c3RlbXMgQWR2YW5jZWQgVGVjaG5vbG9neSBDZW50 cmUKPldlc3QgSGFubmluZ2ZpZWxkIFJvYWQsIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgQ00y IDhITiwgVUsKPlRlbDogKzQ0IDEyNDUgMjQyMTk0P3wgIEZheDogKzQ0IDEyNDUgMjQyMTI0Cj5j aHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSB8IGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20K Pgo+QkFFIFN5c3RlbXMgKE9wZXJhdGlvbnMpIExpbWl0ZWQKPlJlZ2lzdGVyZWQgT2ZmaWNlOiBX YXJ3aWNrIEhvdXNlLCBQTyBCb3ggODcsIEZhcm5ib3JvdWdoIEFlcm9zcGFjZSBDZW50cmUsIEZh cm5ib3JvdWdoLCBIYW50cywgR1UxNCA2WVUsIFVLCj5SZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBX YWxlcyBObzogMTk5NjY4Nwo+Cj4KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgTW9iaWxlIEFkLWhvYyBOZXR3b3JrcyBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLgo+Cj4JVGl0bGUgICAgICAgICAgIDogVXNpbmcgSW50ZWdyaXR5IENoZWNr IFZhbHVlcyBhbmQgVGltZXN0YW1wcyBGb3IgUm91dGVyIEFkbWl0dGFuY2UgaW4gTkhEUAo+CUF1 dGhvcihzKSAgICAgICA6IFVscmljaCBIZXJiZXJnCj4gICAgICAgICAgICAgICAgICAgICAgICAg IFRob21hcyBIZWlkZSBDbGF1c2VuCj4JRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1tYW5l dC1uaGRwLXNlYy0wMi50eHQKPglQYWdlcyAgICAgICAgICAgOiAxMgo+CURhdGUgICAgICAgICAg ICA6IDIwMTItMDUtMjkKPgo+ICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSBzZWN1cml0eSBl eHRlbnNpb24gdG8gdGhlIE1BTkVUCj4gICBOZWlnaGJvcmhvb2QgRGlzY292ZXJ5IFByb3RvY29s IChOSERQKS4gIFRoZSBleHRlbnNpb24gaW50cm9kdWNlcyB0aGUKPiAgIHVzZSBvZiBJbnRlZ3Jp dHkgQ2hlY2sgVmFsdWVzIChJQ1ZzKSBhbmQgVGltZXN0YW1wcyBpbiBIRUxMTyBtZXNzYWdlcwo+ ICAgaW4gb3JkZXIgdG8gcHJvdmlkZSBhIHJvdXRlciBhZG1pdHRhbmNlIG1lY2hhbmlzbSwgYW5k IHRoZXJlZm9yZSB0bwo+ICAgY291bnRlciBhIHNlbGVjdGlvbiBvZiBzZWN1cml0eSB0aHJlYXRz IHRvIE5IRFAuCj4KPgo+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6Cj5odHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLTAy LnR4dAo+Cj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6Cj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLwo+Cj5UaGlzIEludGVy bmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6Cj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtbWFuZXQtbmhkcC1zZWMtMDIudHh0Cj4KPlRoZSBJRVRGIGRh dGF0cmFja2VyIHBhZ2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6Cj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1hbmV0LW5oZHAtc2VjLwo+Cj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+bWFuZXQgbWFpbGluZyBs aXN0Cj5tYW5ldEBpZXRmLm9yZwo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tYW5ldAo+Cj4KPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqCj5UaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKPnJlY2lwaWVudCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkCj5yZWNpcGllbnQgcGxl YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4KPllv dSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xv c2Ugb3IKPmRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCj4qKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgo+Cj4KPgo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4KPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj5tYW5ldCBtYWlsaW5nIGxp c3QKPm1hbmV0QGlldGYub3JnCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21hbmV0Cj4KPgo+RW5kIG9mIG1hbmV0IERpZ2VzdCwgVm9sIDk2LCBJc3N1ZSAyNwo+KioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgo= From ulrich@herberg.name Wed May 30 09:53: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 40D3911E80A4 for ; Wed, 30 May 2012 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.510, 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 mghjaZ8TVOPg for ; Wed, 30 May 2012 09:53:54 -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 1EFD311E8083 for ; Wed, 30 May 2012 09:53:54 -0700 (PDT) Received: by qabj40 with SMTP id j40so175580qab.15 for ; Wed, 30 May 2012 09:53:53 -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=C2fRhA9psevxD4u3peUgOsj+lWB1nuLz6hAGTYYzF24=; b=HtS88RoCsVnJPY0em1DE2rnz1GEs8YfN6YmvorNSo6q35syGTxmGAJjjRdbyPRKS2N lS5beZXWUPR/mbyiJB+j2vvf7vGhKMqpV+n7Cpp8LnYoZNM91X6hrExUAur0MBACEr9G s0BihxH2ORl5ZzirkU+vsSUpgAn7aox7WxLIc= 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=C2fRhA9psevxD4u3peUgOsj+lWB1nuLz6hAGTYYzF24=; b=g89UMKdlxUDwuYQI9sd+iv6El7dM00q2XoL+Xksy8iJEFJCZo4osP0mjL4ALpJnz1x vqy3r8ctAJPjPQeZqtMo+ryrQgjZpQJBW5bSx4w7aGlW4qz3bPSsEdjfk17XYPlfFr7z B+N9gtGylhjrj4QYEfvvGiiN+5GLEi45EXNtSD7QVDFu82y6GMizs7W0sINQL15tm8KR laY40y/470SHYZB0fMnXACyxPG+4CRwuo57T6Uv/5Y+LLCglF0fENQenutiCxZGSuXR2 ExAzIzuyN/eP1U+qozft4+5aC4YKwrfc4pt5atcN1zQimIHlLQGpFZNjDA3d9kEJ/xlz 83cg== MIME-Version: 1.0 Received: by 10.224.184.1 with SMTP id ci1mr14342812qab.97.1338396833494; Wed, 30 May 2012 09:53:53 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Wed, 30 May 2012 09:53:53 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 May 2012 09:53:53 -0700 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl3bLgGqq2lFrssZKRdwy8kVyrJODi0yVB2l0kS4eV27UwGnQoECgJF8/UiHveOQEh0j10q Cc: manet Subject: Re: [manet] Discussing LOADng suggestions 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, 30 May 2012 16:53:55 -0000 Abdussalam, we are aware that the LOADng draft needs some updates, before it could be considered by the MANET WG, notably support for RFC5444 and some editorial updates. We plan to work on these in the next days, and will submit a new revision likely next week. So, just stay tuned! Best Ulrich On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun wrote: > On 5/29/12, JP Vasseur wrote: >> >> We already have two different WG: MANET and ROLL. >> > > Yes we know. That is why LOADng authors should choose either to serve > LLN that is considered by ROLL WG or they choose serving MANET, and it > is considered by MANET WG. But the question is which suggestion option > do you think is better for LOADng-draft? > >>MANET is tasked, amongst other, to publish a reactive >>routing protocol. > > MANET is tasked to publish routing protocols that serve the MANET > network. IMO, MANET-WG is not tasked to publish protocols serving only > LLN just because the protocol is reactive. Please note that LOADng > protocol does not even mention MANET nor mobile routers in its draft, > which confuses its purpose, the authors should look into that. > > Abdussalam Baryun > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> I did not understand your refering to movment without mentioning that >>> LOADng-draft specifies that it is for LLN (I do not see in draft any >>> reference to movement in LOADng!) >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> This distinction does not make sense. >>> >>> >>> Adhoc networks deal with link that can fluctuate quite a lot. For most >>> protocols and routing metrics it doesn't matter if this happens >>> because of the metric, the radio environment or movement (exception >>> are protocols/metrics that incorporate explicit algorithms for >>> exploiting knowledge about movement or even terrain). >>> >>> Henning Rogge >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> On 5/29/12, Abdussalam Baryun wrote: >>>> Hi >>>> >>>> I think at the WG 83 meeting, regarding LOADng to be discussed, and >>>> that the suggestions were either of the following: >>>> >>>> 1- to accommodate LOADng for MANET WG, >>>> ( some prefered to see LOADng possibly adapted to the MANET working >>>> group as reactive protocol with RFC5444 compliance), or >>>> 2- to leave LOADng for LLN group to look at it, other than MANET WG, or >>>> 3- to join LOADng authors with DYMO authors in one work. >>>> >>>> IMO it is interesting to have a reactive MANET protocol using RFC5444. >>>> There is motivation to use RFC5444 for interoperability between >>>> routers and security purposes. However, LOADng is for lossy ad-hoc >>>> networks more than mobile ad-hoc nets. If authors decide LOADng is for >>>> LLN then they should take it to LLN groups, but if the protocol and >>>> document is modified it can be an alternative MANET reactive protocol >>>> that differs from DYMO. So I agree to option-1 more than 2 depending >>>> on the LOADng-authors' thoughts. >>>> >>>> It was mentioned in the meeting that DYMO and LOADng are close. I do >>>> not see that that LOADng and AODVv2 are close (someone mentioned in 83 >>>> meeting), but LOADng is a RFC5444-based reactive protocol that is >>>> derived from AODV [RFC3561], it focuses on low power and lossy nets, >>>> but DYMO is derived from DSR and AODV, and so far does not fully use >>>> RFC5444. >>>> >>>> The suggestion option 3 maybe not interesting in this stage, because >>>> usually it is better decided by the authors if they like the join >>>> their drafts to one, but it is interesting to the WG to have >>>> alternatives and that DYMO and LOADng are not similar functions. So I >>>> disagree with option-3. >>>> >>>> IMHO that AODVv2 does not involve/use similar of LOADng, but it can >>>> use RFC5444 differently from LOADng, or use only RFC5444 techniques. >>>> Also LOADng does not use much of AODV-RFC3561, but it can use its >>>> reactive technique adding to it energy efficiency techniques. LOADng >>>> is for low power routers, but while reading it I am not sure how it >>>> solves the power-problem. Furthermore, LOADng can be pushed to focus >>>> on low-power MANET instead of LLN, it may only have lossy links, not a >>>> lossy network. I suggest to replace 'LLN' in the protocol name to ' >>>> Low-power' without lossy-net, and to make its functions consider >>>> network energy consumptions. >>>> >>>> Abdussalam Baryun >>>> University of Glamorgan, UK. >>>> >>> _______________________________________________ >>> 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 charliep@computer.org Wed May 30 12:12: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 3A17E11E8113 for ; Wed, 30 May 2012 12:12:23 -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 1dqi011s-b5Z for ; Wed, 30 May 2012 12:12:22 -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 8233811E80C5 for ; Wed, 30 May 2012 12:12:22 -0700 (PDT) Received: from [12.207.18.42] (helo=[192.168.255.187]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1SZoJg-0002hr-3t; Wed, 30 May 2012 15:12:22 -0400 Message-ID: <4FC67102.50903@computer.org> Date: Wed, 30 May 2012 12:12: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: Abdussalam Baryun References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86af33fc3464d9e72fc8410c5427379775350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.207.18.42 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 30 May 2012 19:12:23 -0000 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. From henning.rogge@fkie.fraunhofer.de Wed May 30 22: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 6276511E809A for ; Wed, 30 May 2012 22:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.344 X-Spam-Level: X-Spam-Status: No, score=-1.344 tagged_above=-999 required=5 tests=[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 cCQY2SXqHZlc for ; Wed, 30 May 2012 22:24:18 -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 23AB021F8631 for ; Wed, 30 May 2012 22:24:13 -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 1SZxro-0006uX-Jx for manet@ietf.org; Thu, 31 May 2012 07:24:12 +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 1SZxro-0004X5-HJ for manet@ietf.org; Thu, 31 May 2012 07:24:12 +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); Thu, 31 May 2012 07:24:12 +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; Thu, 31 May 2012 07:24:12 +0200 Message-ID: <4FC70075.8080501@fkie.fraunhofer.de> Date: Thu, 31 May 2012 07:24:05 +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: <4FC67102.50903@computer.org> In-Reply-To: <4FC67102.50903@computer.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070208000407060706050202" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 31 May 2012 05:24:12.0325 (UTC) FILETIME=[9CD8FD50:01CD3EED] X-Virus-Scanned: yes (ClamAV 0.97.3/14984/Thu May 31 02:31:26 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: b023bd6aafd0ed920562fab22193c372 Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 05:24:19 -0000 --------------ms070208000407060706050202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 05/30/2012 09:12 PM, Charles E. Perkins wrote: > I understand this point. However, I have always believed that AODV is a= lso > applicable for LLNs and sensor networks. I agree, the difference between "LLNs" and "MANETs" is mostly one of the = focus of optimization. Depending on the traffic pattern and timing=20 settings, AODV should work well for LLNs. 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 --------------ms070208000407060706050202 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 Fw0xMjA1MzEwNTI0MDlaMCMGCSqGSIb3DQEJBDEWBBTbWKrTqOPyJMURp7tgiCUMlc/I2DBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQBwfC3pQPRe1NSs8rIOLNeQSIlKLAAKQ8AvhXv8oNJxJuqAW/pzW2ASpxjVQV7G yll3xnyYo/l2y+mdvLk+9D93Ve1P/XlFxos+JhlKJUHnennK2LZpB4sCChp2T9cagcMuyR9H BV7rGWVRe8aGwXhvUbQizAu8wepDewCUjTfNzen5Vsswy6bq7ykeTKZNb5q15UBSjQSTWrsm oyRBekmbQN7od65KY/e25AdHBWaySi4lE7oXSjEk2Pbns6WLHIJXHQkPjBpHb0PWXQ79erI2 9Go+2BfE8NmWR6Ed2N1X14poXEBs2AYHu6CGLJuOix78j8DD988C+HolVLsO9khPAAAAAAAA --------------ms070208000407060706050202-- From abdussalambaryun@gmail.com Thu May 31 03:35: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 93C1021F8655 for ; Thu, 31 May 2012 03:35: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=[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 HxObyJp3gI5Q for ; Thu, 31 May 2012 03:35:39 -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 62A2721F8653 for ; Thu, 31 May 2012 03:35:35 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so535140vbb.31 for ; Thu, 31 May 2012 03:35:34 -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=JqmH+o13urtBMSaYxW+py4AsNb31JL9RvxDsNKirCBo=; b=M88DCKgT0EFt1fcIOwYpqIKjceatC77/cIH3FsVevM2gDeB/l27+AyH8s5zeNz6+tm YvNeUiHgVH+oP5nSy1cUgRf8P3jzWtreeYS0n6C7BDMmaWteZizz2Exs4pK+H8lBuT1y O1VAyybmIxj9WRfInYnLZV3XEwvyJb+GKxgF50FEIaaJfE+iV4TKh+e4SIj+5MPklYJ+ NnruPunWXJaV8pup0GE3plJyOBVX4o0Lf0q8J6P35IaKcQpEjRzkFVZM+RZoeT8J/JSV L/LCjyIgcoldXJNqKMojSugbytap2QcbzExvZOozHt+Itvg48JEu8IwgMccTiwUXBI+i eNGA== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr1144521vdb.103.1338460534789; Thu, 31 May 2012 03:35:34 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 03:35:33 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 May 2012 11:35:33 +0100 Message-ID: From: Abdussalam Baryun To: Ulrich Herberg Content-Type: multipart/alternative; boundary=20cf3071d098b8d7ee04c152a0fa Cc: manet Subject: Re: [manet] Discussing LOADng suggestions 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, 31 May 2012 10:35:40 -0000 --20cf3071d098b8d7ee04c152a0fa Content-Type: text/plain; charset=ISO-8859-1 Hi Herberg, That is a good news for me and think it is for many others, but why we don't discuss what authors are doing, why we wait. I like that we discuss while authors updating the draft because they already proposed in the 83 meeting in a very accusing way that MANET is not considering it. Why proposing if you don't want to discuss your proposal. Please note that I am interested in LOADng, so I can not wait after hearing a strong proposal and WG-chairs asking to discuss it. Therefore, I RECOMMEND in the future no author of any draft should propose ideas until s/he gets things/thoughts updated first or is able to discuss what s/he is proposing. Under this condition we don't waste time in discusion-process and we don't make people forget what was discussed. Regards Abdussalam On Wed, May 30, 2012 at 5:53 PM, Ulrich Herberg wrote: > Abdussalam, > > we are aware that the LOADng draft needs some updates, before it could > be considered by the MANET WG, notably support for RFC5444 and some > editorial updates. We plan to work on these in the next days, and will > submit a new revision likely next week. So, just stay tuned! > > Best > Ulrich > > On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun > wrote: > > On 5/29/12, JP Vasseur wrote: > >> > >> We already have two different WG: MANET and ROLL. > >> > > > > Yes we know. That is why LOADng authors should choose either to serve > > LLN that is considered by ROLL WG or they choose serving MANET, and it > > is considered by MANET WG. But the question is which suggestion option > > do you think is better for LOADng-draft? > > > >>MANET is tasked, amongst other, to publish a reactive > >>routing protocol. > > > > MANET is tasked to publish routing protocols that serve the MANET > > network. IMO, MANET-WG is not tasked to publish protocols serving only > > LLN just because the protocol is reactive. Please note that LOADng > > protocol does not even mention MANET nor mobile routers in its draft, > > which confuses its purpose, the authors should look into that. > > > > Abdussalam Baryun > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> I did not understand your refering to movment without mentioning that > >>> LOADng-draft specifies that it is for LLN (I do not see in draft any > >>> reference to movement in LOADng!) > >>> > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> This distinction does not make sense. > >>> > >>> > >>> Adhoc networks deal with link that can fluctuate quite a lot. For most > >>> protocols and routing metrics it doesn't matter if this happens > >>> because of the metric, the radio environment or movement (exception > >>> are protocols/metrics that incorporate explicit algorithms for > >>> exploiting knowledge about movement or even terrain). > >>> > >>> Henning Rogge > >>> > >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> > >>> On 5/29/12, Abdussalam Baryun wrote: > >>>> Hi > >>>> > >>>> I think at the WG 83 meeting, regarding LOADng to be discussed, and > >>>> that the suggestions were either of the following: > >>>> > >>>> 1- to accommodate LOADng for MANET WG, > >>>> ( some prefered to see LOADng possibly adapted to the MANET working > >>>> group as reactive protocol with RFC5444 compliance), or > >>>> 2- to leave LOADng for LLN group to look at it, other than MANET WG, > or > >>>> 3- to join LOADng authors with DYMO authors in one work. > >>>> > >>>> IMO it is interesting to have a reactive MANET protocol using RFC5444. > >>>> There is motivation to use RFC5444 for interoperability between > >>>> routers and security purposes. However, LOADng is for lossy ad-hoc > >>>> networks more than mobile ad-hoc nets. If authors decide LOADng is for > >>>> LLN then they should take it to LLN groups, but if the protocol and > >>>> document is modified it can be an alternative MANET reactive protocol > >>>> that differs from DYMO. So I agree to option-1 more than 2 depending > >>>> on the LOADng-authors' thoughts. > >>>> > >>>> It was mentioned in the meeting that DYMO and LOADng are close. I do > >>>> not see that that LOADng and AODVv2 are close (someone mentioned in 83 > >>>> meeting), but LOADng is a RFC5444-based reactive protocol that is > >>>> derived from AODV [RFC3561], it focuses on low power and lossy nets, > >>>> but DYMO is derived from DSR and AODV, and so far does not fully use > >>>> RFC5444. > >>>> > >>>> The suggestion option 3 maybe not interesting in this stage, because > >>>> usually it is better decided by the authors if they like the join > >>>> their drafts to one, but it is interesting to the WG to have > >>>> alternatives and that DYMO and LOADng are not similar functions. So I > >>>> disagree with option-3. > >>>> > >>>> IMHO that AODVv2 does not involve/use similar of LOADng, but it can > >>>> use RFC5444 differently from LOADng, or use only RFC5444 techniques. > >>>> Also LOADng does not use much of AODV-RFC3561, but it can use its > >>>> reactive technique adding to it energy efficiency techniques. LOADng > >>>> is for low power routers, but while reading it I am not sure how it > >>>> solves the power-problem. Furthermore, LOADng can be pushed to focus > >>>> on low-power MANET instead of LLN, it may only have lossy links, not a > >>>> lossy network. I suggest to replace 'LLN' in the protocol name to ' > >>>> Low-power' without lossy-net, and to make its functions consider > >>>> network energy consumptions. > >>>> > >>>> Abdussalam Baryun > >>>> University of Glamorgan, UK. > >>>> > >>> _______________________________________________ > >>> 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 > --20cf3071d098b8d7ee04c152a0fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Herberg,
=A0
That is a good news for me and think it is for many others, but why we= don't discuss what authors are doing, why we wait. I like that we disc= uss while authors updating the draft because they already proposed in the 8= 3 meeting in a very accusing way that MANET is not considering it. Why prop= osing if you don't want to discuss your proposal.
=A0
Please note that I am interested in LOADng, so I can not wait after he= aring a strong proposal and WG-chairs asking to discuss it. Therefore, I RE= COMMEND in the future no author of any draft should propose=A0ideas=A0until= s/he gets things/thoughts updated first or is able to discuss what s/he is= proposing.=A0Under this condition=A0we don't waste time in discusion-p= rocess and we don't make people forget what was discussed.
=A0
Regards
Abdussalam

On Wed, May 30, 2012 at 5:53 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Abdussalam,

we are aware that = the LOADng draft needs some updates, before it could
be considered by th= e MANET WG, notably support for RFC5444 and some
editorial updates. We plan to work on these in the next days, and will
s= ubmit a new revision likely next week. So, just stay tuned!

Best
= Ulrich

On Wed, May 30, 2012 at 3:45 AM, Abdussalam Baryun<abdussalambaryun@gmail.c= om> wrote:
> On 5/29/12, JP Vasseur <jpv@cisco.com> wrote:
>>
>> We already have two different WG: MANET and ROLL.
&= gt;>
>
> Yes we know. That is why LOADng authors should choo= se either to serve
> LLN that is considered by ROLL WG or they choose= serving MANET, and it
> is considered by MANET WG. But the question is which suggestion option=
> do you think is better for LOADng-draft?
>
>>MANET = is tasked, amongst other, to publish a reactive
>>routing protocol= .
>
> MANET is tasked to publish routing protocols that serve the MA= NET
> network. IMO, MANET-WG is not tasked to publish protocols servi= ng only
> LLN just because the protocol is reactive. Please note that= LOADng
> protocol does not even mention MANET nor mobile routers in its draft,<= br>> which confuses its purpose, the authors should look into that.
&= gt;
> Abdussalam Baryun
> +++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++
>>> I did not understand your refering to movment without mentioni= ng that
>>> LOADng-draft specifies that it is for LLN (I do not= see in draft any
>>> reference to movement in LOADng!)
>>>
>>> ++++++++++++++++++++++++++++++++++++++++++++++= ++++++++++
>>> This distinction does not make sense.
>>= ;>
>>>
>>> Adhoc networks deal with link that ca= n fluctuate quite a lot. For most
>>> protocols and routing metrics it doesn't matter if this ha= ppens
>>> because of the metric, the radio environment or movem= ent (exception
>>> are protocols/metrics that incorporate expli= cit algorithms for
>>> exploiting knowledge about movement or even terrain).
>&= gt;>
>>> Henning Rogge
>>>
>>> +++++= +++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> On 5/29/12, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
>>>= > Hi
>>>>
>>>> I think at the WG 83 meetin= g, regarding LOADng to be discussed, and
>>>> that the suggestions were either of the following:
>= >>>
>>>> 1- to accommodate LOADng for MANET WG,
= >>>> ( some prefered to see LOADng possibly adapted to the MANE= T working
>>>> group as reactive protocol with RFC5444 compliance), or>>>> 2- to leave LOADng for LLN group to look at it, other tha= n MANET WG, or
>>>> 3- to join LOADng authors with DYMO auth= ors in one work.
>>>>
>>>> IMO it is interesting to have a reacti= ve MANET protocol using RFC5444.
>>>> There is motivation to= use RFC5444 for interoperability between
>>>> routers and s= ecurity purposes. However, LOADng is for lossy ad-hoc
>>>> networks more than mobile ad-hoc nets. If authors decide L= OADng is for
>>>> LLN then they should take it to LLN groups= , but if the protocol and
>>>> document is modified it can b= e an alternative MANET reactive protocol
>>>> that differs from DYMO. So I agree to option-1 more than 2= depending
>>>> on the LOADng-authors' thoughts.
>= >>>
>>>> It was mentioned in the meeting that DYMO = and LOADng are close. I do
>>>> not see that that LOADng and AODVv2 are close (someone men= tioned in 83
>>>> meeting), but LOADng is a RFC5444-based re= active protocol that is
>>>> derived from AODV [RFC3561], it= focuses on low power and lossy nets,
>>>> but DYMO is derived from DSR and AODV, and so far does not= fully use
>>>> RFC5444.
>>>>
>>>= > The suggestion option 3 maybe not interesting in this stage, because >>>> usually it is better decided by the authors if they like t= he join
>>>> their drafts to one, but it is interesting to t= he WG to have
>>>> alternatives and that DYMO and LOADng are= not similar functions. So I
>>>> disagree with option-3.
>>>>
>>>= ;> IMHO that AODVv2 does not involve/use similar of LOADng, but it can>>>> use RFC5444 differently from LOADng, or use only RFC5444= techniques.
>>>> Also LOADng does not use much of AODV-RFC3561, but it can = use its
>>>> reactive technique adding to it energy efficien= cy techniques. LOADng
>>>> is for low power routers, but whi= le reading it I am not sure how it
>>>> solves the power-problem. Furthermore, LOADng can be pushe= d to focus
>>>> on low-power MANET instead of LLN, it may on= ly have lossy links, not a
>>>> lossy network. I suggest to = replace 'LLN' in the protocol name to '
>>>> Low-power' without lossy-net, and to make its function= s consider
>>>> network energy consumptions.
>>>= >
>>>> Abdussalam Baryun
>>>> University o= f Glamorgan, UK.
>>>>
>>> __________________________________________= _____
>>> manet mailing list
>>> manet@ietf.org
>>> https://www.ietf.org/mail= man/listinfo/manet
>>
>>
> ______________________________________________= _
> manet mailing list
> mane= t@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

--20cf3071d098b8d7ee04c152a0fa-- From abdussalambaryun@gmail.com Thu May 31 04:30: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 5D43121F855D for ; Thu, 31 May 2012 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 62G3g75y7iyG for ; Thu, 31 May 2012 04:30: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 4989621F8540 for ; Thu, 31 May 2012 04:30:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so563626vbb.31 for ; Thu, 31 May 2012 04:30: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 :content-type; bh=7cAogUD6I/Wl1ClBGy2hVl7FXf0hANL8xOwe8cyWBZg=; b=u0WfVlaxpEIrAA55QFsFa6OqL3yUXdkqv0YA7uwE5znXxsnqowtKbNDwA64wMkoo9u Mu8iXV54FyzVbjQI0waOo8cOwHnjO4E7cnCUZTaR5g5+FRMU53sGgzKJEAdmEu7hGQCp QFCDkDF25/KMaOQYFJzmfbgff4Z1i+Loan0tvKnYDI4/kjyGUAXsNXnFl+pDV28cRvpO sn9AGQ0PqVqZI2lcadDUht3a8YOhshjwevd9gM3KIl9pcvF4qQ6wrDQRSPqUkFJZ1Cu1 ljjd7tCD3/ZOJ7UCKKQNRwMF8OLN6KP6g+Dh5Z+uRtw8rlGOlWsF4Nz1H8q/OBWH+mmG shXQ== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr1413789vdb.10.1338463802466; Thu, 31 May 2012 04:30:02 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 04:30:02 -0700 (PDT) In-Reply-To: <4FC67102.50903@computer.org> References: <4FC67102.50903@computer.org> Date: Thu, 31 May 2012 12:30:02 +0100 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" , manet Content-Type: multipart/alternative; boundary=20cf307f31667da33904c15363f5 Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 11:30:04 -0000 --20cf307f31667da33904c15363f5 Content-Type: text/plain; charset=ISO-8859-1 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. > --20cf307f31667da33904c15363f5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Charlie, and All
=A0
I don't mind to have=A0DYMO and AODVv2 without=A0divergence, just = from the protocol=A0name and=A0draft-understanding, DYMO was derived from A= ODV+DSR, and from the change of name to AODVv2 it made me think more=A0abou= t the extending of AODV. Therefore,=A0I may suggest that it is interested t= o see DSRv2 ( which I thought new DYMO may take that direction), and was th= inking if the authors of DSR or others in WG are happy to extend that proto= col.
=A0
If we can get a new DSRv2 that is able to use RFC5444 or use a modifie= d format of RFC5444, it will be great. Because if OLSRv2-15 is now deleting= its=A0source-routing option=A0as was included in OLSRv2-14, and AODVv2 is = not doing source routing, then it is interested to have=A0a=A0routing proto= col that is able to source route.
=A0
Abdussalam Baryun,
University of Glamorgan, UK.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++

On Wed, May 30, 2012 at 8:12 PM, Charles E. Perk= ins <charliep@computer.org> wrote:

Hello folks,

I think it= 9;s a good idea to enable alternate metrics in AODVv2/DYMO
and for LOADn= g for that matter. =A0In fact, LOADng already has a form of
alternate metric.=20


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
f= ormat) if you think it is better for the protocol, this is a way that
ma= kes 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.=20


to be clear, we can standardize AODVv= 2 *with* packet-BB
right now, and submit for consideration another docum= ent for
AODVv2 that does not require packet-BB. =A0Or, we can enable both
ways i= n the next revision. =A0Or, we can standardize AODVv2
that does NOT use = packet-BB, and then submit for consideration
another document that DOES = use packet-BB. =A0All 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-for= mat (special formats for DYMO), and AODVv2 with using
modified-5444-form= at (as below suggestion of adding metric-type), and
LOADng fully using RFC5444. So we may join LOADng in MANET.


I understand this point. =A0However, I have always believed = that AODV is also
applicable for LLNs and sensor networks. =A0Previous w= ork to focus AODV for
better performance in specific networks has produced quite interesting and<= br>good results. =A0It would have been very appropriate to bring these modi= fications
into the [manet] WG for adoption into the evolved WG documents= . =A0Making
an oversimplification, it seems that the areas where DYMO/AODV have beenviewed as inadequate for networks with reduced-functionality nodes are
= mostly as follows:
1. protocol complexity
2. packet size
3. neighb= orhood detection

1) is clearly an area where discussion in [manet] should have happened,=
=A0 =A0 and is happening now thanks to LOADng development
2) is a pr= oblem sometimes difficult to solve in the IETF
3) was mostly resolved by= specifically enabling DYMO/AODVv2 to use
=A0 =A0 any appropriate neighborhood detection algorithm. =A0In fact, this = was
=A0 =A0 always possible even with AODV, but somehow the HELLO messag= es
=A0 =A0 were viewed as a central part of AODV even after the publicat= ion of
=A0 =A0 SMURF and other related efforts.

In particular I would not b= e happy to see any divergence between a protocol
named "DYMO" = and a protocol named "AODVv2".

Regards,
Charlie P.
<= /blockquote>

--20cf307f31667da33904c15363f5-- From henning.rogge@fkie.fraunhofer.de Thu May 31 04:38:17 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 DD70F21F860D for ; Thu, 31 May 2012 04:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_43=0.6, 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 ornmvlSNo+bI for ; Thu, 31 May 2012 04:38:17 -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 157B921F85C6 for ; Thu, 31 May 2012 04:38:17 -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 1Sa3ho-00067q-E1 for manet@ietf.org; Thu, 31 May 2012 13:38:16 +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 1Sa3ho-0006Oc-BN for manet@ietf.org; Thu, 31 May 2012 13:38:16 +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); Thu, 31 May 2012 13:38:16 +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; Thu, 31 May 2012 13:38:15 +0200 Message-ID: <4FC75826.4050603@fkie.fraunhofer.de> Date: Thu, 31 May 2012 13:38:14 +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: <4FC67102.50903@computer.org> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090608000200040704050800" X-Originating-IP: [128.7.5.36] X-OriginalArrivalTime: 31 May 2012 11:38:16.0169 (UTC) FILETIME=[DE6BCD90:01CD3F21] X-Virus-Scanned: yes (ClamAV 0.97.3/14985/Thu May 31 12:16:53 2012) by a.mx.fkie.fraunhofer.de X-Scan-Signature: c7f8db32b27897ddd5dcaf8162788e46 Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 11:38:18 -0000 --------------ms090608000200040704050800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 05/31/2012 01:30 PM, 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, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would consider this a reason the not accept a protocol. > it will be great. Because if OLSRv2-15 is now deleting its > source-routing option as was included in OLSRv2-14, Not sure why it was ever there, because the mechanism to use source routing with OLSR was never described in the draft. Feel free to write an extension draft OLSRv2-with-sourcerouting > and AODVv2 is not doing source routing, then it is interested to have > a routing protocol that is able to source route. Can you state a reason why you think that source routing is interesting=20 for you? I know it makes a lot of trouble, but whats the advantage if=20 every OLSR node (as an example) has to store the whole topology anyways? 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 --------------ms090608000200040704050800 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 Fw0xMjA1MzExMTM4MTRaMCMGCSqGSIb3DQEJBDEWBBQaa18njbzTxkjS8eRiHb11TJAGDzBf BgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgIC AIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYQGCSsGAQQBgjcQ BDF3MHUwZzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkZyYXVuaG9mZXIxITAfBgNVBAsTGEZy YXVuaG9mZXIgQ29ycG9yYXRlIFBLSTEgMB4GA1UEAxMXRnJhdW5ob2ZlciBVc2VyIENBIDIw MDcCCjQb6OgAAAAAuuYwgYYGCyqGSIb3DQEJEAILMXegdTBnMQswCQYDVQQGEwJERTETMBEG A1UEChMKRnJhdW5ob2ZlcjEhMB8GA1UECxMYRnJhdW5ob2ZlciBDb3Jwb3JhdGUgUEtJMSAw HgYDVQQDExdGcmF1bmhvZmVyIFVzZXIgQ0EgMjAwNwIKNBvo6AAAAAC65jANBgkqhkiG9w0B AQEFAASCAQDDLc7n1n0/a07koHChG+OZNimY9ah6PvFPTUmPIOiiOQwNE2XePRrp9A1RZ925 gxx5aawnJ3VJbfdCEYK5CW9aCa+FgGKEcEOYmpf9pc/W2XdL4LI1Kq/Dz1ucY6Vf3oDAthoC YWf0Bf+1TIk5k+HCygp1q5dhrWHlsiLwnY3oUMuAS56oqC6y/YyOi16QCCIitBNe6QVJ41vZ n7lSgdh1zqWNgKcaA28qbCRCyvC8HX75MtFC08VX1O96AKq8mN5HJBefutURZnygMBKj6aob mZvMSQwb51jUyLIx6vKwyzuXKOMZX/+P98do9MUZxZOuyoDmhI0OzIWpjG0s4cAcAAAAAAAA --------------ms090608000200040704050800-- From Chris.Dearlove@baesystems.com Thu May 31 05:18:34 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 D1E2021F8630 for ; Thu, 31 May 2012 05:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 QoJxoqetOYLZ for ; Thu, 31 May 2012 05:18:33 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4453C21F862A for ; Thu, 31 May 2012 05:18:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="242824603" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 May 2012 13:18:22 +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 q4VCILRw020505 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 May 2012 13:18:21 +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; Thu, 31 May 2012 13:18:21 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , "manet@ietf.org" Thread-Topic: [manet] A view on packet-BB Thread-Index: AQHNJ+X7nMtvbPBQX0OYzXHJO0L0ZZbg14UAgAH4GwCAARFAAIAAAkoAgAAZLxA= Date: Thu, 31 May 2012 12:18:20 +0000 Message-ID: References: <4FC67102.50903@computer.org> <4FC75826.4050603@fkie.fraunhofer.de> In-Reply-To: <4FC75826.4050603@fkie.fraunhofer.de> 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] A view on packet-BB 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, 31 May 2012 12:18:35 -0000 I agree with Henning, including on his emphasised point. With regard to the source routing paragraph in OLSRv2, it appeared for abou= t one draft, because someone (I don't recall who) said (roughly) "you've go= t the information to do source routing, why not mention that", and so it wa= s added in the non-normative part. (Note that it was never in the normative= part.) Then a draft or so later it was taken out because actually no one o= rdered that, and because it's not quite that simple, you can't source route= to attached networks, only to their gateways. The idea of having to explai= n an exception to a mechanism that no one wanted and wasn't normative seeme= d like a very bad idea. "Interesting" is not enough. I could write a long list of interesting thing= s. What we should be doing in an IETF WG is something people want (or even = need). We also don't want more protocols, we dropped from four experimental= protocols to two standards track deliberately. Roughly speaking OLSR and A= ODV won over DSR and TBRPF for a variety of reasons, but DSR's source routi= ng was a strike against it, not for it. --=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: 31 May 2012 12:38 To: manet@ietf.org Subject: Re: [manet] A view on packet-BB On 05/31/2012 01:30 PM, 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, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I would consider this a reason the not accept a protocol. > it will be great. Because if OLSRv2-15 is now deleting its > source-routing option as was included in OLSRv2-14, Not sure why it was ever there, because the mechanism to use source routing with OLSR was never described in the draft. Feel free to write an extension draft OLSRv2-with-sourcerouting > and AODVv2 is not doing source routing, then it is interested to have > a routing protocol that is able to source route. Can you state a reason why you think that source routing is interesting=20 for you? I know it makes a lot of trouble, but whats the advantage if=20 every OLSR node (as an example) has to store the whole topology anyways? 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 ******************************************************************** 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 May 31 06:39: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 BD14E21F869E for ; Thu, 31 May 2012 06:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.401 X-Spam-Level: X-Spam-Status: No, score=-3.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 vIXe15cbAZ5O for ; Thu, 31 May 2012 06:39:40 -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 E301221F8690 for ; Thu, 31 May 2012 06:39:39 -0700 (PDT) Received: by vcqp1 with SMTP id p1so655197vcq.31 for ; Thu, 31 May 2012 06:39:39 -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=y79HiIOlpdEwPh/b8y/mpFD7EpbGV5YMMx+a9090t/c=; b=thp3UVEeCXbpn10jQmJ+vDvHmQcnX4fJTbA/ij93uTKco+9DR1fvH3YcM3AtmOnXNi gqcsktWF5v5qB3Tad6plROfMj5C3xjrQDV0U+RbxoSovTtcSu1sONbvsN1FnIOHkZTXy 2mN9o1wwdvbajym6AjLMprc08ToDfxWja1g3z6vzUJ06yHkW58VJaYrjgX0kLG1hj/ZW ygFYl2BQiEmYV5SCSaPcw3sgJM1w7N76WG9i8Q3u/57/gyYlWSkIltkKp4d/kCaK1P+n OIpr0/YDoTsbYKyxl3MSS6EUEvCIaQ2B8lWNF/iiYPafLXvVJukfqJztAK4VtykkaT7V s+1A== MIME-Version: 1.0 Received: by 10.220.151.80 with SMTP id b16mr2203534vcw.4.1338471579179; Thu, 31 May 2012 06:39:39 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 06:39:38 -0700 (PDT) Date: Thu, 31 May 2012 15:39:38 +0200 Message-ID: From: Abdussalam Baryun To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 13:39:40 -0000 Hi Chris, I agree and like your statement 'Interesting is not enough, what we should be doing in an IETF WG is something people want or even need', however, it should not mean that discussion-list should not include interests, or motivations, because IMO interests are the most important thing to start any work in any organisations, yes you or me may not be interested in something today but some one maybe interested in it today or tomorrow. However, if we don't remember who mentioned to include the source routing without knowing how it will be working, this should not be in our IETF discussion. We should know who is discussing and who mentions so we can ask him again why you want this or that, otherwise we have no communication. If this idea was important I will request the WG secretary to find out who mentioned the idea of source routing in OLSRv2, so we can see his/her views, so we can have good discussion in it. I am not interested to know, but I hope in future we know who put any idea/interest in any manet-draft so we can question them and the authors in our discussions. Regarding puting interests in the list I think it is healthy, but puting interests-without-discussions into drafts is not healthy in IETF. The one that mentioned source routing to include in some OLSRv2-draft had an interest and still authors put it through to the draft without they knowing if relevant. In my post discussion I am not asking any one to put my interest in any draft, but I am asking the WG to think about it, and if someone else is interested, then I will open discussion about that when knowing that person. Therefore, my interests will still go through to the discussion list, and hope that others do the same so we can see more discussion, that in future make better drafts or even more focused drafts. sorry to reply in long message, Regards Abdussalam Baryun, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I agree with Henning, including on his emphasised point. With regard to the source routing paragraph in OLSRv2, it appeared for about one draft, because someone (I don't recall who) said (roughly) "you've got the information to do source routing, why not mention that", and so it was added in the non-normative part. (Note that it was never in the normative part.) Then a draft or so later it was taken out because actually no one ordered that, and because it's not quite that simple, you can't source route to attached networks, only to their gateways. The idea of having to explain an exception to a mechanism that no one wanted and wasn't normative seemed like a very bad idea. "Interesting" is not enough. I could write a long list of interesting things. What we should be doing in an IETF WG is something people want (or even need). We also don't want more protocols, we dropped from four experimental protocols to two standards track deliberately. Roughly speaking OLSR and AODV won over DSR and TBRPF for a variety of reasons, but DSR's source routing was a strike against it, not for it. -- Christopher Dearlove From Chris.Dearlove@baesystems.com Thu May 31 06:49: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 8858921F865E for ; Thu, 31 May 2012 06:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 XlY6sNTPqaxs for ; Thu, 31 May 2012 06:49:45 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) by ietfa.amsl.com (Postfix) with ESMTP id 3B40A21F8666 for ; Thu, 31 May 2012 06:49:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="242865521" Received: from unknown (HELO baemasmds009.greenlnk.net) ([141.245.68.246]) by baemasmds003ir.sharelnk.net with ESMTP; 31 May 2012 14:49:44 +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 q4VDnhFL023107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 May 2012 14:49:44 +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; Thu, 31 May 2012 14:49:43 +0100 From: "Dearlove, Christopher (UK)" To: Abdussalam Baryun Thread-Topic: [manet] A view on packet-BB Thread-Index: AQHNPzLSnMtvbPBQX0OYzXHJO0L0ZZbj54mw Date: Thu, 31 May 2012 13:49:43 +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] A view on packet-BB 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, 31 May 2012 13:49:46 -0000 It's not in the least important to know who made the source routing suggest= ion. And asking the "WG secretary" isn't a practical idea because first who= is that? and second how would he or she know? The people to ask would be = the draft authors - and I'm one of those. If I have the information it's bu= ried in a large pile of emails I have zero interest in looking through. I'm also afraid that's not the only example of what I'd characterise as mud= dled thinking in this and previous posts. However I don't choose to discuss this further, I just wanted to make the p= oint I made in my last posting, which is done. --=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: 31 May 2012 14:40 To: Dearlove, Christopher (UK) Cc: Henning Rogge; manet; ulrich@herberg.name Subject: Re: [manet] A view on packet-BB ----------------------! 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 agree and like your statement 'Interesting is not enough, what we should be doing in an IETF WG is something people want or even need', however, it should not mean that discussion-list should not include interests, or motivations, because IMO interests are the most important thing to start any work in any organisations, yes you or me may not be interested in something today but some one maybe interested in it today or tomorrow. However, if we don't remember who mentioned to include the source routing without knowing how it will be working, this should not be in our IETF discussion. We should know who is discussing and who mentions so we can ask him again why you want this or that, otherwise we have no communication. If this idea was important I will request the WG secretary to find out who mentioned the idea of source routing in OLSRv2, so we can see his/her views, so we can have good discussion in it. I am not interested to know, but I hope in future we know who put any idea/interest in any manet-draft so we can question them and the authors in our discussions. Regarding puting interests in the list I think it is healthy, but puting interests-without-discussions into drafts is not healthy in IETF. The one that mentioned source routing to include in some OLSRv2-draft had an interest and still authors put it through to the draft without they knowing if relevant. In my post discussion I am not asking any one to put my interest in any draft, but I am asking the WG to think about it, and if someone else is interested, then I will open discussion about that when knowing that person. Therefore, my interests will still go through to the discussion list, and hope that others do the same so we can see more discussion, that in future make better drafts or even more focused drafts. sorry to reply in long message, Regards Abdussalam Baryun, ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ I agree with Henning, including on his emphasised point. With regard to the source routing paragraph in OLSRv2, it appeared for about one draft, because someone (I don't recall who) said (roughly) "you've got the information to do source routing, why not mention that", and so it was added in the non-normative part. (Note that it was never in the normative part.) Then a draft or so later it was taken out because actually no one ordered that, and because it's not quite that simple, you can't source route to attached networks, only to their gateways. The idea of having to explain an exception to a mechanism that no one wanted and wasn't normative seemed like a very bad idea. "Interesting" is not enough. I could write a long list of interesting things. What we should be doing in an IETF WG is something people want (or even need). We also don't want more protocols, we dropped from four experimental protocols to two standards track deliberately. Roughly speaking OLSR and AODV won over DSR and TBRPF for a variety of reasons, but DSR's source routing was a strike against it, not for it. --=20 Christopher Dearlove ******************************************************************** 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 May 31 05:59: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 CE30921F8592 for ; Thu, 31 May 2012 05:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-1.138, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MISSING_SUBJECT=1.762, 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 kw96viAlUf9a for ; Thu, 31 May 2012 05:59:58 -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 4C15321F856F for ; Thu, 31 May 2012 05:59:58 -0700 (PDT) Received: by vcqp1 with SMTP id p1so622477vcq.31 for ; Thu, 31 May 2012 05:59:57 -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=J93qbuBc8CJTxJdjmwANjfYFLQHkuHJoKj6ZQwhALvg=; b=AUDvYLW2KUqHv5kPVyJZGo0/DwRXI97zLz1FDQ5/sMALuS6PLsOa6WkDsJDFbBWcB7 I92nxFfxb3Ybb5Mv/Jl1h3qimoqFLTUI6iRrqTuKgklWWjyhRBBhcXfoegV92+NsOMwz A1T+Zwqo4ykfq9NFz5KbsHHbsraeqcCQRaEdQu67zbKxwvGimes+93sND4FCWFnXIzdk T8VQagbosY87eJkPsezIr8Lx/k2BGLVlt2qdX0jpvHcv2uGA0xzdruNJzvH+m8yR6+8c fkbzpGze7MpdqjgG27qDtOYb2BLCY9di6CruXkIF/oYtCcQ+pkOoobZDgYRreIMAwJiE 7Jpw== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr1554711vdb.103.1338469197729; Thu, 31 May 2012 05:59:57 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 05:59:57 -0700 (PDT) Date: Thu, 31 May 2012 14:59:57 +0200 Message-ID: From: Abdussalam Baryun To: henning.rogge@fkie.fraunhofer.de Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 31 May 2012 07:03:26 -0700 Subject: [manet] (no subject) 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, 31 May 2012 12:59:58 -0000 >Not sure why it was ever there, because the mechanism to use source >routing with OLSR was never described in the draft. Feel free to write >an extension draft OLSRv2-with-sourcerouting I disagree to use source routing for OLSRv2, but it was in OLSRv2-14 draft please read it again. >Can you state a reason why you think that source routing is interesting for you? I >know it makes a lot of trouble, but whats the advantage if every OLSR node (as an >example) has to store the whole topology anyways? >Henning Rogge There are reasons for source routing as a protocol in MANET you need to read DSR protocol, but source routing SHOULD not be use in OLSRv2, as the authors included it in their draft-14, I think your question should be for them not me. I written the interest in DSRv2 not in OLSRv2-sourceRouting, please read my discussion again (see below). Abdussalam Baryun, +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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. From abdussalambaryun@gmail.com Thu May 31 06:01: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 16B1921F869C for ; Thu, 31 May 2012 06:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.114 X-Spam-Level: X-Spam-Status: No, score=-3.114 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 XDMAyk7A8bSc for ; Thu, 31 May 2012 06:01:22 -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 7D9CE21F869A for ; Thu, 31 May 2012 06:01:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so625457vbb.31 for ; Thu, 31 May 2012 06:01:22 -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=yEsy5qGMie0e8vMkA8aN7o2RbkNlG1tAdhzdtXb2T+c=; b=whnTBbCpbIHZwbSUb9+37GsCVB07UCYrCiQFneNPVIMOUq6d6UN75IB1Hkc4yzxj10 SjVQ38b4Wk03s4eEbskuQiqPKNvvGT6eR9E7BhzGWTUf6xTru5bLn4mSFuuvotPAsyFK 5xbWRMUEX5L0ZbwC3BJARhPOc4zA7SIw6n35jfEo7WxzIaypKuFp5iXLsP1ePp00NlQ/ XVMW1BVh2E8Y5Rgwvbam7YMTNg4n2HQauMys7V2B5zBWrUp/5GnfoFQAD1Sm4eA2obae dV6bcxk+6NmBA3UUYUMw/B36Z6WTqid8vMLynywphvL0rAhsl00QTTZuiQwbIYeuI1nf gqsw== MIME-Version: 1.0 Received: by 10.220.149.148 with SMTP id t20mr1852741vcv.12.1338469281902; Thu, 31 May 2012 06:01:21 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 06:01:21 -0700 (PDT) Date: Thu, 31 May 2012 15:01:21 +0200 Message-ID: From: Abdussalam Baryun To: henning.rogge@fkie.fraunhofer.de Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Thu, 31 May 2012 07:03:26 -0700 Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 13:01:23 -0000 >>Not sure why it was ever there, because the mechanism to use source >>routing with OLSR was never described in the draft. Feel free to write >>an extension draft OLSRv2-with-sourcerouting I disagree to use source routing for OLSRv2, but it was in OLSRv2-14 draft please read it again. >>Can you state a reason why you think that source routing is interesting for >> you? I >know it makes a lot of trouble, but whats the advantage if every >> OLSR node (as an >example) has to store the whole topology anyways? >>Henning Rogge There are reasons for source routing as a protocol in MANET you need to read DSR protocol, but source routing SHOULD not be use in OLSRv2, as the authors included it in their draft-14, I think your question should be for them not me. I written the interest in DSRv2 not in OLSRv2-sourceRouting, please read my discussion again (see below). Abdussalam Baryun, +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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. > From abdussalambaryun@gmail.com Thu May 31 07:27: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 33C5721F86A5 for ; Thu, 31 May 2012 07:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.121 X-Spam-Level: X-Spam-Status: No, score=-3.121 tagged_above=-999 required=5 tests=[AWL=-0.122, 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 Qph637rbHuRF for ; Thu, 31 May 2012 07:27:25 -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 9BB7721F867E for ; Thu, 31 May 2012 07:27:25 -0700 (PDT) Received: by vcqp1 with SMTP id p1so697321vcq.31 for ; Thu, 31 May 2012 07:27:25 -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=2UnuJDti6wuUzHZ7EsiWzxCBj6IpKwZsQOeCo0V/A2I=; b=VhGYsfTwVkHDxO4zU5tgwEsOSm1mMd1aIWRQ3w4pjMMCMZMuea6O+rwXiAcmZQNl8S a9ZbgHzmkm9g/ZqFwlCrpPSL08WKUSmF+15Zfq7N+cT6Vs5fgD4YkpQAWi/yEfcw3ZOo FrXntzNT0zQ4AIgHc/RojeTrLbXOmMnQo3eSqb2ErUhAiX/JIGXRp8ZiwXBdxex3hUYv 5N+HrXbIPQSzukiKN4pYBQ28hDAheJ1iPt8PdvEi4hE0S1S9unhJEFZqS5pQIF9NCrve YhmpXQRmvnvrEzhF/qr6Lvf/92H+bdHcImTBWEwSbjyJgjF4U75toJ97vVYic3aI+Egp aXEA== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr18355849vdf.127.1338474445134; Thu, 31 May 2012 07:27:25 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 07:27:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 May 2012 16:27:24 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 14:27:28 -0000 Hi All, Henning> Not sure why it was ever there, because the mechanism to use source >routing with OLSR was never described in the draft. Feel free to write >an extension draft OLSRv2-with-sourcerouting. >Can you state a reason why you think that source routing is interesting for you? >I know it makes a lot of trouble, but whats the advantage if every OLSR node >(as an example) has to store the whole topology anyways? Chris> I agree with Henning, including on his emphasised point. I noticed that OLSRv2-14 draft was presented at 83 meeting and authors proposed it for last call because there are no important issues, so Henning's question still stands: Why someone want source-routing in OLSRv2? and mine is to authors: Why OLSRv2-author did not discussed about how it can be possible this protocol to have hop-by-hop routing and have source-routing techniques before calling for WGLC? However, I am happy that OLSRv2-15 has deleted it and now I am about to finish my comments on the new draft. > And asking the "WG secretary" isn't a practical idea because > first who is that? and second how would he or she know? The people to ask > would be the draft authors - and I'm one of those. If I have the information > it's buried in a large pile of emails I have zero interest in looking > through. Ok, I don't want to know the person either and don't want to discuss these buried-issues, but I just replied to comments on my interests of DSRv2, and would like to go forward to other better discusions, Best Regards AB ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/31/12, Dearlove, Christopher (UK) wrote: > It's not in the least important to know who made the source routing > suggestion. And asking the "WG secretary" isn't a practical idea because > first who is that? and second how would he or she know? The people to ask > would be the draft authors - and I'm one of those. If I have the information > it's buried in a large pile of emails I have zero interest in looking > through. > > I'm also afraid that's not the only example of what I'd characterise as > muddled thinking in this and previous posts. > > However I don't choose to discuss this further, I just wanted to make the > point I made in my last posting, which is done. > > -- > 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > Sent: 31 May 2012 14:40 > To: Dearlove, Christopher (UK) > Cc: Henning Rogge; manet; ulrich@herberg.name > Subject: Re: [manet] A view on packet-BB > > ----------------------! 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 agree and like your statement 'Interesting is not enough, what we > should be doing in an IETF WG is something people want or even need', > however, it should not mean that discussion-list should not include > interests, or motivations, because IMO interests are the most > important thing to start any work in any organisations, yes you or me > may not be interested in something today but some one maybe interested > in it today or tomorrow. However, if we don't remember who mentioned > to include the source routing without knowing how it will be working, > this should not be in our IETF discussion. We should know who is > discussing and who mentions so we can ask him again why you want this > or that, otherwise we have no communication. If this idea was > important I will request the WG secretary to find out who mentioned > the idea of source routing in OLSRv2, so we can see his/her views, so > we can have good discussion in it. I am not interested to know, but I > hope in future we know who put any idea/interest in any manet-draft so > we can question them and the authors in our discussions. > > Regarding puting interests in the list I think it is healthy, but > puting interests-without-discussions into drafts is not healthy in > IETF. The one that mentioned source routing to include in some > OLSRv2-draft had an interest and still authors put it through to the > draft without they knowing if relevant. In my post discussion I am not > asking any one to put my interest in any draft, but I am asking the WG > to think about it, and if someone else is interested, then I will open > discussion about that when knowing that person. Therefore, my > interests will still go through to the discussion list, and hope that > others do the same so we can see more discussion, that in future make > better drafts or even more focused drafts. > > sorry to reply in long message, > > Regards > Abdussalam Baryun, > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From sratliff@cisco.com Thu May 31 07:50: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 C199D21F86A0 for ; Thu, 31 May 2012 07:50: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_43=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 G--+vLLHDESO for ; Thu, 31 May 2012 07:50:10 -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 7439321F863B for ; Thu, 31 May 2012 07:50:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sratliff@cisco.com; l=7317; q=dns/txt; s=iport; t=1338475810; x=1339685410; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=WA6U91YIkEjoWxDpbCdp2KtTyC8Jbf7dOJ9BrUtvgpc=; b=f/lG9Kqqs9FL8WQQdrEbWPz34jr8rjePnUBz25/3P0OgXSiL9o3epNcY mDuT4DtIEeBi/fATOTiz0YSdTmd4lqx2ppcJwB4JyUrwaX1Bu8RBpf4Xq RnY+t+xCcknfQor49T3Aj8u+ObxJvp0zKPMtL1zowyFXS56FFrU5ITE9d Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIuEx0+tJV2b/2dsb2JhbABEtAuBB4IYAQEBAwEBAQEPAQodGxkDCAUHBAsRBAEBAScHIQYfCQgGEyKHWwMGBQuZGpYBDYlOijBhFA6ERGADlRiKeIMVgWaCfIE6CQ X-IronPort-AV: E=Sophos;i="4.75,692,1330905600"; d="scan'208";a="88314912" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 May 2012 14:50: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-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4VEo9QR017931; Thu, 31 May 2012 14:50:09 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stan Ratliff In-Reply-To: Date: Thu, 31 May 2012 10:50:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abdussalam Baryun X-Mailer: Apple Mail (2.1278) Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 14:50:12 -0000 On May 31, 2012, at 10:27 AM, Abdussalam Baryun wrote: > Hi All, >=20 > Henning> Not sure why it was ever there, because the mechanism to use = source >> routing with OLSR was never described in the draft. Feel free to = write >> an extension draft OLSRv2-with-sourcerouting. >> Can you state a reason why you think that source routing is = interesting for you? >> I know it makes a lot of trouble, but whats the advantage if every = OLSR node >> (as an example) has to store the whole topology anyways? >=20 > Chris> I agree with Henning, including on his emphasised point. >=20 > I noticed that OLSRv2-14 draft was presented at 83 meeting and authors > proposed it for last call because there are no important issues, so > Henning's question still stands: Why someone want source-routing in > OLSRv2? and mine is to authors: Why OLSRv2-author did not discussed > about how it can be possible this protocol to have hop-by-hop routing > and have source-routing techniques before calling for WGLC? However, > I am happy that OLSRv2-15 has deleted it and now I am about to finish > my comments on the new draft. >=20 >> And asking the "WG secretary" isn't a practical idea because >> first who is that? and second how would he or she know? The people = to ask >> would be the draft authors - and I'm one of those. If I have the = information >> it's buried in a large pile of emails I have zero interest in looking >> through. >=20 > Ok, I don't want to know the person either and don't want to discuss > these buried-issues, but I just replied to comments on my interests of > DSRv2, and would like to go forward to other better discussions, This "discussion" seems to be going around and around in circles, and is = only tangentially related to a document that has cleared WGLC. 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. But please, let this thread = end. Stan >=20 > Best Regards > AB > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > On 5/31/12, Dearlove, Christopher (UK) = wrote: >> It's not in the least important to know who made the source routing >> suggestion. And asking the "WG secretary" isn't a practical idea = because >> first who is that? and second how would he or she know? The people = to ask >> would be the draft authors - and I'm one of those. If I have the = information >> it's buried in a large pile of emails I have zero interest in looking >> through. >>=20 >> I'm also afraid that's not the only example of what I'd characterise = as >> muddled thinking in this and previous posts. >>=20 >> However I don't choose to discuss this further, I just wanted to make = the >> point I made in my last posting, which is done. >>=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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >> Sent: 31 May 2012 14:40 >> To: Dearlove, Christopher (UK) >> Cc: Henning Rogge; manet; ulrich@herberg.name >> Subject: Re: [manet] A view on packet-BB >>=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 Chris, >>=20 >> I agree and like your statement 'Interesting is not enough, what we >> should be doing in an IETF WG is something people want or even need', >> however, it should not mean that discussion-list should not include >> interests, or motivations, because IMO interests are the most >> important thing to start any work in any organisations, yes you or me >> may not be interested in something today but some one maybe = interested >> in it today or tomorrow. However, if we don't remember who mentioned >> to include the source routing without knowing how it will be working, >> this should not be in our IETF discussion. We should know who is >> discussing and who mentions so we can ask him again why you want this >> or that, otherwise we have no communication. If this idea was >> important I will request the WG secretary to find out who mentioned >> the idea of source routing in OLSRv2, so we can see his/her views, so >> we can have good discussion in it. I am not interested to know, but I >> hope in future we know who put any idea/interest in any manet-draft = so >> we can question them and the authors in our discussions. >>=20 >> Regarding puting interests in the list I think it is healthy, but >> puting interests-without-discussions into drafts is not healthy in >> IETF. The one that mentioned source routing to include in some >> OLSRv2-draft had an interest and still authors put it through to the >> draft without they knowing if relevant. In my post discussion I am = not >> asking any one to put my interest in any draft, but I am asking the = WG >> to think about it, and if someone else is interested, then I will = open >> discussion about that when knowing that person. Therefore, my >> interests will still go through to the discussion list, and hope that >> others do the same so we can see more discussion, that in future make >> better drafts or even more focused drafts. >>=20 >> sorry to reply in long message, >>=20 >> Regards >> Abdussalam Baryun, >>=20 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Hi Charlie, and All >=20 > 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. >=20 > 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. >=20 > Abdussalam Baryun, > University of Glamorgan, UK. > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From abdussalambaryun@gmail.com Thu May 31 08:30: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 74C6821F8780 for ; Thu, 31 May 2012 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=-0.111, 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 VmNP+guLjThT for ; Thu, 31 May 2012 08:30:32 -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 278D121F8783 for ; Thu, 31 May 2012 08:30:32 -0700 (PDT) Received: by vcqp1 with SMTP id p1so752864vcq.31 for ; Thu, 31 May 2012 08:30:31 -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=z1jYeeUaeXfsn8r/Dv8f0KpUXrMSMiJBNLg1WbKvKaI=; b=Io/8Dtfpr6WU9prgZyb+78qCa1rP041WRNIk2jifDfh9Grbyib+9X1XeABiYYgHpdo 29vqlz15bgLYc9cQYb6+jHFXD7JR1+6jvpwOEWSiYtpe5E9x7KaYAk7Wv8nU9Z4Nwewk S6Sky9oawFFOaMMrQUgt0v83euYM7ciR0MW2hu/BnthqBNf8wmSlMcGree5t0M0/teHz 8pmPMs5L4vK4OqYC9MGfwliZ64DuF9tYLUjnAyRFn8K7PQ99o9raGGqarTcwfX/S9odZ fg7aDDrtB8uEahQwOYzQurgmanKAAn+VqRODW43xw07N76BwwToEe0c/WQeotALbjR8W O9Xw== MIME-Version: 1.0 Received: by 10.220.150.205 with SMTP id z13mr6339026vcv.19.1338478231565; Thu, 31 May 2012 08:30:31 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 08:30:31 -0700 (PDT) Date: Thu, 31 May 2012 17:30:31 +0200 Message-ID: From: Abdussalam Baryun To: Stan Ratliff Content-Type: text/plain; charset=ISO-8859-1 Cc: "jpmacker@gmail.com" , manet Subject: [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: Thu, 31 May 2012 15:30:33 -0000 Hi Stan, >But please, let this thread end. Thank you for your comments. I am sorry not sure which you want me to end, I am discussing the use of RFC5444 (packet-bb) by manet protocols in this subject: Re:A view on packet-bb, so I don't see that I am around. Active Drafts as AODVv2, OLSRv2, DLEP, are using the technique of packet-bb and I commented on these and related issues. Yes, I am interested to participate in drafting DSRv2 and will need some time to find who are interested first using the list, then I open a discussion about it, if you and group don't mind. I understood from the group 83 meeting you mentioned that we need to discuss the use of RFC5444, and that is what I am doing. So do you mean that you want to stop the discussion you requested, or do you mean that we stop discussing OLSRv2-draft because cleared WGLC. If the last reason, I thought I still can discuss and comment on any thing, draft or RFC in the list any time as long it relates to MANET group purposes. Please advise, AB ++++++++++++++++++++++++++++++++++++++++++++ On 5/31/12, Stan Ratliff wrote: > > On May 31, 2012, at 10:27 AM, Abdussalam Baryun wrote: > >> Hi All, >> >> Henning> Not sure why it was ever there, because the mechanism to use >> source >>> routing with OLSR was never described in the draft. Feel free to write >>> an extension draft OLSRv2-with-sourcerouting. >>> Can you state a reason why you think that source routing is interesting >>> for you? >>> I know it makes a lot of trouble, but whats the advantage if every OLSR >>> node >>> (as an example) has to store the whole topology anyways? >> >> Chris> I agree with Henning, including on his emphasised point. >> >> I noticed that OLSRv2-14 draft was presented at 83 meeting and authors >> proposed it for last call because there are no important issues, so >> Henning's question still stands: Why someone want source-routing in >> OLSRv2? and mine is to authors: Why OLSRv2-author did not discussed >> about how it can be possible this protocol to have hop-by-hop routing >> and have source-routing techniques before calling for WGLC? However, >> I am happy that OLSRv2-15 has deleted it and now I am about to finish >> my comments on the new draft. >> >>> And asking the "WG secretary" isn't a practical idea because >>> first who is that? and second how would he or she know? The people to >>> ask >>> would be the draft authors - and I'm one of those. If I have the >>> information >>> it's buried in a large pile of emails I have zero interest in looking >>> through. >> >> Ok, I don't want to know the person either and don't want to discuss >> these buried-issues, but I just replied to comments on my interests of >> DSRv2, and would like to go forward to other better discussions, > > This "discussion" seems to be going around and around in circles, and is > only tangentially related to a document that has cleared WGLC. 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. But please, let this thread end. > > Stan > > >> > >> Best Regards >> AB >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> On 5/31/12, Dearlove, Christopher (UK) >> wrote: >>> It's not in the least important to know who made the source routing >>> suggestion. And asking the "WG secretary" isn't a practical idea because >>> first who is that? and second how would he or she know? The people to >>> ask >>> would be the draft authors - and I'm one of those. If I have the >>> information >>> it's buried in a large pile of emails I have zero interest in looking >>> through. >>> >>> I'm also afraid that's not the only example of what I'd characterise as >>> muddled thinking in this and previous posts. >>> >>> However I don't choose to discuss this further, I just wanted to make >>> the >>> point I made in my last posting, which is done. >>> >>> -- >>> 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: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] >>> Sent: 31 May 2012 14:40 >>> To: Dearlove, Christopher (UK) >>> Cc: Henning Rogge; manet; ulrich@herberg.name >>> Subject: Re: [manet] A view on packet-BB >>> >>> ----------------------! 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 agree and like your statement 'Interesting is not enough, what we >>> should be doing in an IETF WG is something people want or even need', >>> however, it should not mean that discussion-list should not include >>> interests, or motivations, because IMO interests are the most >>> important thing to start any work in any organisations, yes you or me >>> may not be interested in something today but some one maybe interested >>> in it today or tomorrow. However, if we don't remember who mentioned >>> to include the source routing without knowing how it will be working, >>> this should not be in our IETF discussion. We should know who is >>> discussing and who mentions so we can ask him again why you want this >>> or that, otherwise we have no communication. If this idea was >>> important I will request the WG secretary to find out who mentioned >>> the idea of source routing in OLSRv2, so we can see his/her views, so >>> we can have good discussion in it. I am not interested to know, but I >>> hope in future we know who put any idea/interest in any manet-draft so >>> we can question them and the authors in our discussions. >>> >>> Regarding puting interests in the list I think it is healthy, but >>> puting interests-without-discussions into drafts is not healthy in >>> IETF. The one that mentioned source routing to include in some >>> OLSRv2-draft had an interest and still authors put it through to the >>> draft without they knowing if relevant. In my post discussion I am not >>> asking any one to put my interest in any draft, but I am asking the WG >>> to think about it, and if someone else is interested, then I will open >>> discussion about that when knowing that person. Therefore, my >>> interests will still go through to the discussion list, and hope that >>> others do the same so we can see more discussion, that in future make >>> better drafts or even more focused drafts. >>> >>> sorry to reply in long message, >>> >>> Regards >>> Abdussalam Baryun, >>> >> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> 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. >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet > > From charliep@computer.org Thu May 31 08:47: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 0EE9E11E812A for ; Thu, 31 May 2012 08:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 nrTeP8tiLYp9 for ; Thu, 31 May 2012 08:47: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 010FE11E811C for ; Thu, 31 May 2012 08:47:12 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.84]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Sa7ai-000160-9e; Thu, 31 May 2012 11:47:12 -0400 Message-ID: <4FC79274.7060003@computer.org> Date: Thu, 31 May 2012 08:47:00 -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: <4FC67102.50903@computer.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020508050705010106020301" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad864363b3e035e8257cd9e426c663999cee350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 15:47:14 -0000 This is a multi-part message in MIME format. --------------020508050705010106020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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. --------------020508050705010106020301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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 <charliep@computer.org> 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.
--------------020508050705010106020301-- From abdussalambaryun@gmail.com Thu May 31 09:11: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 407B711E8146 for ; Thu, 31 May 2012 09:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.101 X-Spam-Level: X-Spam-Status: No, score=-3.101 tagged_above=-999 required=5 tests=[AWL=-0.101, 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 eahHjdrWKFz8 for ; Thu, 31 May 2012 09:11: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 4F69011E8138 for ; Thu, 31 May 2012 09:11:51 -0700 (PDT) Received: by vcqp1 with SMTP id p1so786801vcq.31 for ; Thu, 31 May 2012 09:11: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; bh=DyyIDJ9sFu2M9/WfQ7QwPDD6mr4yEYloUgQLrolBzmk=; b=w0xmmis+hu6+N10K5T2Ll7FgZEJ+rCosZdSi29LDq06AmGyXXSpfKMIiH7K0mlzrKg aIidenlqelK+AjcM28SNTBsDHIgea2MqkNJRSIXVSAGZNR215mpHwwFFmcsXfKRQ1dTn 81OTJ+BtxvvUX9OWMlGFmSn27l2kYcF4PsnFBs2d9xuN6+uIZQicYgTSRh2qQwt+7aJb +JLHPumTmfZn2642GSEcvGBIVewVdLp4LN1FDgmauatCoiEJXI0y3OgcDzQ7aKQdTab3 2MPqb6u5Zm1lFKVSYmehJr/g8OMBy8XDEZJU60UqgWmZRjtPiIf1ZtocSMJxSSDBUtA6 pZJQ== MIME-Version: 1.0 Received: by 10.220.151.80 with SMTP id b16mr2796912vcw.4.1338480710722; Thu, 31 May 2012 09:11:50 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 09:11:49 -0700 (PDT) In-Reply-To: <4FC79274.7060003@computer.org> References: <4FC67102.50903@computer.org> <4FC79274.7060003@computer.org> Date: Thu, 31 May 2012 18:11:49 +0200 Message-ID: From: Abdussalam Baryun To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Cc: manet Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 16:11:52 -0000 Hello Chalie, I agree with you regarding DYMO and AODVv2. Also thank you for your comments, it will help us in the group's progress testing. Best regards Abdussalam Baryun University of Glamorgan, UK. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ On 5/31/12, Charles E. Perkins wrote: > > 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. > > From d.sturek@att.net Thu May 31 09:29: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 6424111E8091 for ; Thu, 31 May 2012 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.602 X-Spam-Level: X-Spam-Status: No, score=-0.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=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 JzEHNNmkF5gF for ; Thu, 31 May 2012 09:29:18 -0700 (PDT) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by ietfa.amsl.com (Postfix) with SMTP id F2A8111E807F for ; Thu, 31 May 2012 09:29:17 -0700 (PDT) Received: from [98.139.215.143] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2012 16:29:17 -0000 Received: from [68.142.200.224] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 31 May 2012 16:29:17 -0000 Received: from [66.94.237.113] by t5.bullet.mud.yahoo.com with NNFMP; 31 May 2012 16:29:17 -0000 Received: from [127.0.0.1] by omp1018.access.mail.mud.yahoo.com with NNFMP; 31 May 2012 16:29:17 -0000 X-Yahoo-Newman-Id: 73468.46721.bm@omp1018.access.mail.mud.yahoo.com Received: (qmail 35374 invoked from network); 31 May 2012 16:29:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1338481757; bh=2BN/X8AacUd958/WbcytUgykgBBVuTvMQ8PVjPx6BrE=; 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=weCBqDEOIQ77O2Kk3FYoA6GpmJCA7qfKifFgvz+mEFCQKQ8WwlkhxtXUPwHjEMLvLqv1oMDNPNTHgnja6f5MGVrlPC5DDQllN0oVa+RagZ4m77CV4OrjZiTMTvbCyEBju9dscfHiv4bGQu8oYRyaOVLdn0KgOC3RiL3NAQ4GIrA= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: q3Rr9VoVM1lEkAN9nqpySAfeRVXGaYxUeYLJFD1rhGjimkC cir6yd8CtB5_h1BdlrypTCXK333wdYOSE4VCX5Sxc7se1q90QZIc9QEJg3Dq bOVe0kqbb8v2qzE3fN5nZWVEOUJjhSM9Z8moBCy9RrYCiuvzraIcrWMOUWeU JpICpAGRvFbCHwhi1sv1sv5Rj0384gSXHmv7zAazKmm8tOW4NJ71lXnkkezx mprJ6.EmY3OfqE_jLtvNSi771IzPPqZvTHP8HdvSCjsETH42y90BVZiKuQkd Lhz8lEBjsNWJxmMj88pfwoDBx4fiewwwaOQwYLcaTL3L6a86QyBHKygoy.7y SWvuUIV4uO8xFbK0FVSi_rAqoRCGsvuevdhH8iYUYKqyzoZCzUVyqSGj8C6n IFWQKaqgUIoq.muZnLzZEjVpBwFSkBU2Mqg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.143] (d.sturek@66.27.60.174 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 31 May 2012 09:29:16 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 31 May 2012 09:29:14 -0700 From: Don Sturek To: "Charles E. Perkins" , Abdussalam Baryun Message-ID: Thread-Topic: [manet] A view on packet-BB In-Reply-To: <4FC79274.7060003@computer.org> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3421301356_198281" Cc: manet Subject: Re: [manet] A view on packet-BB 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, 31 May 2012 16:29:19 -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_3421301356_198281 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit 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 --B_3421301356_198281 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hi Charlie,

I think updating AODV would be a great idea.   We have some ex= perience with AODV in a commercial deployment.  Here are some enhanceme= nts to consider:
1)  Neighbor table management supported by e= xchanging one hop messages containing LQI between one hop neighbors.  T= his would be nicely supported via Packet BB.
2)  Pruning of n= eighbor table entries to ensure two way communication (allows for use of for= ward routing path as the return routing path)
3)  Multicast r= oute replies from data sink devices (many to one feature)
4)  = ;Optimization of route tables to reduce size (have a look at AODV Jr in Sour= ceForge)

Overall, AODV has many benefits that would= be useful as an enhanced RFC.

Don



From: = "Charles E. Perkins" <charliep@com= puter.org>
Organization: Sa= ratoga Blue Skies
Date: Thursday, = May 31, 2012 8:47 AM
To: Abdussala= m Baryun <abdussalambaryun@gm= ail.com>
Cc: manet <manet@ietf.org>
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.&nbs= p; 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, regardles= s 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 divergenc= e, 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 wa= s 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 <charliep@computer.org> 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 a= re 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 th= at 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. &= nbsp;In fact, this was
    always possible even with AODV, but somehow the HEL= LO messages
    were viewed as a central part of AODV even after th= e 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 --B_3421301356_198281-- From abdussalambaryun@gmail.com Thu May 31 13:23:50 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 972C621F86CF for ; Thu, 31 May 2012 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 zJnNLCfj+p-w for ; Thu, 31 May 2012 13:23:49 -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 EB3CF21F86CE for ; Thu, 31 May 2012 13:23:48 -0700 (PDT) Received: by vcqp1 with SMTP id p1so972508vcq.31 for ; Thu, 31 May 2012 13:23:48 -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=ypsKLCJJ3t+fcurN/44zjtu+WVUMHFEH7YnJHqpYwiw=; b=qvn5sg+dmAxH09Tb0DEVj9Dt2Am5Zx4TUj3WeHuLhknv7JJ2mVVBY/m3TduOZwXL+4 Z5TR5dsEnwH3dq8MQ47kQ3KnmgikDmQ54SbqktjtsAbc8kvF8Ezgx3hD3hceFGNpqAgc mRhBLxwUKNmkdTG+N8iKsYp3MxeyAMcOou/GM0cSc8uGQv7VfmL4VkpPZ5L4A1dD1fgv cl6F8U6RnwhP8mxpRb8lWA3jvn6kLZnSO36ZVNgn0QXOuhwDbdaKtQVRyHoQ11J41nf3 8PyF4QJ3oRntQy9DNA4w6EztCliBrGAtjYuZBuzF3mHfDwV1BFUP+q4TxZzlrKPxRGuy cvHg== MIME-Version: 1.0 Received: by 10.52.100.4 with SMTP id eu4mr39683vdb.66.1338495828481; Thu, 31 May 2012 13:23:48 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 31 May 2012 13:23:48 -0700 (PDT) Date: Thu, 31 May 2012 22:23:48 +0200 Message-ID: From: Abdussalam Baryun To: manet Content-Type: text/plain; charset=ISO-8859-1 Cc: Emmanuel.Baccelli@inria.fr Subject: [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: Thu, 31 May 2012 20:23:50 -0000 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
On Tue, May 1, 2012 at 4:41 A= M, Abdussalam Baryun <abdussalambaryun@gmail.com> w= rote:
Herberg>so far, nobody else seemed t= o be confused on which layer OLSRv2 is used (or how the interfaces are defi= ned). >IMO, unless other people in the WG see the same danger of confusi= on, I would not change it.
I have no problem with your reaction, so than wait until you get other= voices then (not sure how many you want), as long as the draft doesn't= care about each single review-comment it only follows majority agreement o= n comments. This type of review-system makes the document=A0not include all= readers level of knowledge, that means the document is for specific group = which exclueds other readers or groups.

The IETF does not work by means of "majority&quo= t; (which is not even possible since there is no formal membership), but by= rough consensus (and running code). And every individual can (and should!)= review a document and give suggestions, which can help to improve a docume= nt. I just don't see how your suggestions about the MANET/OLSRv2 interf= aces would improve the OLSRv2 draft (for the reasons that Chris, Thomas and= I have pointed out).

Regards
Ulrich

=A0
However, I just will mention my comments and do my work,= I really don't care of the outcome decision, but I will care if I auth= ored a reviewed document.

clausen>An OLSRv2 interface can be physical or virtual. Chris expla= ined it well, I suggest re-reading his email.
=A0
chris explained>An OLSRv2 interface (a special case of a MANET interface, see RFC 6130) is= an IP interface, one which IP receives packets on, has one or more IP addr= esses etc. It has a data link layer below it, but OLSRv2 doesn=92t care abo= ut that. Your statement =93a MANET interface is a data link interface=94 is= wrong.

Ok, I read again.=A0It does not mention that it may be physical. I unde= rstand from him it never can be physical, so I needed that to be clear, but= now you mentioned that it can be physical.
=A0
Abdussalam Baryun
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++= +++++++
=A0
On Mon, Apr 30, 2012 at 10:28 PM, Ulrich Herberg= <ulrich@herberg.name> wrote:
Abdussalam,

so far, nobody els= e seemed to be confused on which layer OLSRv2 is used (or how the interface= s are defined). IMO, unless other people in the WG see the same danger of c= onfusion, I would not change it.

Regards
Ulrich=20


On Mon, Apr 30, 2012 at 2:10 PM, Abdussalam Bary= un <abdussalambaryun@gmail.com> wrote:
Hi Herberg,
=A0
I am suggesting to clarify interfaces, I d= onot like=A0to change=A0if unnecessary. Mentioning that an interface is in = the layer 3, or its logical, or even just explaining the way Chris defined = to me, really makes difference. My question is why is the draft not mention= ing that OLSRv2-interface is an IP-interface or a logical-interface? Does t= he authors see that this information is not important? or even MANET-interf= aces are in layer 3.=A0 If we define protocols without mentioning which lay= er it is located in, then how can we define such protocol, its layer-locati= on is more important than its functionality, because each layer has its spe= cial interfaces, functions, services, and messages. There are many document= s that explain interface in the same model that OLSRv2 is presenting so why= didn't have confusion when I read them?

>An OLSRv2 interface (a special case of a MANET= interface, see RFC 6130) is an IP interface, one which IP >receives pac= kets on, has one or more IP addresses etc. It has a data link layer below i= t, but OLSRv2 doesn=92t >care about that. Your statement =93a MANET inte= rface is a data link interface=94 is wrong.

>I don't think there is any confusion. Chris has pointed out the= relationship between MANET interface and OLSRv2 >interface clearly. I t= hink that RFC6130/draft-ietf-manet-olsrv2 define the terminology correctly.= If you would like to >change anything, please suggest concrete text to = replace, so that I can better understand what you mean.

I disagree that there is no confusion. There are confusions in defining= terms in MANET WG, I have seen in the past a long discussion between many,= just arguing about defining host or router, and now l was confused of inte= rfaces in OLSRv2-draft. Maybe because I am not much familiar with OLSR, or = reading about network-interface in many papers, and I read RFC2501 (it refe= rs alot to wireless interface and communications) and mentioned in RFC6130 = for the interface as attach to communication medium, I thought it was a med= ium as physical medium.

I suggest to clarify by adding information in one of the following expl= anation to the draft (even a line will do):
=A0
- Mentioning which layer(s)=A0the OLSRv2-interface works or allowed to= be at by the protocol, or
- defining the MANET-interface as=A0Chris defined (IP-interface, at la= yer 3) in terminology, or
- mentioning that OLSRv2-interface is not a wireless interface, or
- defining MANET-interface as logical interface.

I am sorry to disturb, I actually still have many comments for OLS= Rv2-draft and will try to submit, and let the WG to decide. However, I than= k you and Chris to explain to me so at least my other comments will be in u= nderstanding.

Abdussalam
++++++++++++++++++

On Mon, Apr 30, 2012 at 5:45 PM, Ulrich Herberg = <ulrich@herberg.name> wrote:
Abdussalam,

RFC6130 defines:= =20


MANET interface:
An interface participating in a MANET and = using this neighborhood
=A0=A0=A0=A0=A0 discovery protocol.=A0 A router = may have several MANET interfaces.

And draft-ietf-manet-olsrv2= defines:=20

OLSRv2 interface:
=A0=A0=A0=A0=A0 A MANET interface running thi= s protocol.=A0 A router running this
=A0=A0=A0=A0=A0 protocol MUST have = at least one OLSRv2 interface.

In one of the last OLSRv2 revis= ions, we made sure that OLSRv2 differentiates between neighbors running onl= y NHDP and neighbors running also OLSRv2, and only the latter are used for = MPR selection, etc. I do not understand what you would like to change in th= e OLSRv2 draft.

See comments below:

On Mon, Apr 30, 2012 at 8:24 AM, Abdussalam Baryun &= lt;abdussal= ambaryun@gmail.com> wrote:
Hi Henning,
=A0
Please note that I read the first pages of draft=A0many times before p= osting any information.
=A0
HR>I would suggest reading the OLSRv2-draft again, especially secti= on 2.=20


>OLSRv2 interface:
>A MANET interface running this pr= otocol. =A0A router running this
>protocol MUST have at least one OLS= Rv2 interface.

HR>A routing protocol which does not run on = any interface would be pretty
>useless, right?
You reply to the second sentence not the first which has 'running = this protocol' relating it not to the router it is relating it to the i= nterface. I know that router must have at least a network-interface ( or da= ta-link-layer)=A0or=A0MANET interface, this is not what I commenting and th= e draft is mentioning. We don't assume at least Data-Link because it is= obvious and we are following TCP/IP model in the internet, but not at leas= t a specific-interface called bla bla.
=A0
Why it defines the 'OLSRv2-interface' as a MANET-interface tha= t RUNS this protocol (OLSRv2) this means there is some thing=A0related to O= LSRv2 in the layer-2. You should read again another paragraph mentioning as= if there is difference between MANET-interface and OLSRv2-interface.
=A0
OLSRv2-14>p9>

Supports routers that eac= h have one or more participating OLSRv2

interfaces, which will co= nsist of some or all of its MANET

interfaces using [RFC6130]. The set of a router=92s OLSRv2<= /span>

interfaces, and the sets = of its other MANET and non-MANET

interfaces, may change ov= er time. Each interface may have one or

more network addresses (w= hich may have prefix lengths), and these

may also be dynamically c= hanging.

=A0
AB> it is clear from the above draft-page-9, that all MANET interfa= ces=A0are not an OLSRv2-interface, but All OLSRv2 interfaces are MANET-inte= rfaces. So we have to have in or node at least an OLSRv2-interface, not at = least one MANET-interfac so the protocol to work correctly.
=A0
AB> The above page-9 mentions NHDP as well that interfaces need thi= s protocol. What if there is not NHDP, or if it is not working, what will h= appen. The draft SHOULD explain these issues.


=A0
AB> It may be that all OLSRv2 routers (as implementation point of p= ractice) only need at least one MANET interface. But the authors need to ch= ange. therefore, we know that All routers need at least on interface, but t= he draft-wording has a special OLSRv2-interface. Then we need to change the= draft wording to the right explaination.


Can you suggest what you would like to change? I don't und= erstand your point.

Best regards
Ul= rich
=A0+++++++++++++++++++++++++++++++++++++++++++


Hi Chris
=A0
ok then if it was simple to explain as a special interface=A0as IP-int= erface why we have OLSRv2_draft saying that it is network-interface as MANE= T is a network, but IP is not it is a protocol. IMO it=A0is wrong to refer = to a network while you mean a protocol, even though I know I may misunderst= ood. I sugget that this SHOULD be explained clearly. I think every one seem= s to understand that network-interface must include=A0Data-Link-layer, ther= efore, RFC6130 or OLSRv2-draft should define well as you did. I thank you f= or your comment,
=A0
Therefore I suggest to change OLSRv2-interface definition as Chris def= ined it very clearly. I hope the draft can=A0change the definition,
=A0
Abdussalam

++++++++++++++++++++++++++++++++++++++++++++++= +++++++++++++++++++++++++++
On Mon, Apr 30, 2012 at 4:25 PM, Dearlove, C= hristopher (UK) <Chris.Dearlove at bae= systems.com> wrote:


An OLSRv2 interface (a special = case of a MANET interface, see RFC 6130) is an IP interface, one which IP r= eceives packets on, has one or more IP addresses etc. It has a data link la= yer below it, but OLSRv2 doesn=92t care about that. Your statement =93a MAN= ET interface is a data link interface=94 is wrong.

=A0

--

Christopher Dearlove

Senior Principal Engineer, Comm= unications Group
Communications, Networks and Image Analysis Capability<= br> BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Bad= dow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194<= /a>=A0|=A0 Fax: +44 1245 242124

chris.dearlove at baesystems.com | http://www.baesys= tems.com


<= br>