From nobody Sun May 4 09:55:27 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F0F1A01BE for ; Sun, 4 May 2014 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBYq0h76mSrI for ; Sun, 4 May 2014 09:55:22 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACE41A01BC for ; Sun, 4 May 2014 09:55:22 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so1309406veb.41 for ; Sun, 04 May 2014 09:55:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7noMZpsK3/to0MFoZW1eJ7hgqKkOx5ZaY2azxjNApkw=; b=FUtSK6LKTqsEY1aN75Pa3EOH8DzQanDAIHqVn0iacCzrW+4/qUVibiKuYzPqpABe2u xsa3murZHzBhkN8I3OQBwJWnRZX09CfNLQDDdjciT9vfo4NohkccKASHET9FNackwnqx hIZ7nAc/39kRuYkkQgGP5S3ElCkHPZ9kpR2LnfNUXGjqQK0AoLg2YkKtTjZosolX1xyg j/vNOFnE+WV23dKn6wjuxP9PKVNGxJ8VLk50H6iOa9+veiZmXi0156UFgd35zdVhpIZd lqEM7vfo585SQehFYDxM+qORIVWaPrMFlwMYFesFYgHwJNhMgJJRLMUkpU6kRmfCZFwD MMRw== MIME-Version: 1.0 X-Received: by 10.58.181.170 with SMTP id dx10mr1417819vec.25.1399222519317; Sun, 04 May 2014 09:55:19 -0700 (PDT) Received: by 10.58.150.135 with HTTP; Sun, 4 May 2014 09:55:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 17:55:19 +0100 Message-ID: From: John Dowdell To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7b676da439caef04f895e159 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/byly77CDRu6lL110zmI_yEw3F6c Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 16:55:24 -0000 --047d7b676da439caef04f895e159 Content-Type: text/plain; charset=UTF-8 Abdussalam I do not have time to search just now, but search the DLEP list around the time of the last conference. The list is there for all to see, on an email posted by Rick. Nothing is hidden. John On Wednesday, April 30, 2014, Henning Rogge wrote: > Hi, > > I think Stan is just very busy with other things at the moment. The DT > thinks we resolved all our open points, so the next draft will be the > result of the design team to the mailing list. The DT can be shut down > after this and we can have a look at the result on the Manet List, > hopefully going towards a WGLC. > > Henning Rogge > > On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun > > wrote: > > I need to see Rick's list mentioned in the 89 WG meeting. As > > understood from the meeting there was consensus on going for a minimal > > spec for DLEP and extensions for other future documents (and maybe > > having WGLC after draft-06 in July 2014). > > > > AB > > > > _______________________________________________ > > 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 > --047d7b676da439caef04f895e159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Abdussalam

I do not have time to search just now, but se= arch the DLEP list around the time of the last conference. The list is ther= e for all to see, on an email posted by Rick.=C2=A0Nothing is hidden.
=

John

On Wednesday, April 30, 2014, Henning Rogge <= hrogge@gmail.com> wrote:
Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal=
> spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--047d7b676da439caef04f895e159-- From nobody Mon May 5 09:07:05 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B911A038B for ; Mon, 5 May 2014 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_kOmpt8Ox3j for ; Mon, 5 May 2014 09:07:01 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C6B261A039D for ; Mon, 5 May 2014 09:07:01 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 142so960900ykq.4 for ; Mon, 05 May 2014 09:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X+Chc0bf+1hjBsrebC2yHD1j8r6MAElwcmH5wqOLZkk=; b=Apbqc9RhvCp5neygKGBV/8MlX6ATXl7QloZHx8N9vSvYA+HmChhsTPJQpdvW0HuEQY FvWvus5rzHgKXl+vK34K0LuHKr/NVkTULNT36HyHSfGGZ7cOz1xg+NWVjZ/TGxeBq6i3 74k+4oxnMETppxyxnXIG5n+HTkVKThseGMXIGQ55+Zy6vnUB5mgEvCCbn9E+s7IJ8zun 5gYYG5PaECXGYEiZAhK7YdPuyp5QZldsEY8kmIQ6vv991c/d4a537m18mcYj2gOed2ek BDXRi68Q+qg66mbBGYp9MLK0kHN50BM65UHfUMf4GTLb+kIsB/r1p0+gvoWp3j+fxxfK 0fgA== MIME-Version: 1.0 X-Received: by 10.236.199.212 with SMTP id x60mr48484334yhn.90.1399306017992; Mon, 05 May 2014 09:06:57 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Mon, 5 May 2014 09:06:57 -0700 (PDT) In-Reply-To: References: Date: Mon, 5 May 2014 17:06:57 +0100 Message-ID: From: Abdussalam Baryun To: John Dowdell Content-Type: multipart/alternative; boundary=bcaec52c622322a27c04f8a95244 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/3_TcBoVvvw41sCaJNMzBE3Ve-uk Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 16:07:03 -0000 --bcaec52c622322a27c04f8a95244 Content-Type: text/plain; charset=UTF-8 John, The list mentioned in the meeting by Rick, I understood it was a new one/update and it was to be sent to WG for the new version -06 to consider, so I just asked if it can be sent/found and not only mentioned in minutes. I may misunderstood. AB On Sunday, May 4, 2014, John Dowdell wrote: > Abdussalam > > I do not have time to search just now, but search the DLEP list around the > time of the last conference. The list is there for all to see, on an email > posted by Rick. Nothing is hidden. > > John > > On Wednesday, April 30, 2014, Henning Rogge > > wrote: > >> Hi, >> >> I think Stan is just very busy with other things at the moment. The DT >> thinks we resolved all our open points, so the next draft will be the >> result of the design team to the mailing list. The DT can be shut down >> after this and we can have a look at the result on the Manet List, >> hopefully going towards a WGLC. >> >> Henning Rogge >> >> On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun >> wrote: >> > I need to see Rick's list mentioned in the 89 WG meeting. As >> > understood from the meeting there was consensus on going for a minimal >> > spec for DLEP and extensions for other future documents (and maybe >> > having WGLC after draft-06 in July 2014). >> > >> > AB >> > >> > _______________________________________________ >> > 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 >> > --bcaec52c622322a27c04f8a95244 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John,

The list mentioned in the meeting by Rick,=C2=A0I = understood it was a new one/update=C2=A0and=C2=A0it was to be sent to WG fo= r the new version -06 to consider, so I just asked if it can be sent/found = and=C2=A0not only mentioned in minutes. I may misunderstood.=C2=A0

AB

On Sunday, May 4, 2014, John Dowdell wrote:<= br>
Abdussalam

I do not ha= ve time to search just now, but search the DLEP list around the time of the= last conference. The list is there for all to see, on an email posted by R= ick.=C2=A0Nothing is hidden.

John

On Wednesday, April 30, 2014, Henning Rogge <= hrogge@gmail.com> wrote:
Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal=
> spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--bcaec52c622322a27c04f8a95244-- From nobody Mon May 5 12:59:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7671A0484 for ; Mon, 5 May 2014 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx9AuJO-F-nb for ; Mon, 5 May 2014 12:59:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 493FA1A01AF for ; Mon, 5 May 2014 12:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7404; q=dns/txt; s=iport; t=1399319973; x=1400529573; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3r/VTdDB9Sv8h7eH1NLNABHp2M4O2IGrbn8M5g3poxY=; b=kbgF/99jr8OV2nwTzsSLF6z/YfblWdbzDGvY9A4RITUCDjGag/Iv4o4N Q1KnbZFdy88kXlVK8Zz7BnstbZiYlnQRa4ge21pdmpDd7Q0A69M0BBBlV 0IEm3WVrX9DjtCKwIw7C7kdbOP0SCc7K7vcrnYs9v4b+kFiW733jq4R1d k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0FACnsZ1OtJA2G/2dsb2JhbABZgwZPWL0LAYc6gRoWdIIlAQEBBAEBAWUGCxACAQgYJwchBgsUEQIEDgWILQMRDcZoDYZCEwEDBow1gTURAUwEB4MqgRUEhXaRTIFyjReFXYM0gXY5 X-IronPort-AV: E=Sophos;i="4.97,991,1389744000"; d="scan'208,217";a="319490268" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 05 May 2014 19:59:32 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s45JxWeb014211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 May 2014 19:59:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 5 May 2014 14:59:32 -0500 From: "Stan Ratliff (sratliff)" To: Abdussalam Baryun Thread-Topic: [manet] DT output list and WG decision for DLEP Thread-Index: AQHPZHuWmK3twfVp5EKoHs3p+XQuipsqkM4AgAZtT4CAAYTRgIAAQPqA Date: Mon, 5 May 2014 19:59:31 +0000 Message-ID: <53B9A477-060E-43D6-8DD8-5265539C9930@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.184] Content-Type: multipart/alternative; boundary="_000_53B9A477060E43D68DD85265539C9930ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hERdAzSHA9Z42qtHRoACSf0BUXk Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 19:59:38 -0000 --_000_53B9A477060E43D68DD85265539C9930ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable AB, The members of the design team reached consensus on content to be changed/a= dded/deleted from -05 to create a -06. IIRC, Rick's email contained a synop= sis of the conclusions reached by the members of the DT. For the record, I'= ll note again - the opinions of the DT are just that: Opinions. As always, = it is up to the Working Group as a whole to reach consensus on any WG docum= ent. As Henning mentioned in his email, I've been incredibly busy with my "day j= ob" recently. I still plan on posting an 06 version of DLEP prior to the ne= xt IETF meeting for the working group to consider and comment on. As of thi= s writing, I cannot provide a ETA - I'm still pretty swamped. As was also m= entioned by Henning (and Rick in his original email), the DT decided to cea= se operation at the last IETF, as the members had reached consensus on all = of the DT-chartered items. Regards, Stan On May 5, 2014, at 12:06 PM, Abdussalam Baryun > wrote: John, The list mentioned in the meeting by Rick, I understood it was a new one/up= date and it was to be sent to WG for the new version -06 to consider, so I = just asked if it can be sent/found and not only mentioned in minutes. I may= misunderstood. AB On Sunday, May 4, 2014, John Dowdell wrote: Abdussalam I do not have time to search just now, but search the DLEP list around the = time of the last conference. The list is there for all to see, on an email = posted by Rick. Nothing is hidden. John On Wednesday, April 30, 2014, Henning Rogge > wrote: Hi, I think Stan is just very busy with other things at the moment. The DT thinks we resolved all our open points, so the next draft will be the result of the design team to the mailing list. The DT can be shut down after this and we can have a look at the result on the Manet List, hopefully going towards a WGLC. Henning Rogge On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun wrote: > I need to see Rick's list mentioned in the 89 WG meeting. As > understood from the meeting there was consensus on going for a minimal > spec for DLEP and extensions for other future documents (and maybe > having WGLC after draft-06 in July 2014). > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_53B9A477060E43D68DD85265539C9930ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable AB, 

The members of the design team reached consensus on content to be chan= ged/added/deleted from -05 to create a -06. IIRC, Rick's email contained a = synopsis of the conclusions reached by the members of the DT. For the recor= d, I'll note again - the opinions of the DT are just that: Opinions. As always, it is up to the Working Grou= p as a whole to reach consensus on any WG document.  

As Henning mentioned in his email, I've been incredibly busy with my &= quot;day job" recently. I still plan on posting an 06 version of DLEP = prior to the next IETF meeting for the working group to consider and commen= t on. As of this writing, I cannot provide a ETA - I'm still pretty swamped. As was also mentioned by Henning (and Ri= ck in his original email), the DT decided to cease operation at the last IE= TF, as the members had reached consensus on all of the DT-chartered items.&= nbsp;

Regards,
Stan


On May 5, 2014, at 12:06 PM, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

John,

The list mentioned in the meeting by Rick, I understood it was a = new one/update and it was to be sent to WG for the new version -0= 6 to consider, so I just asked if it can be sent/found and not only me= ntioned in minutes. I may misunderstood. 

AB

On Sunday, May 4, 2014, John Dowdell wrote:
Abdussalam

I do not have time to search just now, but search the DLEP list around= the time of the last conference. The list is there for all to see, on an e= mail posted by Rick. Nothing is hidden.

John

On Wednesday, April 30, 2014, Henning Rogge <hrogge@gmail.com>= ; wrote:
Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal=
> spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

--_000_53B9A477060E43D68DD85265539C9930ciscocom_-- From nobody Mon May 5 13:03:47 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377B31A0196 for ; Mon, 5 May 2014 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOIAdAchg0X3 for ; Mon, 5 May 2014 13:03:43 -0700 (PDT) Received: from ironport.idirect.net (ironport.dmz.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 68BEB1A01AF for ; Mon, 5 May 2014 13:03:43 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of bsnyder@idirect.net) identity=pra; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible Received-SPF: Neutral (ironport.idirect.net: domain of bsnyder@idirect.net does not assert whether or not 10.250.250.128 is permitted sender) identity=mailfrom; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="bsnyder@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.128; receiver=ironport.idirect.net; envelope-from="bsnyder@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="4.97,991,1389762000"; d="scan'208";a="9391490" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.128]) by ironport.idirect.net with ESMTP; 05 May 2014 16:03:30 -0400 Received: from VAUS-MBX03.idirect.net ([fe80::f4a3:646a:da7:39c9]) by VAUS-CASHUB01.idirect.net ([::1]) with mapi id 14.02.0387.000; Mon, 5 May 2014 16:03:30 -0400 From: "Snyder, Brian" To: "manet@ietf.org" Thread-Topic: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Index: AQHPaJkWaoE5fYWylUqnpHbXTZ0qW5syZHoQ Date: Mon, 5 May 2014 20:03:29 +0000 Message-ID: <84585478AABBBF4B9DF597FC0F84AF7342FA3288@VAUS-MBX03.idirect.net> References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> In-Reply-To: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/KL4RPkm4rziFcpVmLJaeP6O7PEk Subject: [manet] FW: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 20:03:45 -0000 Hello all, Nobo and I have been working on publishing a new informational RFC related= to proxying BFD via monitored links. This is written as a generalized sol= ution for all monitored links, but with satellite use case as the primary e= xample. Additionally, prior to writing this document, I have actually code= d up a proof of concept which has been proven to work in the stated use cas= e. If anyone would care to review and comment it would be most appreciated. Thanks, Brian & Nobo -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, May 05, 2014 3:34 PM To: Nobo Akiya; Snyder, Brian; Nobo Akiya; Snyder, Brian Subject: New Version Notification for draft-snyder-bfd-proxy-connections-mo= nitored-links-00.txt A new version of I-D, draft-snyder-bfd-proxy-connections-monitored-links-00= .txt has been successfully submitted by Brian Snyder and posted to the IETF repo= sitory. Name: draft-snyder-bfd-proxy-connections-monitored-links Revision: 00 Title: BFD Proxy for Connections over Monitored Links Document date: 2014-05-05 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-snyder-bfd-proxy-= connections-monitored-links-00.txt Status: https://datatracker.ietf.org/doc/draft-snyder-bfd-proxy-con= nections-monitored-links/ Htmlized: http://tools.ietf.org/html/draft-snyder-bfd-proxy-connectio= ns-monitored-links-00 Abstract: This document describes a Bidirectional Forwarding Detection (BFD) proxy mechanism to allow intermediate networking equipment (ex: Satellite HUB/Modem) to intercept BFD packets and to generate BFD packets to relay the health of connection monitored links. Note that this is an informational document that does not propose any changes to the BFD protocol. = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue May 6 14:38:06 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C231A0499 for ; Tue, 6 May 2014 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VhOK8KNo78C for ; Tue, 6 May 2014 14:38:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id ACE051A03A8 for ; Tue, 6 May 2014 14:38:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id E51A0241A9B; Tue, 6 May 2014 14:37:57 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.142] (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 34FC2241895; Tue, 6 May 2014 14:37:57 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-2FB73929-1465-4BB5-87FE-09138DCD3F2F Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D201) In-Reply-To: Date: Tue, 6 May 2014 23:37:55 +0200 Content-Transfer-Encoding: 7bit Message-Id: <092E1BC3-4CAF-4D30-A114-BDB19E1D370A@thomasclausen.org> References: To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/qtfZaXjkEHQK5Uwz6oU_2ND3VaA Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 21:38:04 -0000 --Apple-Mail-2FB73929-1465-4BB5-87FE-09138DCD3F2F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable FWIW, I also recall discussions in London about a "list of issues pending re= solution" that was to be posted to manet@ietf.org - but I do not think that I= have seen that list yet. And yes, I am the person compulsively checking the secret DLEP list on a dai= ly basis, given that I am not allowed to receive mails sent to it in my emai= l client. Thomas Sent from my iPad > On 5 mai 2014, at 18:06, Abdussalam Baryun wr= ote: >=20 > John, >=20 > The list mentioned in the meeting by Rick, I understood it was a new one/u= pdate and it was to be sent to WG for the new version -06 to consider, so I j= ust asked if it can be sent/found and not only mentioned in minutes. I may m= isunderstood.=20 >=20 > AB >=20 >> On Sunday, May 4, 2014, John Dowdell wrote: >> Abdussalam >>=20 >> I do not have time to search just now, but search the DLEP list around th= e time of the last conference. The list is there for all to see, on an email= posted by Rick. Nothing is hidden. >>=20 >> John >>=20 >>> On Wednesday, April 30, 2014, Henning Rogge wrote: >>> Hi, >>>=20 >>> I think Stan is just very busy with other things at the moment. The DT >>> thinks we resolved all our open points, so the next draft will be the >>> result of the design team to the mailing list. The DT can be shut down >>> after this and we can have a look at the result on the Manet List, >>> hopefully going towards a WGLC. >>>=20 >>> Henning Rogge >>>=20 >>> On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun >>> wrote: >>> > I need to see Rick's list mentioned in the 89 WG meeting. As >>> > understood from the meeting there was consensus on going for a minimal= >>> > spec for DLEP and extensions for other future documents (and maybe >>> > having WGLC after draft-06 in July 2014). >>> > >>> > AB >>> > >>> > _______________________________________________ >>> > manet mailing list >>> > manet@ietf.org >>> > https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-2FB73929-1465-4BB5-87FE-09138DCD3F2F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
FWIW, I also recall discussions in Lon= don about a "list of issues pending resolution" that was to be posted to manet@ietf.org - but I do not think that I= have seen that list yet.

And yes, I am the person c= ompulsively checking the secret DLEP list on a daily basis, given that I am n= ot allowed to receive mails sent to it in my email client.

Thomas

Sent from my iPad

On 5 mai 2014, at 18:0= 6, Abdussalam Baryun <abdus= salambaryun@gmail.com> wrote:

=
John,

The list mentioned in the meeting by Rick,&nbs= p;I understood it was a new one/update and it was to be sent to WG= for the new version -06 to consider, so I just asked if it can be sent/foun= d and not only mentioned in minutes. I may misunderstood. 

AB

On Sunday, May 4, 2014, John Dowdell wrote:
Abdussalam

I do not have t= ime to search just now, but search the DLEP list around the time of the last= conference. The list is there for all to see, on an email posted by Rick.&n= bsp;Nothing is hidden.

John

On Wednesday, April 30, 2014, Henning Rogge <<= a href=3D"javascript:_e(%7B%7D,'cvml','hrogge@gmail.com');" target=3D"_blank= ">hrogge@gmail.com> wrote:
Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal<= br> > spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/manet
____________________= ___________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mai= lman/listinfo/manet
= --Apple-Mail-2FB73929-1465-4BB5-87FE-09138DCD3F2F-- From nobody Wed May 7 01:24:55 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B661A0278 for ; Wed, 7 May 2014 01:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2_O4-LQzylO for ; Wed, 7 May 2014 01:24:51 -0700 (PDT) Received: from mail-dotnet4.eads.net (mail-dotnet4.eads.net [193.56.40.77]) by ietfa.amsl.com (Postfix) with ESMTP id E46791A0262 for ; Wed, 7 May 2014 01:24:49 -0700 (PDT) Received: from unknown (HELO fr-gate1.mailhub.intra.corp) ([53.154.16.33]) by mail-dotnet4.eads.net with ESMTP; 07 May 2014 10:24:42 +0200 Received: from f8561vs5.main.fr.ds.corp ([10.37.8.21]) by fr-gate1.mailhub.intra.corp with Microsoft SMTPSVC(5.0.2195.7381); Wed, 7 May 2014 10:24:42 +0200 Received: from f8562vs4.main.fr.ds.corp ([10.37.8.22]) by f8561vs5.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 May 2014 10:24:42 +0200 Received: from SUCNPTEXC01.com.ad.uk.ds.corp ([10.80.73.70]) by f8562vs4.main.fr.ds.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 May 2014 10:24:41 +0200 Received: from SUCNPTEXM01.COM.AD.UK.DS.CORP ([fe80::2543:10a0:fd02:b894]) by SUCNPTEXC01.com.ad.uk.ds.corp ([::1]) with mapi id 14.02.0318.004; Wed, 7 May 2014 09:24:41 +0100 From: "Taylor, Rick" To: Thomas Heide Clausen , Abdussalam Baryun Thread-Topic: [manet] DT output list and WG decision for DLEP Thread-Index: AQHPaXNwNvHE/d2Crkqf2QZIN7jkH5s0x/ew Date: Wed, 7 May 2014 08:24: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.80.22.49] Content-Type: multipart/alternative; boundary="_000_B177F831FB91F242972D0C35F6A0733106FD208FSUCNPTEXM01coma_" MIME-Version: 1.0 X-OriginalArrivalTime: 07 May 2014 08:24:41.0836 (UTC) FILETIME=[CB60BAC0:01CF69CD] X-TM-AS-Product-Ver: SMEX-8.0.0.4194-7.500.1017-20590.005 X-TM-AS-Result: No--27.278900-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rKAKnV9ikwNzhuFAZ_Cf8JfO6I4 Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 08:24:54 -0000 --_000_B177F831FB91F242972D0C35F6A0733106FD208FSUCNPTEXM01coma_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVwYXJlZCBhIGxpc3Qgb2YgaXNzdWVzIGFuZCByZXNvbHV0aW9ucyAodGhlIG91dHN0YW5k aW5nIGlzc3VlcyBvbiB0aGUgbGlzdCB3ZXJlIGFsbCByZXNvbHZlZCB0byB0aGUgc2F0aXNmYWN0 aW9uIG9mIHRoZSBEVCBtZW1iZXJzIGF0IExvbmRvbikuDQoNCkkgaGF2ZSB5ZXQgdG8gcG9zdCBp dCB0byB0aGUg4oCYbWFpbuKAmSBsaXN0IGFzIEkgd2FzIHdhaXRpbmcgb24gZmVlZGJhY2sgZnJv bSB0aGUgb3RoZXIgRFQgbWVtYmVycyB0byBtYWtlIHN1cmUgSSBoYWRu4oCZdCBtaXNzZWQgYW55 dGhpbmcgdml0YWwsIGJ1dCBhcyB0aGF0IHdhcyBzb21lIHRpbWUgYWdvIEkgd2lsbCBnaXZlIHRo ZSBEVCBtZW1iZXJzIGEgbGFzdCBjaGFuY2UgdG8gcHJvdGVzdCBvbiB0aGlzIGxpc3QgYmVmb3Jl IHNlbmRpbmcgaXQgdG8gaGVyZS4NCg0KSG93IGRvZXMgdGhhdCBzb3VuZD8NCg0KUmljaw0KDQpG cm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBU aG9tYXMgSGVpZGUgQ2xhdXNlbg0KU2VudDogMDYgTWF5IDIwMTQgMjI6MzgNClRvOiBBYmR1c3Nh bGFtIEJhcnl1bg0KQ2M6IG1hbmV0DQpTdWJqZWN0OiBSZTogW21hbmV0XSBEVCBvdXRwdXQgbGlz dCBhbmQgV0cgZGVjaXNpb24gZm9yIERMRVANCg0KRldJVywgSSBhbHNvIHJlY2FsbCBkaXNjdXNz aW9ucyBpbiBMb25kb24gYWJvdXQgYSAibGlzdCBvZiBpc3N1ZXMgcGVuZGluZyByZXNvbHV0aW9u IiB0aGF0IHdhcyB0byBiZSBwb3N0ZWQgdG8gbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGll dGYub3JnPiAtIGJ1dCBJIGRvIG5vdCB0aGluayB0aGF0IEkgaGF2ZSBzZWVuIHRoYXQgbGlzdCB5 ZXQuDQoNCkFuZCB5ZXMsIEkgYW0gdGhlIHBlcnNvbiBjb21wdWxzaXZlbHkgY2hlY2tpbmcgdGhl IHNlY3JldCBETEVQIGxpc3Qgb24gYSBkYWlseSBiYXNpcywgZ2l2ZW4gdGhhdCBJIGFtIG5vdCBh bGxvd2VkIHRvIHJlY2VpdmUgbWFpbHMgc2VudCB0byBpdCBpbiBteSBlbWFpbCBjbGllbnQuDQoN ClRob21hcw0KDQpTZW50IGZyb20gbXkgaVBhZA0KDQpPbiA1IG1haSAyMDE0LCBhdCAxODowNiwg QWJkdXNzYWxhbSBCYXJ5dW4gPGFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPG1haWx0bzphYmR1 c3NhbGFtYmFyeXVuQGdtYWlsLmNvbT4+IHdyb3RlOg0KSm9obiwNCg0KVGhlIGxpc3QgbWVudGlv bmVkIGluIHRoZSBtZWV0aW5nIGJ5IFJpY2ssIEkgdW5kZXJzdG9vZCBpdCB3YXMgYSBuZXcgb25l L3VwZGF0ZSBhbmQgaXQgd2FzIHRvIGJlIHNlbnQgdG8gV0cgZm9yIHRoZSBuZXcgdmVyc2lvbiAt MDYgdG8gY29uc2lkZXIsIHNvIEkganVzdCBhc2tlZCBpZiBpdCBjYW4gYmUgc2VudC9mb3VuZCBh bmQgbm90IG9ubHkgbWVudGlvbmVkIGluIG1pbnV0ZXMuIEkgbWF5IG1pc3VuZGVyc3Rvb2QuDQoN CkFCDQoNCk9uIFN1bmRheSwgTWF5IDQsIDIwMTQsIEpvaG4gRG93ZGVsbCB3cm90ZToNCkFiZHVz c2FsYW0NCg0KSSBkbyBub3QgaGF2ZSB0aW1lIHRvIHNlYXJjaCBqdXN0IG5vdywgYnV0IHNlYXJj aCB0aGUgRExFUCBsaXN0IGFyb3VuZCB0aGUgdGltZSBvZiB0aGUgbGFzdCBjb25mZXJlbmNlLiBU aGUgbGlzdCBpcyB0aGVyZSBmb3IgYWxsIHRvIHNlZSwgb24gYW4gZW1haWwgcG9zdGVkIGJ5IFJp Y2suIE5vdGhpbmcgaXMgaGlkZGVuLg0KDQpKb2huDQoNCk9uIFdlZG5lc2RheSwgQXByaWwgMzAs IDIwMTQsIEhlbm5pbmcgUm9nZ2UgPGhyb2dnZUBnbWFpbC5jb20+IHdyb3RlOg0KSGksDQoNCkkg dGhpbmsgU3RhbiBpcyBqdXN0IHZlcnkgYnVzeSB3aXRoIG90aGVyIHRoaW5ncyBhdCB0aGUgbW9t ZW50LiBUaGUgRFQNCnRoaW5rcyB3ZSByZXNvbHZlZCBhbGwgb3VyIG9wZW4gcG9pbnRzLCBzbyB0 aGUgbmV4dCBkcmFmdCB3aWxsIGJlIHRoZQ0KcmVzdWx0IG9mIHRoZSBkZXNpZ24gdGVhbSB0byB0 aGUgbWFpbGluZyBsaXN0LiBUaGUgRFQgY2FuIGJlIHNodXQgZG93bg0KYWZ0ZXIgdGhpcyBhbmQg d2UgY2FuIGhhdmUgYSBsb29rIGF0IHRoZSByZXN1bHQgb24gdGhlIE1hbmV0IExpc3QsDQpob3Bl ZnVsbHkgZ29pbmcgdG93YXJkcyBhIFdHTEMuDQoNCkhlbm5pbmcgUm9nZ2UNCg0KT24gV2VkLCBB cHIgMzAsIDIwMTQgYXQgMzo1MyBQTSwgQWJkdXNzYWxhbSBCYXJ5dW4NCjxhYmR1c3NhbGFtYmFy eXVuQGdtYWlsLmNvbTxtYWlsdG86YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+PiB3cm90ZToN Cj4gSSBuZWVkIHRvIHNlZSBSaWNrJ3MgbGlzdCBtZW50aW9uZWQgaW4gdGhlIDg5IFdHIG1lZXRp bmcuIEFzDQo+IHVuZGVyc3Rvb2QgZnJvbSB0aGUgbWVldGluZyB0aGVyZSB3YXMgY29uc2Vuc3Vz IG9uIGdvaW5nIGZvciBhIG1pbmltYWwNCj4gc3BlYyBmb3IgRExFUCBhbmQgZXh0ZW5zaW9ucyBm b3Igb3RoZXIgZnV0dXJlIGRvY3VtZW50cyAoYW5kIG1heWJlDQo+IGhhdmluZyBXR0xDIGFmdGVy IGRyYWZ0LTA2IGluIEp1bHkgMjAxNCkuDQo+DQo+IEFCDQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1hbmV0IG1haWxpbmcgbGlzdA0KPiBt YW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8 bWFpbHRvOm1hbmV0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCB3aXRoaW4gdGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRh Y2hlZCB0byB0aGlzIGUtbWFpbCBpcyBwcml2YXRlIGFuZCBpbiBhZGRpdGlvbiBtYXkgaW5jbHVk ZSBjb21tZXJjaWFsbHkgc2Vuc2l0aXZlIGluZm9ybWF0aW9uLiBUaGUgY29udGVudHMgb2YgdGhp cyBlLW1haWwgYXJlIGZvciB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkgYW5kIHRoZXJlZm9y ZSBpZiB5b3Ugd2lzaCB0byBkaXNjbG9zZSB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIHdpdGhp biB0aGlzIGUtbWFpbCBvciBhdHRhY2hlZCBmaWxlcywgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRl ciBwcmlvciB0byBhbnkgc3VjaCBkaXNjbG9zdXJlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgY29weWluZyBvciBkaXN0cmlidXRpb24gaXMg cHJvaGliaXRlZC4gUGxlYXNlIGFsc28gY29udGFjdCB0aGUgc2VuZGVyIGFuZCBpbmZvcm0gdGhl bSBvZiB0aGUgZXJyb3IgYW5kIGRlbGV0ZSB0aGUgZS1tYWlsLCBpbmNsdWRpbmcgYW55IGF0dGFj aGVkIGZpbGVzIGZyb20geW91ciBzeXN0ZW0uIENhc3NpZGlhbiBMaW1pdGVkLCBwYXJ0IG9mIHRo ZSBBaXJidXMgRGVmZW5jZSBhbmQgU3BhY2UgZGl2aXNpb24uIFJlZ2lzdGVyZWQgT2ZmaWNlOiBR dWFkcmFudCBIb3VzZSwgQ2VsdGljIFNwcmluZ3MsIENvZWRrZXJuZXcsIE5ld3BvcnQgLCBOUDEw IDhGWi4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBXYWxlcyB1bmRlciBjb21wYW55IG51bWJl ciAwNDE5MTAzNg0K --_000_B177F831FB91F242972D0C35F6A0733106FD208FSUCNPTEXM01coma_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT4NCjwhLS0NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaX0NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hfQ0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiJ9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZX0NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZX0NCnNwYW4uRW1haWxTdHlsZTE3DQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RH0NCi5Nc29DaHBEZWZhdWx0DQoJe2ZvbnQtc2l6 ZToxMC4wcHR9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdH0NCmRpdi5Xb3JkU2VjdGlvbjENCgl7fQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0OyBmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMxRjQ5N0QiPkkgcHJlcGFyZWQgYSBsaXN0IG9mIGlzc3Vl cyBhbmQgcmVzb2x1dGlvbnMgKHRoZSBvdXRzdGFuZGluZyBpc3N1ZXMgb24gdGhlIGxpc3Qgd2Vy ZSBhbGwgcmVzb2x2ZWQgdG8gdGhlIHNhdGlzZmFjdGlvbiBvZiB0aGUgRFQgbWVtYmVycyBhdCBM b25kb24pLjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+ SSBoYXZlIHlldCB0byBwb3N0IGl0IHRvIHRoZSDigJhtYWlu4oCZIGxpc3QgYXMgSSB3YXMgd2Fp dGluZyBvbiBmZWVkYmFjayBmcm9tIHRoZSBvdGhlciBEVCBtZW1iZXJzIHRvIG1ha2Ugc3VyZSBJ IGhhZG7igJl0IG1pc3NlZCBhbnl0aGluZyB2aXRhbCwgYnV0IGFzIHRoYXQgd2FzDQogc29tZSB0 aW1lIGFnbyBJIHdpbGwgZ2l2ZSB0aGUgRFQgbWVtYmVycyBhIGxhc3QgY2hhbmNlIHRvIHByb3Rl c3Qgb24gdGhpcyBsaXN0IGJlZm9yZSBzZW5kaW5nIGl0IHRvIGhlcmUuPC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0OyBmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMUY0OTdEIj5Ib3cgZG9lcyB0aGF0IHNvdW5kPzwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7IGZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzFGNDk3RCI+Umljazwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDsgZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7IGJvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7IHBhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lOyBib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7IHBhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0OyBmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDsgZm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtYW5l dCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRo b21hcyBIZWlkZSBDbGF1c2VuPGJyPg0KPGI+U2VudDo8L2I+IDA2IE1heSAyMDE0IDIyOjM4PGJy Pg0KPGI+VG86PC9iPiBBYmR1c3NhbGFtIEJhcnl1bjxicj4NCjxiPkNjOjwvYj4gbWFuZXQ8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gRFQgb3V0cHV0IGxpc3QgYW5kIFdHIGRlY2lz aW9uIGZvciBETEVQPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RldJVywgSSBhbHNv IHJlY2FsbCBkaXNjdXNzaW9ucyBpbiBMb25kb24gYWJvdXQgYSAmcXVvdDtsaXN0IG9mIGlzc3Vl cyBwZW5kaW5nIHJlc29sdXRpb24mcXVvdDsgdGhhdCB3YXMgdG8gYmUgcG9zdGVkIHRvDQo8YSBo cmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPiAtIGJ1dCBJIGRv IG5vdCB0aGluayB0aGF0IEkgaGF2ZSBzZWVuIHRoYXQgbGlzdCB5ZXQuPC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QW5kIHllcywgSSBhbSB0aGUgcGVyc29uIGNvbXB1bHNpdmVseSBj aGVja2luZyB0aGUgc2VjcmV0IERMRVAgbGlzdCBvbiBhIGRhaWx5IGJhc2lzLCBnaXZlbiB0aGF0 IEkgYW0gbm90IGFsbG93ZWQgdG8gcmVjZWl2ZSBtYWlscyBzZW50IHRvIGl0IGluIG15IGVtYWls IGNsaWVudC48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG9tYXM8YnI+DQo8YnI+ DQpTZW50IGZyb20gbXkgaVBhZDwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gNSBtYWkgMjAxNCwgYXQg MTg6MDYsIEFiZHVzc2FsYW0gQmFyeXVuICZsdDs8YSBocmVmPSJtYWlsdG86YWJkdXNzYWxhbWJh cnl1bkBnbWFpbC5jb20iPmFiZHVzc2FsYW1iYXJ5dW5AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6 PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiw8L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxpc3QgbWVudGlvbmVkIGluIHRoZSBtZWV0aW5nIGJ5IFJp Y2ssJm5ic3A7SSB1bmRlcnN0b29kIGl0IHdhcyBhIG5ldyBvbmUvdXBkYXRlJm5ic3A7YW5kJm5i c3A7aXQgd2FzIHRvIGJlIHNlbnQgdG8gV0cgZm9yIHRoZSBuZXcgdmVyc2lvbiAtMDYgdG8gY29u c2lkZXIsIHNvIEkganVzdCBhc2tlZCBpZiBpdCBjYW4gYmUgc2VudC9mb3VuZCBhbmQmbmJzcDtu b3Qgb25seSBtZW50aW9uZWQgaW4gbWludXRlcy4gSSBtYXkgbWlzdW5kZXJzdG9vZC4mbmJzcDs8 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BQjxicj4NCjxicj4NCk9uIFN1bmRheSwg TWF5IDQsIDIwMTQsIEpvaG4gRG93ZGVsbCB3cm90ZTo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BYmR1c3NhbGFtPC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IGhhdmUgdGltZSB0 byBzZWFyY2gganVzdCBub3csIGJ1dCBzZWFyY2ggdGhlIERMRVAgbGlzdCBhcm91bmQgdGhlIHRp bWUgb2YgdGhlIGxhc3QgY29uZmVyZW5jZS4gVGhlIGxpc3QgaXMgdGhlcmUgZm9yIGFsbCB0byBz ZWUsIG9uIGFuIGVtYWlsIHBvc3RlZCBieSBSaWNrLiZuYnNwO05vdGhpbmcgaXMgaGlkZGVuLjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpvaG48YnI+DQo8YnI+DQpPbiBXZWRuZXNk YXksIEFwcmlsIDMwLCAyMDE0LCBIZW5uaW5nIFJvZ2dlICZsdDs8YSBocmVmPSIiIHRhcmdldD0i X2JsYW5rIj5ocm9nZ2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SGksPGJyPg0KPGJyPg0KSSB0aGluayBTdGFuIGlzIGp1c3QgdmVyeSBidXN5IHdp dGggb3RoZXIgdGhpbmdzIGF0IHRoZSBtb21lbnQuIFRoZSBEVDxicj4NCnRoaW5rcyB3ZSByZXNv bHZlZCBhbGwgb3VyIG9wZW4gcG9pbnRzLCBzbyB0aGUgbmV4dCBkcmFmdCB3aWxsIGJlIHRoZTxi cj4NCnJlc3VsdCBvZiB0aGUgZGVzaWduIHRlYW0gdG8gdGhlIG1haWxpbmcgbGlzdC4gVGhlIERU IGNhbiBiZSBzaHV0IGRvd248YnI+DQphZnRlciB0aGlzIGFuZCB3ZSBjYW4gaGF2ZSBhIGxvb2sg YXQgdGhlIHJlc3VsdCBvbiB0aGUgTWFuZXQgTGlzdCw8YnI+DQpob3BlZnVsbHkgZ29pbmcgdG93 YXJkcyBhIFdHTEMuPGJyPg0KPGJyPg0KSGVubmluZyBSb2dnZTxicj4NCjxicj4NCk9uIFdlZCwg QXByIDMwLCAyMDE0IGF0IDM6NTMgUE0sIEFiZHVzc2FsYW0gQmFyeXVuPGJyPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzphYmR1c3NhbGFtYmFyeXVuQGdtYWlsLmNvbSI+YWJkdXNzYWxhbWJhcnl1bkBn bWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEkgbmVlZCB0byBzZWUgUmljaydzIGxp c3QgbWVudGlvbmVkIGluIHRoZSA4OSBXRyBtZWV0aW5nLiBBczxicj4NCiZndDsgdW5kZXJzdG9v ZCBmcm9tIHRoZSBtZWV0aW5nIHRoZXJlIHdhcyBjb25zZW5zdXMgb24gZ29pbmcgZm9yIGEgbWlu aW1hbDxicj4NCiZndDsgc3BlYyBmb3IgRExFUCBhbmQgZXh0ZW5zaW9ucyBmb3Igb3RoZXIgZnV0 dXJlIGRvY3VtZW50cyAoYW5kIG1heWJlPGJyPg0KJmd0OyBoYXZpbmcgV0dMQyBhZnRlciBkcmFm dC0wNiBpbiBKdWx5IDIwMTQpLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFCPGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IG1hbmV0IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm1hbmV0 QGlldGYub3JnIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIj5tYW5ldEBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tYW5ldDwvYT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDsgbWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciPm1hbmV0QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCB3aXRoaW4gdGhpcyBlLW1haWwgYW5kIGFueSBmaWxlcyBhdHRhY2hlZCB0byB0aGlzIGUtbWFp bCBpcyBwcml2YXRlIGFuZCBpbiBhZGRpdGlvbiBtYXkgaW5jbHVkZSBjb21tZXJjaWFsbHkgc2Vu c2l0aXZlIGluZm9ybWF0aW9uLiBUaGUgY29udGVudHMgb2YgdGhpcyBlLW1haWwgYXJlIGZvciB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9ubHkgYW5kIHRoZXJlZm9yZSBpZiB5b3Ugd2lzaCB0byBk aXNjbG9zZQ0KIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgd2l0aGluIHRoaXMgZS1tYWlsIG9y IGF0dGFjaGVkIGZpbGVzLCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIHByaW9yIHRvIGFueSBz dWNoIGRpc2Nsb3N1cmUuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCBjb3B5aW5nIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBQbGVh c2UgYWxzbyBjb250YWN0IHRoZSBzZW5kZXIgYW5kIGluZm9ybQ0KIHRoZW0gb2YgdGhlIGVycm9y IGFuZCBkZWxldGUgdGhlIGUtbWFpbCwgaW5jbHVkaW5nIGFueSBhdHRhY2hlZCBmaWxlcyBmcm9t IHlvdXIgc3lzdGVtLiBDYXNzaWRpYW4gTGltaXRlZCwgcGFydCBvZiB0aGUgQWlyYnVzIERlZmVu Y2UgYW5kIFNwYWNlIGRpdmlzaW9uLiBSZWdpc3RlcmVkIE9mZmljZTogUXVhZHJhbnQgSG91c2Us IENlbHRpYyBTcHJpbmdzLCBDb2Vka2VybmV3LCBOZXdwb3J0ICwgTlAxMCA4RlouIFJlZ2lzdGVy ZWQgaW4gRW5nbGFuZA0KIGFuZCBXYWxlcyB1bmRlciBjb21wYW55IG51bWJlciAwNDE5MTAzNg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_B177F831FB91F242972D0C35F6A0733106FD208FSUCNPTEXM01coma_-- From nobody Wed May 7 02:31:19 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63D91A0431 for ; Wed, 7 May 2014 02:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UESyR6Iwv0ll for ; Wed, 7 May 2014 02:31:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3D1A03D1 for ; Wed, 7 May 2014 02:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6C53A1C0B5D; Wed, 7 May 2014 02:31:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.142] (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 5A1F61C0299; Wed, 7 May 2014 02:31:12 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4623AEBE-D2FB-48AC-9481-6A4D1D8444BB Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D201) In-Reply-To: Date: Wed, 7 May 2014 11:31:10 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> References: To: "Taylor, Rick" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/NXH2rMAGVvL65yWtXYUAH7B9Vfw Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 09:31:18 -0000 --Apple-Mail-4623AEBE-D2FB-48AC-9481-6A4D1D8444BB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On 7 mai 2014, at 10:24, "Taylor, Rick" wrote:= >=20 > I prepared a list of issues and resolutions (the outstanding issues on the= list were all resolved to the satisfaction of the DT members at London). > =20 > I have yet to post it to the =E2=80=98main=E2=80=99 list as I was waiting o= n feedback from the other DT members to make sure I hadn=E2=80=99t missed an= ything vital, but as that was some time ago I will give the DT members a las= t chance to protest on this list before sending it to here. > =20 > How does that sound? It sounds a lot less frustrating than being kept completely in the dark ;) Thomas > Rick > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Clau= sen > Sent: 06 May 2014 22:38 > To: Abdussalam Baryun > Cc: manet > Subject: Re: [manet] DT output list and WG decision for DLEP > =20 > FWIW, I also recall discussions in London about a "list of issues pending r= esolution" that was to be posted to manet@ietf.org - but I do not think that= I have seen that list yet. > =20 > And yes, I am the person compulsively checking the secret DLEP list on a d= aily basis, given that I am not allowed to receive mails sent to it in my em= ail client. > =20 > Thomas >=20 > Sent from my iPad >=20 > On 5 mai 2014, at 18:06, Abdussalam Baryun wr= ote: >=20 > John, > =20 > The list mentioned in the meeting by Rick, I understood it was a new one/u= pdate and it was to be sent to WG for the new version -06 to consider, so I j= ust asked if it can be sent/found and not only mentioned in minutes. I may m= isunderstood.=20 > =20 > AB >=20 > On Sunday, May 4, 2014, John Dowdell wrote: > Abdussalam > =20 > I do not have time to search just now, but search the DLEP list around the= time of the last conference. The list is there for all to see, on an email p= osted by Rick. Nothing is hidden. > =20 > John >=20 > On Wednesday, April 30, 2014, Henning Rogge wrote: > Hi, >=20 > I think Stan is just very busy with other things at the moment. The DT > thinks we resolved all our open points, so the next draft will be the > result of the design team to the mailing list. The DT can be shut down > after this and we can have a look at the result on the Manet List, > hopefully going towards a WGLC. >=20 > Henning Rogge >=20 > On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun > wrote: > > I need to see Rick's list mentioned in the 89 WG meeting. As > > understood from the meeting there was consensus on going for a minimal > > spec for DLEP and extensions for other future documents (and maybe > > having WGLC after draft-06 in July 2014). > > > > AB > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > The information contained within this e-mail and any files attached to thi= s e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and t= herefore if you wish to disclose the information contained within this e-mai= l or attached files, please contact the sender prior to any such disclosure.= If you are not the intended recipient, any disclosure, copying or distribut= ion is prohibited. Please also contact the sender and inform them of the err= or and delete the e-mail, including any attached files from your system. Cas= sidian Limited, part of the Airbus Defence and Space division. Registered Of= fice: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. Regist= ered in England and Wales under company number 04191036 --Apple-Mail-4623AEBE-D2FB-48AC-9481-6A4D1D8444BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 7 mai 2014, at 10:24= , "Taylor, Rick" <Rick.Taylo= r@cassidian.com> wrote:

I prepared a list of issu= es and resolutions (the outstanding issues on the list were all resolved to t= he satisfaction of the DT members at London).

 

I have yet to post it to t= he =E2=80=98main=E2=80=99 list as I was waiting on feedback from the other D= T members to make sure I hadn=E2=80=99t missed anything vital, but as that w= as some time ago I will give the DT members a last chance to protest on this l= ist before sending it to here.

 

How does that sound?


It sounds= a lot less frustrating than being kept completely in the dark ;)

Thomas

Rick

 

From: manet [mailto= :manet-bounces@ietf.org] On Behalf Of Thomas Heide Clausen
Sent: 06 May 2014 22:38
To: Abdussalam Baryun
Cc: manet
Subject: Re: [manet] DT output list and WG decision for DLEP

 

FWIW, I also recall discussions in London about a "li= st of issues pending resolution" that was to be posted to manet@ietf.org - but I do not think th= at I have seen that list yet.

 

And yes, I am the person compulsively checking the se= cret DLEP list on a daily basis, given that I am not allowed to receive mail= s sent to it in my email client.

 

Thomas

Sent from my iPad


On 5 mai 2014, at 18:06, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

John,

 

The list mentioned in the meeting by Rick, I und= erstood it was a new one/update and it was to be sent to WG for th= e new version -06 to consider, so I just asked if it can be sent/found and&n= bsp;not only mentioned in minutes. I may misunderstood. 

 

AB

On Sunday, May 4, 2014, John Dowdell wrote:

Abdussalam

 

I do not have time to search just now, but search the= DLEP list around the time of the last conference. The list is there for all= to see, on an email posted by Rick. Nothing is hidden.

 

John

On Wednesday, April 30, 2014, Henning Rogge <hrogge@gmail.com> wrote:

Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.com= > wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal<= br> > spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

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

The information contained within this e-mail and any files attached to this e= -mail is private and in addition may include commercially sensitive informat= ion. The contents of this e-mail are for the intended recipient only and the= refore if you wish to disclose the information contained within this e-mail or attached files, please cont= act the sender prior to any such disclosure. If you are not the intended rec= ipient, any disclosure, copying or distribution is prohibited. Please also c= ontact the sender and inform them of the error and delete the e-mail, including any attached files from y= our system. Cassidian Limited, part of the Airbus Defence and Space division= . Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , N= P10 8FZ. Registered in England and Wales under company number 04191036
= --Apple-Mail-4623AEBE-D2FB-48AC-9481-6A4D1D8444BB-- From nobody Wed May 7 08:37:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8D41A035C for ; Wed, 7 May 2014 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJdu8dLWfYL8 for ; Wed, 7 May 2014 08:37:12 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (unknown [188.94.42.120]) by ietfa.amsl.com (Postfix) with ESMTP id 6778D1A02EA for ; Wed, 7 May 2014 08:37:11 -0700 (PDT) Received: from tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d]) by tss-server1.home.tropicalstormsoftware.com ([fe80::753b:fa82:5c0:af0d%10]) with mapi; Wed, 7 May 2014 16:36:28 +0100 From: Rick Taylor To: Thomas Heide Clausen Thread-Topic: [manet] DT output list and WG decision for DLEP Thread-Index: AQHPZHuMIfCJAxJxnkCqF/M8NA3y+Js0x/ewgAAMdwCAAHYz9g== Date: Wed, 7 May 2014 15:34:13 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98010CE7A1F8@tss-server1.home.tropicalstormsoftware.com> References: , <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> In-Reply-To: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_38A5475DE83986499AEACD2CFAFC3F98010CE7A1F8tssserver1hom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/noGRe-7NU8CCeZwES86VcHa85fc Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:37:15 -0000 --_000_38A5475DE83986499AEACD2CFAFC3F98010CE7A1F8tssserver1hom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, Here is my updated list of TODOs that became DONEs (I reckon we should get the output of our meeting on the main WG list while there is still lots of = post meeting activity) Stan has committed to updating the session initiation description to place = the TCP server in the modem, so the initial part of the protocol is: Modem broadcasts UDP Hello packets containing version, ident and TCP address/port. Router TCP connects, session initiation occurs via the new T= CP connection. Credit windowing will stay in the document, but will be clearly marked as a= n optional part of the protocol. There was some concern raised over the clar= ity of the current text which will need to be address before last call. Vendor extensions will be defined using a new Data Item, containing a OUI (or something from an existing registry) and space for a payload. There wi= ll need to be some guidance verbiage to characterise what is a valid vendor extension and what is not. There was clarification of what both ends of a DLEP session must do on receipt of an unrecognized signal and data item. For a data item, the rece= iver MUST ignore the data item, for a signal the recipient MUST send an error status signal and terminate the TCP connection. There will be no facility in DLEP v1 for vendor extended signals. Any extr= a signals will require an uplift of the verion of the protocol and require a = new draft. There will be no such thing as a Peer Characteristic Request. This will pr= event abuse and misuse of the DLEP protocol to act as a configuration mechanism. The latency and EFT metrics were agreed to be fundamentally the same metric= , whether EFT is used to measure the latency or some other algorithm, and so = EFT will be dropped from the draft, leaving latency, with some text covering th= e use of EFT for defining latency. Also, it was decided that latency should be d= efined as a 32-bit positive number of microseconds. There was further discussion concerning multiple QoS flows with seperate metrics across a single link. This was agreed to be pushed out to another draft after DLEP v1, after some analysis that the proposed approach (hierarchical data items) will not break existing DLEP v1 implementations. = Stan agreed to double check that the text specified 16bit length values for all = TLVs (data and signals). There was discussion about enumerating error codes, and potential error text. The status signal MUST include an error code, 0 being success, other= s to be enumerated after close analysis of the protocol, plus an optional free text field to carry loggable information, capped at 80 bytes, utf8 encoded. There was discussion of confidence values for metrics, and this was rejecte= d as a core DLEP mechanism, and the suggestion was to use an extension data item TLV instead. In light of achieving their goal of listing the outstanding points that nee= ded to be resolved before DLEP can make progress to WG last-call, and actually achieving suitable consensus to resolve the outstanding issues to the satisfaction of one of the authors present, the DT decided to not apply for= a continuation of their charter, and to instead announce "Mission Complete" Rick ________________________________ From: manet [manet-bounces@ietf.org] on behalf of Thomas Heide Clausen [iet= f@thomasclausen.org] Sent: 07 May 2014 10:31 To: Taylor, Rick Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP On 7 mai 2014, at 10:24, "Taylor, Rick" > wrote: I prepared a list of issues and resolutions (the outstanding issues on the = list were all resolved to the satisfaction of the DT members at London). I have yet to post it to the =91main=92 list as I was waiting on feedback f= rom the other DT members to make sure I hadn=92t missed anything vital, but= as that was some time ago I will give the DT members a last chance to prot= est on this list before sending it to here. How does that sound? It sounds a lot less frustrating than being kept completely in the dark ;) Thomas Rick From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Claus= en Sent: 06 May 2014 22:38 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP FWIW, I also recall discussions in London about a "list of issues pending r= esolution" that was to be posted to manet@ietf.org -= but I do not think that I have seen that list yet. And yes, I am the person compulsively checking the secret DLEP list on a da= ily basis, given that I am not allowed to receive mails sent to it in my em= ail client. Thomas Sent from my iPad On 5 mai 2014, at 18:06, Abdussalam Baryun > wrote: John, The list mentioned in the meeting by Rick, I understood it was a new one/up= date and it was to be sent to WG for the new version -06 to consider, so I = just asked if it can be sent/found and not only mentioned in minutes. I may= misunderstood. AB On Sunday, May 4, 2014, John Dowdell wrote: Abdussalam I do not have time to search just now, but search the DLEP list around the = time of the last conference. The list is there for all to see, on an email = posted by Rick. Nothing is hidden. John On Wednesday, April 30, 2014, Henning Rogge > wrote: Hi, I think Stan is just very busy with other things at the moment. The DT thinks we resolved all our open points, so the next draft will be the result of the design team to the mailing list. The DT can be shut down after this and we can have a look at the result on the Manet List, hopefully going towards a WGLC. Henning Rogge On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun > wrote: > I need to see Rick's list mentioned in the 89 WG meeting. As > understood from the meeting there was consensus on going for a minimal > spec for DLEP and extensions for other future documents (and maybe > having WGLC after draft-06 in July 2014). > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, part of the Airbus Defence and Space division. Regis= tered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8F= Z. Registered in England and Wales under company number 04191036 --_000_38A5475DE83986499AEACD2CFAFC3F98010CE7A1F8tssserver1hom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi All,
Here is my updated list of TODOs that became DONEs (I reckon we should get<= br> the output of our meeting on the main WG list while there is still lots of = post meeting activity)

Stan has committed to updating the session initiation description to place = the
TCP server in the modem, so the initial part of the protocol is:  Mode= m
broadcasts UDP Hello packets containing version, ident and TCP
address/port.  Router TCP connects, session initiation occurs via the = new TCP
connection.

Credit windowing will stay in the document, but will be clearly marked as a= n
optional part of the protocol.  There was some concern raised over the= clarity
of the current text which will need to be address before last call.

Vendor extensions will be defined using a new Data Item, containing a OUI (or something from an existing registry) and space for a payload.  The= re will
need to be some guidance verbiage to characterise what is a valid vendor extension and what is not.

There was clarification of what both ends of a DLEP session must do on
receipt of an unrecognized signal and data item.  For a data item, the= receiver
MUST ignore the data item, for a signal the recipient MUST send an error status signal and terminate the TCP connection.

There will be no facility in DLEP v1 for vendor extended signals.  Any= extra
signals will require an uplift of the verion of the protocol and require a = new
draft.

There will be no such thing as a Peer Characteristic Request.  This wi= ll prevent
abuse and misuse of the DLEP protocol to act as a configuration mechanism.<= br>
The latency and EFT metrics were agreed to be fundamentally the same metric= ,
whether EFT is used to measure the latency or some other algorithm, and so = EFT
will be dropped from the draft, leaving latency, with some text covering th= e use
of EFT for defining latency.  Also, it was decided that latency should= be defined as a
32-bit positive number of microseconds.

There was further discussion concerning multiple QoS flows with seperate metrics across a single link.  This was agreed to be pushed out to ano= ther
draft after DLEP v1, after some analysis that the proposed approach
(hierarchical data items) will not break existing DLEP v1 implementations.&= nbsp; Stan
agreed to double check that the text specified 16bit length values for all = TLVs
(data and signals).

There was discussion about enumerating error codes, and potential error
text.  The status signal MUST include an error code, 0 being success, = others to
be enumerated after close analysis of the protocol, plus an optional free text field to carry loggable information, capped at 80 bytes, utf8 encoded.=

There was discussion of confidence values for metrics, and this was rejecte= d
as a core DLEP mechanism, and the suggestion was to use an extension data item TLV instead.

In light of achieving their goal of listing the outstanding points that nee= ded
to be resolved before DLEP can make progress to WG last-call, and actually<= br> achieving suitable consensus to resolve the outstanding issues to the
satisfaction of one of the authors present, the DT decided to not apply for= a
continuation of their charter, and to instead announce "Mission Comple= te"

Rick


 
From: manet [manet-bounces@ietf.org] on b= ehalf of Thomas Heide Clausen [ietf@thomasclausen.org]
Sent: 07 May 2014 10:31
To: Taylor, Rick
Cc: manet
Subject: Re: [manet] DT output list and WG decision for DLEP


On 7 mai 2014, at 10:24, "Taylor, Rick" <Rick.Taylor@cassidian.com> wrote:

I prepared a list of is= sues and resolutions (the outstanding issues on the list were all resolved = to the satisfaction of the DT members at London).

 

I have yet to post it t= o the =91main=92 list as I was waiting on feedback from the other DT member= s to make sure I hadn=92t missed anything vital, but as that was some time ago I will give the DT members a last chance to protest on this = list before sending it to here.

 

How does that sound?


It sounds a lot less frustrating than being kept completely in the dark ;)

Thomas

Rick

 

 

 

And yes, I am the person compulsively checking the s= ecret DLEP list on a daily basis, given that I am not allowed to receive ma= ils sent to it in my email client.

 

Thomas

Sent from my iPad


On 5 mai 2014, at 18:06, Abdussalam Baryun <abdussalambaryun@gmail.com> wrot= e:

John,

 

The list mentioned in the meeting by Rick, I un= derstood it was a new one/update and it was to be sent to WG for = the new version -06 to consider, so I just asked if it can be sent/found an= d not only mentioned in minutes. I may misunderstood. 

 

AB

On Sunday, May 4, 2014, John Dowdell wrote:

Abdussalam

 

I do not have time to search just now, but search th= e DLEP list around the time of the last conference. The list is there for a= ll to see, on an email posted by Rick. Nothing is hidden.

 

John

On Wednesday, April 30, 2014, Henning Rogge <hrogge@gmail.com> wrote:

Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussa= lambaryun@gmail.com> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal=
> spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet

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

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

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, part of the Airbus Defence and Space divis= ion. Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport= , NP10 8FZ. Registered in England and Wales under company number 04191036
--_000_38A5475DE83986499AEACD2CFAFC3F98010CE7A1F8tssserver1hom_-- From nobody Wed May 7 08:39:52 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21411A0394 for ; Wed, 7 May 2014 08:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NUl6yqHYT7Os for ; Wed, 7 May 2014 08:39:48 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9601A037D for ; Wed, 7 May 2014 08:39:48 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so885441eek.12 for ; Wed, 07 May 2014 08:39:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4vS14wTLJz4Hdr+XyBw7zLfFmyQCt/fc+zvmC2a+XJo=; b=OQYd9XUU5FKYGopgDzS5RvbVYlt+9yvQD/kLDIAZ+FJgzSl6vJzDZ4Pg6e41KsJKhq 3pCAxn5rj5aa3Es94MgWW1oxpPhG4YXFA+77nOt60I2oE7vhQ9ZxsmYb8Wi1/ltZhnPA n25fbYCt/zdS8zuo6EwzlOAYDYt/4lKDnCWipqOVsEu7+s2dM61XG2t5aR21RERNJgYF jXAcMDSMzQrk96ApkGgt7mr72Gt5EZUPEBUNH1xd2CgjD7H4BGzvv1d63UhVYJCM2p41 x/C2TKCe0i8z76jg1yAQGxa7svTTll99G9cKsoFY3zfA614Y76OL22ufyEkpBl+5BO/Z fxLw== X-Gm-Message-State: ALoCoQnRyn6AzuzE08FMESOyXsZptTwRnR5OKUsM7yAE4gAIeKO9ieshryc6AQJBlRTcdZjStDcl X-Received: by 10.14.225.73 with SMTP id y49mr18597750eep.43.1399477183528; Wed, 07 May 2014 08:39:43 -0700 (PDT) Received: from [10.87.191.115] ([88.128.80.60]) by mx.google.com with ESMTPSA id 4sm47107376eeq.33.2014.05.07.08.39.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 08:39:42 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Teco Boot In-Reply-To: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> Date: Wed, 7 May 2014 17:39:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/I2-8PqFvp0kH_JRoyCJT9i5zrI4 Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 15:39:51 -0000 Op 7 mei 2014, om 11:31 heeft Thomas Heide Clausen = het volgende geschreven: >=20 > On 7 mai 2014, at 10:24, "Taylor, Rick" = wrote: >=20 >> I prepared a list of issues and resolutions (the outstanding issues = on the list were all resolved to the satisfaction of the DT members at = London). >>=20 >> I have yet to post it to the =91main=92 list as I was waiting on = feedback from the other DT members to make sure I hadn=92t missed = anything vital, but as that was some time ago I will give the DT members = a last chance to protest on this list before sending it to here. >>=20 >> How does that sound? >>=20 >=20 > It sounds a lot less frustrating than being kept completely in the = dark ;) There is nothing in the dark. The outcome of last meeting is on DLEP DT = list. We wait on updated draft, where DT members check agreed issues and = posted remarks are processed. Then, we release to MANET WG for feedback. Teco >=20 > Thomas >=20 >> Rick >>=20 >> From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide = Clausen >> Sent: 06 May 2014 22:38 >> To: Abdussalam Baryun >> Cc: manet >> Subject: Re: [manet] DT output list and WG decision for DLEP >>=20 >> FWIW, I also recall discussions in London about a "list of issues = pending resolution" that was to be posted to manet@ietf.org - but I do = not think that I have seen that list yet. >>=20 >> And yes, I am the person compulsively checking the secret DLEP list = on a daily basis, given that I am not allowed to receive mails sent to = it in my email client. >>=20 >> Thomas >>=20 >> Sent from my iPad >>=20 >> On 5 mai 2014, at 18:06, Abdussalam Baryun = wrote: >>=20 >> John, >>=20 >> The list mentioned in the meeting by Rick, I understood it was a new = one/update and it was to be sent to WG for the new version -06 to = consider, so I just asked if it can be sent/found and not only mentioned = in minutes. I may misunderstood.=20 >>=20 >> AB >>=20 >> On Sunday, May 4, 2014, John Dowdell wrote: >> Abdussalam >>=20 >> I do not have time to search just now, but search the DLEP list = around the time of the last conference. The list is there for all to = see, on an email posted by Rick. Nothing is hidden. >>=20 >> John >>=20 >> On Wednesday, April 30, 2014, Henning Rogge wrote: >> Hi, >>=20 >> I think Stan is just very busy with other things at the moment. The = DT >> thinks we resolved all our open points, so the next draft will be the >> result of the design team to the mailing list. The DT can be shut = down >> after this and we can have a look at the result on the Manet List, >> hopefully going towards a WGLC. >>=20 >> Henning Rogge >>=20 >> On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun >> wrote: >>> I need to see Rick's list mentioned in the 89 WG meeting. As >>> understood from the meeting there was consensus on going for a = minimal >>> spec for DLEP and extensions for other future documents (and maybe >>> having WGLC after draft-06 in July 2014). >>>=20 >>> AB >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> The information contained within this e-mail and any files attached = to this e-mail is private and in addition may include commercially = sensitive information. The contents of this e-mail are for the intended = recipient only and therefore if you wish to disclose the information = contained within this e-mail or attached files, please contact the = sender prior to any such disclosure. If you are not the intended = recipient, any disclosure, copying or distribution is prohibited. Please = also contact the sender and inform them of the error and delete the = e-mail, including any attached files from your system. Cassidian = Limited, part of the Airbus Defence and Space division. Registered = Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8FZ. = Registered in England and Wales under company number 04191036 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 7 09:50:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA621A0775 for ; Wed, 7 May 2014 09:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oos8BoAYX-k0 for ; Wed, 7 May 2014 09:50:32 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id B9D301A0385 for ; Wed, 7 May 2014 09:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14196; q=dns/txt; s=iport; t=1399481427; x=1400691027; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JWgJRJtyFbBzfbAfEqvdtelLYOt2hw62Wpndf4EeyQk=; b=A08geLVQ/UEGqloB4jGrqaW2tN1GBxUPijxzI4KjtYkWbNnfYOhSQTuC yvwLMHkEhlSGBi20+cqqPi5RRL9TMg46G4ZPt4opYTXAOx08NQP14aGl1 c4in29LIwMSlH/mbXKd6nxUsRBaDGIvGvTQFrIIprU4F8xiiluwKekndu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANZjalOtJA2J/2dsb2JhbABagkJET1isCZFVAYc7AYEZFnSCJQEBAQQBAQFlBgsQAgEIEQQBAQEnByEGCxQJCAIEDgWILQMRDckpDYY+EwSMO4E1CgQDARkzBAYBAoMogRUEl0WBco0ahWGDNIFtBQQXIg X-IronPort-AV: E=Sophos;i="4.97,1004,1389744000"; d="scan'208,217";a="41815264" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP; 07 May 2014 16:50:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s47GoRTp012995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 7 May 2014 16:50:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.55]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 7 May 2014 11:50:26 -0500 From: "Stan Ratliff (sratliff)" To: Thomas Heide Clausen Thread-Topic: [manet] DT output list and WG decision for DLEP Thread-Index: AQHPZHuWmK3twfVp5EKoHs3p+XQuips0x/ewgABxDACAAHq6gA== Date: Wed, 7 May 2014 16:50:26 +0000 Message-ID: <6C77F2F6-E1D6-4866-8411-B767352B9D46@cisco.com> References: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> In-Reply-To: <3333F701-CAE5-46DB-80F8-D68C22581095@thomasclausen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.40.184] Content-Type: multipart/alternative; boundary="_000_6C77F2F6E1D648668411B767352B9D46ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/B4Xhz6NfCh84heWqvtM5yvBpeL4 Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 16:50:37 -0000 --_000_6C77F2F6E1D648668411B767352B9D46ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On May 7, 2014, at 5:31 AM, Thomas Heide Clausen > wrote: On 7 mai 2014, at 10:24, "Taylor, Rick" > wrote: I prepared a list of issues and resolutions (the outstanding issues on the = list were all resolved to the satisfaction of the DT members at London). I have yet to post it to the =91main=92 list as I was waiting on feedback f= rom the other DT members to make sure I hadn=92t missed anything vital, but= as that was some time ago I will give the DT members a last chance to prot= est on this list before sending it to here. How does that sound? It sounds a lot less frustrating =85for you, anyway=85 ;-) Regards, Stan than being kept completely in the dark ;) Thomas Rick From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Claus= en Sent: 06 May 2014 22:38 To: Abdussalam Baryun Cc: manet Subject: Re: [manet] DT output list and WG decision for DLEP FWIW, I also recall discussions in London about a "list of issues pending r= esolution" that was to be posted to manet@ietf.org -= but I do not think that I have seen that list yet. And yes, I am the person compulsively checking the secret DLEP list on a da= ily basis, given that I am not allowed to receive mails sent to it in my em= ail client. Thomas Sent from my iPad On 5 mai 2014, at 18:06, Abdussalam Baryun > wrote: John, The list mentioned in the meeting by Rick, I understood it was a new one/up= date and it was to be sent to WG for the new version -06 to consider, so I = just asked if it can be sent/found and not only mentioned in minutes. I may= misunderstood. AB On Sunday, May 4, 2014, John Dowdell wrote: Abdussalam I do not have time to search just now, but search the DLEP list around the = time of the last conference. The list is there for all to see, on an email = posted by Rick. Nothing is hidden. John On Wednesday, April 30, 2014, Henning Rogge = > wrote: Hi, I think Stan is just very busy with other things at the moment. The DT thinks we resolved all our open points, so the next draft will be the result of the design team to the mailing list. The DT can be shut down after this and we can have a look at the result on the Manet List, hopefully going towards a WGLC. Henning Rogge On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun > wrote: > I need to see Rick's list mentioned in the 89 WG meeting. As > understood from the meeting there was consensus on going for a minimal > spec for DLEP and extensions for other future documents (and maybe > having WGLC after draft-06 in July 2014). > > AB > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-= mail or attached files, please contact the sender prior to any such disclos= ure. If you are not the intended recipient, any disclosure, copying or dist= ribution is prohibited. Please also contact the sender and inform them of t= he error and delete the e-mail, including any attached files from your syst= em. Cassidian Limited, part of the Airbus Defence and Space division. Regis= tered Office: Quadrant House, Celtic Springs, Coedkernew, Newport , NP10 8F= Z. Registered in England and Wales under company number 04191036 _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet --_000_6C77F2F6E1D648668411B767352B9D46ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On May 7, 2014, at 5:31 AM, Thomas Heide Clausen <ietf@thomasclausen.org> wrote:


On 7 mai 2014, at 10:24, "Taylor, Rick" <Rick.Taylor@cassidian.com> wrote:

I prepared a list of is= sues and resolutions (the outstanding issues on the list were all resolved = to the satisfaction of the DT members at London).

 

I have yet to post it t= o the =91main=92 list as I was waiting on feedback from the other DT member= s to make sure I hadn=92t missed anything vital, but as that was some time ago I will give the DT members a last chance to protest on this = list before sending it to here.

 

How does that sound?



It sounds a lot less frustrating


=85for you, anyway=85 ;-) 

Regards,
Stan


than being kept completely in the dark ;)

Thomas

Rick

 

From: manet [ma= ilto:manet-bounces@ietf.org] On Behalf Of Thomas Heide Clausen
Sent: 06 May 2014 22:38
To: Abdussalam Baryun
Cc: manet
Subject: Re: [manet] DT output list and WG decision for DLEP<= /p>

 

FWIW, I also recall discussions in London about a &q= uot;list of issues pending resolution" that was to be posted to manet@ietf.org - but I do not think t= hat I have seen that list yet.

 

And yes, I am the person compulsively checking the s= ecret DLEP list on a daily basis, given that I am not allowed to receive ma= ils sent to it in my email client.

 

Thomas

Sent from my iPad


On 5 mai 2014, at 18:06, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:

John,

 

The list mentioned in the meeting by Rick, I un= derstood it was a new one/update and it was to be sent to WG for = the new version -06 to consider, so I just asked if it can be sent/found an= d not only mentioned in minutes. I may misunderstood. 

 

AB

On Sunday, May 4, 2014, John Dowdell wrote:

Abdussalam

 

I do not have time to search just now, but search th= e DLEP list around the time of the last conference. The list is there for a= ll to see, on an email posted by Rick. Nothing is hidden.

 

John

On Wednesday, April 30, 2014, Henning Rogge <hrogge@gmail.com> wrote:

Hi,

I think Stan is just very busy with other things at the moment. The DT
thinks we resolved all our open points, so the next draft will be the
result of the design team to the mailing list. The DT can be shut down
after this and we can have a look at the result on the Manet List,
hopefully going towards a WGLC.

Henning Rogge

On Wed, Apr 30, 2014 at 3:53 PM, Abdussalam Baryun
<abdussalambaryun@gmail.co= m> wrote:
> I need to see Rick's list mentioned in the 89 WG meeting. As
> understood from the meeting there was consensus on going for a minimal=
> spec for DLEP and extensions for other future documents (and maybe
> having WGLC after draft-06 in July 2014).
>
> AB
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

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

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

The information contained within this e-mail and any files attached to this= e-mail is private and in addition may include commercially sensitive infor= mation. The contents of this e-mail are for the intended recipient only and= therefore if you wish to disclose the information contained within this e-mail or attached files, please con= tact the sender prior to any such disclosure. If you are not the intended r= ecipient, any disclosure, copying or distribution is prohibited. Please als= o contact the sender and inform them of the error and delete the e-mail, including any attached files from= your system. Cassidian Limited, part of the Airbus Defence and Space divis= ion. Registered Office: Quadrant House, Celtic Springs, Coedkernew, Newport= , NP10 8FZ. Registered in England and Wales under company number 04191036
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet

--_000_6C77F2F6E1D648668411B767352B9D46ciscocom_-- From nobody Mon May 12 13:11:22 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2646D1A0766 for ; Mon, 12 May 2014 13:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVHBA64_1x6X for ; Mon, 12 May 2014 13:11:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 695CC1A0727 for ; Mon, 12 May 2014 13:11:13 -0700 (PDT) Received: from CO1PR07MB345.namprd07.prod.outlook.com (10.141.51.25) by CO1PR07MB345.namprd07.prod.outlook.com (10.141.51.25) with Microsoft SMTP Server (TLS) id 15.0.939.12; Mon, 12 May 2014 20:11:06 +0000 Received: from CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.46]) by CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.46]) with mapi id 15.00.0939.000; Mon, 12 May 2014 20:11:06 +0000 From: "Soyata, Tolga" To: "manet@ietf.org" Thread-Topic: Call for Papers : CCSNA 2014 [publicity] Thread-Index: Ac9uHjtmQtSJOapdS4KQ1RhbaAociw== Date: Mon, 12 May 2014 20:11:05 +0000 Message-ID: <80249608b002480e96955ce5432fa969@CO1PR07MB345.namprd07.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.151.160.221] x-forefront-prvs: 0209425D0A x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(15975445006)(76482001)(31966008)(16601075003)(74502001)(99396002)(46102001)(54356999)(50986999)(81542001)(74662001)(83072002)(15202345003)(77982001)(64706001)(20776003)(18717965001)(76576001)(4396001)(75432001)(101416001)(16799955002)(66066001)(92566001)(79102001)(21056001)(19300405004)(16236675002)(19580395003)(83322001)(87936001)(74316001)(85852003)(80022001)(2656002)(86362001)(33646001)(81342001)(99286001)(19625215002)(225293001)(24736002)(6606295002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB345; H:CO1PR07MB345.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: rochester.edu does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tolga.soyata@rochester.edu; Content-Type: multipart/alternative; boundary="_000_80249608b002480e96955ce5432fa969CO1PR07MB345namprd07pro_" MIME-Version: 1.0 X-OriginatorOrg: rochester.edu Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ngqAW9JrnswS2voX_3rAk8EqpaA Subject: [manet] Call for Papers : CCSNA 2014 [publicity] X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 20:11:19 -0000 --_000_80249608b002480e96955ce5432fa969CO1PR07MB345namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IEEE International Workshop on Cloud Computing Systems, Networks, and Applications (CCSNA) (Apologies for multiple copies) Organized in conjunction with IEEE Global Communications Conference (GLOBECOM 2014) 8-12 December 2014, Austin, Texas, USA Workshop web: http://cloud.it.teithe.gr/ EDAS submission web link: https://edas.info/newPaper.php?c=3D17545 Paper submission deadline: July 15, 2014 Cloud Computing, as well as Cloud-inspired business models, enable on-deman= d access to a shared pool of resources, namely computing, storage, networks= , services, and applications. With the advent of Cloud-based systems, cloud= operators have been aiming at reliable, secured, privacy-preserving and co= st-efficient cloud design and management. As the Cloud infrastructure aims = at offering various IT resources as services, requirements of Cloud applica= tions vary based on the resources which are requested as services. Thus, th= e resources may refer to heavy computation resources, massive storage resou= rces, high-capacity network resources and so on. The heterogeneity of cloud= applications leads to the challenge of holistic design of a robust Cloud s= ystem which can oversee and handle the diverse needs of numerous types of a= pplications. On the other hand, these challenges enforce cooperation of var= ious players in the Cloud system, each of which focuses on a different segm= ent such as network, computing, applications, and systems. The Second Inter= national workshop on Cloud Computing Systems, Networks, and Applications (C= CSNA-2014) aims at the crossroads between scientists, researchers, practiti= oners and students from diverse domains in Cloud computing research. The wo= rkshop aims at attracting contributions of system and network design that c= an support existing and future applications and services. Researchers are e= ncouraged to submit original research contributions in all major areas, whi= ch include, but not limited to: *Cloud computing systems and networking- principles, designs, analyses, and= performance -Theoretical analysis for cloud systems -Cloud system and network design -Optimization for cloud computing, networking, and applications -Green cloud systems and networking -Storage, data, and analytics for clouds design and networking -Virtualization for cloud computing systems and networking -Modeling and performance analysis for cloud system, network and storage -Intra-cloud/inter-cloud computing and networking -Cloud computing architectures and cloud solution design patterns -Cloud migration, composition, federation, bridging, and bursting -Cloud provisioning and migration -Cloud DevOps -Cloud system design with FPGA, GPU, APU -Network Programmability, Software-Defined Networking and Virtual Ethernet = Switching *Big data, data centers, and cloud managements -Big data storage and networking -Real-time resource reporting and monitoring for cloud management -Cloud quality management and service level agreement (SLA) -Cloud configuration, performance, and capacity management -Cloud workload profiling and deployment control -Autonomic business process and workflow management in clouds -Collaboration, management, and administration of clouds and services -Quality of service on clouds and applications, including reliability, avai= lability -Scalability, performance, and load balance -Knowledge engineering and data mining techniques and systems on clouds -Data center network management, reliability, optimization, and bridging -Distributed data center architectures -Cloud traffic engineering and control-plane architectures *Cloud services, applications, security, and interdisciplinary topics -Cloud system and storage security -Mobile cloud system design -Cloud media and storage design -Security, privacy, and compliance management for clouds -Self-service cloud portal, dashboard, and analytics -Infrastructure, platform, application, business, social, and mobile clouds -Security, privacy, and compliance management for public, private, and hybr= id clouds -Innovative cloud applications and experiences -Economic, business and ROI models for cloud computing -Mobile-aware networking, protocols, and infrastructures -Content and service distribution in clouds -Audit, authentication and authorization in clouds -Service-oriented architecture in clouds -Cloud support for IoTs and their services -Cloud for service discovery -Image processing and efficient video transmission on clouds -Multimedia service provisioning on clouds -MapReduce -Resilience, fault tolerance *Surveys -Surveys on any topics above Submission Procedure Submitted papers must represent original material which is not currently un= der review in any other conference or journal and has not been previously p= ublished. Paper length should not exceed five-page standard IEEE conference= two-column format (including all text, figures, and references). Please se= e the Author Information page for submission guidelines in the IEEE GLOBECO= M 2014 website http://www.ieee-globecom.org. All submitted papers will go t= hrough a peer review process. All accepted and presented papers will be inc= luded in the IEEE GLOBECOM 2014 proceedings and IEEE digital library. IEEE = reserves the right to exclude an accepted and registered but not presented = paper from the IEEE digital library. Selected papers will be invited to be= peer-reviewed for a special issue in an IEEE journal and another journal s= pecial issue. Honorary General Chair Rajkumar Buyya, University of Melbourne, Australia General co-Chairs: Andy Rindos, IBM Research, USA Periklis Chatzimisios, Alexander TEI of Thessaloniki, Greece Technical Program co-Chairs: Burak Kantarci, University of Ottawa, Canada Kun Yang, University of Essex, U.K, Di Wu, Sun Yat-sen University, China Invited Speaker and Panel Co-Chairs: Luca Foschini (University of Bologna, Italy) Sun Zhili (University of Surrey, UK) Fen Hou ( University of Macau, China) Publication and EDAS Co-Chairs: Ranga Rao Venkatesha Prasad (Delft University of Technology, Netherlands) Berk Canberk (Istanbul Technical University, Turkey) Publicity Co-chairs Elhadj Benkhelifa, (Staffordshire University, UK) Tolga Soyata (University of Rochester) Ying Qian (East China Normal University, China) Christos Kouroupetroglou (Alexander TEI of Thessaloniki, Greece) Liang Zhou, Nanjing University of Posts and Telecommunications, China) Steering Committee Chuan Heng Foh (University of Surrey,UK) Jinsong Wu (Alcatel-Lucent, China) Yaser Jararweh (Jordan University of Science and Technology, Jordan) Mladen Vouk (North Carolina State University, USA) Important Dates Paper submission deadline: July 15, 2014 Author notification: August 20, 2014 Camera ready: October 1, 2014 --_000_80249608b002480e96955ce5432fa969CO1PR07MB345namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IEEE International Workshop on

Cloud Computing Systems, Networks, and Applications (CCSNA= )

 

(Apologies for multip= le copies)

 

Organized in conjunction wi= th

IEEE Global Communicatio= ns Conference (GLOBECOM 2014) 

8-12 December 2014, Austin,= Texas, USA

Workshop web: http://cloud.it.teithe.gr/ 

<= /o:p>

EDAS submission web link: https://edas.info/newPaper.php?c=3D1= 7545

 =

Paper submission deadline: July 15= , 2014

 =

Cloud Computing, as well as Cloud-inspired business model= s, enable on-demand access to a shared pool of resources, namely computing,= storage, networks, services, and applications. With the advent of Cloud-based systems, cloud operators have been aiming a= t reliable, secured, privacy-preserving and cost-efficient cloud design and= management. As the Cloud infrastructure aims at offering various IT resour= ces as services, requirements of Cloud applications vary based on the resources which are requested as serv= ices. Thus, the resources may refer to heavy computation resources, massive= storage resources, high-capacity network resources and so on. The heteroge= neity of cloud applications leads to the challenge of holistic design of a robust Cloud system which can ove= rsee and handle the diverse needs of numerous types of applications. On the= other hand, these challenges enforce cooperation of various players in the= Cloud system, each of which focuses on a different segment such as network, computing, applications, and syste= ms. The Second International workshop on Cloud Computing Systems, Networks,= and Applications (CCSNA-2014) aims at the crossroads between scientists, r= esearchers, practitioners and students from diverse domains in Cloud computing research. The workshop aims at att= racting contributions of system and network design that can support existin= g and future applications and services. Researchers are encouraged to submi= t original research contributions in all major areas, which include, but not limited to:

*C= loud computing systems and networking- principles, designs, analyses, and p= erformance

-T= heoretical analysis for cloud systems

-C= loud system and network design

-O= ptimization for cloud computing, networking, and applications

-G= reen cloud systems and networking

-S= torage, data, and analytics for clouds design and networking

-V= irtualization for cloud computing systems and networking

-M= odeling and performance analysis for cloud system, network and storage

-I= ntra-cloud/inter-cloud computing and networking=

-C= loud computing architectures and cloud solution design patterns

-C= loud migration, composition, federation, bridging, and bursting

-C= loud provisioning and migration

-C= loud DevOps

-C= loud system design with FPGA, GPU, APU

-N= etwork Programmability, Software-Defined Networking and Virtual Ethernet Sw= itching

&n= bsp;

&n= bsp;

*B= ig data, data centers, and cloud managements

-B= ig data storage and networking

-R= eal-time resource reporting and monitoring for cloud management

-C= loud quality management and service level agreement (SLA)

-C= loud configuration, performance, and capacity management

-C= loud workload profiling and deployment control<= o:p>

-A= utonomic business process and workflow management in clouds

-C= ollaboration, management, and administration of clouds and services<= span lang=3D"EN-CA">

-Q= uality of service on clouds and applications, including reliability, availa= bility

-S= calability, performance, and load balance<= /o:p>

-K= nowledge engineering and data mining techniques and systems on clouds

-D= ata center network management, reliability, optimization, and bridging

-D= istributed data center architectures=

-C= loud traffic engineering and control-plane architectures

&n= bsp;

*C= loud services, applications, security, and interdisciplinary topics<= span lang=3D"EN-CA">

-C= loud system and storage security

-M= obile cloud system design

-C= loud media and storage design=

-S= ecurity, privacy, and compliance management for clouds

-S= elf-service cloud portal, dashboard, and analytics

-I= nfrastructure, platform, application, business, social, and mobile clouds

-S= ecurity, privacy, and compliance management for public, private, and hybrid= clouds

-I= nnovative cloud applications and experiences

-E= conomic, business and ROI models for cloud computing

-M= obile-aware networking, protocols, and infrastructures

-C= ontent and service distribution in clouds<= /o:p>

-A= udit, authentication and authorization in clouds

-S= ervice-oriented architecture in clouds

-C= loud support for IoTs and their services

-C= loud for service discovery

-I= mage processing and efficient video transmission on clouds

-M= ultimedia service provisioning on clouds

-M= apReduce

-R= esilience, fault tolerance

&n= bsp;

*S= urveys

-S= urveys on any topics above

 

Submission Procedure

Submitted papers must represe= nt original material which is not currently under review in a= ny other conference or journal and has not been previously published. Paper= length should not exceed five-page standard IEEE conference two-c= olumn format (including all text,= figures, and references). Please see the Autho= r Information page for submission guidelines in the IEEE GLOBECOM 2014 webs= ite http://www.ieee-globecom.org. All submitted papers= will go through a peer review pr= ocess. All accepted and pre= sented papers will be included in the IEEE GLOBECOM 2014 proceedings and IE= EE digital library. IEEE reserves the right to exclude an accepted and regi= stered but not presented paper from the IEEE digital library.  Selected papers will be invited to be p= eer-reviewed for a special issue in an IEEE journal and another journal spe= cial issue.

 

Honorary General Chair

Rajkumar Buyya, University of Melbo= urne, Australia

 <= o:p>

General co-Chairs:

Andy Rindos, IBM Research, USA

Periklis Chatzimisios, Alexander TE= I of Thessaloniki, Greece

 

Technical Program co-Chairs:

Burak Kantarci, University of Ottaw= a, Canada

Kun Yang, University of Essex, U.K,

Di Wu, Sun Yat-sen University, Chin= a

 

Invited Speaker and Panel Co-Cha= irs: 

Luca Foschini (University of Bologn= a, Italy)

Sun Zhili (University of Surrey, UK= )

Fen Hou ( University of Macau, Chin= a)

 

Publication and EDAS Co-Chairs:&= nbsp;

Ranga Rao Venkatesha Prasad (Delft = University of Technology, Netherlands)

Berk Canberk (Istanbul Technical Un= iversity, Turkey)

 

Publicity Co-chairs

Elhadj Benkhelifa, (Staffordshire U= niversity, UK)

Tolga Soyata (University of Rochest= er)

Ying Qian (East China Normal Univer= sity, China)

Christos Kouroupetroglou (Alexander= TEI of Thessaloniki, Greece) <= /span>

Liang Zhou, Nanjing University of P= osts and Telecommunications, China)<= /span>

 

Steering Committee

Chuan Heng Foh (University of Surre= y,UK) 

Jinsong Wu (Alcatel-Lucent, China) =  

Yaser Jararweh (Jordan University o= f Science and Technology, Jordan) 

Mladen Vouk (North Carolina State U= niversity, USA)

&= nbsp;

I= mportant Dates

Paper submission deadline: July 15, 2014

Author notification: August 20, 2014

Camera ready: October 1, 2014

 =

--_000_80249608b002480e96955ce5432fa969CO1PR07MB345namprd07pro_-- From nobody Tue May 13 13:37:52 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982381A01F0 for ; Tue, 13 May 2014 13:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSDSrFM1UQiP for ; Tue, 13 May 2014 13:37:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) by ietfa.amsl.com (Postfix) with ESMTP id CE2831A013F for ; Tue, 13 May 2014 13:37:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BB0DA245E66; Tue, 13 May 2014 13:37:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 3E44E245E62; Tue, 13 May 2014 13:37:41 -0700 (PDT) From: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=Apple-Mail-5B427315-5FE9-483E-8184-10D7DFFB0C63 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Tue, 13 May 2014 22:37:38 +0200 References: <53727B87.1010008@gmail.com> To: manet , Mark Townsley X-Mailer: iPad Mail (11D201) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/exmoq0KMOraY-FICRIf6ffzOg2Y Subject: [manet] Fwd: [OPSAWG] BOF proposal on autonomic networking use cases X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 20:37:49 -0000 --Apple-Mail-5B427315-5FE9-483E-8184-10D7DFFB0C63 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable This does look like something, that might be of interest to this WG to keep t= ap on. Chairs: have you been previously engaging with the people behind UCAN, or th= e corresponding IRTF work cited? Best, Thomas Sent from my iPad Begin forwarded message: > From: Brian E Carpenter > Date: 13 mai 2014 22:07:35 UTC+2 > To: opsawg@ietf.org > Subject: [OPSAWG] BOF proposal on autonomic networking use cases >=20 > FYI >=20 > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart#UCANproposal >=20 > Brian >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg --Apple-Mail-5B427315-5FE9-483E-8184-10D7DFFB0C63 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
This does look like something, that mi= ght be of interest to this WG to keep tap on.

Chair= s: have you been previously engaging with the people behind UCAN, or the cor= responding IRTF work cited?

Best,

Thomas

Sent from my iPad

Begin forwarded message:

<= /div>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>= ;
Date: 13 mai 2014 22:07:35 UTC+2
To: opsawg@ietf.org
Subject: [OPSAWG] BOF pro= posal on autonomic networking use cases

= = --Apple-Mail-5B427315-5FE9-483E-8184-10D7DFFB0C63-- From nobody Wed May 14 10:07:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4686E1A029F for ; Wed, 14 May 2014 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RD7-vvNI_m8 for ; Wed, 14 May 2014 10:07:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2651A02DD for ; Wed, 14 May 2014 10:07:02 -0700 (PDT) Received: from CO1PR07MB345.namprd07.prod.outlook.com (10.141.51.25) by CO1PR07MB347.namprd07.prod.outlook.com (10.141.51.18) with Microsoft SMTP Server (TLS) id 15.0.939.12; Wed, 14 May 2014 17:06:54 +0000 Received: from CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.46]) by CO1PR07MB345.namprd07.prod.outlook.com ([169.254.13.46]) with mapi id 15.00.0939.000; Wed, 14 May 2014 17:06:54 +0000 From: "Soyata, Tolga" To: "manet@ietf.org" Thread-Topic: CALL FOR CHAPTERS: "Enabling Real-Time Mobile Cloud Computing through Emerging Technologies" Thread-Index: Ac9vlnuvxf5e/LqmSjmmGAujhvVyIQAABemA Date: Wed, 14 May 2014 17:06:53 +0000 Message-ID: <46a6c3e15bc94b50950588577b229957@CO1PR07MB345.namprd07.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.151.160.221] x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(428001)(199002)(189002)(19625215002)(75432001)(4396001)(79102001)(83322001)(74316001)(87936001)(64706001)(20776003)(86362001)(2656002)(81342001)(18717965001)(76482001)(561944003)(50986999)(77982001)(54356999)(19300405004)(19580395003)(81542001)(76576001)(99286001)(99396002)(46102001)(83072002)(19609705001)(21056001)(74502001)(85852003)(15975445006)(80022001)(66066001)(31966008)(74662001)(101416001)(92566001)(16236675002)(33646001)(218763003)(15202345003)(16601075003)(24736002)(217873001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR07MB347; H:CO1PR07MB345.namprd07.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: rochester.edu does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tolga.soyata@rochester.edu; Content-Type: multipart/alternative; boundary="_000_46a6c3e15bc94b50950588577b229957CO1PR07MB345namprd07pro_" MIME-Version: 1.0 X-OriginatorOrg: rochester.edu Archived-At: http://mailarchive.ietf.org/arch/msg/manet/y8eWXWDX8ApUZl7mGw7cNPMumZ0 Subject: [manet] CALL FOR CHAPTERS: "Enabling Real-Time Mobile Cloud Computing through Emerging Technologies" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2014 17:07:06 -0000 --_000_46a6c3e15bc94b50950588577b229957CO1PR07MB345namprd07pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CALL FOR CHAPTERS "Enabling Real-Time Mobile Cloud Computing through Emerging Technologies" Details : http://www.igi-global.com/publish/call-for-papers/call-details/12= 55 To Propose a chapter: http://www.igi-global.com/publish/call-for-papers/sub= mit/1255 Editors Tolga Soyata, University of Rochester, USA Call for Chapters Proposals Submission Deadline: May 30, 2014 Full Chapters Due: July 31, 2014 Submission Date: September 14, 2014 Introduction Today's smartphones and mobile devices are capable of running power hungry = applications thanks to their quad-core CPUs and integrated GPUs. Great user= demand for these applications have pushed the mobile devices to their comp= utational limit. The disparity between user demand for computational power = and the architectural limits on mobile processing power gave rise to the em= ergence of mobile-cloud-computing: a platform that allows mobile devices to= utilize cloud resources to augment their computational (and storage) capab= ility. Due to the mature cloud computing infrastructure provided by cloud o= perators such as Amazon, Google, and Microsoft, offloading a part of the mo= bile processing to the cloud seems like a natural step towards accelerating= mobile applications. An emerging set of mobile-cloud applications require real-time response, pu= tting pressure on both computational and communication resources. This addi= tional pressure on communication resources motivate a reformulation of the = entire mobile-cloud computing process. Application based techniques, such a= s efficient scheduling and data caching, can be employed to alleviate some = of the pressure. Alternatively, protocol level advances can provide improve= ment at a much lower layer, but require the adoption of non-standard protoc= ols. Objective Enabling Real-Time Mobile Cloud Computing through Emerging Technologies aim= s to identify existing research topics, whether futuristic or readily-appli= cable, to allow the real-time execution of mobile cloud computing applicati= ons. The aspiration of this project is to become a collection of relevant r= esearch chapters in real-time mobile cloud computing encompassing various c= ommunication layers, in addition to comprehensive tutorials or surveys in t= hese topics. Target Audience This book is intended to be invaluable to any M.S. or Ph.D. students and pr= ofessors completing research in this field who need to be well versed in th= e most recent research and applications of mobile cloud computing. Recommended Topics This book will consist of approximately 20 edited chapters, prepared by aut= hors from the academia and the industry. The submissions from the academia = should focus on the theoretical foundation of real-time mobile-cloud comput= ing, while submissions from the industry should give insight to the practic= ality of the proposed ideas, as well as existing applications. Possible sub= mission topics include, but are not limited to: 1. Emerging or futuristic non-traditional protocols and their detailed theo= retical assessments, 2. Emerging architectural communication components, e.g., cloudlets, 3. Emerging infrastructural components, such as, fibre, 4. Emerging applications requiring real-time response, e.g., real-time face= recognition, 5. Emerging open source structures to allow application development, 6. Emerging techniques to enable secure mobile cloud computing, 7. Application cost structure of mobile cloud computing. Submission Procedure Please prepare a 2-3 page chapter proposal that clearly explains and illust= rates your proposed chapter. The proposed chapter should include (I) author= name(s), (II) a single contact email and an optional phone number, and (II= I) the CV of every author. Publisher This book is scheduled to be published by IGI Global (formerly Idea Group I= nc.), publisher of the "Information Science Reference" (formerly Idea Group= Reference), "Medical Information Science Reference," "Business Science Ref= erence," and "Engineering Science Reference" imprints. For additional infor= mation regarding the publisher, please visit www.igi-global.com. This publication is anticipated to be released in 2015. Important Dates May 30, 2014 Proposal Submission Deadline July 30, 2014 Full Chapter Submission Deadline September 14, 2014 Final Chapter Submission --_000_46a6c3e15bc94b50950588577b229957CO1PR07MB345namprd07pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

CALL FOR CHAPTERS

 

"Enabling Real= -Time Mobile Cloud Computing through Emerging Technologies"=

 

Details : http://www.igi-global.com/publish/call-= for-papers/call-details/1255

 

To Propose a chapter: http://www.igi-global.com/publish/call-for-= papers/submit/1255

 

 

Editors

Tolga Soyata, University of Rochester, USA

Call for Chapters

Proposals Submission Deadline: May 30, 2014
Full Chapters Due: July 31, 2014
Submission Date: September 14, 2014

Introduction

Today's smartphones and mobile devices are capable = of running power hungry applications thanks to their quad-core CPUs and int= egrated GPUs. Great user demand for these applications have pushed the mobile devices to their computational limit. The disparity= between user demand for computational power and the architectural limits o= n mobile processing power gave rise to the emergence of mobile-cloud-comput= ing: a platform that allows mobile devices to utilize cloud resources to augment their computational (and sto= rage) capability. Due to the mature cloud computing infrastructure provided= by cloud operators such as Amazon, Google, and Microsoft, offloading a par= t of the mobile processing to the cloud seems like a natural step towards accelerating mobile applications. =

An emerging set of mobile-cloud applications require real-time response, pu= tting pressure on both computational and communication resources. This addi= tional pressure on communication resources motivate a reformulation of the = entire mobile-cloud computing process. Application based techniques, such as efficient scheduling and data cachin= g, can be employed to alleviate some of the pressure. Alternatively, protoc= ol level advances can provide improvement at a much lower layer, but requir= e the adoption of non-standard protocols.

Objective

Enabling Real-Time Mobile Cloud Computing through E= merging Technologies aims to identify existing research topics, whether fut= uristic or readily-applicable, to allow the real-time execution of mobile cloud computing applications. The aspiration of this p= roject is to become a collection of relevant research chapters in real-time= mobile cloud computing encompassing various communication layers, in addit= ion to comprehensive tutorials or surveys in these topics.

Target Audience

This book is intended to be invaluable to any M.S. = or Ph.D. students and professors completing research in this field who need= to be well versed in the most recent research and applications of mobile cloud computing.

Recommended Topics

This book will consist of approximately 20 edited c= hapters, prepared by authors from the academia and the industry. The submis= sions from the academia should focus on the theoretical foundation of real-time mobile-cloud computing, while submissions from the= industry should give insight to the practicality of the proposed ideas, as= well as existing applications. Possible submission topics include, but are= not limited to:

1. Emerging or futuristic non-traditional protocols and their detailed theo= retical assessments,
2. Emerging architectural communication components, e.g., cloudlets,
3. Emerging infrastructural components, such as, fibre,
4. Emerging applications requiring real-time response, e.g., real-time face= recognition,
5. Emerging open source structures to allow application development,
6. Emerging techniques to enable secure mobile cloud computing,
7. Application cost structure of mobile cloud computing.<= /p>

Submission Procedure

Please prepare a 2-3 page chapter proposal that cle= arly explains and illustrates your proposed chapter. The proposed chapter s= hould include (I) author name(s), (II) a single contact email and an optional phone number, and (III) the CV of every author.=

Publisher

This book is scheduled to be published by IGI Globa= l (formerly Idea Group Inc.), publisher of the "Information Science Re= ference" (formerly Idea Group Reference), "Medical Information Science Reference," "Business Science Reference," and "= ;Engineering Science Reference" imprints. For additional information r= egarding the publisher, please visit www.igi-global.com. This publicat= ion is anticipated to be released in 2015.

Important Dates

May 30, 2014 Proposal Submission Deadline
July 30, 2014 Full Chapter Submission Deadline
September 14, 2014 Final Chapter Submission

 

--_000_46a6c3e15bc94b50950588577b229957CO1PR07MB345namprd07pro_-- From nobody Wed May 21 08:54:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9530A1A03C9 for ; Wed, 21 May 2014 08:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.078 X-Spam-Level: X-Spam-Status: No, score=-1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, MANGLED_WRLDWD=2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAg47iYy5vQo for ; Wed, 21 May 2014 08:54:06 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80081A0135 for ; Wed, 21 May 2014 08:54:05 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so2760170vcb.41 for ; Wed, 21 May 2014 08:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=+s31VMSGI309X2zPQCzaiG2QL0H0X5F98auVUmnePBg=; b=riHy5W+OUoJd8Vp5DdIDoAZtixUJzphUEuYzIt7ZcCe8gooZmaCcS5KSg7I3O3+G+0 UnXdW/W9Aq8peC0ODRb3uEFj/Ht9mFFC6IEDX/3oU2wWUlP2MrECw+T/EEMTswHo/rNY ZqC1ozKEtcmm2FQkZsgfo4WQxb2wc2M51WNmc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=+s31VMSGI309X2zPQCzaiG2QL0H0X5F98auVUmnePBg=; b=HLjdwyZxOZ6BGyXPq8hk3BWYPCQUAuxNFYyNDgb9SRANdKpP0CmF1xjn/mmWotS+iq 7dAd/k9iTNOA/lxaj1hKm25942Xqi1tCKpuesBy5OFHoPRBeLPPIt5odnvqDzIUpwnrL nK5UiXKR1R3pv6XryDkTZ3QMTKzsXdXkKa6eJ+F1ZUKftai0/qfY7spZQf+czTSYdZaZ 8T6oYKZCdg9ROdfyh5y/yA78BAOcHQdBe32HfvQjI29Scu2Thch2tll4IGJ7iC0nOHuP ozj3NoTHA26zk5JWinpJlyetFpKVweTF2Mj+5o4d9YWlQlSynozOZ9LMzSe01B8g2Ron 7Kng== X-Gm-Message-State: ALoCoQkAh3MwDlQb3xDUPBXuZyHaYd4FsoZkNgi2Bh1/e0ggHVCbyvBH2QYXK6zXjeM2oX0pz5BY MIME-Version: 1.0 X-Received: by 10.52.165.37 with SMTP id yv5mr977462vdb.58.1400687644389; Wed, 21 May 2014 08:54:04 -0700 (PDT) Received: by 10.221.21.129 with HTTP; Wed, 21 May 2014 08:54:04 -0700 (PDT) Date: Wed, 21 May 2014 08:54:04 -0700 Message-ID: From: Ulrich Herberg To: manet@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/WtADxGegScqi4R07UTGQItfEDuQ Subject: [manet] Fwd: Invitation to Participate in IETF 90 Bits-N-Bites: Internet of Things X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:54:07 -0000 FYI ---------- Forwarded message ---------- From: Alexa Morris Date: Wed, May 21, 2014 at 8:07 AM Subject: Invitation to Participate in IETF 90 Bits-N-Bites: Internet of Thi= ngs Bits-N-Bites at IETF 90 in Toronto will focus on the Internet of Things, and the IETF invites you and your organization to participate! The arrival of Things connected to the Internet in recent years has given life to new applications in both the consumer and industrial market segments. We are surrounded by products that utilize connectivity and a growing enthusiasm suggests imminent and impressive deployments: billions of new connected devices are expected by year 2020. In the industrial world, wide spread wireless sensoring devices that collect data and measurements will move us into the next phase of process optimization. This will require the combination of the best of Information Technology (IT) and Operational Technology (OT), forming the IT/OT convergence. When deploying multi-stage Thing topologies, two trends compete: IP protocols are enhanced and transformed into less end-to-end protocols (address translation, header compression, 'mesh under' routing and more) and, alternatively, existing IP protocols are reduced to their bare minimum such as to fit in reduced Things (reduced CPU frequency and number of transistors, dimensions and energy consumption). IETF 90 demonstrations should exhibit recent developments of IP protocols for IoT networks (6lowpan adaptation layers, MANET and RPL routing protocols, 6tsch time-constrained communications, CoAP app-layer protocols) as well as demonstrations of the tendency of bringing the known IPv6 as close as possible to the Thing - minimum set of unmodified IPv6, Neighbor Discovery, DHCP, HTTP, IKEv2. Demonstrations of geo-location uses in and for IP networking and the surrounding privacy issues are also welcome. Does your organization want to reach 1,200 Internet engineers and demonstrate your IoT technologies and usage of IETF protocols? This is your opportunity to show leading industry professionals the latest and greatest of what you do in a social and interactive setting. Examples of demos include, but are not limited, to: =E2=80=A2 home automation controller using SNMP for HVAC and ambient temperature, electricity counter; =E2=80=A2 industrial-grade Wireless Sensor Network products; =E2=80=A2 scalable wireless designs and existing deployments; =E2=80=A2 IPv6 end-to-end and backbone interconnection; =E2=80=A2 tablet summarizing status of widespread devices through heterogeneous link connections; =E2=80=A2 smart belt collecting body information with low-energy communicat= ion protocols; =E2=80=A2 vehicle interior connected designs, vehicle-to-road sensor-based communications; =E2=80=A2 sensor-assisted autonomous mobile Things (mono-, bi-, quad- wheel= ed or propelled devices); =E2=80=A2 vehicular communications (e.g. dead-reckoning enhancements for enhanced GPS localization, geo-dissemination); =E2=80=A2 smartphone applications relying on geo-localization. There many ways to configure your demo, such as: =E2=80=A2 Things deployed on a table, relying on local connections and alternatively exhibiting remote access across the Internet; =E2=80=A2 a poster describing a demo; =E2=80=A2 video sequence showing a lab demonstration. For information about IETF 90 Bits-N-Bites, please see http://www.ietf.org/meeting/90/90-bits-n-bites.html or send email to bnbsg@ietf.org. Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo From nobody Fri May 23 05:28:19 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB21A0193 for ; Fri, 23 May 2014 05:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emWqyrjV7s6I for ; Fri, 23 May 2014 05:28:15 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1C2F1A0192 for ; Fri, 23 May 2014 05:28:15 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id id10so2734819vcb.20 for ; Fri, 23 May 2014 05:28:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=IbA145H6LBiVExRhXFMkQJhiXxsKU5tdzBYWokJiZog=; b=i47pzaIe1pM9poN1VYA3CMjrm3u+THBJ8UyUykAO1XxvczNTLHVJV83cvAgrNNkxIv 0gDFOIdKpfTfS1X9jzdRZU+dXUJuFpfGp4enQcm+lymA53P171LaVLdcsgHZbFFw38Eb dz/g+znY9sLCYTr+kmF8N1t0skJBBd13W2G8K8TyQohLnWrGw0099CQX+BJNYJh9fmI0 M3/VRFXOx6rr4Nk5ZfNTNXs79ihiTRnVOintaSzHeCehoTOU7R5CZpeCqIpqNTGaumzb r9+rMllbTzqEVIS08qdx5DRU/0u+FtCKZmuiW2EmdpFcJLnN80LJFdIlhCEGMmy17oCc ts6A== X-Gm-Message-State: ALoCoQkInrzaFkd05d0382/1h0knRw/jLtQuqDq08/2NCWCpBw22HAPXqTutsFdhEtraUHXSRwhZ MIME-Version: 1.0 X-Received: by 10.221.51.77 with SMTP id vh13mr316604vcb.41.1400848092519; Fri, 23 May 2014 05:28:12 -0700 (PDT) Received: by 10.58.127.100 with HTTP; Fri, 23 May 2014 05:28:12 -0700 (PDT) X-Originating-IP: [80.246.32.33] Date: Fri, 23 May 2014 14:28:12 +0200 Message-ID: From: Hagen Paul Pfeifer To: manet@ietf.org, henning.rogge@fkie.fraunhofer.de Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kNJCGEQJvTWXipYR36gGLlYsl0U Subject: [manet] draft-ietf-manet-olsrv2-dat-metric-00 - Datarate Encoding (DAT_MINIMUM_BITRATE) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 12:28:17 -0000 Hello Henning, one short note? Why is DAT_MINIMUM_BITRATE (1024) a basis 2 constant (2^n) and not basis 10 constant (10^n). I mean it is just a constant and can be anything. But networking natural way is to use kbit/s (kilobit) opposed to Kibit/s (kibibit). Any thoughts on that? Cheers, Hagen From nobody Tue May 27 05:32:23 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC91A0037 for ; Tue, 27 May 2014 05:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T53tbo2n_gHF for ; Tue, 27 May 2014 05:32:19 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3321A0125 for ; Tue, 27 May 2014 05:32:18 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id r5so5331244qcx.38 for ; Tue, 27 May 2014 05:32: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:from:date:message-id:subject:to :cc:content-type; bh=Cbom8s31IJMY8/R745gDvOV9CpH0alCPWKWbprrNCPw=; b=xxQsE1+WsJ/vVwkwv1rV9R2j7/taqQMK2NVNfvgByATH6ERMKudXfzOMBc63QoQIku 94fj4o9nHXSNs+LPky5EKX8A7Tie+Vpe6JOSPAT8NigMe0oinMD3xdtHzS0mxIMZuaOP CfVJbMdl6jtc/Kp9tvZcngAWqBTKSMt5V5YyVtLTUCFYCj/HDwN87Q5oBcLf5k3pltuv O4KeH4PdlG2+W3i43N0//u6gpUrWUWU5nS9ZS1ttnStWog4qHU2rIoiQDs65G5J1joPW 1lz+MKuCbcNaoY1qq3Ob4J4hYhxulWrzAUoHYTTud4EWvbpqJ0J0Y4F8XJ3r70c1aAyu Xr2Q== X-Received: by 10.224.36.141 with SMTP id t13mr38967742qad.75.1401193935516; Tue, 27 May 2014 05:32:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.112.71 with HTTP; Tue, 27 May 2014 05:31:55 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Tue, 27 May 2014 14:31:55 +0200 Message-ID: To: Hagen Paul Pfeifer Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/BJW0BMDxjYBdQt16aaPcGnFMDO8 Cc: MANET IETF Subject: Re: [manet] draft-ietf-manet-olsrv2-dat-metric-00 - Datarate Encoding (DAT_MINIMUM_BITRATE) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 12:32:21 -0000 Hi, I did it in a power of 2 because the encoding of the metric is also in factors of a power of 2... I have no real preference here, we could change this. Henning On Fri, May 23, 2014 at 2:28 PM, Hagen Paul Pfeifer wrote: > Hello Henning, > > one short note? Why is DAT_MINIMUM_BITRATE (1024) a basis 2 constant > (2^n) and not basis 10 constant (10^n). I mean it is just a constant > and can be anything. But networking natural way is to use kbit/s > (kilobit) opposed to Kibit/s (kibibit). Any thoughts on that? > > Cheers, Hagen > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 27 08:39:26 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802F21A02C9 for ; Tue, 27 May 2014 08:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.152 X-Spam-Level: X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMbRdAIAFvWm for ; Tue, 27 May 2014 08:39:22 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2F51A0157 for ; Tue, 27 May 2014 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3133; q=dns/txt; s=iport; t=1401205159; x=1402414759; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=L6aNAcTPaK7um8K2yekqAA2/FMhk14s/2kGEd+eZjKA=; b=M2Jx9rU9hE+zHy2jVkevVKgafKs4zE6sLhqbvAlC0NAV2DikNLN/XQhI QRdYD5iyrum/ho8jj1Vsvw/uVRRL31mLnnPD4lJJ82SMPGW0Ox5XKIjHk m103V/G+NOSPAjFpPCZXivTC2gzWtSaHEfGkR2R1HcUgDAD8rMjWvIzp4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOqwhFOtJA2J/2dsb2JhbABZgmUiUli6YIc6AYEOFnSCJQEBAQQBAQE3NAkOBAIBCBEEAQELFAkHJwsUCQgCBAESCAESiCcBDNRuF44hOAaDJYEVBJswkWqBeIFAgi8 X-IronPort-AV: E=Sophos;i="4.98,920,1392163200"; d="scan'208";a="328036756" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP; 27 May 2014 15:39:18 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4RFdIHb029533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 May 2014 15:39:18 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Tue, 27 May 2014 10:39:18 -0500 From: "Nobo Akiya (nobo)" To: "Snyder, Brian" , "manet@ietf.org" Thread-Topic: New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt Thread-Index: AQHPaJkAIoW6FeSubkyTbj2TSLnbl5syvMmAgCH0NVA= Date: Tue, 27 May 2014 15:39:16 +0000 Message-ID: References: <20140505193415.20998.63258.idtracker@ietfa.amsl.com> <84585478AABBBF4B9DF597FC0F84AF7342FA3288@VAUS-MBX03.idirect.net> In-Reply-To: <84585478AABBBF4B9DF597FC0F84AF7342FA3288@VAUS-MBX03.idirect.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Sydrdg59BlnErgpUqh66GI1qYVE Subject: Re: [manet] New Version Notification for draft-snyder-bfd-proxy-connections-monitored-links-00.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:39:23 -0000 Hi MANET Folks, There was a small discussion on the BFD list, primary to better understand = the proposal. The proposed, we believe, provides a beneficial BFD implementation techniqu= e to subset of the MANET use cases (i.e. faster convergence over Satellite)= . We are planning to discuss with the MANET chairs to reserve a short present= ation slot for IETF90 in the MANET WG session, but any early feedback on th= e list is appreciated. Thanks! -Nobo & Brian > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Snyder, Brian > Sent: Monday, May 05, 2014 4:03 PM > To: manet@ietf.org > Subject: [manet] FW: New Version Notification for draft-snyder-bfd-proxy- > connections-monitored-links-00.txt >=20 > Hello all, >=20 > Nobo and I have been working on publishing a new informational RFC > related to proxying BFD via monitored links. This is written as a genera= lized > solution for all monitored links, but with satellite use case as the prim= ary > example. Additionally, prior to writing this document, I have actually c= oded > up a proof of concept which has been proven to work in the stated use cas= e. >=20 > If anyone would care to review and comment it would be most appreciated. >=20 > Thanks, > Brian & Nobo >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, May 05, 2014 3:34 PM > To: Nobo Akiya; Snyder, Brian; Nobo Akiya; Snyder, Brian > Subject: New Version Notification for draft-snyder-bfd-proxy-connections- > monitored-links-00.txt >=20 >=20 > A new version of I-D, draft-snyder-bfd-proxy-connections-monitored-links- > 00.txt > has been successfully submitted by Brian Snyder and posted to the IETF > repository. >=20 > Name: draft-snyder-bfd-proxy-connections-monitored-links > Revision: 00 > Title: BFD Proxy for Connections over Monitored Links > Document date: 2014-05-05 > Group: Individual Submission > Pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-snyder-bfd-prox= y- > connections-monitored-links-00.txt > Status: https://datatracker.ietf.org/doc/draft-snyder-bfd-proxy- > connections-monitored-links/ > Htmlized: http://tools.ietf.org/html/draft-snyder-bfd-proxy- > connections-monitored-links-00 >=20 >=20 > Abstract: > This document describes a Bidirectional Forwarding Detection (BFD) > proxy mechanism to allow intermediate networking equipment (ex: > Satellite HUB/Modem) to intercept BFD packets and to generate BFD > packets to relay the health of connection monitored links. >=20 > Note that this is an informational document that does not propose any > changes to the BFD protocol. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 27 08:50:25 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A901A0428 for ; Tue, 27 May 2014 08:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jryZzpa5aR_q for ; Tue, 27 May 2014 08:50:22 -0700 (PDT) Received: from mail-ve0-f182.google.com (mail-ve0-f182.google.com [209.85.128.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 710C61A044C for ; Tue, 27 May 2014 08:50:16 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so10990114veb.13 for ; Tue, 27 May 2014 08:50:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Z0PaDWu+xqM8/YBx9Y7koBZ2MvgrI/Smb08m4sCw/0w=; b=CQFtAu97545m5dth3GfaPVGTpwWXYiBUlna5hUb8jtqBw6hiqToYDUCjDyv4wz9Lvh BinvESjYJBVhOPtSHOL7DVPUTf48QKzYJZrmhXowflaFT9XOKJ1EOBzVQ/v83A0VQex4 r7vCvUP2sYStVNGwkAa09Zau/T6FRbyKdl6L5Rgr2pn2yaWiDIRbglcOYBSWkOG3BzvV PHFe25XRXqukyvlgZ+uDbpnGZBp6LTmKK9mSCrZMLxuaquieJvelDAlc/s7EdfRPMCVi nqTEqYdewMRCELXmmi9E3wERTR4EiTHFEaSyo0oRb43D7R10Qdy5YbF+ZwJtu61bEZVy SOEw== X-Gm-Message-State: ALoCoQksnnTXGRW6o6He/POiaGcLIm8bYvCwbhVeXlRhQNYv6TEu77LX+EilE5ppL9IlzBLHXq1O MIME-Version: 1.0 X-Received: by 10.220.179.197 with SMTP id br5mr1570196vcb.80.1401205812731; Tue, 27 May 2014 08:50:12 -0700 (PDT) Received: by 10.58.127.100 with HTTP; Tue, 27 May 2014 08:50:12 -0700 (PDT) X-Originating-IP: [109.43.1.63] Received: by 10.58.127.100 with HTTP; Tue, 27 May 2014 08:50:12 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 17:50:12 +0200 Message-ID: From: Hagen Paul Pfeifer To: Henning Rogge Content-Type: multipart/alternative; boundary=001a11c1bc16b9e32404fa63a69d Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GQkVpjCPuI5T6Cxyjxj98EytbUA Cc: manet@ietf.org Subject: Re: [manet] draft-ietf-manet-olsrv2-dat-metric-00 - Datarate Encoding (DAT_MINIMUM_BITRATE) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 15:50:23 -0000 --001a11c1bc16b9e32404fa63a69d Content-Type: text/plain; charset=UTF-8 On 27 May 2014 14:31, Henning Rogge wrote: > I did it in a power of 2 because the encoding of the metric is also in > factors of a power of 2... I have no real preference here, we could > change this. Then I vote for a change in -01 Henning. Just because it is common to use decimal prefix for bandwidth/datarate. Thank you, Hagen --001a11c1bc16b9e32404fa63a69d Content-Type: text/html; charset=UTF-8

On 27 May 2014 14:31, Henning Rogge <hrogge@gmail.com> wrote:

> I did it in a power of 2 because the encoding of the metric is also in
> factors of a power of 2... I have no real preference here, we could
> change this.

Then I vote for a change in -01 Henning. Just because it is common to use decimal prefix for bandwidth/datarate.

Thank you, Hagen

--001a11c1bc16b9e32404fa63a69d-- From nobody Wed May 28 10:29:54 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D991A044A for ; Wed, 28 May 2014 10:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGQFZKojaNsH for ; Wed, 28 May 2014 10:29:50 -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 4A9221A0168 for ; Wed, 28 May 2014 10:29:50 -0700 (PDT) Received: from [107.1.141.74] (helo=[192.168.252.251]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Wphfb-0006jU-SD; Wed, 28 May 2014 13:29:44 -0400 Message-ID: <53861D03.4020805@computer.org> Date: Wed, 28 May 2014 10:29:39 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Martin Heusse References: <061.38a7788f3dfe934d4b40ca8d7fd57c11@trac.tools.ietf.org> <53489520.6030604@computer.org> <8726221D-23F3-433E-B4F1-1100BB7D8F32@imag.fr> In-Reply-To: <8726221D-23F3-433E-B4F1-1100BB7D8F32@imag.fr> Content-Type: multipart/alternative; boundary="------------030407060106060803040607" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c67fbe4464bcf422c5a93a4b6424e367350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/stgEe3ntcmv7MYrUWiug37eOKH0 Cc: manet@ietf.org Subject: Re: [manet] #20 (aodvv2): Idle routes must be marked as active after re-use X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 17:29:52 -0000 This is a multi-part message in MIME format. --------------030407060106060803040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hello Martin, Your points are well taken. However, the "active status" of a route is important when determining whether or not to report it as broken. Routes that are inactive don't need to be included in an RERR message even if the next hop link is broken. The way that AODVv2 determines whether a route is active or not, is by keeping track of how recently it has been used. Less important, but still with some value, is the distinction between idle routes and expired routes. An idle route can be used to forward packets, and an expired route cannot. However, even an expired route contains one valuable field, namely the latest known sequence number. If there is no penalty, it can be useful to keep that information in case there are some old RREQ packets still being retransmitted (say, because of really full queues at some nodes in the network). This situation is rare, but Murphy's law demands that it happen sometimes. I don't believe there is any significant penalty for trying to prevent it. Finally, there comes a time when even the sequence number is potentially harmful. This happens when it is so old that it might have been duplicated by the node after rebooting. It was shown some years ago that sequence numbers have to be expunged after a time equal to the hold-down time for nodes after reboot (MAX_SEQNUM_LIFETIME). More on this last point later... On 4/30/2014 2:44 AM, Martin Heusse wrote: > > Does this really belong to the protocol specification? To me, if a > node runs out of memory space, it's a local decision to remove a > route or the other. The protocol will still operate properly. > Granted, it's more efficient if everyone follows pretty much the same > policy :-) > > Now, removing the oldest route may not be the best idea: it's not > unlikely that the first route a "node" creates is the most important! > > > Maybe a statement like: "routers should discard routes in order of > least recent usage" could be enough? (And then, you don't have to > care about idle/inactive/active route status. This information is not > exchanged between nodes, anyway.) > > Martin > > Le 12 avr. 2014 à 03:21, Charles E. Perkins a > écrit : > >> Proposal: after the text: >>> When a route is no longer Active, it becomes an Idle route. >> >> The proposed text: >> >>> If an Idle route is used to forward a packet, it becomes an >>> Active route once again. >> >> >> However, there may be a better solution which requires more >> extensive changes. While the distinction between an active route >> and an idle route is interesting to consider, the main difference >> between them is that an idle route is preferred for deletion >> whenever space needs to be reclaimed. The same effect can be had >> by specifying that route table memory space be reclaimed by >> deleting the oldest routes first. I think this will produce some >> simplification to the text without any real loss of clarity. >> >> I am O.K. going either way, and only offer this suggestion for >> consideration. > > -- Regards, Charlie P. --------------030407060106060803040607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Martin,

Your points are well taken.  However, the "active status" of a route
is important when determining whether or not to report it as
broken.  Routes that are inactive don't need to be included in an
RERR message even if the next hop link is broken.  The way that
AODVv2 determines whether a route is active or not, is by
keeping track of how recently it has been used.

Less important, but still with some value, is the distinction
between idle routes and expired routes.  An idle route can be
used to forward packets, and an expired route cannot.  However,
even an expired route contains one valuable field, namely the
latest known sequence number.  If there is no penalty, it can
be useful to keep that information in case there are some old
RREQ packets still being retransmitted (say, because of really
full queues at some nodes in the network).  This situation is
rare, but Murphy's law demands that it happen sometimes.
I don't believe there is any significant penalty for trying to
prevent it.

Finally, there comes a time when even the sequence number
is potentially harmful.  This happens when it is so old that it
might have been duplicated by the node after rebooting.
It was shown some years ago that sequence numbers have to
be expunged after a time equal to the hold-down time for nodes
after reboot (MAX_SEQNUM_LIFETIME).

More on this last point later...




On 4/30/2014 2:44 AM, Martin Heusse wrote:
>
> Does this really belong to the protocol specification? To me, if a
> node runs out of memory space, it's a local decision to remove a
> route or the other. The protocol will still operate properly.
> Granted, it's more efficient if everyone follows pretty much the same
> policy :-)
>
> Now, removing the oldest route may not be the best idea: it's not
> unlikely that the first route a "node" creates is the most important!
>
>
> Maybe a statement like: "routers should discard routes in order of
> least recent usage" could be enough? (And then, you don't have to
> care about idle/inactive/active route status. This information is not
> exchanged between nodes, anyway.)
>
> Martin
>
> Le 12 avr. 2014 à 03:21, Charles E. Perkins <charliep@computer.org> a
> écrit :
>
>> Proposal: after the text:
>>> When a route is no longer Active, it becomes an Idle route.
>>
>> The proposed text:
>>
>>> If an Idle route is used to forward a packet, it becomes an
>>> Active route once again.
>>
>>
>> However, there may be a better solution which requires more
>> extensive changes. While the distinction between an active route
>> and an idle route is interesting to consider, the main difference
>> between them is that an idle route is preferred for deletion
>> whenever space needs to be reclaimed.  The same effect can be had
>> by specifying that route table memory space be reclaimed by
>> deleting the oldest routes first.  I think this will produce some
>> simplification to the text without any real loss of clarity.
>>
>> I am O.K. going either way, and only offer this suggestion for
>> consideration.
>
>

--
Regards,
Charlie P.

--------------030407060106060803040607-- From nobody Wed May 28 10:34:58 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BD41A0A18 for ; Wed, 28 May 2014 10:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHwwRcnUlTCY for ; Wed, 28 May 2014 10:34:53 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDF01A0A16 for ; Wed, 28 May 2014 10:34:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VlPUr8DTsK+7rUwBoEJWjneZWP6uXButGP4KUoNSSLkGCDLwXSJviQ8Qaiu2e2vA; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.252.251]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WphkL-0003Fi-J5; Wed, 28 May 2014 13:34:37 -0400 Message-ID: <53861E28.1070700@earthlink.net> Date: Wed, 28 May 2014 10:34:32 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org, lotte.steenbrink@fu-berlin.de References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> In-Reply-To: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac73918c9bae58cc4933abd8a300ebb5fc9350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/o1i5fLTH1nKP9o37Mv8la7noU2s Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 17:34:55 -0000 Hello Lotte, I am O.K. with removing the RREP_ACK from the draft. There was some discussion a while back about compatibility, but I have not seen anyone defending the RREP_ACK in this discussion and it was not present in the previous DYMO drafts. If anyone would prefer to keep RREP_ACK, then I will try to fashion some more detailed specification for handling it, which will be basically the way it was handled by AODV. Regards, Charlie P. On 4/22/2014 12:39 PM, manet issue tracker wrote: > #41: AckReq vs RREP_ACK > > In Section 13.5., the AODVv2 Draft briefly describes a mechanism called > RREP_ACK, which seems to serve a similar purpose as the AckReqs described > in section 5.2. > While RFC 3561, which is referenced in section 13.5., explains that a > RREP-ACK is sent when a packet with the 'A' bit set is received, the > AODVv2 does not describe how a RREP_ACK is triggered. > Additionally, the draft does not specify how a RREP_ACK should be handled. > If the feature of a RREP_ACK is really needed, a more thorough explanation > should be added. Otherwise, removing it could be a step towards de- > cluttering the draft. > From nobody Wed May 28 11:09:28 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335131A6F04 for ; Wed, 28 May 2014 11:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79oM4XiHLo6H for ; Wed, 28 May 2014 11:09:25 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id B60321A6F02 for ; Wed, 28 May 2014 11:09:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KWrhVfryT4GEpeFmJ7JPavaAT8kND3ue4zezyPEjrpX5OwGaV65wDe86hMI3jrbJ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.252.251]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpiHr-0007z6-J2; Wed, 28 May 2014 14:09:15 -0400 Message-ID: <53862649.7020108@earthlink.net> Date: Wed, 28 May 2014 11:09:13 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: manet@ietf.org References: <061.04d6856ca1d9c40a9ad288f003eeb91f@trac.tools.ietf.org> <53487C1A.6060401@computer.org> In-Reply-To: <53487C1A.6060401@computer.org> Content-Type: multipart/alternative; boundary="------------050403080901090305090302" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac726065f69dd232a2d5782ba81b37a1ea5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/c5zEK8w6UXon0Fs5pYw9Bfg0qYY Cc: draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #22 (aodvv2): Multiple terms for same concept X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 18:09:27 -0000 This is a multi-part message in MIME format. --------------050403080901090305090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello again folks, It turns out to be quite straightforward to revise the text so that the term "active source" is not needed. So, I don't need to make a definition for this term. Regards, Charlie P. On 4/11/2014 4:34 PM, Charles E. Perkins wrote: > Hello folks, > > PktSource means the source of the packet that triggered > the RERR. It could be renamed to be "RERR_Dest", since the > RERR is being sent to the source of the packet that triggered > the RERR. > > "active sources" are those actively sending data. I will make > a new definition for this. > > Regards, > Charlie P. > > > On 4/4/2014 1:32 PM, Abdussalam Baryun wrote: >> IMHO, MANET has more concepts depending on the network use and >> status. Therefore it is good that this work considers many use cases. >> >> On Thursday, April 3, 2014, manet issue tracker wrote: >> >> #22: Multiple terms for same concept >> >> (Thomas Clausen) While we are on that, I notice that "active >> source" is >> used; I am not sure what that is vs a "source" and vs a !PktSource. >> >> >> It is clear in MANET that active node means there is sleep period >> within that node, so when the node is out of that period it is active. >> >> A >> source is someone who generates data traffic, I would suspect >> ... so an >> active source is....what? Or, is a source someone who can, but >> doesn't, >> generate data traffic? >> >> >> The source is a node that generates data. The active node is a node >> that generates data for some determined period of times, and does not >> receive/generate within sleeping periods. >> >> if so, what is the significance of that wrt. >> routing protocol operation? And, wrt a /reactive/ routing >> protocol, which >> I would assume constructs routes only for active >> source-destination pairs? >> >> >> I don't think that is correct. In MANET we say it MAY have LLN >> nodes so it is good AODVv2 considers LLNs scenarios. The ROLL WG have >> done a terminology RFC, I will try to continue the Manet terminology >> draft. The routing in LLNs and MANETs does construct routes not only >> for active source-destination pairs, but routes that have multihops >> with sleep periods as well. >> >> AB > > -- > Regards, > Charlie P. --------------050403080901090305090302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello again folks,

It turns out to be quite straightforward to revise the text
so that the term "active source" is not needed.  So, I don't
need to make a definition for this term.

Regards,
Charlie P.


On 4/11/2014 4:34 PM, Charles E. Perkins wrote:
Hello folks,

PktSource means the source of the packet that triggered
the RERR.  It could be renamed to be "RERR_Dest", since the
RERR is being sent to the source of the packet that triggered
the RERR.

"active sources" are those actively sending data.  I will make
a new definition for this.

Regards,
Charlie P.


On 4/4/2014 1:32 PM, Abdussalam Baryun wrote:
IMHO, MANET has more concepts depending on the network use and status. Therefore it is good that this work considers many use cases. 

On Thursday, April 3, 2014, manet issue tracker wrote:
#22: Multiple terms for same concept

 (Thomas Clausen) While we are on that, I notice that "active source" is
 used; I am not sure what that is vs a "source" and vs a !PktSource. 

It is clear in MANET that active node means there is sleep period within that node, so when the node is out of that period it is active. 

A
 source is someone who generates data traffic, I would suspect ... so an
 active source is....what?  Or, is a source someone who can, but doesn't,
 generate data traffic? 

The source is a node that generates data. The active node is a node that generates data for some determined period of times, and does not receive/generate within sleeping periods. 
 
 if so, what is the significance of that wrt.
 routing protocol operation? And, wrt a /reactive/ routing protocol, which
 I would assume constructs routes only for active source-destination pairs?

I don't think that is correct. In MANET we say it MAY have LLN nodes so it is good AODVv2 considers LLNs scenarios. The ROLL WG have done a terminology RFC, I will try to continue the Manet terminology draft. The routing in LLNs and MANETs does construct routes not only for active source-destination pairs, but routes that have multihops with sleep periods as well. 

AB

-- 
Regards,
Charlie P.

--------------050403080901090305090302-- From nobody Wed May 28 11:51:42 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13221A064A for ; Wed, 28 May 2014 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNrqqgO-YR0N for ; Wed, 28 May 2014 11:51:37 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 47BF91A0649 for ; Wed, 28 May 2014 11:51:37 -0700 (PDT) Received: from [107.1.141.74] (helo=[192.168.252.251]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpiwV-0004ev-3z; Wed, 28 May 2014 14:51:15 -0400 Message-ID: <5386301E.2@computer.org> Date: Wed, 28 May 2014 11:51:10 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> In-Reply-To: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac778a2daf80e0c40d5f31465e46b7f472d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Qj4pZrd561EJPIJyeJ1oDdLPVR0 Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 18:51:39 -0000 Hello folks, I'm not quite sure what to do about this. Contrary to the assertion, the term "Protocol Constant" is pretty well understood and has been used with the same meaning in numerous existing RFCs. I think that it would be interesting to explore the results of using different constants, but the intention is clearly that implementations should use the numbers as provided. If desired, I can try to fashion some text to suggest the results of using different numbers (e.g., for use in atypical situations). Regards, Charlie P. On 4/3/2014 2:34 PM, manet issue tracker wrote: > #35: A constant is constant > > (Thomas Clausen) > Section 14.2 "Protocol Constants" contains a semantically null > sentence AODVv2 protocol constants typically do not require changes > > A constant is constant, therefore it doesn't change. Even for very > loose definitions of constant. With that being said, the interesting > part here is actually not that bit...but rather, what happens *if* > these are not set to the values that are indicated? Or, if different > implementations use different values for these? The same holds for > 14.2, btw: is a network able to operate with different routers setting > different values? Will it break? Degrade gracefully? Just work? > -- Regards, Charlie P. From nobody Wed May 28 12:03:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C71A0584 for ; Wed, 28 May 2014 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mec5UYfa0eDc for ; Wed, 28 May 2014 12:03:42 -0700 (PDT) Received: from mail4.hitachi.co.jp (mail4.hitachi.co.jp [133.145.228.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB211A06D5 for ; Wed, 28 May 2014 12:03:42 -0700 (PDT) Received: from mlsv1.hitachi.co.jp (unknown [133.144.234.166]) by mail4.hitachi.co.jp (Postfix) with ESMTP id 6765233CC3; Thu, 29 May 2014 04:03:38 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv1.hitachi.co.jp (8.13.1/8.13.1) id s4SJ3ciG004599; Thu, 29 May 2014 04:03:38 +0900 Received: from vshuts01.hitachi.co.jp (vshuts01.hitachi.co.jp [10.201.6.83]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id s4SJ3brQ016207; Thu, 29 May 2014 04:03:38 +0900 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts01.hitachi.co.jp (Postfix) with ESMTP id 22C7C2F0038; Thu, 29 May 2014 04:03:37 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.8/3.7W11021512) id s4SJ3bDE022959; Thu, 29 May 2014 04:03:37 +0900 X-AuditID: 85900ec0-d1328b9000001514-d4-538633082d5c Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.yrl.intra.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id CFA31236561; Thu, 29 May 2014 04:03:36 +0900 (JST) Received: from maila.sdl.hitachi.co.jp (sdl99a.yrl.intra.hitachi.co.jp [133.144.14.196]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id A62F353C21A; Thu, 29 May 2014 04:08:41 +0900 (JST) Received: from [10.198.219.54] (unknown [10.198.219.54]) by maila.sdl.hitachi.co.jp (Postfix) with ESMTP id B86AD495B85; Thu, 29 May 2014 04:03:36 +0900 (JST) Message-ID: <53863308.3070704@hitachi.com> Date: Thu, 29 May 2014 04:03:36 +0900 From: Yuichi IGARASHI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Charlie Perkins References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> In-Reply-To: <53861E28.1070700@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-5-pHQzmioinQS3YkoXChE3d6X8 Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 19:03:45 -0000 Hi Charlie, It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, if you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links are bi-directional? AODVv2 requires all routes to implement other protocol for verifying bi-directionality of links? I am sure that would cause interoperability problems. Also, this is related to tickets #26 and #27, I think. Regards, Yuichi (2014/05/29 2:34), Charlie Perkins wrote: > > Hello Lotte, > > I am O.K. with removing the RREP_ACK from the draft. There was > some discussion a while back about compatibility, but I have not > seen anyone defending the RREP_ACK in this discussion and it was > not present in the previous DYMO drafts. > > If anyone would prefer to keep RREP_ACK, then I will try to fashion > some more detailed specification for handling it, which will be > basically the way it was handled by AODV. > > Regards, > Charlie P. > > > On 4/22/2014 12:39 PM, manet issue tracker wrote: >> #41: AckReq vs RREP_ACK >> >> In Section 13.5., the AODVv2 Draft briefly describes a mechanism called >> RREP_ACK, which seems to serve a similar purpose as the AckReqs >> described >> in section 5.2. >> While RFC 3561, which is referenced in section 13.5., explains that a >> RREP-ACK is sent when a packet with the 'A' bit set is received, the >> AODVv2 does not describe how a RREP_ACK is triggered. >> Additionally, the draft does not specify how a RREP_ACK should be >> handled. >> If the feature of a RREP_ACK is really needed, a more thorough >> explanation >> should be added. Otherwise, removing it could be a step towards de- >> cluttering the draft. >> > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > -- Hitachi, Ltd., Yokohama Research Laboratory Yuichi Igarashi Mail： yuichi.igarashi.hb@hitachi.com Tel ： +81-(0)50-3135-3457 From nobody Wed May 28 14:42:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC971A028E for ; Wed, 28 May 2014 14:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDc4hK8OkA9L for ; Wed, 28 May 2014 14:42:05 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 051E11A0261 for ; Wed, 28 May 2014 14:42:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=SBNTfcd1oc7WFhvSJbjbQNmBwKTgsYg8Ip4szeqHfhO6bOkasw7HOvz/EBMEW8HC; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Wplbb-0008C3-Ma; Wed, 28 May 2014 17:41:51 -0400 Message-ID: <5386581E.3070907@earthlink.net> Date: Wed, 28 May 2014 14:41:50 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Yuichi IGARASHI References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> In-Reply-To: <53863308.3070704@hitachi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7cff5ab7e0ede3457292495df01a32de7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rsuj_C48NW3Z88048sj7VOMcDnA Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:42:07 -0000 Hello Yuishi, Bidirectionality can be tested in various ways, even by just using ping (which is required by IP and thus always available). This is discussed briefly at the top of page 9 in the current revision, but I will be happy to expand the discussion. Please let me know how I can improve the description. I will cite include a citation for ping (i.e., ICMP Echo Request/Reply). Regards, Charlie P. On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: > Hi Charlie, > > It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, > if you remove RREP_ACK from the spec, how does AODVv2 itself ensure > all links are bi-directional? AODVv2 requires all routes to implement > other protocol for verifying bi-directionality of links? I am sure > that would cause interoperability problems. > Also, this is related to tickets #26 and #27, I think. > > Regards, > Yuichi > (2014/05/29 2:34), Charlie Perkins wrote: >> >> Hello Lotte, >> >> I am O.K. with removing the RREP_ACK from the draft. There was >> some discussion a while back about compatibility, but I have not >> seen anyone defending the RREP_ACK in this discussion and it was >> not present in the previous DYMO drafts. >> >> If anyone would prefer to keep RREP_ACK, then I will try to fashion >> some more detailed specification for handling it, which will be >> basically the way it was handled by AODV. >> >> Regards, >> Charlie P. >> >> >> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>> #41: AckReq vs RREP_ACK >>> >>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>> called >>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>> described >>> in section 5.2. >>> While RFC 3561, which is referenced in section 13.5., explains that a >>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>> AODVv2 does not describe how a RREP_ACK is triggered. >>> Additionally, the draft does not specify how a RREP_ACK should be >>> handled. >>> If the feature of a RREP_ACK is really needed, a more thorough >>> explanation >>> should be added. Otherwise, removing it could be a step towards de- >>> cluttering the draft. >>> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > From nobody Wed May 28 14:59:34 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4836C1A0272 for ; Wed, 28 May 2014 14:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnz18rHPB5DF for ; Wed, 28 May 2014 14:59:30 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC1DF1A0643 for ; Wed, 28 May 2014 14:59:29 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id j107so19818459qga.34 for ; Wed, 28 May 2014 14:59: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=mhSmkOi6yzffy38FWVXdF7nt39UFQDBRLJ83SGR6CRg=; b=XVWoDFxMkH/oChxVBvv3Gt8fkBeFp8omnIM4GpVJBvJnUnsRYqSUBoB/0FX2uor0sh G/TH2Zl5tqSgLiZdZe4OtXRjirp02UfavVGEc+/Ycfloy8P1wHFwWc57oHTHNnmxqeLo oleL7kOMf0oc6JlUDBamawqJBlGMUatI/gYbsaG8ZmhSWDGnylEVSgXeM7v8UJ0FSd1k Y7RsqfjqfvJscoePorrU4qaj6ENCB8+4oM46F9IbHWXyMJ8X3k9GgeKPNdeYN69I71Cc IbNoent3QAZA+/zZUu0KlsQZc1TxV/THkbOUAAxu3zGKVWq2FK0qzXlzJcx+sTeynR5D RbKg== X-Received: by 10.140.102.115 with SMTP id v106mr3941065qge.8.1401314365832; Wed, 28 May 2014 14:59:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.112.71 with HTTP; Wed, 28 May 2014 14:59:05 -0700 (PDT) In-Reply-To: <5386581E.3070907@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> From: Henning Rogge Date: Wed, 28 May 2014 23:59:05 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/GiQ1hnsKOfgCqPwwDjr9rkeTxdQ Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 21:59:32 -0000 Hi Charlie, so you plan to remove the "AODVv2 does only support bidirectional links" pa= rt? Henning Rogge On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins wrote: > Hello Yuishi, > > Bidirectionality can be tested in various ways, even by > just using ping (which is required by IP and thus always > available). This is discussed briefly at the top of > page 9 in the current revision, but I will be happy to > expand the discussion. Please let me know how I can > improve the description. I will cite include a citation > for ping (i.e., ICMP Echo Request/Reply). > > Regards, > Charlie P. > > > > On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >> >> Hi Charlie, >> >> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D= . But, if >> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all lin= ks >> are bi-directional? AODVv2 requires all routes to implement other protoc= ol >> for verifying bi-directionality of links? I am sure that would cause >> interoperability problems. >> Also, this is related to tickets #26 and #27, I think. >> >> Regards, >> Yuichi >> (2014/05/29 2:34), Charlie Perkins wrote: >>> >>> >>> Hello Lotte, >>> >>> I am O.K. with removing the RREP_ACK from the draft. There was >>> some discussion a while back about compatibility, but I have not >>> seen anyone defending the RREP_ACK in this discussion and it was >>> not present in the previous DYMO drafts. >>> >>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>> some more detailed specification for handling it, which will be >>> basically the way it was handled by AODV. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>> >>>> #41: AckReq vs RREP_ACK >>>> >>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>> called >>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>> described >>>> in section 5.2. >>>> While RFC 3561, which is referenced in section 13.5., explains that = a >>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>> Additionally, the draft does not specify how a RREP_ACK should be >>>> handled. >>>> If the feature of a RREP_ACK is really needed, a more thorough >>>> explanation >>>> should be added. Otherwise, removing it could be a step towards de- >>>> cluttering the draft. >>>> >>> >>> _______________________________________________ >>> 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 nobody Wed May 28 15:26:52 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B731A0301 for ; Wed, 28 May 2014 15:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vNa2vZK1-Oq for ; Wed, 28 May 2014 15:26:48 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 367BB1A0284 for ; Wed, 28 May 2014 15:26:48 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpmIm-0003z4-KO; Wed, 28 May 2014 18:26:28 -0400 Message-ID: <53866290.6070309@computer.org> Date: Wed, 28 May 2014 15:26:24 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: manet@ietf.org, draft-ietf-manet-aodvv2@tools.ietf.org References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> In-Reply-To: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7c3095dc69650291180fcc2bc2d8e7eff350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/neMMtUl1A8RpuctmRKCEFSeOIag Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:26:50 -0000 I did not find the specification within RFC5444 mandating the limitation as stated below. In fact, RFC 5444 has the following text: ============================================================= o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. .... o field, if present, contains the number of hops on which the packet has traveled across the MANET. .... ============================================================== which many people would interpret to indicate that a packet might traverse multiple hops. Anyway, I will do the following: a) make it clear that AODV multicast packets traverse only a single hop and b) remove the unnecessary passages from the relevant text cited below in section 5.4. On 4/3/2014 2:31 PM, manet issue tracker wrote: > #33: RFC 5444 processing constraint > > (Thomas Clausen) > I have a general concern about how this protocol imposes constraints > on RFC5444 usage, which precludes co-existence with other RFC5444 > protocols running on the same device. > > Let me give an example hereof, from Section 5.4: > > > {{{ > When multiple messages are aggregated into a single packet > according to RFC 5444 formatting, and the aggregation of > messages is also authenticated (e.g., with IPsec), and the > IP destination is multiple hops away, it becomes > infeasible > to delete individual messages. In such cases, instead of > deleting individual messages, they are maintained in the > aggregation of messages, but simply ignored for further > processing. In such cases where individual messages > cannot > be deleted, in this document "disregarded" means > "ignored". > Otherwise, any such "disregarded" AODVv2 messages SHOULD > be > deleted from the aggregated messages in the RFC 5444 > packet. > }}} > > An RFC5444 packet is *never* to be sent more than one hop. > ... A router receives an RFC5444 packet, decapsulates > it, process each message (if appropriate), the owner process of each > message identifies which messages are to be forwarded (if appropriate), > hands those off to the appropriate "message multiplexing engine" which > packs those messages up in a new RFC5444 packet, and transmits that > new RFC5444 packet. Check. > > Also, in RFC5444 messages, addresses are contained in address blocks. > There is no semantics associated with an address being in one address > block, or in another (in fact, (re-)organising addresses into address > blocks is one of the tricks to use to obtain more compact messages). > Likewise, there is no semantics associated with an address being first, > last, or in any other position in an address block: the ordering of > addresses in an address block carries no semantics. > > Therefore, writing something like this: > > > {{{ > RteMsg.Address[i] denotes the [i]th address in an RFC 5444 > AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the > associated prefix length for RteMsg.Address[i], and > RteMsg.{field} denotes the corresponding value in the > named > AddrTLV block associated with RteMsg.Address[i]. > }}} > > > makes no sense whatsoever (aside from the fact that I do not understand > the notation !RteMsg.{field} - that would indicate a "field" in a > message, not in an attribute associated with an address). I don't think this is still an issue in the current draft. However, it is notable that certain ordering constraints must be associated with addresses and associated TLVs. For instance, the [i]th element of an array of values in a TLV must be associated with the [i]th address. > > Let me give one more example, from section 9: > > > {{{ > If a message with an unknown type is received, the message is > disregarded. > }}} > > > An implementation of this specification will (according to RFC5444) > "own", and therefore get messages that this protocol has gotten > assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any > other Message Types will not (again, according to RFC5444) be > delivered to an implementation of this protocol. > > Therefore, this protocol > specify discarding any message types other than those than it "owns". Well, O.K. if we are going to agree that it's impossible for AODVv2 to receive a message of an unknown type, the text is redundant and can be removed. It boils down to having RFC 5444 enforce the type checking instead of AODVv2. Sounds less than robust to me. -- Regards, Charlie P. From nobody Wed May 28 15:33:39 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F71A06F0 for ; Wed, 28 May 2014 15:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_kLlhnQ1ifR for ; Wed, 28 May 2014 15:33:30 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAAF1A06E1 for ; Wed, 28 May 2014 15:33:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id F02E0940E2C; Wed, 28 May 2014 15:33:26 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (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 mailc1.tigertech.net (Postfix) with ESMTPSA id 57DE4940E2B; Wed, 28 May 2014 15:33:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D201) In-Reply-To: <53866290.6070309@computer.org> Date: Thu, 29 May 2014 00:33:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9F4F44F7-3510-4114-A076-191529A5C6A4@thomasclausen.org> References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/hE4h7FDwpV7fUPzUVK2sJbdS_aA Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:33:36 -0000 > On 29 mai 2014, at 00:26, "Charles E. Perkins" wro= te: >=20 > I did not find the specification within RFC5444 mandating the > limitation as stated below. In fact, RFC 5444 has the following text: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. .... >=20 > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. .... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > which many people would interpret to indicate that a packet might > traverse multiple hops. Packet !=3D message Thomas > Anyway, I will do the following: > a) make it clear that AODV multicast packets traverse only a single > hop and > b) remove the unnecessary passages from the relevant text cited below > in section 5.4. >=20 >=20 >> On 4/3/2014 2:31 PM, manet issue tracker wrote: >> #33: RFC 5444 processing constraint >>=20 >> (Thomas Clausen) >> I have a general concern about how this protocol imposes constraints >> on RFC5444 usage, which precludes co-existence with other RFC5444 >> protocols running on the same device. >>=20 >> Let me give an example hereof, from Section 5.4: >>=20 >>=20 >> {{{ >> When multiple messages are aggregated into a single pack= et >> according to RFC 5444 formatting, and the aggregation of= >> messages is also authenticated (e.g., with IPsec), and t= he >> IP destination is multiple hops away, it becomes >> infeasible >> to delete individual messages. In such cases, instead o= f >> deleting individual messages, they are maintained in the= >> aggregation of messages, but simply ignored for further >> processing. In such cases where individual messages >> cannot >> be deleted, in this document "disregarded" means >> "ignored". >> Otherwise, any such "disregarded" AODVv2 messages SHOULD= >> be >> deleted from the aggregated messages in the RFC 5444 >> packet. >> }}} >>=20 >> An RFC5444 packet is *never* to be sent more than one hop. >> ... A router receives an RFC5444 packet, decapsulates >> it, process each message (if appropriate), the owner process of each >> message identifies which messages are to be forwarded (if appropriate), >> hands those off to the appropriate "message multiplexing engine" which >> packs those messages up in a new RFC5444 packet, and transmits that >> new RFC5444 packet. >=20 > Check. >=20 >>=20 >> Also, in RFC5444 messages, addresses are contained in address blocks. >> There is no semantics associated with an address being in one address >> block, or in another (in fact, (re-)organising addresses into address >> blocks is one of the tricks to use to obtain more compact messages). >> Likewise, there is no semantics associated with an address being first, >> last, or in any other position in an address block: the ordering of >> addresses in an address block carries no semantics. >>=20 >> Therefore, writing something like this: >>=20 >>=20 >> {{{ >> RteMsg.Address[i] denotes the [i]th address in an RFC 54= 44 >> AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes th= e >> associated prefix length for RteMsg.Address[i], and >> RteMsg.{field} denotes the corresponding value in the >> named >> AddrTLV block associated with RteMsg.Address[i]. >> }}} >>=20 >>=20 >> makes no sense whatsoever (aside from the fact that I do not understand >> the notation !RteMsg.{field} - that would indicate a "field" in a >> message, not in an attribute associated with an address). >=20 > I don't think this is still an issue in the current draft. However, it > is notable that certain ordering constraints must be associated with > addresses and associated TLVs. For instance, the [i]th element of an > array of values in a TLV must be associated with the [i]th address. >=20 >>=20 >> Let me give one more example, from section 9: >>=20 >>=20 >> {{{ >> If a message with an unknown type is received, the message is= >> disregarded. >> }}} >>=20 >>=20 >> An implementation of this specification will (according to RFC5444) >> "own", and therefore get messages that this protocol has gotten >> assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any >> other Message Types will not (again, according to RFC5444) be >> delivered to an implementation of this protocol. >>=20 >> Therefore, this protocol >> specify discarding any message types other than those than it "owns". >=20 > Well, O.K. if we are going to agree that it's impossible for AODVv2 > to receive a message of an unknown type, the text is redundant and > can be removed. It boils down to having RFC 5444 enforce the type > checking instead of AODVv2. Sounds less than robust to me. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 28 15:48:46 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230AF1A0716 for ; Wed, 28 May 2014 15:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5l6u-uzvt7w for ; Wed, 28 May 2014 15:48:42 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9251F1A0272 for ; Wed, 28 May 2014 15:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 04698940FBC; Wed, 28 May 2014 15:48:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.147.142] (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 mailc1.tigertech.net (Postfix) with ESMTPSA id 944E8940FBB; Wed, 28 May 2014 15:48:37 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-4B1E8887-E17A-42C3-960A-0DEF0AD31191 Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D201) In-Reply-To: <53866290.6070309@computer.org> Date: Thu, 29 May 2014 00:48:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> To: "Charles E. Perkins" Archived-At: http://mailarchive.ietf.org/arch/msg/manet/W-J1Xff6OeaN_HR53wgGa4JnBYg Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:48:45 -0000 --Apple-Mail-4B1E8887-E17A-42C3-960A-0DEF0AD31191 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Or to be more specific... > On 29 mai 2014, at 00:26, "Charles E. Perkins" wro= te: >=20 > I did not find the specification within RFC5444 mandating the > limitation as stated below. In fact, RFC 5444 has the following text: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. .... >=20 > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. .... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > which many people would interpret to indicate that a packet might > traverse multiple hops. >=20 What you quote is from Appendix B, and you quote selectively... Here are the= bullets in full: o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the packet has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. o If the and fields are both present, then the Message Header provides the information to make forwarding decisions for scope-limited flooding. This may be by any appropriate flooding mechanism specified by a protocol using this specification. Please refer to section 5.2 in RFC5444 - which is normative, and which there= fore takes precedence.=20 Also please note that the parts that you conveniently didn't quote from thes= e two bullet points (as well as the text preceding the bulleted list) correc= tly talk about messages - which many people would use as an indicator that t= he first use of "packet" in these bullet points is in error. (It might be appropriate to file an errata against Appendix B to correct "pa= cket" to "message" in these two occurrences) Thomas > Anyway, I will do the following: > a) make it clear that AODV multicast packets traverse only a single > hop and > b) remove the unnecessary passages from the relevant text cited below > in section 5.4. >=20 >=20 >> On 4/3/2014 2:31 PM, manet issue tracker wrote: >> #33: RFC 5444 processing constraint >>=20 >> (Thomas Clausen) >> I have a general concern about how this protocol imposes constraints >> on RFC5444 usage, which precludes co-existence with other RFC5444 >> protocols running on the same device. >>=20 >> Let me give an example hereof, from Section 5.4: >>=20 >>=20 >> {{{ >> When multiple messages are aggregated into a single pack= et >> according to RFC 5444 formatting, and the aggregation of= >> messages is also authenticated (e.g., with IPsec), and t= he >> IP destination is multiple hops away, it becomes >> infeasible >> to delete individual messages. In such cases, instead o= f >> deleting individual messages, they are maintained in the= >> aggregation of messages, but simply ignored for further >> processing. In such cases where individual messages >> cannot >> be deleted, in this document "disregarded" means >> "ignored". >> Otherwise, any such "disregarded" AODVv2 messages SHOULD= >> be >> deleted from the aggregated messages in the RFC 5444 >> packet. >> }}} >>=20 >> An RFC5444 packet is *never* to be sent more than one hop. >> ... A router receives an RFC5444 packet, decapsulates >> it, process each message (if appropriate), the owner process of each >> message identifies which messages are to be forwarded (if appropriate), >> hands those off to the appropriate "message multiplexing engine" which >> packs those messages up in a new RFC5444 packet, and transmits that >> new RFC5444 packet. >=20 > Check. >=20 >>=20 >> Also, in RFC5444 messages, addresses are contained in address blocks. >> There is no semantics associated with an address being in one address >> block, or in another (in fact, (re-)organising addresses into address >> blocks is one of the tricks to use to obtain more compact messages). >> Likewise, there is no semantics associated with an address being first, >> last, or in any other position in an address block: the ordering of >> addresses in an address block carries no semantics. >>=20 >> Therefore, writing something like this: >>=20 >>=20 >> {{{ >> RteMsg.Address[i] denotes the [i]th address in an RFC 54= 44 >> AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes th= e >> associated prefix length for RteMsg.Address[i], and >> RteMsg.{field} denotes the corresponding value in the >> named >> AddrTLV block associated with RteMsg.Address[i]. >> }}} >>=20 >>=20 >> makes no sense whatsoever (aside from the fact that I do not understand >> the notation !RteMsg.{field} - that would indicate a "field" in a >> message, not in an attribute associated with an address). >=20 > I don't think this is still an issue in the current draft. However, it > is notable that certain ordering constraints must be associated with > addresses and associated TLVs. For instance, the [i]th element of an > array of values in a TLV must be associated with the [i]th address. >=20 >>=20 >> Let me give one more example, from section 9: >>=20 >>=20 >> {{{ >> If a message with an unknown type is received, the message is= >> disregarded. >> }}} >>=20 >>=20 >> An implementation of this specification will (according to RFC5444) >> "own", and therefore get messages that this protocol has gotten >> assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any >> other Message Types will not (again, according to RFC5444) be >> delivered to an implementation of this protocol. >>=20 >> Therefore, this protocol >> specify discarding any message types other than those than it "owns". >=20 > Well, O.K. if we are going to agree that it's impossible for AODVv2 > to receive a message of an unknown type, the text is redundant and > can be removed. It boils down to having RFC 5444 enforce the type > checking instead of AODVv2. Sounds less than robust to me. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-4B1E8887-E17A-42C3-960A-0DEF0AD31191 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Or to be more specific...
On 29 mai 2014, at 00:26, "Charles E. Perkins" <charliep@computer.org> wrote:

I did not find the specification wit= hin RFC5444 mandating the
limitation as stated below.  =  In fact, RFC 5444 has the following text:

<= span>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
  o  <m= sg-hop-limit> field, if present, contains the number of hops on      which the packet is allowed to travel b= efore being discarded by a
     MA= NET router.    ....

 &= nbsp;o  <msg-hop-count> field, if present, contains the number of= hops on
     which the packet has= traveled across the MANET.      ....
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

which man= y people would interpret to indicate that a packet might
tra= verse multiple hops.


=

What you quote is from Appendix B= , and you quote selectively... Here are the bullets in full:

<= /div>

  o  <msg-hop-limit> f= ield, if present, contains the number of hops on

      which the packet is allowed to t= ravel before being discarded by a

      MANET router.  The <msg= -hop-limit> is set by the message

      originator and is used to preve= nt messages from endlessly

      circulating in a MANET.  W= hen forwarding a message, a MANET router

      should decrease the <msg-hop= -limit> by 1, and the message should

      be discarded when <msg-hop-l= imit> reaches 0.


   o  <msg-hop-count> field, if= present, contains the number of hops on

      which the packet has traveled a= cross the MANET.  The <msg-hop-

      count> is set to 0 by the me= ssage originator and is used to

      prevent messages from endlessly= circulating in a MANET.  When

      forwarding a message, a MANET r= outer should increase <msg-hop-

      count> by 1 and should disca= rd the message when <msg-hop-count>

      reaches 255.


   o  If the <msg-hop-limit> an= d <msg-hop-count> fields are both

      present, then the Message Heade= r provides the information to make

      forwarding decisions for scope-= limited flooding.  This may be by

      any appropriate flooding mechan= ism specified by a protocol using

      this specification.

<= /div>

Please refe= r to section 5.2 in RFC5444 - which is normative, and which therefore takes p= recedence. 

Also please note that the parts th= at you conveniently didn't quote from these two bullet points (as well as th= e text preceding the bulleted list) correctly talk about messages - which ma= ny people would use as an indicator that the first use of "packet" in these b= ullet points is in error.

(It might be appropriate t= o file an errata against Appendix B to correct "packet" to "message" in thes= e two occurrences)

Thomas

Anyway, I will do the following:
a) mak= e it clear that AODV multicast packets traverse only a single
    hop and
b) remove the unnecessary= passages from the relevant text cited below
  &n= bsp;in section 5.4.


On 4/3= /2014 2:31 PM, manet issue tracker wrote:
#33: RFC 5444 processing constraint

 (Thomas Clausen)
=  I have a general concern about how this protocol imposes constr= aints
 on RFC54= 44 usage, which precludes co-existence with other RFC5444
 protocols running on the same de= vice.

 Let me give an example hereo= f, from Section 5.4:
=

 {{{
        &= nbsp;        When multiple messages a= re aggregated into a single packet
          &n= bsp;      according to RFC 5444 formatting, an= d the aggregation of
=             &nb= sp;    messages is also authenticated (e.g., with IPsec)= , and the
 &nbs= p;            &n= bsp;  IP destination is multiple hops away, it becomes
<= /blockquote>
 infeasible
     &nbs= p;           to delet= e individual messages.  In such cases, instead of
       = ;          deleting indivi= dual messages, they are maintained in the
         =         aggregation of messages, but= simply ignored for further
           &n= bsp;     processing.  In such cases where indi= vidual messages
&nbs= p;cannot
  = ;            &nb= sp;  be deleted, in this document "disregarded" means
 "ignored".
      = ;           Otherwise= , any such "disregarded" AODVv2 messages SHOULD
 be
          = ;       deleted from the aggregated messa= ges in the RFC 5444
&= nbsp;packet.
 }= }}

 An RFC5444 packet is *never* to= be sent more than one hop.
 ... A router receives an RFC5444 packet, decapsulates
 it, process each messa= ge (if appropriate), the owner process of each
 message identifies which messages are to be= forwarded (if appropriate),
 hands those off to the appropriate "message multiplexing engi= ne" which
 pack= s those messages up in a new RFC5444 packet, and transmits that
 new RFC5444 packet.=

Check.


 Also, in RFC5444 messages, addresses are contained in addre= ss blocks.
 The= re is no semantics associated with an address being in one address
 block, or in another (i= n fact, (re-)organising addresses into address
 blocks is one of the tricks to use to obtai= n more compact messages).
<= span>  Likewise, there is no semantics associated with an address being= first,
 last, o= r in any other position in an address block: the ordering of
 addresses in an address block= carries no semantics.

 Therefore, w= riting something like this:


 {{{
       =           RteMsg.Address[i= ] denotes the [i]th address in an RFC 5444
         = ;        AddrBlk of the RteMsg. RteM= sg.PrefixLength[i] denotes the
           = ;      associated prefix length for RteMsg.Add= ress[i], and
 &= nbsp;            = ;   RteMsg.{field} denotes the corresponding value in the
 named
<= /blockquote>
     &= nbsp;           AddrT= LV block associated with RteMsg.Address[i].
 }}}

=
 makes no sense whats= oever (aside from the fact that I do not understand
<= blockquote type=3D"cite">  the notation !RteMsg.{field} - that wo= uld indicate a "field" in a
 message, not in an attribute associated with an address).

I don't think this is still an iss= ue in the current draft.  However, it
is notable that c= ertain ordering constraints must be associated with
addresse= s and associated TLVs.  For instance, the [i]th element of anarray of values in a TLV must be associated with the [i]th address.


 Let me give one more example, f= rom section 9:


 {{{
         &n= bsp;  If a message with an unknown type is received, the message i= s
   =          disregarded.
 }}}


&nb= sp;An implementation of this specification will (according to RFC5444)
 "own", and therefor= e get messages that this protocol has gotten
 assigned by IANA, say, RREQ/RREP/RERR/RREP_AC= K.  Messages of any
 other Message Types will not (again, according to RFC5444) be
 delivered to an i= mplementation of this protocol.

 Th= erefore, this protocol <should not>
 specify discarding any message types other than t= hose than it "owns".

Well, O.K= . if we are going to agree that it's impossible for AODVv2
t= o receive a message of an unknown type, the text is redundant and
= can be removed.  It boils down to having RFC 5444 enforce the typ= e
checking instead of AODVv2.  Sounds less than robust t= o me.

--
Regards,Charlie P.

________________________= _______________________
manet mailing list
<= a href=3D"mailto:manet@ietf.org">manet@ietf.org
https://www.ietf.org/mailman/l= istinfo/manet
= --Apple-Mail-4B1E8887-E17A-42C3-960A-0DEF0AD31191-- From nobody Wed May 28 15:49:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB091A0740 for ; Wed, 28 May 2014 15:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEpHrXt7CQtw for ; Wed, 28 May 2014 15:49:01 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id CAC1F1A073E for ; Wed, 28 May 2014 15:49:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QXGei/ROTsP84K7+HZcHvRGZCMNJWG+1gLyHcm3DCN6MTsi+eVK+OC4oO1KTi1oP; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpmeD-00077Z-WF; Wed, 28 May 2014 18:48:38 -0400 Message-ID: <538667C4.5070503@earthlink.net> Date: Wed, 28 May 2014 15:48:36 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Henning Rogge References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7a80a5dab44480850de54b17e9eb59105350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/_8e13QadhYuwCxFYwtOVNOBdMqk Cc: draft-ietf-manet-aodvv2@tools.ietf.org, MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:49:03 -0000 Hello Henning, No, just the parts about RREP_ACK. In order to support bidirectional links, more protocol is needed. This is well known from past efforts, but not part of the current reactive protocol. Instead, the document will suggest other methods for testing bidirectionality (for example, ping). Regards, Charlie P. On 5/28/2014 2:59 PM, Henning Rogge wrote: > Hi Charlie, > > so you plan to remove the "AODVv2 does only support bidirectional links" part? > > Henning Rogge > > On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins > wrote: >> Hello Yuishi, >> >> Bidirectionality can be tested in various ways, even by >> just using ping (which is required by IP and thus always >> available). This is discussed briefly at the top of >> page 9 in the current revision, but I will be happy to >> expand the discussion. Please let me know how I can >> improve the description. I will cite include a citation >> for ping (i.e., ICMP Echo Request/Reply). >> >> Regards, >> Charlie P. >> >> >> >> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >>> Hi Charlie, >>> >>> It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, if >>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links >>> are bi-directional? AODVv2 requires all routes to implement other protocol >>> for verifying bi-directionality of links? I am sure that would cause >>> interoperability problems. >>> Also, this is related to tickets #26 and #27, I think. >>> >>> Regards, >>> Yuichi >>> (2014/05/29 2:34), Charlie Perkins wrote: >>>> >>>> Hello Lotte, >>>> >>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>> some discussion a while back about compatibility, but I have not >>>> seen anyone defending the RREP_ACK in this discussion and it was >>>> not present in the previous DYMO drafts. >>>> >>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>> some more detailed specification for handling it, which will be >>>> basically the way it was handled by AODV. >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>> #41: AckReq vs RREP_ACK >>>>> >>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>>> called >>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>> described >>>>> in section 5.2. >>>>> While RFC 3561, which is referenced in section 13.5., explains that a >>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>> handled. >>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>> explanation >>>>> should be added. Otherwise, removing it could be a step towards de- >>>>> cluttering the draft. >>>>> >>>> _______________________________________________ >>>> 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 nobody Wed May 28 15:57:24 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FE91A0724 for ; Wed, 28 May 2014 15:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8xqGMTHVm2y for ; Wed, 28 May 2014 15:57:22 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406831A0725 for ; Wed, 28 May 2014 15:57:22 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so20022580qgd.27 for ; Wed, 28 May 2014 15:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dy1Ukk+bYyDfEoM01U6q2f0+XC2RYLwZIgEDpkjC+Mw=; b=G2+2LKG9Lejkbh2uIxHAWHC4uHmopsrQebTDBQjeOkaMfGsTEM3V1I6XTL9ypqAjEi 1hAh7O7apUZ4+iXkKYh++6LuHw0B42WkmrQugTb7njZ+FVM1TVu5prWDut0PGWwoYtZH m1kFp8hbo1bGE9SDITJSFkR2AdcmW9zaSMZ9GjVvOGXhYjXXzAk4YiNTEicieruhZGyU v4x7rbQimZJugP5u+LCnUzBJcfQw+G0FsPxw/gYoBctdXK2x6zgp0nIaGXVXI+WEBsSS Rc9mRFb9ILYSAdROoTrU07oSmUNBJwBAfXRJat+ALIrN93Ix8FJ0NVpLVjjoYzVXkv5+ vvyw== X-Received: by 10.140.47.18 with SMTP id l18mr4135652qga.9.1401317838049; Wed, 28 May 2014 15:57:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.112.71 with HTTP; Wed, 28 May 2014 15:56:57 -0700 (PDT) In-Reply-To: <538667C4.5070503@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> From: Henning Rogge Date: Thu, 29 May 2014 00:56:57 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/CDF_W3Fp_EgOfdgWtL-1tJxhV34 Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:57:23 -0000 On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins wrote: > > Hello Henning, > > No, just the parts about RREP_ACK. In order to support > bidirectional links, more protocol is needed. This is well > known from past efforts, but not part of the current > reactive protocol. > > Instead, the document will suggest other methods for > testing bidirectionality (for example, ping). Sorry, but I don't think this makes sense. If your routing protocol does ONLY support bidirectional links, it needs to make sure not to setup routes over non-bidirectional links. Just to make this clear, will AODVv2 setup routes over links that are asymmetric? Or do you plan to call external programs for checking links to be bidirectional during the routing processing? Henning Rogge From nobody Wed May 28 15:58:24 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6121A0745 for ; Wed, 28 May 2014 15:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 971eoRrwBpT0 for ; Wed, 28 May 2014 15:58:21 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3536B1A0725 for ; Wed, 28 May 2014 15:58:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ABp4wvhdmHj22hJXS34jY2qeQqzLQxKJ1xaNkBRUiXqOOvoH1fvHFQ9B10RmCcWZ; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpmnN-0003p9-VY; Wed, 28 May 2014 18:58:06 -0400 Message-ID: <538669FB.7030004@earthlink.net> Date: Wed, 28 May 2014 15:58:03 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Henning Rogge References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> In-Reply-To: <538667C4.5070503@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac79676aa7a7c94f6a1ddb2ddd85b41ab0d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/rZpGWrs7EORtGTtP2AWSp5Qnt4M Cc: draft-ietf-manet-aodvv2@tools.ietf.org, MANET IETF Subject: [manet] Re: #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 22:58:23 -0000 Hello again Henning, Oops... I meant, "In order to support unidirectional links, more protocol is needed." ... Regards, Charlie P. On 5/28/2014 3:48 PM, Charlie Perkins wrote: > > Hello Henning, > > No, just the parts about RREP_ACK. In order to support > bidirectional links, more protocol is needed. This is well > known from past efforts, but not part of the current > reactive protocol. > > Instead, the document will suggest other methods for > testing bidirectionality (for example, ping). > > Regards, > Charlie P. > > On 5/28/2014 2:59 PM, Henning Rogge wrote: >> Hi Charlie, >> >> so you plan to remove the "AODVv2 does only support bidirectional >> links" part? >> >> Henning Rogge >> >> On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins >> wrote: >>> Hello Yuishi, >>> >>> Bidirectionality can be tested in various ways, even by >>> just using ping (which is required by IP and thus always >>> available). This is discussed briefly at the top of >>> page 9 in the current revision, but I will be happy to >>> expand the discussion. Please let me know how I can >>> improve the description. I will cite include a citation >>> for ping (i.e., ICMP Echo Request/Reply). >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >>>> Hi Charlie, >>>> >>>> It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. >>>> But, if >>>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure >>>> all links >>>> are bi-directional? AODVv2 requires all routes to implement other >>>> protocol >>>> for verifying bi-directionality of links? I am sure that would cause >>>> interoperability problems. >>>> Also, this is related to tickets #26 and #27, I think. >>>> >>>> Regards, >>>> Yuichi >>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>> >>>>> Hello Lotte, >>>>> >>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>> some discussion a while back about compatibility, but I have not >>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>> not present in the previous DYMO drafts. >>>>> >>>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>>> some more detailed specification for handling it, which will be >>>>> basically the way it was handled by AODV. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>>> #41: AckReq vs RREP_ACK >>>>>> >>>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>>>> called >>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>> described >>>>>> in section 5.2. >>>>>> While RFC 3561, which is referenced in section 13.5., explains >>>>>> that a >>>>>> RREP-ACK is sent when a packet with the 'A' bit set is >>>>>> received, the >>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>>> handled. >>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>> explanation >>>>>> should be added. Otherwise, removing it could be a step >>>>>> towards de- >>>>>> cluttering the draft. >>>>>> >>>>> _______________________________________________ >>>>> 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 nobody Wed May 28 16:03:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01261A075C for ; Wed, 28 May 2014 16:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd-Tvp56KP1d for ; Wed, 28 May 2014 16:03:06 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53B71A029A for ; Wed, 28 May 2014 16:03:05 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so12007048wgg.30 for ; Wed, 28 May 2014 16:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3EWUucS279xsDh2hSedOM3jEPTO96KrQ/lSN0tMTl2c=; b=uIv/vKvas5hly53yI7kKz1umTp44OQ0c1skEFXe7ZRipbSIaI/6oiw/z2lZAOq43qq sSeHIJLmea5uv2nvE65E0xF0m2JuLFbzPoQ6L/gvP9fqn4TJyDRH3q/4CDaA6tnhmypo OwCC/8t3ik0XpIjJJycKU9uwFMt6R59hrTGE12FOAS6IA4t+z7+I4VKGQqI0+99t51kg XYGNAbJVfR/fGq722NY79sxup38vOrChoEb/8Vx9FjuiaGsUs0VMUsWtPmQeUsM/PyX2 Lxtv+qLp5U7Rdap969o9uvxMtvIkVF7AKvLk9sVlkRUDRgJGONMZJUo5ffHp/Bp3NmxG JBew== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr52852410wic.34.1401318180910; Wed, 28 May 2014 16:03:00 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.118.134 with HTTP; Wed, 28 May 2014 16:03:00 -0700 (PDT) In-Reply-To: <538667C4.5070503@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> Date: Thu, 29 May 2014 01:03:00 +0200 X-Google-Sender-Auth: HAJ0Rt98nWoqNmpiTNpEoDnhPpY Message-ID: From: Jiazi YI To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a11c2444863fd0a04fa7dd0dd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/B7_NWYcdQfma7RYkdyuxS9gL_2Q Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:03:08 -0000 --001a11c2444863fd0a04fa7dd0dd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Charlie, In my opinion, the handling of uni-directional links is very important for MANET protocols. Giving several possible options without specification doesn't look like a standard track protocol. best Jiazi On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > > Hello Henning, > > No, just the parts about RREP_ACK. In order to support > bidirectional links, more protocol is needed. This is well > known from past efforts, but not part of the current > reactive protocol. > > Instead, the document will suggest other methods for > testing bidirectionality (for example, ping). > > Regards, > Charlie P. > > > On 5/28/2014 2:59 PM, Henning Rogge wrote: > >> Hi Charlie, >> >> so you plan to remove the "AODVv2 does only support bidirectional links" >> part? >> >> Henning Rogge >> >> On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins >> wrote: >> >>> Hello Yuishi, >>> >>> Bidirectionality can be tested in various ways, even by >>> just using ping (which is required by IP and thus always >>> available). This is discussed briefly at the top of >>> page 9 in the current revision, but I will be happy to >>> expand the discussion. Please let me know how I can >>> improve the description. I will cite include a citation >>> for ping (i.e., ICMP Echo Request/Reply). >>> >>> Regards, >>> Charlie P. >>> >>> >>> >>> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >>> >>>> Hi Charlie, >>>> >>>> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80= =9D. But, >>>> if >>>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all >>>> links >>>> are bi-directional? AODVv2 requires all routes to implement other >>>> protocol >>>> for verifying bi-directionality of links? I am sure that would cause >>>> interoperability problems. >>>> Also, this is related to tickets #26 and #27, I think. >>>> >>>> Regards, >>>> Yuichi >>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>> >>>>> >>>>> Hello Lotte, >>>>> >>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>> some discussion a while back about compatibility, but I have not >>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>> not present in the previous DYMO drafts. >>>>> >>>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>>> some more detailed specification for handling it, which will be >>>>> basically the way it was handled by AODV. >>>>> >>>>> Regards, >>>>> Charlie P. >>>>> >>>>> >>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>> >>>>>> #41: AckReq vs RREP_ACK >>>>>> >>>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>>>> called >>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>> described >>>>>> in section 5.2. >>>>>> While RFC 3561, which is referenced in section 13.5., explains >>>>>> that a >>>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, >>>>>> the >>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>>> handled. >>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>> explanation >>>>>> should be added. Otherwise, removing it could be a step towards d= e- >>>>>> cluttering the draft. >>>>>> >>>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>> >>>>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --001a11c2444863fd0a04fa7dd0dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charlie,=C2=A0

In my opinion, the ha= ndling of uni-directional links is very important for MANET protocols.=C2= =A0
Giving several possible options without specification doesn&#= 39;t look like a standard track protocol.=C2=A0

best

Jiazi


On Thu, May 29, 2014 = at 12:48 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Henning,

No, just the parts about RREP_ACK. =C2=A0In order to support
bidirectional links, more protocol is needed. =C2=A0This is well
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, ping).

Regards,
Charlie P.


On 5/28/2014 2:59 PM, Henning Rogge wrote:
Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional link= s" part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<char= les.perkins@earthlink.net> wrote:
Hello Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available). =C2=A0This is discussed briefly at the top of
page 9 in the current revision, but I will be happy to
expand the discussion. =C2=A0Please let me know how I can
improve the description. =C2=A0I will cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.



On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80= =9D. But, if
you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links<= br> are bi-directional? AODVv2 requires all routes to implement other protocol<= br> for verifying bi-directionality of links? I am sure that would cause
interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft. =C2=A0There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

=C2=A0 =C2=A0In Section 13.5., the AODVv2 Draft briefly describes a mechani= sm
called
=C2=A0 =C2=A0RREP_ACK, which seems to serve a similar purpose as the AckReq= s
described
=C2=A0 =C2=A0in section 5.2.
=C2=A0 =C2=A0While RFC 3561, which is referenced in section 13.5., explains= that a
=C2=A0 =C2=A0RREP-ACK is sent when a packet with the 'A' bit set is= received, the
=C2=A0 =C2=A0AODVv2 does not describe how a RREP_ACK is triggered.
=C2=A0 =C2=A0Additionally, the draft does not specify how a RREP_ACK should= be
handled.
=C2=A0 =C2=A0If the feature of a RREP_ACK is really needed, a more thorough=
explanation
=C2=A0 =C2=A0should be added. Otherwise, removing it could be a step toward= s de-
=C2=A0 =C2=A0cluttering the draft.

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

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

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

--001a11c2444863fd0a04fa7dd0dd-- From nobody Wed May 28 16:06:36 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9551A075C for ; Wed, 28 May 2014 16:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDKnPp4IRvyQ for ; Wed, 28 May 2014 16:06:33 -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 3B1101A075A for ; Wed, 28 May 2014 16:06:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NCIb8b5jzwRAeCrsYjCXMBB7GAWcj4iSogyODAvCY5hJFPrA/BYmP0d9GNJKLAZM; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Wpmv2-0005sp-7a; Wed, 28 May 2014 19:06:00 -0400 Message-ID: <53866BD6.9060107@earthlink.net> Date: Wed, 28 May 2014 16:05:58 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jiazi YI References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org><53861E28.1070700@earthlink.net><53863308.3070704@hitachi.com><5386581E.3070907@earthlink.net><538667C4.5070503@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050206060101000205060004" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7d6c5edc5a0b49fab9baba9a42b135516350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/-5Ttor6f3e81Dh3O3aF7tbj2_0A Cc: draft-ietf-manet-aodvv2@tools.ietf.org, MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:06:36 -0000 This is a multi-part message in MIME format. --------------050206060101000205060004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Jiazi, Do you mean to say that you think AODVv2 should provide routes whenever they exist even in networks with unidirectional links? Regards, Charlie P. On 5/28/2014 4:03 PM, Jiazi YI wrote: > Hi Charlie, > > In my opinion, the handling of uni-directional links is very important > for MANET protocols. > Giving several possible options without specification doesn't look > like a standard track protocol. > > best > > Jiazi > > > On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins > > > wrote: > > > Hello Henning, > > No, just the parts about RREP_ACK. In order to support > bidirectional links, more protocol is needed. This is well > known from past efforts, but not part of the current > reactive protocol. > > Instead, the document will suggest other methods for > testing bidirectionality (for example, ping). > > Regards, > Charlie P. > > > On 5/28/2014 2:59 PM, Henning Rogge wrote: > > Hi Charlie, > > so you plan to remove the "AODVv2 does only support > bidirectional links" part? > > Henning Rogge > > On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins > > wrote: > > Hello Yuishi, > > Bidirectionality can be tested in various ways, even by > just using ping (which is required by IP and thus always > available). This is discussed briefly at the top of > page 9 in the current revision, but I will be happy to > expand the discussion. Please let me know how I can > improve the description. I will cite include a citation > for ping (i.e., ICMP Echo Request/Reply). > > Regards, > Charlie P. > > > > On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: > > Hi Charlie, > > It says in sec.4 that "AODVv2 only supports > bidirectional linksâ€. But, if > you remove RREP_ACK from the spec, how does AODVv2 > itself ensure all links > are bi-directional? AODVv2 requires all routes to > implement other protocol > for verifying bi-directionality of links? I am sure > that would cause > interoperability problems. > Also, this is related to tickets #26 and #27, I think. > > Regards, > Yuichi > (2014/05/29 2:34), Charlie Perkins wrote: > > > Hello Lotte, > > I am O.K. with removing the RREP_ACK from the > draft. There was > some discussion a while back about compatibility, > but I have not > seen anyone defending the RREP_ACK in this > discussion and it was > not present in the previous DYMO drafts. > > If anyone would prefer to keep RREP_ACK, then I > will try to fashion > some more detailed specification for handling it, > which will be > basically the way it was handled by AODV. > > Regards, > Charlie P. > > > On 4/22/2014 12:39 PM, manet issue tracker wrote: > > #41: AckReq vs RREP_ACK > > In Section 13.5., the AODVv2 Draft briefly > describes a mechanism > called > RREP_ACK, which seems to serve a similar > purpose as the AckReqs > described > in section 5.2. > While RFC 3561, which is referenced in > section 13.5., explains that a > RREP-ACK is sent when a packet with the 'A' > bit set is received, the > AODVv2 does not describe how a RREP_ACK is > triggered. > Additionally, the draft does not specify > how a RREP_ACK should be > handled. > If the feature of a RREP_ACK is really > needed, a more thorough > explanation > should be added. Otherwise, removing it > could be a step towards de- > cluttering the draft. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --------------050206060101000205060004 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello Jiazi,

Do you mean to say that you think AODVv2 should provide routes
whenever they exist even in networks with unidirectional links?

Regards,
Charlie P.


On 5/28/2014 4:03 PM, Jiazi YI wrote:
Hi Charlie, 

In my opinion, the handling of uni-directional links is very important for MANET protocols. 
Giving several possible options without specification doesn't look like a standard track protocol. 

best

Jiazi


On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Henning,

No, just the parts about RREP_ACK.  In order to support
bidirectional links, more protocol is needed.  This is well
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, ping).

Regards,
Charlie P.


On 5/28/2014 2:59 PM, Henning Rogge wrote:
Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional links" part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available).  This is discussed briefly at the top of
page 9 in the current revision, but I will be happy to
expand the discussion.  Please let me know how I can
improve the description.  I will cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.



On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, if
you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links
are bi-directional? AODVv2 requires all routes to implement other protocol
for verifying bi-directionality of links? I am sure that would cause
interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft.  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

   In Section 13.5., the AODVv2 Draft briefly describes a mechanism
called
   RREP_ACK, which seems to serve a similar purpose as the AckReqs
described
   in section 5.2.
   While RFC 3561, which is referenced in section 13.5., explains that a
   RREP-ACK is sent when a packet with the 'A' bit set is received, the
   AODVv2 does not describe how a RREP_ACK is triggered.
   Additionally, the draft does not specify how a RREP_ACK should be
handled.
   If the feature of a RREP_ACK is really needed, a more thorough
explanation
   should be added. Otherwise, removing it could be a step towards de-
   cluttering the draft.

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

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

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


--------------050206060101000205060004-- From nobody Wed May 28 16:12:14 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A9D1A06C6 for ; Wed, 28 May 2014 16:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFXR5xUJxqIm for ; Wed, 28 May 2014 16:12:09 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0FA11A029D for ; Wed, 28 May 2014 16:12:08 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so11868424wgh.23 for ; Wed, 28 May 2014 16:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WcJWjEIL0O9b2PRMdyhdPQKxQIaOjpPftnDIYuHyfWQ=; b=VJi1GRRLnOxNIUPVCx2A0jf79jGrVAwEKzGGT1/j0G19L8ynC5YYabDAFHvQRkp1xo NJr6wBhrvdITcYDOswVOGUS+U9oZ7UndIZkiUA/QgfisCDUIzkQo82CHLxnfuee6ajR8 QurzOXNu40vaNSlluKpnzQzEfrl8XfkFw8QkwNV2Z0+0FDz5GuJYKzkomvOjtR0c3ZrW jkpgHdLWE/qMOw4qbdrqa4DZ7vnQi8FhQDTeOovMyq2aELcemS3Byw41d9smFlIsZ/pq 9o29D2Z11CrzU+dJaDCmuu7pF/wgc2B4YyGEQ55rz6pNhtsvUIG6oC4oYZMoO6E64II0 g5PQ== MIME-Version: 1.0 X-Received: by 10.194.186.210 with SMTP id fm18mr4012537wjc.67.1401318723725; Wed, 28 May 2014 16:12:03 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.118.134 with HTTP; Wed, 28 May 2014 16:12:03 -0700 (PDT) In-Reply-To: <53866BD6.9060107@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> <53866BD6.9060107@earthlink.net> Date: Thu, 29 May 2014 01:12:03 +0200 X-Google-Sender-Auth: Lp4qXsKjpcmgfK2fZRrQ1UuEeYc Message-ID: From: Jiazi YI To: Charlie Perkins Content-Type: multipart/alternative; boundary=e89a8f234449beb2a404fa7df099 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/0ofEY_L8Ctw1gxlHAvgDyIGkAdE Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:12:10 -0000 --e89a8f234449beb2a404fa7df099 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Charlie, No exactly what I meant. Unidirectional links are common in MANET - I think we agree on this. Therefore, the routing protocol should be able to build provide routes considering the fact given above. It can be, for example, avoid using such kind of links -- or other smarter ways. But not matter which way to take, it should be clearly specified. best Jiazi On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > > Hello Jiazi, > > Do you mean to say that you think AODVv2 should provide routes > whenever they exist even in networks with unidirectional links? > > Regards, > Charlie P. > > > > On 5/28/2014 4:03 PM, Jiazi YI wrote: > > Hi Charlie, > > In my opinion, the handling of uni-directional links is very important > for MANET protocols. > Giving several possible options without specification doesn't look like a > standard track protocol. > > best > > Jiazi > > > On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins < > charles.perkins@earthlink.net> wrote: > >> >> Hello Henning, >> >> No, just the parts about RREP_ACK. In order to support >> bidirectional links, more protocol is needed. This is well >> known from past efforts, but not part of the current >> reactive protocol. >> >> Instead, the document will suggest other methods for >> testing bidirectionality (for example, ping). >> >> Regards, >> Charlie P. >> >> >> On 5/28/2014 2:59 PM, Henning Rogge wrote: >> >>> Hi Charlie, >>> >>> so you plan to remove the "AODVv2 does only support bidirectional links= " >>> part? >>> >>> Henning Rogge >>> >>> On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins >>> wrote: >>> >>>> Hello Yuishi, >>>> >>>> Bidirectionality can be tested in various ways, even by >>>> just using ping (which is required by IP and thus always >>>> available). This is discussed briefly at the top of >>>> page 9 in the current revision, but I will be happy to >>>> expand the discussion. Please let me know how I can >>>> improve the description. I will cite include a citation >>>> for ping (i.e., ICMP Echo Request/Reply). >>>> >>>> Regards, >>>> Charlie P. >>>> >>>> >>>> >>>> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >>>> >>>>> Hi Charlie, >>>>> >>>>> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80= =9D. But, >>>>> if >>>>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all >>>>> links >>>>> are bi-directional? AODVv2 requires all routes to implement other >>>>> protocol >>>>> for verifying bi-directionality of links? I am sure that would cause >>>>> interoperability problems. >>>>> Also, this is related to tickets #26 and #27, I think. >>>>> >>>>> Regards, >>>>> Yuichi >>>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>> >>>>>> >>>>>> Hello Lotte, >>>>>> >>>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>>> some discussion a while back about compatibility, but I have not >>>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>>> not present in the previous DYMO drafts. >>>>>> >>>>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>>>> some more detailed specification for handling it, which will be >>>>>> basically the way it was handled by AODV. >>>>>> >>>>>> Regards, >>>>>> Charlie P. >>>>>> >>>>>> >>>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>>> >>>>>>> #41: AckReq vs RREP_ACK >>>>>>> >>>>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>>>>> called >>>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>>> described >>>>>>> in section 5.2. >>>>>>> While RFC 3561, which is referenced in section 13.5., explains >>>>>>> that a >>>>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, >>>>>>> the >>>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>>> Additionally, the draft does not specify how a RREP_ACK should b= e >>>>>>> handled. >>>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>>> explanation >>>>>>> should be added. Otherwise, removing it could be a step towards >>>>>>> de- >>>>>>> cluttering the draft. >>>>>>> >>>>>>> _______________________________________________ >>>>>> manet mailing list >>>>>> manet@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/manet >>>>>> >>>>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>> >>> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > --e89a8f234449beb2a404fa7df099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charlie,

No exactly what I mea= nt.=C2=A0
Unidirectional links are common in MANET - I think we agree o= n this.=C2=A0
Therefore, the routing protocol should be able to b= uild provide routes considering the fact given above.=C2=A0
It can be, for example, avoid using such kind of links -- or other sma= rter ways.=C2=A0
But not matter which way to take, it should be c= learly specified.=C2=A0

best

<= div>Jiazi



On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins = <char= les.perkins@earthlink.net> wrote:
=20 =20 =20

Hello Jiazi,

Do you mean to say that you think AODVv2 should provide routes
whenever they exist even in networks with unidirectional links?

Regards,
Charlie P.



On 5/28/2014 4:03 PM, Jiazi YI wrote:
Hi Charlie,=C2=A0

In my opinion, the handling of uni-directional links is very important for MANET protocols.=C2=A0
Giving several possible options without specification doesn't look like a standard track protocol.=C2=A0

best

Jiazi


On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <charles.perkins@earthlink.net&g= t; wrote:

Hello Henning,

No, just the parts about RREP_ACK. =C2=A0In order to support bidirectional links, more protocol is needed. =C2=A0This is wel= l
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, ping).

Regards,
Charlie P.


On 5/28/2014 2:59 PM, Henning Rogge wrote:
Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional links" part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available). =C2=A0This is discussed briefly at the top = of
page 9 in the current revision, but I will be happy to
expand the discussion. =C2=A0Please let me know how I c= an
improve the description. =C2=A0I will cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.



On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D. But, if
you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links
are bi-directional? AODVv2 requires all routes to implement other protocol
for verifying bi-directionality of links? I am sure that would cause
interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft. =C2=A0There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

=C2=A0 =C2=A0In Section 13.5., the AODVv2 Draft b= riefly describes a mechanism
called
=C2=A0 =C2=A0RREP_ACK, which seems to serve a sim= ilar purpose as the AckReqs
described
=C2=A0 =C2=A0in section 5.2.
=C2=A0 =C2=A0While RFC 3561, which is referenced = in section 13.5., explains that a
=C2=A0 =C2=A0RREP-ACK is sent when a packet with = the 'A' bit set is received, the
=C2=A0 =C2=A0AODVv2 does not describe how a RREP_= ACK is triggered.
=C2=A0 =C2=A0Additionally, the draft does not spe= cify how a RREP_ACK should be
handled.
=C2=A0 =C2=A0If the feature of a RREP_ACK is real= ly needed, a more thorough
explanation
=C2=A0 =C2=A0should be added. Otherwise, removing= it could be a step towards de-
=C2=A0 =C2=A0cluttering the draft.

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

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

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



--e89a8f234449beb2a404fa7df099-- From nobody Wed May 28 16:13:55 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000881A029D for ; Wed, 28 May 2014 16:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pT7xi_SAOx0 for ; Wed, 28 May 2014 16:13:51 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 77D891A06C6 for ; Wed, 28 May 2014 16:13:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZAXfwkjJSmsuDm650IfNYR+fzOHT1AZ0Sbf4uQn6mgPU+HnSxVN0IwJJxQb3DX7O; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Wpn2Z-0003Re-Gd; Wed, 28 May 2014 19:13:47 -0400 Message-ID: <53866DAA.6010307@earthlink.net> Date: Wed, 28 May 2014 16:13:46 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Henning Rogge References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7b5dea486e8c32ec1a8c046b4e54d2d65350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/5xbtgpRpUmNAGSM8KQTttxWSEqs Cc: MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:13:53 -0000 Hello Henning, There are several methods by which bidirectionality can be assured, including the use of blacklists for RREQ/RREP, NHDP, ping, and others. DYMO had left this choice up to the implementation, and other implementations in the past have shown that was feasible. The only reason for the more recent inclusion of RREP_ACK was upon suggestion for compatibility with other proposals, and I am O.K. with either taking out RREP_ACK or leaving it in with additional specification. I don't think "ping" qualifies as an external program. Regards, Charlie P. On 5/28/2014 3:56 PM, Henning Rogge wrote: > On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins > wrote: >> Hello Henning, >> >> No, just the parts about RREP_ACK. In order to support >> bidirectional links, more protocol is needed. This is well >> known from past efforts, but not part of the current >> reactive protocol. >> >> Instead, the document will suggest other methods for >> testing bidirectionality (for example, ping). > Sorry, but I don't think this makes sense. > > If your routing protocol does ONLY support bidirectional links, it > needs to make sure not to setup routes over non-bidirectional links. > > Just to make this clear, will AODVv2 setup routes over links that are > asymmetric? Or do you plan to call external programs for checking > links to be bidirectional during the routing processing? > > Henning Rogge > From nobody Wed May 28 16:41:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBAB1A06AC for ; Wed, 28 May 2014 16:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxQuo1VOvDXw for ; Wed, 28 May 2014 16:41:05 -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 C11261A02B0 for ; Wed, 28 May 2014 16:41:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=AvpsAjgwAI/JfDMM03BzoOxa/eRB6xYHzYauiZPBT0/fn1svM98vw+7SJl+arbda; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WpnSl-0002h3-UW; Wed, 28 May 2014 19:40:52 -0400 Message-ID: <53867402.3090508@earthlink.net> Date: Wed, 28 May 2014 16:40:50 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Jiazi YI References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org><53861E28.1070700@earthlink.net><53863308.3070704@hitachi.com><5386581E.3070907@earthlink.net><538667C4.5070503@earthlink.net><53866BD6.9060107@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040200060109020402050205" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac78bcf539176b67a6d9081dc6713ec3e68350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/DVPCHelsLs6ItmOF2Ot0XSOQ1dQ Cc: MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:41:07 -0000 This is a multi-part message in MIME format. --------------040200060109020402050205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Jiazi, On 5/28/2014 4:12 PM, Jiazi YI wrote: > Hi Charlie, > > No exactly what I meant. > Unidirectional links are common in MANET - I think we agree on this. > Therefore, the routing protocol should be able to build provide routes > considering the fact given above. > It can be, for example, avoid using such kind of links -- or other > smarter ways. Check. > But not matter which way to take, it should be clearly specified. Also check. However, different implementations may have various differences about which method is best. Regards, Charlie P. > > best > > Jiazi > > > > On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins > > > wrote: > > > Hello Jiazi, > > Do you mean to say that you think AODVv2 should provide routes > whenever they exist even in networks with unidirectional links? > > Regards, > Charlie P. > > > > On 5/28/2014 4:03 PM, Jiazi YI wrote: >> Hi Charlie, >> >> In my opinion, the handling of uni-directional links is very >> important for MANET protocols. >> Giving several possible options without specification doesn't >> look like a standard track protocol. >> >> best >> >> Jiazi >> >> >> On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins >> > > wrote: >> >> >> Hello Henning, >> >> No, just the parts about RREP_ACK. In order to support >> bidirectional links, more protocol is needed. This is well >> known from past efforts, but not part of the current >> reactive protocol. >> >> Instead, the document will suggest other methods for >> testing bidirectionality (for example, ping). >> >> Regards, >> Charlie P. >> >> >> On 5/28/2014 2:59 PM, Henning Rogge wrote: >> >> Hi Charlie, >> >> so you plan to remove the "AODVv2 does only support >> bidirectional links" part? >> >> Henning Rogge >> >> On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins >> > > wrote: >> >> Hello Yuishi, >> >> Bidirectionality can be tested in various ways, even by >> just using ping (which is required by IP and thus always >> available). This is discussed briefly at the top of >> page 9 in the current revision, but I will be happy to >> expand the discussion. Please let me know how I can >> improve the description. I will cite include a citation >> for ping (i.e., ICMP Echo Request/Reply). >> >> Regards, >> Charlie P. >> >> >> >> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >> >> Hi Charlie, >> >> It says in sec.4 that "AODVv2 only supports >> bidirectional linksâ€. But, if >> you remove RREP_ACK from the spec, how does >> AODVv2 itself ensure all links >> are bi-directional? AODVv2 requires all routes to >> implement other protocol >> for verifying bi-directionality of links? I am >> sure that would cause >> interoperability problems. >> Also, this is related to tickets #26 and #27, I >> think. >> >> Regards, >> Yuichi >> (2014/05/29 2:34), Charlie Perkins wrote: >> >> >> Hello Lotte, >> >> I am O.K. with removing the RREP_ACK from the >> draft. There was >> some discussion a while back about >> compatibility, but I have not >> seen anyone defending the RREP_ACK in this >> discussion and it was >> not present in the previous DYMO drafts. >> >> If anyone would prefer to keep RREP_ACK, then >> I will try to fashion >> some more detailed specification for handling >> it, which will be >> basically the way it was handled by AODV. >> >> Regards, >> Charlie P. >> >> >> On 4/22/2014 12:39 PM, manet issue tracker wrote: >> >> #41: AckReq vs RREP_ACK >> >> In Section 13.5., the AODVv2 Draft >> briefly describes a mechanism >> called >> RREP_ACK, which seems to serve a >> similar purpose as the AckReqs >> described >> in section 5.2. >> While RFC 3561, which is referenced in >> section 13.5., explains that a >> RREP-ACK is sent when a packet with >> the 'A' bit set is received, the >> AODVv2 does not describe how a >> RREP_ACK is triggered. >> Additionally, the draft does not >> specify how a RREP_ACK should be >> handled. >> If the feature of a RREP_ACK is really >> needed, a more thorough >> explanation >> should be added. Otherwise, removing >> it could be a step towards de- >> cluttering the draft. >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > --------------040200060109020402050205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Jiazi,

On 5/28/2014 4:12 PM, Jiazi YI wrote:
Hi Charlie,

No exactly what I meant. 
Unidirectional links are common in MANET - I think we agree on this. 
Therefore, the routing protocol should be able to build provide routes considering the fact given above. 
It can be, for example, avoid using such kind of links -- or other smarter ways.

Check.

But not matter which way to take, it should be clearly specified.

Also check.  However, different implementations may have various
differences about which method is best.

Regards,
Charlie P.


best

Jiazi



On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Jiazi,

Do you mean to say that you think AODVv2 should provide routes
whenever they exist even in networks with unidirectional links?

Regards,
Charlie P.



On 5/28/2014 4:03 PM, Jiazi YI wrote:
Hi Charlie, 

In my opinion, the handling of uni-directional links is very important for MANET protocols. 
Giving several possible options without specification doesn't look like a standard track protocol. 

best

Jiazi


On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Henning,

No, just the parts about RREP_ACK.  In order to support
bidirectional links, more protocol is needed.  This is well
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, ping).

Regards,
Charlie P.


On 5/28/2014 2:59 PM, Henning Rogge wrote:
Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional links" part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available).  This is discussed briefly at the top of
page 9 in the current revision, but I will be happy to
expand the discussion.  Please let me know how I can
improve the description.  I will cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.



On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
Hi Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, if
you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links
are bi-directional? AODVv2 requires all routes to implement other protocol
for verifying bi-directionality of links? I am sure that would cause
interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft.  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

   In Section 13.5., the AODVv2 Draft briefly describes a mechanism
called
   RREP_ACK, which seems to serve a similar purpose as the AckReqs
described
   in section 5.2.
   While RFC 3561, which is referenced in section 13.5., explains that a
   RREP-ACK is sent when a packet with the 'A' bit set is received, the
   AODVv2 does not describe how a RREP_ACK is triggered.
   Additionally, the draft does not specify how a RREP_ACK should be
handled.
   If the feature of a RREP_ACK is really needed, a more thorough
explanation
   should be added. Otherwise, removing it could be a step towards de-
   cluttering the draft.

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

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

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




--------------040200060109020402050205-- From nobody Wed May 28 16:54:46 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBA21A07B0 for ; Wed, 28 May 2014 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBrSnHhtbscr for ; Wed, 28 May 2014 16:54:42 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE6E1A07A7 for ; Wed, 28 May 2014 16:54:41 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so11965361wes.38 for ; Wed, 28 May 2014 16:54:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id; bh=SUoLAJchi1znKGVyZgbbtn6yYV2ZstUup+YVlgjAjqA=; b=rBZQJBiv30xgI7gsHqio+Ma6An1Mo4cv+04WEETP6IzSQdRN4dG16mH4dW1eKf9OXn Z/dtdY2Nf4GZ8UtoaPEoOKvLpSoix/bqS/G6xCdwnzDcOaxxlZ5Y5atE3VObx6tbzrMx ed5ZjnPGX5XcdqogNadmwAWvYuNKHNE5HZizfIMUBc43TgwqoUfyGuA+SLr7Iexb96Rt CmzL9FzH4qHcgwFDW5wt9sQBEJW+c73eCmU/XVX5qLvs+UYL8gm4QLnRDUZHFfiVV2m8 VUCNGo5OX6B91adekJywb6mAYoFe/cdWYAr9FTRKcacx4DLv7BbtYAjKH5ZGcdt11mXl 2Mdw== X-Received: by 10.180.97.131 with SMTP id ea3mr52891520wib.35.1401321276504; Wed, 28 May 2014 16:54:36 -0700 (PDT) Received: from [192.168.254.7] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id b1sm47042261wjb.37.2014.05.28.16.54.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 16:54:36 -0700 (PDT) From: Christopher Dearlove Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0FC4C3AF-2CB9-4264-B823-14FDB1950C34" Date: Thu, 29 May 2014 00:54:34 +0100 In-Reply-To: <53867402.3090508@earthlink.net> To: "manet@ietf.org List" References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org><53861E28.1070700@earthlink.net><53863308.3070704@hitachi.com><5386581E.3070907@earthlink.net><538667C4.5070503@earthlink.net><53866BD6.9060107@earthlink.net> <53867402.3090508@earthlink.net> Message-Id: <21F71727-9E0C-4FEC-8E24-C17BAC9913A8@gmail.com> X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/aWhMNSsaowAqJGj6q401D0oMONI Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 23:54:44 -0000 --Apple-Mail=_0FC4C3AF-2CB9-4264-B823-14FDB1950C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The important thing is that implementations interoperate and work. - Multiple options that don't interoperate is not going to fly as a = standards track protocol. - Multiple options where each router could pick a different option = really needs to justify that this will work, and still is going to have = an uphill struggle to be acceptable. It would be useful to know what here makes things not really reactive, = but partially proactive, and what here adds to reactive route discovery = delay. What's been implemented here - even in simulation? On 29 May 2014, at 00:40, Charlie Perkins wrote: > Hello Jiazi, >=20 > On 5/28/2014 4:12 PM, Jiazi YI wrote: >> Hi Charlie, >>=20 >> No exactly what I meant.=20 >> Unidirectional links are common in MANET - I think we agree on this.=20= >> Therefore, the routing protocol should be able to build provide = routes considering the fact given above.=20 >> It can be, for example, avoid using such kind of links -- or other = smarter ways. >=20 > Check. >=20 >> But not matter which way to take, it should be clearly specified. >=20 > Also check. However, different implementations may have various > differences about which method is best. >=20 > Regards, > Charlie P. >=20 >>=20 >> best >>=20 >> Jiazi >>=20 >>=20 >>=20 >> On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins = wrote: >>=20 >> Hello Jiazi, >>=20 >> Do you mean to say that you think AODVv2 should provide routes >> whenever they exist even in networks with unidirectional links? >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >>=20 >> On 5/28/2014 4:03 PM, Jiazi YI wrote: >>> Hi Charlie,=20 >>>=20 >>> In my opinion, the handling of uni-directional links is very = important for MANET protocols.=20 >>> Giving several possible options without specification doesn't look = like a standard track protocol.=20 >>>=20 >>> best >>>=20 >>> Jiazi >>>=20 >>>=20 >>> On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins = wrote: >>>=20 >>> Hello Henning, >>>=20 >>> No, just the parts about RREP_ACK. In order to support >>> bidirectional links, more protocol is needed. This is well >>> known from past efforts, but not part of the current >>> reactive protocol. >>>=20 >>> Instead, the document will suggest other methods for >>> testing bidirectionality (for example, ping). >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> On 5/28/2014 2:59 PM, Henning Rogge wrote: >>> Hi Charlie, >>>=20 >>> so you plan to remove the "AODVv2 does only support bidirectional = links" part? >>>=20 >>> Henning Rogge >>>=20 >>> On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins >>> wrote: >>> Hello Yuishi, >>>=20 >>> Bidirectionality can be tested in various ways, even by >>> just using ping (which is required by IP and thus always >>> available). This is discussed briefly at the top of >>> page 9 in the current revision, but I will be happy to >>> expand the discussion. Please let me know how I can >>> improve the description. I will cite include a citation >>> for ping (i.e., ICMP Echo Request/Reply). >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>>=20 >>> On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >>> Hi Charlie, >>>=20 >>> It says in sec.4 that "AODVv2 only supports bidirectional links=94. = But, if >>> you remove RREP_ACK from the spec, how does AODVv2 itself ensure all = links >>> are bi-directional? AODVv2 requires all routes to implement other = protocol >>> for verifying bi-directionality of links? I am sure that would cause >>> interoperability problems. >>> Also, this is related to tickets #26 and #27, I think. >>>=20 >>> Regards, >>> Yuichi >>> (2014/05/29 2:34), Charlie Perkins wrote: >>>=20 >>> Hello Lotte, >>>=20 >>> I am O.K. with removing the RREP_ACK from the draft. There was >>> some discussion a while back about compatibility, but I have not >>> seen anyone defending the RREP_ACK in this discussion and it was >>> not present in the previous DYMO drafts. >>>=20 >>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>> some more detailed specification for handling it, which will be >>> basically the way it was handled by AODV. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>> #41: AckReq vs RREP_ACK >>>=20 >>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>> called >>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>> described >>> in section 5.2. >>> While RFC 3561, which is referenced in section 13.5., explains = that a >>> RREP-ACK is sent when a packet with the 'A' bit set is received, = the >>> AODVv2 does not describe how a RREP_ACK is triggered. >>> Additionally, the draft does not specify how a RREP_ACK should be >>> handled. >>> If the feature of a RREP_ACK is really needed, a more thorough >>> explanation >>> should be added. Otherwise, removing it could be a step towards = de- >>> cluttering the draft. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_0FC4C3AF-2CB9-4264-B823-14FDB1950C34 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
=20
Hello Jiazi,

On 5/28/2014 4:12 PM, Jiazi YI = wrote:
Hi Charlie,

No exactly what I meant. 
Unidirectional links are common in MANET - I think we agree on this. 
Therefore, the routing protocol should be able to build provide routes considering the fact given above. 
It can be, for example, avoid using such kind of links -- or other smarter ways.

Check.

But not matter which way to take, it should be clearly specified.

Also check.  However, different implementations may have = various
differences about which method is best.

Regards,
Charlie P.


best

Jiazi



On Thu, May 29, 2014 at 1:05 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Jiazi,

Do you mean to say that you think AODVv2 should provide routes
whenever they exist even in networks with unidirectional links?

Regards,
Charlie P.



On 5/28/2014 4:03 PM, Jiazi YI wrote:
Hi Charlie, 

In my opinion, the handling of uni-directional links is very important for MANET protocols. 
Giving several possible options without specification doesn't look like a standard track protocol. 

best

Jiazi


On Thu, May 29, 2014 at 12:48 AM, Charlie Perkins <charles.perkins@earthlink.net> wrote:

Hello Henning,

No, just the parts about RREP_ACK.  In = order to support
bidirectional links, more protocol is needed.  This is well
known from past efforts, but not part of the current
reactive protocol.

Instead, the document will suggest other methods for
testing bidirectionality (for example, = ping).

Regards,
Charlie P.


On 5/28/2014 2:59 PM, Henning Rogge = wrote:
Hi Charlie,

so you plan to remove the "AODVv2 does only support bidirectional links" = part?

Henning Rogge

On Wed, May 28, 2014 at 11:41 PM, Charlie Perkins
<charles.perkins@earthlink.net> wrote:
Hello = Yuishi,

Bidirectionality can be tested in various ways, even by
just using ping (which is required by IP and thus always
available).  This is discussed = briefly at the top of
page 9 in the current revision, but I will be happy to
expand the discussion.  Please = let me know how I can
improve the description.  I will = cite include a citation
for ping (i.e., ICMP Echo Request/Reply).

Regards,
Charlie P.



On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote:
Hi = Charlie,

It says in sec.4 that "AODVv2 only supports bidirectional links=94. = But, if
you remove RREP_ACK from the spec, how does AODVv2 itself ensure all links
are bi-directional? AODVv2 requires all routes to implement other protocol
for verifying bi-directionality of links? I am sure that would = cause
interoperability problems.
Also, this is related to tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft. =  There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

   In Section 13.5., = the AODVv2 Draft briefly describes a mechanism
called
   RREP_ACK, which = seems to serve a similar purpose as the AckReqs
described
   in section 5.2.
   While RFC 3561, = which is referenced in section 13.5., explains that a
   RREP-ACK is sent = when a packet with the 'A' bit set is received, the
   AODVv2 does not = describe how a RREP_ACK is triggered.
   Additionally, the = draft does not specify how a RREP_ACK should be
handled.
   If the feature of a = RREP_ACK is really needed, a more thorough
explanation
   should be added. = Otherwise, removing it could be a step towards de-
   cluttering the = draft.

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

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

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




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

= --Apple-Mail=_0FC4C3AF-2CB9-4264-B823-14FDB1950C34-- From nobody Wed May 28 17:00:55 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1701A067F for ; Wed, 28 May 2014 17:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCDBNKD7cd5I for ; Wed, 28 May 2014 17:00:51 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7188B1A02AE for ; Wed, 28 May 2014 17:00:51 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so12291344wev.31 for ; Wed, 28 May 2014 17:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:mime-version:content-type:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V25rsLJJUMPqLiPZgXpNDnDL5cENohvuvhn/bg+xhqk=; b=JAT5oUO/vzqi6IgrCIZTehVbnwc1T6AXbfIji+hURxotNn+mIRjJVvi3iHixRfv0Wu WUsJsIcuSP0+fyJQoYUTyTOiIZZzIxq8dS0CgcI7QzVMEe8Pv6zPXVx++BWnCuNY/cr+ N/qH+WKN6lLk8piCPEVwLC2DBIdjzqlUbGgtlyF/7vEyxodNyTaz5BaNHxDg2jxFfvmi bk4LJ0qYrynHxZzPnoS4XXHljXW89bLy0Ve/TABLt+tns7Ytqwi5KPuo2elmasBnNmDd sKwxLKH3iPmVu3PVtTZKGg12ohODUTd1OiMjub4pyKwjf7FQ8lyZwRWrKO7pvlx+B1Xt s/Iw== X-Received: by 10.180.103.228 with SMTP id fz4mr14173584wib.4.1401321646538; Wed, 28 May 2014 17:00:46 -0700 (PDT) Received: from [192.168.254.7] (mnemosyne.demon.co.uk. [62.49.16.209]) by mx.google.com with ESMTPSA id vm8sm47071908wjc.27.2014.05.28.17.00.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 17:00:46 -0700 (PDT) From: Christopher Dearlove X-Google-Original-From: Christopher Dearlove Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii In-Reply-To: <53866290.6070309@computer.org> Date: Thu, 29 May 2014 01:00:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> To: Charles E. Perkins X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PHq5yQjsqo1RYuoHXqu8wrH_srY Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 00:00:54 -0000 Charlie Thanks for pointing that out. That is text in a non-normative appendix = and is an error. The normative text in Section 5.2 refers to messages, = and so should this appendix. I will put in an erratum to correct that. But your (a) is incorrect. There are no such things as AODV packets. = Packets are owned by the 5444/5498 multiplexing process. Only messages = are owned by AODVv2. Christopher On 28 May 2014, at 23:26, Charles E. Perkins wrote: > I did not find the specification within RFC5444 mandating the > limitation as stated below. In fact, RFC 5444 has the following = text: >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. .... >=20 > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. .... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > which many people would interpret to indicate that a packet might > traverse multiple hops. >=20 > Anyway, I will do the following: > a) make it clear that AODV multicast packets traverse only a single > hop and > b) remove the unnecessary passages from the relevant text cited below > in section 5.4. >=20 >=20 > On 4/3/2014 2:31 PM, manet issue tracker wrote: >> #33: RFC 5444 processing constraint >>=20 >> (Thomas Clausen) >> I have a general concern about how this protocol imposes constraints >> on RFC5444 usage, which precludes co-existence with other RFC5444 >> protocols running on the same device. >>=20 >> Let me give an example hereof, from Section 5.4: >>=20 >>=20 >> {{{ >> When multiple messages are aggregated into a single = packet >> according to RFC 5444 formatting, and the aggregation = of >> messages is also authenticated (e.g., with IPsec), = and the >> IP destination is multiple hops away, it becomes >> infeasible >> to delete individual messages. In such cases, = instead of >> deleting individual messages, they are maintained in = the >> aggregation of messages, but simply ignored for = further >> processing. In such cases where individual messages >> cannot >> be deleted, in this document "disregarded" means >> "ignored". >> Otherwise, any such "disregarded" AODVv2 messages = SHOULD >> be >> deleted from the aggregated messages in the RFC 5444 >> packet. >> }}} >>=20 >> An RFC5444 packet is *never* to be sent more than one hop. >> ... A router receives an RFC5444 packet, decapsulates >> it, process each message (if appropriate), the owner process of each >> message identifies which messages are to be forwarded (if = appropriate), >> hands those off to the appropriate "message multiplexing engine" = which >> packs those messages up in a new RFC5444 packet, and transmits that >> new RFC5444 packet. >=20 > Check. >=20 >>=20 >> Also, in RFC5444 messages, addresses are contained in address blocks. >> There is no semantics associated with an address being in one address >> block, or in another (in fact, (re-)organising addresses into address >> blocks is one of the tricks to use to obtain more compact messages). >> Likewise, there is no semantics associated with an address being = first, >> last, or in any other position in an address block: the ordering of >> addresses in an address block carries no semantics. >>=20 >> Therefore, writing something like this: >>=20 >>=20 >> {{{ >> RteMsg.Address[i] denotes the [i]th address in an RFC = 5444 >> AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes = the >> associated prefix length for RteMsg.Address[i], and >> RteMsg.{field} denotes the corresponding value in the >> named >> AddrTLV block associated with RteMsg.Address[i]. >> }}} >>=20 >>=20 >> makes no sense whatsoever (aside from the fact that I do not = understand >> the notation !RteMsg.{field} - that would indicate a "field" in a >> message, not in an attribute associated with an address). >=20 > I don't think this is still an issue in the current draft. However, = it > is notable that certain ordering constraints must be associated with > addresses and associated TLVs. For instance, the [i]th element of an > array of values in a TLV must be associated with the [i]th address. >=20 >>=20 >> Let me give one more example, from section 9: >>=20 >>=20 >> {{{ >> If a message with an unknown type is received, the message = is >> disregarded. >> }}} >>=20 >>=20 >> An implementation of this specification will (according to RFC5444) >> "own", and therefore get messages that this protocol has gotten >> assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any >> other Message Types will not (again, according to RFC5444) be >> delivered to an implementation of this protocol. >>=20 >> Therefore, this protocol >> specify discarding any message types other than those than it "owns". >=20 > Well, O.K. if we are going to agree that it's impossible for AODVv2 > to receive a message of an unknown type, the text is redundant and > can be removed. It boils down to having RFC 5444 enforce the type > checking instead of AODVv2. Sounds less than robust to me. >=20 > --=20 > Regards, > Charlie P. >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 28 19:44:55 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CCC1A084D for ; Wed, 28 May 2014 19:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78HnKdVzCtjc for ; Wed, 28 May 2014 19:44:52 -0700 (PDT) Received: from mail7.hitachi.co.jp (mail7.hitachi.co.jp [133.145.228.42]) by ietfa.amsl.com (Postfix) with ESMTP id A54861A0860 for ; Wed, 28 May 2014 19:44:47 -0700 (PDT) Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 738F637AC7; Thu, 29 May 2014 11:44:43 +0900 (JST) Received: from mfilter03.hitachi.co.jp by mlsv3.hitachi.co.jp (8.13.1/8.13.1) id s4T2ihdO014653; Thu, 29 May 2014 11:44:43 +0900 Received: from vshuts04.hitachi.co.jp (vshuts04.hitachi.co.jp [10.201.6.86]) by mfilter03.hitachi.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id s4T2igST018292; Thu, 29 May 2014 11:44:43 +0900 Received: from hsdlmain.sdl.hitachi.co.jp (unknown [133.144.14.194]) by vshuts04.hitachi.co.jp (Postfix) with ESMTP id 3668614003D; Thu, 29 May 2014 11:44:42 +0900 (JST) Received: from hsdlvgate2.sdl.hitachi.co.jp by hsdlmain.sdl.hitachi.co.jp (8.13.8/3.7W11021512) id s4T2igai016744; Thu, 29 May 2014 11:44:42 +0900 X-AuditID: 85900ec0-d1328b9000001514-16-53869f1966e1 Received: from sdl99w.sdl.hitachi.co.jp (sdl99w.yrl.intra.hitachi.co.jp [133.144.14.250]) by hsdlvgate2.sdl.hitachi.co.jp (Symantec Mail Security) with ESMTP id C549D236561; Thu, 29 May 2014 11:44:41 +0900 (JST) Received: from maila.sdl.hitachi.co.jp (sdl99a.yrl.intra.hitachi.co.jp [133.144.14.196]) by sdl99w.sdl.hitachi.co.jp (Postfix) with ESMTP id 1A53753C21A; Thu, 29 May 2014 11:49:47 +0900 (JST) Received: from [10.198.219.54] (unknown [10.198.219.54]) by maila.sdl.hitachi.co.jp (Postfix) with ESMTP id A0AA5495B85; Thu, 29 May 2014 11:44:41 +0900 (JST) Message-ID: <53869F19.9020109@hitachi.com> Date: Thu, 29 May 2014 11:44:41 +0900 From: Yuichi IGARASHI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Charlie Perkins References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> In-Reply-To: <5386581E.3070907@earthlink.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/manet/9KNmzTVPkg3yNW9-AsFUlc6lGI0 Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 02:44:54 -0000 Hi Charlie, I understand there are some ways(ping, etc) to verify that. But what you mentioned seems that specifying a way to check that is out of scope of this draft( depends on implementations), although AODVv2 supports bidirectional links. My suggestion is to describe details of RREP_ACK processing/generating parts additionally in order to interoperate easily with multi vendors, instead of removing RREP_ACK part. Also,it should be removed MAY and various options. Regards, Yuichi (2014/05/29 6:41), Charlie Perkins wrote: > Hello Yuishi, > > Bidirectionality can be tested in various ways, even by > just using ping (which is required by IP and thus always > available). This is discussed briefly at the top of > page 9 in the current revision, but I will be happy to > expand the discussion. Please let me know how I can > improve the description. I will cite include a citation > for ping (i.e., ICMP Echo Request/Reply). > > Regards, > Charlie P. > > > On 5/28/2014 12:03 PM, Yuichi IGARASHI wrote: >> Hi Charlie, >> >> It says in sec.4 that "AODVv2 only supports bidirectional linksâ€. But, >> if you remove RREP_ACK from the spec, how does AODVv2 itself ensure >> all links are bi-directional? AODVv2 requires all routes to implement >> other protocol for verifying bi-directionality of links? I am sure >> that would cause interoperability problems. >> Also, this is related to tickets #26 and #27, I think. >> >> Regards, >> Yuichi >> (2014/05/29 2:34), Charlie Perkins wrote: >>> >>> Hello Lotte, >>> >>> I am O.K. with removing the RREP_ACK from the draft. There was >>> some discussion a while back about compatibility, but I have not >>> seen anyone defending the RREP_ACK in this discussion and it was >>> not present in the previous DYMO drafts. >>> >>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>> some more detailed specification for handling it, which will be >>> basically the way it was handled by AODV. >>> >>> Regards, >>> Charlie P. >>> >>> >>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>> #41: AckReq vs RREP_ACK >>>> >>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism >>>> called >>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>> described >>>> in section 5.2. >>>> While RFC 3561, which is referenced in section 13.5., explains that a >>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>> Additionally, the draft does not specify how a RREP_ACK should be >>>> handled. >>>> If the feature of a RREP_ACK is really needed, a more thorough >>>> explanation >>>> should be added. Otherwise, removing it could be a step towards de- >>>> cluttering the draft. >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>> >> > -- Hitachi, Ltd., Yokohama Research Laboratory Yuichi Igarashi Mail： yuichi.igarashi.hb@hitachi.com Tel ： +81-(0)50-3135-3457 From nobody Thu May 29 00:52:00 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999591A07DA for ; Thu, 29 May 2014 00:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FV-0kMB7-vXX for ; Thu, 29 May 2014 00:51:56 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD531A079D for ; Thu, 29 May 2014 00:51:56 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so21030220qge.40 for ; Thu, 29 May 2014 00:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=D4eybIO/yD2/kanGdAMHt+Y9hYrCHLSzZDVthNQYe8I=; b=GiPS5BLOUZFzuBl4HEBivZqCGtpACt4KnJPQU/CnhcVhyMj5ji1Mt6De8xbQLMGKxR Qh+aknKZOpxSXy5MMkq1DUmruwf2o2C0fRp6nl5/2cxbLrEkow+CWWd4U2YjApYx8KK8 +zLpfoYNWiQ8OIyHRjnYkVkH43ne65xFztY+tQnevO6Y8+27cIU2jzHLVPV7RaoVtvtD ekS3zvYstiIoqqckp+5jKAR/EPKbk767GuhrD0j3qVw61OSJs6zLtbzRrKqeVVklO3c8 9G4CejZVrxHavIR1FoWLmjRoVSokVzLukF+qhhRta1PTmZo3torIUXfBLUpJh2a378g7 yVlA== X-Received: by 10.224.6.199 with SMTP id a7mr7615257qaa.24.1401349911872; Thu, 29 May 2014 00:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.112.71 with HTTP; Thu, 29 May 2014 00:51:31 -0700 (PDT) In-Reply-To: <53866DAA.6010307@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <5386581E.3070907@earthlink.net> <538667C4.5070503@earthlink.net> <53866DAA.6010307@earthlink.net> From: Henning Rogge Date: Thu, 29 May 2014 09:51:31 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/s1b5oV-zLHqE2O2gsiEfMKoVksM Cc: MANET IETF Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 07:51:57 -0000 On Thu, May 29, 2014 at 1:13 AM, Charlie Perkins wrote: > > Hello Henning, > > There are several methods by which bidirectionality can > be assured, including the use of blacklists for RREQ/RREP, > NHDP, ping, and others. DYMO had left this choice up > to the implementation, and other implementations in the > past have shown that was feasible. The only reason for the > more recent inclusion of RREP_ACK was upon suggestion for > compatibility with other proposals, and I am O.K. with > either taking out RREP_ACK or leaving it in with additional > specification. > > I don't think "ping" qualifies as an external program. Hi, ICMP/ICMP-Reply might be the only one with a good chance of interoperability if you remove the RREP_ACKs. Because otherwise both sides of the connection have to agree to a mechanism. Still, I don't like the idea of a routing protocol that says "it only supports bidirectional links" but does not make sure itself that it ignores links that are not. Henning Rogge From nobody Thu May 29 02:54:12 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D691A0892 for ; Thu, 29 May 2014 02:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQOFNm8N-aIc for ; Thu, 29 May 2014 02:54:08 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B327E1A0874 for ; Thu, 29 May 2014 02:54:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="375141092" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 May 2014 10:54:02 +0100 X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="59237053" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 29 May 2014 10:53:38 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.86]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0174.001; Thu, 29 May 2014 10:53:35 +0100 From: "Dearlove, Christopher (UK)" To: Christopher Dearlove , Charles E.Perkins Thread-Topic: [manet] #33 (aodvv2): RFC 5444 processing constraint Thread-Index: AQHPesPtA02QX2RInEmmsCMuZCoLuJtWm8cAgAC14eA= Date: Thu, 29 May 2014 09:53:35 +0000 Message-ID: References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> In-Reply-To: <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/7RAj-DRSx0MLNLY--LHZxeJd648 Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:54:10 -0000 I have submitted the appropriate erratum to RFC 5444. (I also checked throu= gh 5444 and didn't find any other uses of packet that should be message. Th= at isn't a guarantee though.) -- = 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 [mailto:manet-bounces@ietf.org] On Behalf Of Christopher Dearlo= ve Sent: 29 May 2014 01:01 To: Charles E.Perkins Cc: draft-ietf-manet-aodvv2@tools.ietf.org; manet@ietf.org Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- Charlie Thanks for pointing that out. That is text in a non-normative appendix and = is an error. The normative text in Section 5.2 refers to messages, and so s= hould this appendix. I will put in an erratum to correct that. But your (a) is incorrect. There are no such things as AODV packets. Packet= s are owned by the 5444/5498 multiplexing process. Only messages are owned = by AODVv2. Christopher On 28 May 2014, at 23:26, Charles E. Perkins wrote: > I did not find the specification within RFC5444 mandating the > limitation as stated below. In fact, RFC 5444 has the following text: > = > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. .... > = > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. .... > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > = > which many people would interpret to indicate that a packet might = > traverse multiple hops. > = > Anyway, I will do the following: > a) make it clear that AODV multicast packets traverse only a single > hop and > b) remove the unnecessary passages from the relevant text cited below > in section 5.4. > = > = > On 4/3/2014 2:31 PM, manet issue tracker wrote: >> #33: RFC 5444 processing constraint >> = >> (Thomas Clausen) >> I have a general concern about how this protocol imposes constraints = >> on RFC5444 usage, which precludes co-existence with other RFC5444 = >> protocols running on the same device. >> = >> Let me give an example hereof, from Section 5.4: >> = >> = >> {{{ >> When multiple messages are aggregated into a single pack= et >> according to RFC 5444 formatting, and the aggregation of >> messages is also authenticated (e.g., with IPsec), and t= he >> IP destination is multiple hops away, it becomes = >> infeasible >> to delete individual messages. In such cases, instead of >> deleting individual messages, they are maintained in the >> aggregation of messages, but simply ignored for further >> processing. In such cases where individual messages = >> cannot >> be deleted, in this document "disregarded" means = >> "ignored". >> Otherwise, any such "disregarded" AODVv2 messages = >> SHOULD be >> deleted from the aggregated messages in the RFC 5444 = >> packet. >> }}} >> = >> An RFC5444 packet is *never* to be sent more than one hop. >> ... A router receives an RFC5444 packet, decapsulates it, process = >> each message (if appropriate), the owner process of each message = >> identifies which messages are to be forwarded (if appropriate), hands = >> those off to the appropriate "message multiplexing engine" which = >> packs those messages up in a new RFC5444 packet, and transmits that = >> new RFC5444 packet. > = > Check. > = >> = >> Also, in RFC5444 messages, addresses are contained in address blocks. >> There is no semantics associated with an address being in one address = >> block, or in another (in fact, (re-)organising addresses into address = >> blocks is one of the tricks to use to obtain more compact messages). >> Likewise, there is no semantics associated with an address being = >> first, last, or in any other position in an address block: the = >> ordering of addresses in an address block carries no semantics. >> = >> Therefore, writing something like this: >> = >> = >> {{{ >> RteMsg.Address[i] denotes the [i]th address in an RFC 54= 44 >> AddrBlk of the RteMsg. RteMsg.PrefixLength[i] denotes the >> associated prefix length for RteMsg.Address[i], and >> RteMsg.{field} denotes the corresponding value in the = >> named >> AddrTLV block associated with RteMsg.Address[i]. >> }}} >> = >> = >> makes no sense whatsoever (aside from the fact that I do not = >> understand the notation !RteMsg.{field} - that would indicate a = >> "field" in a message, not in an attribute associated with an address). > = > I don't think this is still an issue in the current draft. However, = > it is notable that certain ordering constraints must be associated = > with addresses and associated TLVs. For instance, the [i]th element = > of an array of values in a TLV must be associated with the [i]th address. > = >> = >> Let me give one more example, from section 9: >> = >> = >> {{{ >> If a message with an unknown type is received, the message is >> disregarded. >> }}} >> = >> = >> An implementation of this specification will (according to RFC5444) = >> "own", and therefore get messages that this protocol has gotten = >> assigned by IANA, say, RREQ/RREP/RERR/RREP_ACK. Messages of any = >> other Message Types will not (again, according to RFC5444) be = >> delivered to an implementation of this protocol. >> = >> Therefore, this protocol specify discarding any message = >> types other than those than it "owns". > = > Well, O.K. if we are going to agree that it's impossible for AODVv2 to = > receive a message of an unknown type, the text is redundant and can be = > removed. It boils down to having RFC 5444 enforce the type checking = > instead of AODVv2. Sounds less than robust to me. > = > -- > Regards, > Charlie P. > = > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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 nobody Thu May 29 03:03:50 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6AF1A03EA; Thu, 29 May 2014 03:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeGyriZwqfEO; Thu, 29 May 2014 03:03:46 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C17361A0113; Thu, 29 May 2014 03:03:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D851818000D; Thu, 29 May 2014 03:03:06 -0700 (PDT) To: chris.dearlove@baesystems.com, T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140529100306.D851818000D@rfc-editor.org> Date: Thu, 29 May 2014 03:03:06 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/fObocr-utC7ldRU2wz7j16mUvUk Cc: manet@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Errata Verified] RFC5444 (4003) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:03:48 -0000 The following errata report has been verified for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=4003 -------------------------------------- Status: Verified Type: Editorial Reported by: Christopher Dearlove Date Reported: 2014-05-29 Verified by: Adrian Farrel (IESG) Section: Appendix B Original Text ------------- o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the packet has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Corrected Text -------------- o field, if present, contains the number of hops on which the message is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the message has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Notes ----- Two changes of "packet" to "message". Message is consistent with the normative Section 5.2 that defines these fields (which may appear in each message, so are not uniquely defined for a packet), the text introducing these bullet points, and the remainder of these paragraphs. (Note that the original and corrected text has had indentation reduced by one space.) -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 29 03:19:52 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6581A0A23 for ; Thu, 29 May 2014 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzMjXR6yNsAb for ; Thu, 29 May 2014 03:19:45 -0700 (PDT) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C502A1A09F6 for ; Thu, 29 May 2014 03:19:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="375153515" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by Baemasodc001ir.sharelnk.net with ESMTP; 29 May 2014 11:19:40 +0100 X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="59243235" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 29 May 2014 11:19:39 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.86]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0174.001; Thu, 29 May 2014 11:19:39 +0100 From: "Dearlove, Christopher (UK)" To: RFC Errata System , "T.Clausen@computer.org" , "jdean@itd.nrl.navy.mil" , "Cedric.Adjih@inria.fr" , "akatlas@gmail.com" , "adrian@olddog.co.uk" , "sratliff@cisco.com" , "macker@itd.nrl.navy.mil" Thread-Topic: [Technical Errata Reported] RFC5444 (4003) Thread-Index: AQHPeyLiFPToweB6wUSfYLBbuA5C5ZtXVwGg Date: Thu, 29 May 2014 10:19:38 +0000 Message-ID: References: <20140529094554.C7D1F18000D@rfc-editor.org> In-Reply-To: <20140529094554.C7D1F18000D@rfc-editor.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/frFWGirzQ81qS8jGuVRtBAkuIWE Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (4003) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:19:47 -0000 Wearing my author hat, I agree with this erratum. But then I would, as I al= so submitted it. OK, over to the rest of you. (I was very tempted to make an additional editorial wording change in those= paragraphs, "on which" to "that". But resisted as that just muddies the wa= ters.) The parenthetical comment in the Notes is about a bug in the RFC erratum to= ol, I've sent that to the RFC editor separately. If the RFC editor (or IESG= ) can restore the indentation and remove the comment, fine by me. -- = Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194=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: RFC Errata System [mailto:rfc-editor@rfc-editor.org] = Sent: 29 May 2014 10:46 To: T.Clausen@computer.org; Dearlove, Christopher (UK); jdean@itd.nrl.navy.= mil; Cedric.Adjih@inria.fr; akatlas@gmail.com; adrian@olddog.co.uk; sratlif= f@cisco.com; macker@itd.nrl.navy.mil Cc: Dearlove, Christopher (UK); manet@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC5444 (4003) ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- The following errata report has been submitted for RFC5444, "Generalized Mo= bile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5444&eid=3D4003 -------------------------------------- Type: Technical Reported by: Christopher Dearlove Section: Appendix B Original Text ------------- o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the packet has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Corrected Text -------------- o field, if present, contains the number of hops on which the message is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the message has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Notes ----- Two changes of "packet" to "message". Message is consistent with the normat= ive Section 5.2 that defines these fields (which may appear in each message= , so are not uniquely defined for a packet), the text introducing these bul= let points, and the remainder of these paragraphs. (Note that the original and corrected text has had indentation reduced by o= ne space.) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary. = -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Mess= age Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG ******************************************************************** 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 nobody Thu May 29 03:35:29 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF71A08C9 for ; Thu, 29 May 2014 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmz3hLtIqnaL for ; Thu, 29 May 2014 03:35:23 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0AD1A08A8 for ; Thu, 29 May 2014 03:35:22 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4TAYqxD017809; Thu, 29 May 2014 11:34:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s4TAYoD4017794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 May 2014 11:34:51 +0100 From: "Adrian Farrel" To: "'Dearlove, Christopher \(UK\)'" , "'RFC Errata System'" , , , , , , References: <20140529094554.C7D1F18000D@rfc-editor.org> In-Reply-To: Date: Thu, 29 May 2014 11:34:52 +0100 Message-ID: <073201cf7b29$a07b8980$e1729c80$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGA34HBIkJ/0ODlTE3q9WaZIivoeAICNpSLm+SCD0A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20722.006 X-TM-AS-Result: No--23.250-10.0-31-10 X-imss-scan-details: No--23.250-10.0-31-10 X-TMASE-MatchedRID: gTucSmrmRMMeZFtnUZauwCcP0e8lTEHzgo2AmQWC5pe7+NPPxj+R6hU3 wdcgT5Ty7ywKJk9rEWmHc4lwrx5hRFtFsD8r+sfMzNY33yIEF4aQ+p7nZKnwHZpQzIv0XTM8mnW IBkWBuOYVDl89zEK9lbHyebymXrvo/egNi5ZFoZjAJnGRMfFxyaYuYtu360hTKjWoN7rlvuIot4 eEXmG2l2Kj7+xt1m4af2uH1jvrVGF/yCPAJ70SfghWgIsZuXlPt6fWTFY+RBmzU0R+5DbDbO1yz 6ai+TrFF5diznbYrvvBxVNeNzsv2Y4a2rhHAtuZiFoorQjboWmyNcEJTKJGJroDd80wzToFEv86 LHWvloNPkPP8BPNUBr5zmzlC1Q8HbboYgHrsZfI5fy6DvqY6APn7iploxGKIVWoi/SaO4wbnRVN VcdaemQf6oL8Hj94RfAHrISqOiW/HbmVdQqcgVxYUH2zzZ4zbpfVcx39Kq+77W70OT/3Orxkdi8 WIojRfvHX90Gk3SryjHj2908afJEHWbmeNr66RMbXDsac2LZAkMBkEieOjZu4zMLHe1QPblOts7 3NQ5aNOzkOCmEEHSMOXk/+4B8pDnldfsb8faYQX2N9OpwN26I+YVJqrrEz4DZjzHLL3eRZXY6Ib FNKd2zrynTnbVK8J7LejLvGCNgB2W20gLTzAqbYBnn2EUDXrj0Ch4H3a2gSbKItl61J/yeQD/sq qL0mZq7rFUcuGp/G8QIu4z6HhEH7cGd19dSFd Archived-At: http://mailarchive.ietf.org/arch/msg/manet/xZSZdhqVMk8q9ZV8jmnarYzDHXQ Cc: manet@ietf.org Subject: Re: [manet] [Technical Errata Reported] RFC5444 (4003) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:35:27 -0000 Christopher, I went ahead and approved this report, except I "downgraded" it to an = Editorial issue because: - it is in a non-normative appendix - I don't believe that the error would have caused any = mis-implementation or interop problem Thanks, Adrian > -----Original Message----- > From: Dearlove, Christopher (UK) = [mailto:chris.dearlove@baesystems.com] > Sent: 29 May 2014 11:20 > To: RFC Errata System; T.Clausen@computer.org; jdean@itd.nrl.navy.mil; > Cedric.Adjih@inria.fr; akatlas@gmail.com; adrian@olddog.co.uk; > sratliff@cisco.com; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [Technical Errata Reported] RFC5444 (4003) >=20 > Wearing my author hat, I agree with this erratum. But then I would, as = I also > submitted it. OK, over to the rest of you. >=20 > (I was very tempted to make an additional editorial wording change in = those > paragraphs, "on which" to "that". But resisted as that just muddies = the waters.) >=20 > The parenthetical comment in the Notes is about a bug in the RFC = erratum tool, > I've sent that to the RFC editor separately. If the RFC editor (or = IESG) can restore > the indentation and remove the comment, fine by 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 >=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: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 29 May 2014 10:46 > To: T.Clausen@computer.org; Dearlove, Christopher (UK); > jdean@itd.nrl.navy.mil; Cedric.Adjih@inria.fr; akatlas@gmail.com; > adrian@olddog.co.uk; sratliff@cisco.com; macker@itd.nrl.navy.mil > Cc: Dearlove, Christopher (UK); manet@ietf.org; = rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5444 (4003) >=20 > ----------------------! WARNING ! ---------------------- This message originates from > outside our organisation, either from an external partner or from the internet. > Consider carefully whether you should click on any links, open any = attachments > or reply. > Follow the 'Report Suspicious Emails' link on IT matters for = instructions on > reporting suspicious email messages. > -------------------------------------------------------- >=20 > The following errata report has been submitted for RFC5444, = "Generalized > Mobile Ad Hoc Network (MANET) Packet/Message Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5444&eid=3D4003 >=20 > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove >=20 > Section: Appendix B >=20 > Original Text > ------------- > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. The is set by the message > originator and is used to prevent messages from endlessly > circulating in a MANET. When forwarding a message, a MANET = router > should decrease the by 1, and the message should > be discarded when reaches 0. >=20 > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. The count> is set to 0 by the message originator and is used to > prevent messages from endlessly circulating in a MANET. When > forwarding a message, a MANET router should increase count> by 1 and should discard the message when > reaches 255. >=20 >=20 > Corrected Text > -------------- > o field, if present, contains the number of hops on > which the message is allowed to travel before being discarded by = a > MANET router. The is set by the message > originator and is used to prevent messages from endlessly > circulating in a MANET. When forwarding a message, a MANET = router > should decrease the by 1, and the message should > be discarded when reaches 0. >=20 > o field, if present, contains the number of hops on > which the message has traveled across the MANET. The count> is set to 0 by the message originator and is used to > prevent messages from endlessly circulating in a MANET. When > forwarding a message, a MANET router should increase count> by 1 and should discard the message when > reaches 255. >=20 >=20 > Notes > ----- > Two changes of "packet" to "message". Message is consistent with the = normative > Section 5.2 that defines these fields (which may appear in each = message, so are > not uniquely defined for a packet), the text introducing these bullet = points, and > the remainder of these paragraphs. >=20 > (Note that the original and corrected text has had indentation reduced = by one > space.) >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please = use "Reply All" > to discuss whether it should be verified or rejected. When a decision = is reached, > the verifying party (IESG) can log in to change the status and edit = the report, if > necessary. >=20 > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) = Packet/Message > Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG >=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. > ************************************************************** > ****** From nobody Thu May 29 04:39:09 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EFE1A009E for ; Thu, 29 May 2014 04:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RfFgbiPGLza for ; Thu, 29 May 2014 04:39:05 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C071A008A for ; Thu, 29 May 2014 04:39:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="444107038" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 29 May 2014 12:39:00 +0100 X-IronPort-AV: E=Sophos;i="4.98,933,1392163200"; d="scan'208";a="52871588" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 29 May 2014 12:38:58 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.86]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0174.001; Thu, 29 May 2014 12:38:58 +0100 From: "Dearlove, Christopher (UK)" To: "adrian@olddog.co.uk" , 'RFC Errata System' , "T.Clausen@computer.org" , "jdean@itd.nrl.navy.mil" , "Cedric.Adjih@inria.fr" , "akatlas@gmail.com" , "sratliff@cisco.com" , "macker@itd.nrl.navy.mil" Thread-Topic: [Technical Errata Reported] RFC5444 (4003) Thread-Index: AQHPeyLiFPToweB6wUSfYLBbuA5C5ZtXVwGg///1NQCAAB9LsA== Date: Thu, 29 May 2014 11:38:57 +0000 Message-ID: References: <20140529094554.C7D1F18000D@rfc-editor.org> <073201cf7b29$a07b8980$e1729c80$@olddog.co.uk> In-Reply-To: <073201cf7b29$a07b8980$e1729c80$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/HnPdisCaJvMOSR114alVCtlodzs Cc: "manet@ietf.org" Subject: Re: [manet] [Technical Errata Reported] RFC5444 (4003) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:39:07 -0000 Well, actually it arose (Charlie spotted it, but not as an erratum) because= it was threatening mis-implementation, or at least mis-specification, in = AODVv2. But really it is editorial, because the number of surrounding uses = of message should have been a strong hint that it really was about messages= , not packets, and it certainly was an editorial sort of error by the autho= rs. I can live with it either way. --=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: Adrian Farrel [mailto:adrian@olddog.co.uk]=20 Sent: 29 May 2014 11:35 To: Dearlove, Christopher (UK); 'RFC Errata System'; T.Clausen@computer.org= ; jdean@itd.nrl.navy.mil; Cedric.Adjih@inria.fr; akatlas@gmail.com; sratlif= f@cisco.com; macker@itd.nrl.navy.mil Cc: manet@ietf.org Subject: RE: [Technical Errata Reported] RFC5444 (4003) ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- Christopher, I went ahead and approved this report, except I "downgraded" it to an Edito= rial issue because: - it is in a non-normative appendix - I don't believe that the error would have caused any mis-implementation o= r interop problem Thanks, Adrian > -----Original Message----- > From: Dearlove, Christopher (UK)=20 > [mailto:chris.dearlove@baesystems.com] > Sent: 29 May 2014 11:20 > To: RFC Errata System; T.Clausen@computer.org; jdean@itd.nrl.navy.mil;=20 > Cedric.Adjih@inria.fr; akatlas@gmail.com; adrian@olddog.co.uk;=20 > sratliff@cisco.com; macker@itd.nrl.navy.mil > Cc: manet@ietf.org > Subject: RE: [Technical Errata Reported] RFC5444 (4003) >=20 > Wearing my author hat, I agree with this erratum. But then I would, as=20 > I also submitted it. OK, over to the rest of you. >=20 > (I was very tempted to make an additional editorial wording change in=20 > those paragraphs, "on which" to "that". But resisted as that just=20 > muddies the waters.) >=20 > The parenthetical comment in the Notes is about a bug in the RFC=20 > erratum tool, I've sent that to the RFC editor separately. If the RFC=20 > editor (or IESG) can restore > the indentation and remove the comment, fine by me. >=20 > -- > Christopher Dearlove > Senior Principal Engineer, Communications Group Communications,=20 > Networks and Image Analysis Capability BAE Systems Advanced Technology=20 > Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK > Tel: +44 1245 242194=A0| 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=20 > Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales=20 > No: 1996687 >=20 >=20 > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: 29 May 2014 10:46 > To: T.Clausen@computer.org; Dearlove, Christopher (UK);=20 > jdean@itd.nrl.navy.mil; Cedric.Adjih@inria.fr; akatlas@gmail.com;=20 > adrian@olddog.co.uk; sratliff@cisco.com; macker@itd.nrl.navy.mil > Cc: Dearlove, Christopher (UK); manet@ietf.org;=20 > rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5444 (4003) >=20 > ----------------------! WARNING ! ---------------------- This message originates from > outside our organisation, either from an external partner or from the internet. > Consider carefully whether you should click on any links, open any=20 > attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters for=20 > instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > The following errata report has been submitted for RFC5444,=20 > "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5444&eid=3D4003 >=20 > -------------------------------------- > Type: Technical > Reported by: Christopher Dearlove >=20 > Section: Appendix B >=20 > Original Text > ------------- > o field, if present, contains the number of hops on > which the packet is allowed to travel before being discarded by a > MANET router. The is set by the message > originator and is used to prevent messages from endlessly > circulating in a MANET. When forwarding a message, a MANET router > should decrease the by 1, and the message should > be discarded when reaches 0. >=20 > o field, if present, contains the number of hops on > which the packet has traveled across the MANET. The count> is set to 0 by the message originator and is used to > prevent messages from endlessly circulating in a MANET. When > forwarding a message, a MANET router should increase count> by 1 and should discard the message when > reaches 255. >=20 >=20 > Corrected Text > -------------- > o field, if present, contains the number of hops on > which the message is allowed to travel before being discarded by a > MANET router. The is set by the message > originator and is used to prevent messages from endlessly > circulating in a MANET. When forwarding a message, a MANET router > should decrease the by 1, and the message should > be discarded when reaches 0. >=20 > o field, if present, contains the number of hops on > which the message has traveled across the MANET. The count> is set to 0 by the message originator and is used to > prevent messages from endlessly circulating in a MANET. When > forwarding a message, a MANET router should increase count> by 1 and should discard the message when > reaches 255. >=20 >=20 > Notes > ----- > Two changes of "packet" to "message". Message is consistent with the=20 > normative Section 5.2 that defines these fields (which may appear in=20 > each message, so are > not uniquely defined for a packet), the text introducing these bullet=20 > points, and > the remainder of these paragraphs. >=20 > (Note that the original and corrected text has had indentation reduced=20 > by one > space.) >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" > to discuss whether it should be verified or rejected. When a decision=20 > is reached, > the verifying party (IESG) can log in to change the status and edit=20 > the report, if > necessary. >=20 > -------------------------------------- > RFC5444 (draft-ietf-manet-packetbb-17) > -------------------------------------- > Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Me= ssage > Format > Publication Date : February 2009 > Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih > Category : PROPOSED STANDARD > Source : Mobile Ad-hoc Networks > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > ************************************************************** > ****** > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > 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=20 > distribute its contents to any other person. > ************************************************************** > ****** From nobody Thu May 29 06:06:16 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96931A090A for ; Thu, 29 May 2014 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1M1wBkGE060 for ; Thu, 29 May 2014 06:06:09 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE851A0906 for ; Thu, 29 May 2014 06:05:53 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Wq01i-002gLg-Bb>; Thu, 29 May 2014 15:05:46 +0200 Received: from pd957642b.dip0.t-ipconnect.de ([217.87.100.43] helo=[192.168.2.106]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Wq01i-000EBv-7U>; Thu, 29 May 2014 15:05:46 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_45E040EF-2A15-46C8-BFA2-77847383F611" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Lotte Steenbrink In-Reply-To: <53863308.3070704@hitachi.com> Date: Thu, 29 May 2014 15:05:45 +0200 Message-Id: References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> To: manet@ietf.org X-Mailer: Apple Mail (2.1874) X-Originating-IP: 217.87.100.43 X-ZEDAT-Hint: A Archived-At: http://mailarchive.ietf.org/arch/msg/manet/kX62d5mDeO3ucdlAGVU6d8GB1pM Cc: Charlie Perkins Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:06:13 -0000 --Apple-Mail=_45E040EF-2A15-46C8-BFA2-77847383F611 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Yuichi, Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI = : > Hi Charlie, >=20 > It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D= . But, if you remove RREP_ACK from the spec, how does AODVv2 itself = ensure all links are bi-directional? AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional = connectivity. My point was that, given the existence of this AckReq = mechanism, the additional inclusion of RREP_ACK seems redundant. Cheers, Lotte [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 > AODVv2 requires all routes to implement other protocol for verifying = bi-directionality of links? I am sure that would cause interoperability = problems. > Also, this is related to tickets #26 and #27, I think. >=20 > Regards, > Yuichi > (2014/05/29 2:34), Charlie Perkins wrote: >>=20 >> Hello Lotte, >>=20 >> I am O.K. with removing the RREP_ACK from the draft. There was >> some discussion a while back about compatibility, but I have not >> seen anyone defending the RREP_ACK in this discussion and it was >> not present in the previous DYMO drafts. >>=20 >> If anyone would prefer to keep RREP_ACK, then I will try to fashion >> some more detailed specification for handling it, which will be >> basically the way it was handled by AODV. >>=20 >> Regards, >> Charlie P. >>=20 >>=20 >> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>> #41: AckReq vs RREP_ACK >>>=20 >>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism = called >>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>> described >>> in section 5.2. >>> While RFC 3561, which is referenced in section 13.5., explains that = a >>> RREP-ACK is sent when a packet with the 'A' bit set is received, = the >>> AODVv2 does not describe how a RREP_ACK is triggered. >>> Additionally, the draft does not specify how a RREP_ACK should be >>> handled. >>> If the feature of a RREP_ACK is really needed, a more thorough >>> explanation >>> should be added. Otherwise, removing it could be a step towards de- >>> cluttering the draft. >>>=20 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >>=20 >=20 > --=20 > Hitachi, Ltd., Yokohama Research Laboratory > Yuichi Igarashi > Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com > Tel =EF=BC=9A +81-(0)50-3135-3457 --Apple-Mail=_45E040EF-2A15-46C8-BFA2-77847383F611 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello = Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI = <yuichi.igarashi.hb@hitachi.= com>:

Hi Charlie,

It says in sec.4 that "AODVv2 only = supports bidirectional links=E2=80=9D. But, if you remove RREP_ACK from = the spec, how does AODVv2 itself ensure all links are bi-directional? =

AODVv2 proposes the inclusion of an = AckReq TLV to ensure bidirectional connectivity. My point was that, = given the existence of this AckReq mechanism, the additional inclusion = of RREP_ACK seems = redundant.

Cheers,
Lotte

=
AODVv2 requires all routes to implement = other protocol for verifying bi-directionality of links? I am sure that = would cause interoperability problems.
Also, this is related to = tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 = 2:34), Charlie Perkins wrote:

Hello = Lotte,

I am O.K. with removing the RREP_ACK from the draft. =  There was
some discussion a while back about compatibility, but = I have not
seen anyone defending the RREP_ACK in this discussion and = it was
not present in the previous DYMO drafts.

If anyone = would prefer to keep RREP_ACK, then I will try to fashion
some more = detailed specification for handling it, which will be
basically the = way it was handled by AODV.

Regards,
Charlie P.


On = 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

 In Section 13.5., = the AODVv2 Draft briefly describes a mechanism called
=  RREP_ACK, which seems to serve a similar purpose as the = AckReqs
described
 in section 5.2.
 While RFC 3561, = which is referenced in section 13.5., explains that a
 RREP-ACK = is sent when a packet with the 'A' bit set is received, the
=  AODVv2 does not describe how a RREP_ACK is triggered.
=  Additionally, the draft does not specify how a RREP_ACK should = be
handled.
 If the feature of a RREP_ACK is really needed, = a more thorough
explanation
 should be added. Otherwise, = removing it could be a step towards de-
 cluttering the = draft.


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


--
Hitachi, Ltd., = Yokohama Research Laboratory
Yuichi Igarashi
Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.= com
Tel =EF=BC=9A = +81-(0)50-3135-3457

= --Apple-Mail=_45E040EF-2A15-46C8-BFA2-77847383F611-- From nobody Thu May 29 06:43:32 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C01A092E for ; Thu, 29 May 2014 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pszioU7MbCFT for ; Thu, 29 May 2014 06:43:29 -0700 (PDT) Received: from mailc1.tigertech.net (mailc1.tigertech.net [208.80.4.155]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025AB1A092A for ; Thu, 29 May 2014 06:43:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc1.tigertech.net (Postfix) with ESMTP id 2EC431E1882; Thu, 29 May 2014 06:43:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c1.tigertech.net Received: from [192.168.0.8] (180.181.15.93.rev.sfr.net [93.15.181.180]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc1.tigertech.net (Postfix) with ESMTPSA id 8410E1E18E1; Thu, 29 May 2014 06:43:24 -0700 (PDT) References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-77277CAB-E0B3-4310-A4FB-72066F4B655E Message-Id: <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> X-Mailer: iPhone Mail (11D201) From: Thomas Heide Clausen Date: Thu, 29 May 2014 15:43:20 +0200 To: Lotte Steenbrink Archived-At: http://mailarchive.ietf.org/arch/msg/manet/YmARslvfdw89WswrfByeiinThEo Cc: Charlie Perkins , "manet@ietf.org" Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:43:31 -0000 --Apple-Mail-77277CAB-E0B3-4310-A4FB-72066F4B655E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable It would be interesting to understand why AckReq was included in the first p= lace - given that that seems redundant with the well-known rrep_ack mechanis= m, and given that (it seems to me) that there are potential huge downsides t= o AckReq.=20 --=20 Thomas Heide Clausen http://www.thomasclausen.org "Today's scientists have substituted mathematics for=20 experiments, and they wander off through equation=20 after equation, and eventually build a structure=20 which has no relation to reality." - Nikola Tesla,=20 Modern Mechanics and Inventions, July, 1934 > On 29 mai 2014, at 15:05, Lotte Steenbrink = wrote: >=20 > Hello Yuichi, >=20 >> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI : >>=20 >> Hi Charlie, >>=20 >> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D.= But, if you remove RREP_ACK from the spec, how does AODVv2 itself ensure al= l links are bi-directional? >=20 > AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional con= nectivity. My point was that, given the existence of this AckReq mechanism, t= he additional inclusion of RREP_ACK seems redundant. >=20 > Cheers, > Lotte >=20 > [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 >=20 >> AODVv2 requires all routes to implement other protocol for verifying bi-d= irectionality of links? I am sure that would cause interoperability problems= . >> Also, this is related to tickets #26 and #27, I think. >>=20 >> Regards, >> Yuichi >> (2014/05/29 2:34), Charlie Perkins wrote: >>>=20 >>> Hello Lotte, >>>=20 >>> I am O.K. with removing the RREP_ACK from the draft. There was >>> some discussion a while back about compatibility, but I have not >>> seen anyone defending the RREP_ACK in this discussion and it was >>> not present in the previous DYMO drafts. >>>=20 >>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>> some more detailed specification for handling it, which will be >>> basically the way it was handled by AODV. >>>=20 >>> Regards, >>> Charlie P. >>>=20 >>>=20 >>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>> #41: AckReq vs RREP_ACK >>>>=20 >>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism calle= d >>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>> described >>>> in section 5.2. >>>> While RFC 3561, which is referenced in section 13.5., explains that a >>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the >>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>> Additionally, the draft does not specify how a RREP_ACK should be >>>> handled. >>>> If the feature of a RREP_ACK is really needed, a more thorough >>>> explanation >>>> should be added. Otherwise, removing it could be a step towards de- >>>> cluttering the draft. >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >>=20 >> --=20 >> Hitachi, Ltd., Yokohama Research Laboratory >> Yuichi Igarashi >> Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com >> Tel =EF=BC=9A +81-(0)50-3135-3457 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --Apple-Mail-77277CAB-E0B3-4310-A4FB-72066F4B655E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
It would be i= nteresting to understand why AckReq was included in the first place - given t= hat that seems redundant with the well-known rrep_ack mechanism, and given t= hat (it seems to me) that there are potential huge downsides to AckReq. = ;

-- 
Thomas Heide Clausen

"Today's scientists have substituted mathematics for =
  experiments, and they wander off through equation&nbs= p;
  after equation, and eventually  build a struct= ure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics a= nd Inventions, July, 1934

On 29 mai 2014, at 15:05, Lott= e Steenbrink <lotte.stee= nbrink@fu-berlin.de> wrote:

H= ello Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASH= I <yuichi.igarashi.hb@h= itachi.com>:

Hi Charlie,

It says in sec.4 that "AODVv2 only support= s bidirectional links=E2=80=9D. But, if you remove RREP_ACK from the spec, h= ow does AODVv2 itself ensure all links are bi-directional?

AODVv2 proposes the inclusion of an AckReq TLV to ensure bid= irectional connectivity. My point was that, given the existence of this AckR= eq mechanism, the additional inclusion of RREP_ACK seems redundant.

Cheers,
Lotte

[1] <= a href=3D"http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2">h= ttp://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2

=
AODVv2 requires all routes to implement other prot= ocol for verifying bi-directionality of links? I am sure that would cause in= teroperability problems.
Also, this is related to tickets #26 and #27, I t= hink.

Regards,
Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:=

Hello Lotte,

I am O.K. with removin= g the RREP_ACK from the draft.  There was
some discussion a while ba= ck about compatibility, but I have not
seen anyone defending the RREP_ACK= in this discussion and it was
not present in the previous DYMO drafts.
If anyone would prefer to keep RREP_ACK, then I will try to fashionsome more detailed specification for handling it, which will be
basicall= y the way it was handled by AODV.

Regards,
Charlie P.


O= n 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

 In Section 13.5., the AODVv2 Draft b= riefly describes a mechanism called
 RREP_ACK, which seems to serve= a similar purpose as the AckReqs
described
 in section 5.2.
=  While RFC 3561, which is referenced in section 13.5., explains that a=
 RREP-ACK is sent when a packet with the 'A' bit set is received, t= he
 AODVv2 does not describe how a RREP_ACK is triggered.
 = ;Additionally, the draft does not specify how a RREP_ACK should be
handle= d.
 If the feature of a RREP_ACK is really needed, a more thorough<= br>explanation
 should be added. Otherwise, removing it could be a s= tep towards de-
 cluttering the draft.


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


--
Hitachi, Ltd., Yokohama Research Laboratory=
Yuichi Igarashi
Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com
Tel =EF=BC=9A +81-(0)50-= 3135-3457

_______________________________________________=
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
=
= --Apple-Mail-77277CAB-E0B3-4310-A4FB-72066F4B655E-- From nobody Thu May 29 07:52:30 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1161A0974 for ; Thu, 29 May 2014 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p_FP2Jgz473j for ; Thu, 29 May 2014 07:52:28 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1A71A0411 for ; Thu, 29 May 2014 07:52:28 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id z6so361548yhz.11 for ; Thu, 29 May 2014 07:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0sVNcc/pM9NeBr9R1IKz90IOS3A5kcpTliRTNJDBGB8=; b=CYe4Rzxuo43fpsFrn0s/nM8tp2nVRtUr1k3Qu2mBcVquIAn0QYLTfAT7TYz884ozGS obaAWHH/6DsieWfyfZ8l40bmKL51psJGTe+sHOqfw3OVWe+0T7zhzjtM23dn7T1rLo3u N3k6EOAhp5MhGBaO/jD+BZPyP/QpA93OjXPVvbyM6bmD1iNJfGV3+U+SG/ip1k6PK6S5 t44fNHm3/RriFZnt5Q3I6RkeU/PeHqnr9Iu8S/cNYuNP1KTsyPime0fYTxC+Xi3Tt2PL 6zlH7ThEidFFQL7uYjMtSPDm8Yvhp0YDQ4fC7w1W87mMZeNi4hz5UfrqaZlkr+NAEYD4 MfAg== MIME-Version: 1.0 X-Received: by 10.236.206.97 with SMTP id k61mr10732882yho.107.1401375143199; Thu, 29 May 2014 07:52:23 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Thu, 29 May 2014 07:52:23 -0700 (PDT) In-Reply-To: <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> Date: Thu, 29 May 2014 15:52:23 +0100 Message-ID: From: Abdussalam Baryun To: Christopher Dearlove Content-Type: multipart/alternative; boundary=001a11c1d84e9b8b5d04fa8b13f9 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/oTjm-siJBThV2bgj8iJPLahkVBc Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:52:29 -0000 --001a11c1d84e9b8b5d04fa8b13f9 Content-Type: text/plain; charset=UTF-8 On Thu, May 29, 2014 at 1:00 AM, Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > ....... There are no such things as AODV packets. Packets are owned by the > 5444/5498 multiplexing process. Only messages are owned by AODVv2. > >From RFC5444 alone I think any protocol using it can specify its packets, but if we are using same multiplexing within the MANET then your routing protocol needs to follow 5444/5498. AB --001a11c1d84e9b8b5d04fa8b13f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2014 at 1:00 AM, Christopher Dea= rlove <christopher.dearlove@gmail.com> wrote:
.......=C2=A0There are no such things= as AODV packets. Packets are owned by the 5444/5498 multiplexing process. = Only messages are owned by AODVv2.
From RFC5444 alone I think any protocol using it can specify its packe= ts, but if we are using same multiplexing within the MANET then your routin= g protocol needs to follow 5444/5498.
=C2=A0
AB
=C2=A0
=C2=A0
--001a11c1d84e9b8b5d04fa8b13f9-- From nobody Thu May 29 08:03:45 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B6A1A087D for ; Thu, 29 May 2014 02:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.853 X-Spam-Level: X-Spam-Status: No, score=-104.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsFXb6OzezFT for ; Thu, 29 May 2014 02:46:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id C4B231A03D1 for ; Thu, 29 May 2014 02:46:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C7D1F18000D; Thu, 29 May 2014 02:45:54 -0700 (PDT) To: T.Clausen@computer.org, chris.dearlove@baesystems.com, jdean@itd.nrl.navy.mil, Cedric.Adjih@inria.fr, akatlas@gmail.com, adrian@olddog.co.uk, sratliff@cisco.com, macker@itd.nrl.navy.mil X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140529094554.C7D1F18000D@rfc-editor.org> Date: Thu, 29 May 2014 02:45:54 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/manet/bKciZzbxk9n5q8QWg-S8bVDjYk8 X-Mailman-Approved-At: Thu, 29 May 2014 08:03:43 -0700 Cc: chris.dearlove@baesystems.com, manet@ietf.org, rfc-editor@rfc-editor.org Subject: [manet] [Technical Errata Reported] RFC5444 (4003) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:46:36 -0000 The following errata report has been submitted for RFC5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5444&eid=4003 -------------------------------------- Type: Technical Reported by: Christopher Dearlove Section: Appendix B Original Text ------------- o field, if present, contains the number of hops on which the packet is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the packet has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Corrected Text -------------- o field, if present, contains the number of hops on which the message is allowed to travel before being discarded by a MANET router. The is set by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should decrease the by 1, and the message should be discarded when reaches 0. o field, if present, contains the number of hops on which the message has traveled across the MANET. The is set to 0 by the message originator and is used to prevent messages from endlessly circulating in a MANET. When forwarding a message, a MANET router should increase by 1 and should discard the message when reaches 255. Notes ----- Two changes of "packet" to "message". Message is consistent with the normative Section 5.2 that defines these fields (which may appear in each message, so are not uniquely defined for a packet), the text introducing these bullet points, and the remainder of these paragraphs. (Note that the original and corrected text has had indentation reduced by one space.) Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5444 (draft-ietf-manet-packetbb-17) -------------------------------------- Title : Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format Publication Date : February 2009 Author(s) : T. Clausen, C. Dearlove, J. Dean, C. Adjih Category : PROPOSED STANDARD Source : Mobile Ad-hoc Networks Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu May 29 08:15:53 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233F41A0379 for ; Thu, 29 May 2014 08:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.501 X-Spam-Level: X-Spam-Status: No, score=-4.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W6VXk0BA22s for ; Thu, 29 May 2014 08:15:46 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B871A09E3 for ; Thu, 29 May 2014 08:15:45 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1Wq23Q-0039CJ-DK>; Thu, 29 May 2014 17:15:40 +0200 Received: from pd957642b.dip0.t-ipconnect.de ([217.87.100.43] helo=[192.168.2.106]) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1Wq23Q-000Ndk-9d>; Thu, 29 May 2014 17:15:40 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_3E6381EC-9AB0-40C5-BFE7-099CCC6FA877" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Lotte Steenbrink In-Reply-To: <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> Date: Thu, 29 May 2014 17:15:35 +0200 Message-Id: <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1874) X-Originating-IP: 217.87.100.43 X-ZEDAT-Hint: A Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Q_SSdpekJcraF7gH0Al0crn_40g Cc: manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:15:49 -0000 --Apple-Mail=_3E6381EC-9AB0-40C5-BFE7-099CCC6FA877 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen = : > It would be interesting to understand why AckReq was included in the = first place - given that that seems redundant with the well-known = rrep_ack mechanism, and given that (it seems to me) that there are = potential huge downsides to AckReq.=20 Of course. I forgot to check whether my E-Mail client messed up the = order of my mails again before I sent my reply, that's why my reply was = a bit redundant. Sorry about that. The reason I opted for a removal of RREP_ACKs instead of AckReqs was = that, to me, the description of RREP_ACKs in the AODVv2 draft seemed = like an afterthought. Being somewhat new to the topic, I'm as familiar = with RREP_ACKs as I am with AckReqs, with the difference being that I'd = have no idea how to implement RREP_ACKs, at least not from the AODVV2 = specification: How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume = that, because Section 5.2. demands that AckReqs should be requested by = adding an appropriate message TLV, the same applies to RREP_ACKs, but = that kind of guesswork could lead to interoperability issues. Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag = set" should be handled? Why doesn't it remind me that (and how) a = RREP_ACK should be handled? Using other sources, i'd probably be able to cobble *something* = together, but I'd guess that the probability that another programmer = will come up with the same interpretation is not that high. So, what I was basically saying is just: Having two ways of ensuring = bidirectionality is confusing (and maybe standing in the way of = interoperability?), and one of the ways is confusing in itself, and I = think that needs to be sorted out-- by ditching one of the approaches = and being more specific in case RREP_ACKs are here to stay. Cheers, Lotte Steenbrink >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org >=20 > "Today's scientists have substituted mathematics for=20 > experiments, and they wander off through equation=20 > after equation, and eventually build a structure=20 > which has no relation to reality." > - Nikola Tesla,=20 > Modern Mechanics and Inventions, July, 1934 >=20 > On 29 mai 2014, at 15:05, Lotte Steenbrink = wrote: >=20 >> Hello Yuichi, >>=20 >> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI = : >>=20 >>> Hi Charlie, >>>=20 >>> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D= . But, if you remove RREP_ACK from the spec, how does AODVv2 itself = ensure all links are bi-directional? >>=20 >> AODVv2 proposes the inclusion of an AckReq TLV to ensure = bidirectional connectivity. My point was that, given the existence of = this AckReq mechanism, the additional inclusion of RREP_ACK seems = redundant. >>=20 >> Cheers, >> Lotte >>=20 >> [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 >>=20 >>> AODVv2 requires all routes to implement other protocol for verifying = bi-directionality of links? I am sure that would cause interoperability = problems. >>> Also, this is related to tickets #26 and #27, I think. >>>=20 >>> Regards, >>> Yuichi >>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>=20 >>>> Hello Lotte, >>>>=20 >>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>> some discussion a while back about compatibility, but I have not >>>> seen anyone defending the RREP_ACK in this discussion and it was >>>> not present in the previous DYMO drafts. >>>>=20 >>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>> some more detailed specification for handling it, which will be >>>> basically the way it was handled by AODV. >>>>=20 >>>> Regards, >>>> Charlie P. >>>>=20 >>>>=20 >>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>> #41: AckReq vs RREP_ACK >>>>>=20 >>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism = called >>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>> described >>>>> in section 5.2. >>>>> While RFC 3561, which is referenced in section 13.5., explains = that a >>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, = the >>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>> handled. >>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>> explanation >>>>> should be added. Otherwise, removing it could be a step towards = de- >>>>> cluttering the draft. >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>=20 >>> --=20 >>> Hitachi, Ltd., Yokohama Research Laboratory >>> Yuichi Igarashi >>> Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com >>> Tel =EF=BC=9A +81-(0)50-3135-3457 >>=20 >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet --Apple-Mail=_3E6381EC-9AB0-40C5-BFE7-099CCC6FA877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,

Am 29.05.2014 um = 15:43 schrieb Thomas Heide Clausen <ietf@thomasclausen.org>:
It= would be interesting to understand why AckReq was included in the first = place - given that that seems redundant with the well-known rrep_ack = mechanism, and given that (it seems to me) that there are potential huge = downsides to = AckReq. 

Of = course. I forgot to check whether my E-Mail client messed up the order = of my mails again before I sent my reply, that's why my reply was a bit = redundant. Sorry about that.

The reason I opted = for a removal of RREP_ACKs instead of AckReqs was that, to me, the = description of RREP_ACKs in the AODVv2 draft seemed like an = afterthought. Being somewhat new to the topic, I'm as familiar with = RREP_ACKs as I am with AckReqs, with the difference being that I'd have = no idea how to implement RREP_ACKs, at least not from the AODVV2 = specification:
How do I set the 'A' flag in RFC5444 RREPs = correctly? One could assume that, because Section 5.2. demands that = AckReqs should be requested by adding an appropriate message TLV, the = same applies to RREP_ACKs, but that kind of guesswork could lead to = interoperability issues.
Why doesn't the draft remind me that = (and how) a RREP "with the 'A' flag set" should be handled? Why doesn't = it remind me that (and how) a RREP_ACK should be = handled?

Using other sources, i'd probably be = able to cobble *something* together, but I'd guess that the probability = that another programmer will come up with the same interpretation is not = that high.

So, what I was basically saying is = just: Having two ways of ensuring bidirectionality is confusing (and = maybe standing in the way of interoperability?), and one of the ways is = confusing in itself, and I think that needs to be sorted out-- by = ditching one of the approaches and being more specific in case RREP_ACKs = are here to stay.

Cheers,
Lotte = Steenbrink



-- 
Thomas Heide = Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics = for 
  experiments, and they wander off through = equation 
  after equation, and eventually =  build a structure 
  which has no = relation to reality."
 - Nikola = Tesla, 
    Modern Mechanics and = Inventions, July, 1934

On 29 mai 2014, at 15:05, = Lotte Steenbrink <lotte.steenbrink@fu-berlin.d= e> wrote:

Hello = Yuichi,

Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI = <yuichi.igarashi.hb@hitachi.= com>:

Hi Charlie,

It says in sec.4 that "AODVv2 only = supports bidirectional links=E2=80=9D. But, if you remove RREP_ACK from = the spec, how does AODVv2 itself ensure all links are bi-directional? =

AODVv2 proposes the inclusion of an = AckReq TLV to ensure bidirectional connectivity. My point was that, = given the existence of this AckReq mechanism, the additional inclusion = of RREP_ACK seems = redundant.

Cheers,
Lotte

=
AODVv2 requires all routes to implement = other protocol for verifying bi-directionality of links? I am sure that = would cause interoperability problems.
Also, this is related to = tickets #26 and #27, I think.

Regards,
Yuichi
(2014/05/29 = 2:34), Charlie Perkins wrote:

Hello = Lotte,

I am O.K. with removing the RREP_ACK from the draft. =  There was
some discussion a while back about compatibility, but = I have not
seen anyone defending the RREP_ACK in this discussion and = it was
not present in the previous DYMO drafts.

If anyone = would prefer to keep RREP_ACK, then I will try to fashion
some more = detailed specification for handling it, which will be
basically the = way it was handled by AODV.

Regards,
Charlie P.


On = 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

 In Section 13.5., = the AODVv2 Draft briefly describes a mechanism called
=  RREP_ACK, which seems to serve a similar purpose as the = AckReqs
described
 in section 5.2.
 While RFC 3561, = which is referenced in section 13.5., explains that a
 RREP-ACK = is sent when a packet with the 'A' bit set is received, the
=  AODVv2 does not describe how a RREP_ACK is triggered.
=  Additionally, the draft does not specify how a RREP_ACK should = be
handled.
 If the feature of a RREP_ACK is really needed, = a more thorough
explanation
 should be added. Otherwise, = removing it could be a step towards de-
 cluttering the = draft.


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


--
Hitachi, = Ltd., Yokohama Research Laboratory
Yuichi Igarashi
Mail=EF=BC=9A = yuichi.igarashi.hb@hitachi.= com
Tel =EF=BC=9A = +81-(0)50-3135-3457

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

= --Apple-Mail=_3E6381EC-9AB0-40C5-BFE7-099CCC6FA877-- From nobody Thu May 29 09:11:07 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBE11A09B0 for ; Thu, 29 May 2014 09:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je8AXi52riV1 for ; Thu, 29 May 2014 09:11:03 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0151A044D for ; Thu, 29 May 2014 09:11:02 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so949957wib.17 for ; Thu, 29 May 2014 09:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=0nxzhFIFjS/nu+gZxaR0R52CA60tOPfB2m8+vX06dME=; b=J6+ZtSGpAkb08pECv9o/apjiDz9tCi6SV2xf/aMA5ndyRSvKqTP+XEnoQYIc2VoKed Er7j4eCusUK1d6GpCOOLpTuH9QdJdF9BYTCz49McAqw2L7ex2JJmUAmcj19ALSsq1t11 RRwIeXCQEQoV2GPn9byS3y3tSMUsDVES472RpDxXOgFKKVXy8fjTcllmXZH0X5pLRb/I OPrOfakMzXc3Xz0qP73iqHYuqV+Yn0gnzJ0wNn1h2XCzswPR0HkJdew1U4eUjMCrIxe4 8m9dNcpLzhzLSyJPLZVmnHessPe0hedE9rfFLfwV64X6XXAqoRzsRjRmda8CVq+o9AwM HIDw== X-Received: by 10.180.107.97 with SMTP id hb1mr13223859wib.20.1401379857773; Thu, 29 May 2014 09:10:57 -0700 (PDT) Received: from [10.5.224.55] (dab-crx1-h-17-7.dab.02.net. [82.132.226.171]) by mx.google.com with ESMTPSA id ft17sm1967053wjc.14.2014.05.29.09.10.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:10:57 -0700 (PDT) References: <061.a5ce40aa1d210c527317773533e6c828@trac.tools.ietf.org> <53866290.6070309@computer.org> <46A83C8C-54E7-4D67-9D33-658D21739249@mnemosyne.demon.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-50060877-F72F-46FF-B385-79A22965F2B3 Content-Transfer-Encoding: 7bit Message-Id: <3D716D54-9F74-43CB-952B-86CD323C5EE4@gmail.com> X-Mailer: iPhone Mail (11D201) From: Christopher Dearlove Date: Thu, 29 May 2014 17:10:50 +0100 To: Abdussalam Baryun Archived-At: http://mailarchive.ietf.org/arch/msg/manet/h_P3r-6h9lJWlLMOYRUfH53ylrk Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #33 (aodvv2): RFC 5444 processing constraint X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:11:04 -0000 --Apple-Mail-50060877-F72F-46FF-B385-79A22965F2B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable And you have to use that multiplexing if using the manet UDP port or IP prot= ocol. RFC 5498. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 29 May 2014, at 15:52, Abdussalam Baryun w= rote: >=20 >=20 >=20 >> On Thu, May 29, 2014 at 1:00 AM, Christopher Dearlove wrote: >> ....... There are no such things as AODV packets. Packets are owned by th= e 5444/5498 multiplexing process. Only messages are owned by AODVv2. > =46rom RFC5444 alone I think any protocol using it can specify its packets= , but if we are using same multiplexing within the MANET then your routing p= rotocol needs to follow 5444/5498. > =20 > AB > =20 > =20 --Apple-Mail-50060877-F72F-46FF-B385-79A22965F2B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
And you have to use that multiplexing if using the manet UDP port or IP protocol. RFC 5498.

--  
Christopher Dearlove

On 29 May 2014, at 15:52, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:



On Thu, May 29, 2014 at 1:00 AM, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
....... There are no such things as AODV packets. Packets are owned by the 5444/5498 multiplexing process. Only messages are owned by AODVv2.
From RFC5444 alone I think any protocol using it can specify its packets, but if we are using same multiplexing within the MANET then your routing protocol needs to follow 5444/5498.
 
AB
 
 
--Apple-Mail-50060877-F72F-46FF-B385-79A22965F2B3-- From nobody Thu May 29 20:07:04 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B22461A07DD for ; Thu, 29 May 2014 20:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gqMJKX6HkL6 for ; Thu, 29 May 2014 20:07:00 -0700 (PDT) Received: from mailrelay4.nmsu.edu (mailrelay4.nmsu.edu [128.123.34.100]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17121A07BB for ; Thu, 29 May 2014 20:07:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,938,1392188400"; d="scan'208";a="110180519" Received: from EX-MBX-P2.ACN.ad.nmsu.edu ([169.254.2.246]) by EX-HT-P2.ACN.ad.nmsu.edu ([128.123.34.10]) with mapi id 14.02.0347.000; Thu, 29 May 2014 21:06:56 -0600 From: John Mullen To: "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #35 (aodvv2): A constant is constant Thread-Index: AQHPeqXdG6IHt0lPJEyVkml3+t8RuptYb2Q/ Date: Fri, 30 May 2014 03:06:55 +0000 Message-ID: <96E29CF19751734389BE3A1B34684180E5B5E4E3@EX-MBX-P2.ACN.ad.nmsu.edu> References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org>, <5386301E.2@computer.org> In-Reply-To: <5386301E.2@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.161.46.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/x5aXVigID8n9_ng1gRbW0rEc_WQ Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 03:07:02 -0000 Hi All,=0A= I've been a lurker for some time, but as a mathematician and engineer, I've= always interpreted "constant" as a value that is unchanging in the current= analysis, not necessarily a constant in the sense of Euler's constant. So = my interpretation is that these are values that are not to be modified dyna= mically, but may be modified in certain situations and possibly due to some= yet-unknown technology by the people setting up the network. It is also my= experience that people who do this use the default values unless something= comes up that warrants adjustment. So, I think the language is clear enoug= h.=0A= =0A= Back to lurking,=0A= John Mullen=0A= ________________________________________=0A= From: manet [manet-bounces@ietf.org] on behalf of Charles E. Perkins [charl= iep@computer.org]=0A= Sent: Wednesday, May 28, 2014 12:51 PM=0A= To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org=0A= Subject: Re: [manet] #35 (aodvv2): A constant is constant=0A= =0A= Hello folks,=0A= =0A= I'm not quite sure what to do about this. Contrary to the assertion,=0A= the term "Protocol Constant" is pretty well understood and has been=0A= used with the same meaning in numerous existing RFCs. I think that=0A= it would be interesting to explore the results of using different constants= ,=0A= but the intention is clearly that implementations should use the numbers=0A= as provided.=0A= =0A= If desired, I can try to fashion some text to suggest the results of=0A= using different numbers (e.g., for use in atypical situations).=0A= =0A= Regards,=0A= Charlie P.=0A= =0A= =0A= On 4/3/2014 2:34 PM, manet issue tracker wrote:=0A= > #35: A constant is constant=0A= >=0A= > (Thomas Clausen)=0A= > Section 14.2 "Protocol Constants" contains a semantically null=0A= > sentence AODVv2 protocol constants typically do not require changes=0A= >=0A= > A constant is constant, therefore it doesn't change. Even for very=0A= > loose definitions of constant. With that being said, the interesting= =0A= > part here is actually not that bit...but rather, what happens *if*=0A= > these are not set to the values that are indicated? Or, if different=0A= > implementations use different values for these? The same holds for=0A= > 14.2, btw: is a network able to operate with different routers setting= =0A= > different values? Will it break? Degrade gracefully? Just work?=0A= >=0A= =0A= --=0A= Regards,=0A= Charlie P.=0A= =0A= _______________________________________________=0A= manet mailing list=0A= manet@ietf.org=0A= https://www.ietf.org/mailman/listinfo/manet=0A= From nobody Fri May 30 01:49:08 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB64C1A6F00 for ; Fri, 30 May 2014 01:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.551 X-Spam-Level: X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSCu7wTV2hs9 for ; Fri, 30 May 2014 01:49:03 -0700 (PDT) Received: from ukmta1.baesystems.com (ukmta1.baesystems.com [20.133.0.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28201A6EFC for ; Fri, 30 May 2014 01:49:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,939,1392163200"; d="scan'208";a="444385850" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by baemasmds003ir.sharelnk.net with ESMTP; 30 May 2014 09:48:46 +0100 X-IronPort-AV: E=Sophos;i="4.98,939,1392163200"; d="scan'208";a="52974385" Received: from glkxh0006v.greenlnk.net ([10.110.2.32]) by baemasmds017.greenlnk.net with ESMTP; 30 May 2014 09:48:31 +0100 Received: from GLKXM0008V.GREENLNK.net ([169.254.8.29]) by GLKXH0006V.GREENLNK.net ([10.110.2.32]) with mapi id 14.03.0174.001; Fri, 30 May 2014 09:48:27 +0100 From: "Dearlove, Christopher (UK)" To: John Mullen , "manet@ietf.org" , "draft-ietf-manet-aodvv2@tools.ietf.org" Thread-Topic: [manet] #35 (aodvv2): A constant is constant Thread-Index: AQHPeqXis7LrB0AYFUejCMwVnTcncJtYYl2AgABuRTA= Date: Fri, 30 May 2014 08:48:27 +0000 Message-ID: References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org>, <5386301E.2@computer.org> <96E29CF19751734389BE3A1B34684180E5B5E4E3@EX-MBX-P2.ACN.ad.nmsu.edu> In-Reply-To: <96E29CF19751734389BE3A1B34684180E5B5E4E3@EX-MBX-P2.ACN.ad.nmsu.edu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.19.152] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/manet/J1jYv-dmBLq_5HTEbyQNg2DIzds Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:49:05 -0000 The approach we took in NHDP and OLSRv2 is, I think, consistent with how yo= u see it. A constant is the same across the MANET, and (a necessary consequ= ence of that) not dynamically changing. For out of the box compatibility we= had a fixed value that we would expect most, maybe even all, MANETs to use= , but you could deploy a specialised MANET with a different value. I haven't checked the AODVv2 language to see if consistent with that. I thi= nk more variable than that would be confusing to use the word constant. As = a practical matter, a strongly recommended (at least) default value is a go= od idea. More constant than that (fixed value, never changes, same in all M= ANETs) is of course a special case. -- = 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 [mailto:manet-bounces@ietf.org] On Behalf Of John Mullen Sent: 30 May 2014 04:07 To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #35 (aodvv2): A constant is constant ----------------------! WARNING ! ---------------------- This message origi= nates from outside our organisation, either from an external partner or fro= m the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. -------------------------------------------------------- Hi All, I've been a lurker for some time, but as a mathematician and engineer, I've= always interpreted "constant" as a value that is unchanging in the current= analysis, not necessarily a constant in the sense of Euler's constant. So = my interpretation is that these are values that are not to be modified dyna= mically, but may be modified in certain situations and possibly due to some= yet-unknown technology by the people setting up the network. It is also my= experience that people who do this use the default values unless something= comes up that warrants adjustment. So, I think the language is clear enoug= h. Back to lurking, John Mullen ________________________________________ From: manet [manet-bounces@ietf.org] on behalf of Charles E. Perkins [charl= iep@computer.org] Sent: Wednesday, May 28, 2014 12:51 PM To: manet@ietf.org; draft-ietf-manet-aodvv2@tools.ietf.org Subject: Re: [manet] #35 (aodvv2): A constant is constant Hello folks, I'm not quite sure what to do about this. Contrary to the assertion, the t= erm "Protocol Constant" is pretty well understood and has been used with th= e same meaning in numerous existing RFCs. I think that it would be interes= ting to explore the results of using different constants, but the intention= is clearly that implementations should use the numbers as provided. If desired, I can try to fashion some text to suggest the results of using = different numbers (e.g., for use in atypical situations). Regards, Charlie P. On 4/3/2014 2:34 PM, manet issue tracker wrote: > #35: A constant is constant > > (Thomas Clausen) > Section 14.2 "Protocol Constants" contains a semantically null > sentence AODVv2 protocol constants typically do not require changes > > A constant is constant, therefore it doesn't change. Even for very > loose definitions of constant. With that being said, the interesting > part here is actually not that bit...but rather, what happens *if* > these are not set to the values that are indicated? Or, if different > implementations use different values for these? The same holds for > 14.2, btw: is a network able to operate with different routers setting > different values? Will it break? Degrade gracefully? Just work? > -- Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** 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 nobody Fri May 30 09:43:37 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3218B1A09D7 for ; Fri, 30 May 2014 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ER1w98ApOEl1 for ; Fri, 30 May 2014 09:43:26 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5171A09A5 for ; Fri, 30 May 2014 09:43:26 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id z6so1779738yhz.34 for ; Fri, 30 May 2014 09:43: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=HMdbJ8oXswp7nQZATjYO+PrTtB3xlMEC6+i6R8cykxI=; b=XLI8ZYl1MvLU3RqcOAxsNJZiH5VPH8y+pWaC3N3UgmFSz+MGlZgmRJpYuADYgSDyZP GgeV2txpdZGQmrgQ7CrM7pmNNSoHXzefuqq7Z4f634jEzeJ5OYo1eqdnv8/5TjeBp++N q7urrhWOd4Iqn7kxP7ggfZFCqNpLkQcG3cOAQZHJxD40p8lqPv2WYs+SlDhyl5JFO8jX W43QeN6y+7gO3vL+85FIJI1FssaY3PYUBsykBspv1GIdqhHRS9HWvYxoarqIxwWuoaxG t7cf1P6o99hKrj20WrKGgzB67+HE6pTiLmhzPAXlyEEodA6wqv+T4UtWb1l38OIOMg4I eqfA== MIME-Version: 1.0 X-Received: by 10.236.68.34 with SMTP id k22mr22962897yhd.90.1401468201777; Fri, 30 May 2014 09:43:21 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Fri, 30 May 2014 09:43:21 -0700 (PDT) In-Reply-To: <96E29CF19751734389BE3A1B34684180E5B5E4E3@EX-MBX-P2.ACN.ad.nmsu.edu> References: <061.64df908508777a0117e43e7ed153e409@trac.tools.ietf.org> <5386301E.2@computer.org> <96E29CF19751734389BE3A1B34684180E5B5E4E3@EX-MBX-P2.ACN.ad.nmsu.edu> Date: Fri, 30 May 2014 18:43:21 +0200 Message-ID: From: Abdussalam Baryun To: John Mullen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/PcYLXViyXGpMNxEr7-okejREh50 Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #35 (aodvv2): A constant is constant X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:43:30 -0000 This draft purpose is implementation, so the understandning target should be targeting implementers (which they not needed to be engineers or mathematics). IMHO, within any protocol specification/program-language, its constants are not variable and its variables are not constant. IMHO, this ticket #35 mostly points to a sentence, therefore it means: Remove the sentence "AODVv2 protocol constants typically do not require changes". or Replace to: " AODVv2 protocol constants' values are typically default values". I do not disagree with the ticket (i.e. it maybe did not recommend edit sentence), because that sentence may cause confusion to the implementers that know that constants cannot change. If editors don't want to remove/replace then we may add more words to clarify in a better way for all understandings. Please advise, AB On 5/30/14, John Mullen wrote: > Hi All, > I've been a lurker for some time, but as a mathematician and engineer, I've > always interpreted "constant" as a value that is unchanging in the current > analysis, not necessarily a constant in the sense of Euler's constant. So my > interpretation is that these are values that are not to be modified > dynamically, but may be modified in certain situations and possibly due to > some yet-unknown technology by the people setting up the network. It is also > my experience that people who do this use the default values unless > something comes up that warrants adjustment. So, I think the language is > clear enough. > > Back to lurking, > John Mullen From nobody Fri May 30 13:16:14 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFD01A0502 for ; Fri, 30 May 2014 13:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj6DNgtPH1mK for ; Fri, 30 May 2014 13:16:10 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3111A01B4 for ; Fri, 30 May 2014 13:16:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EF9072466C9; Fri, 30 May 2014 13:16:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.142] (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 maila2.tigertech.net (Postfix) with ESMTPSA id A2F4C240499; Fri, 30 May 2014 13:16:04 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0B654C5A-BD6E-4716-A805-2ACB66AF797A Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPad Mail (11D201) In-Reply-To: <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> Date: Fri, 30 May 2014 22:16:01 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <53863308.3070704@hitachi.com> <05CD0538-85C5-4986-A49A-D74965634262@thomasclausen.org> <768F7407-94BE-41F1-ABA6-0FC0131F8B5D@fu-berlin.de> To: Lotte Steenbrink Archived-At: http://mailarchive.ietf.org/arch/msg/manet/Gh1w5udUt3XHFkyI2-_7AYrT1hw Cc: "" , "manet@ietf.org" Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 20:16:13 -0000 --Apple-Mail-0B654C5A-BD6E-4716-A805-2ACB66AF797A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Lotte, > On 29 mai 2014, at 17:15, Lotte Steenbrink = wrote: >=20 > Hello, >=20 >> Am 29.05.2014 um 15:43 schrieb Thomas Heide Clausen : >>=20 >> It would be interesting to understand why AckReq was included in the firs= t place - given that that seems redundant with the well-known rrep_ack mecha= nism, and given that (it seems to me) that there are potential huge downside= s to AckReq.=20 >=20 > Of course. I forgot to check whether my E-Mail client messed up the order o= f my mails again before I sent my reply, that's why my reply was a bit redun= dant. Sorry about that. >=20 > The reason I opted for a removal of RREP_ACKs instead of AckReqs was that,= to me, the description of RREP_ACKs in the AODVv2 draft seemed like an afte= rthought. Being somewhat new to the topic, I'm as familiar with RREP_ACKs as= I am with AckReqs, with the difference being that I'd have no idea how to i= mplement RREP_ACKs, at least not from the AODVV2 specification: Lotte, my question was actually not as much directed as you, as it was to th= e authors of the protocol....RREP_ACK is well-known, there's operational exp= eriences with it, etc., whereas AckReq seems "new" (and, as I indicated, I t= hink - without having analyzed it in details - that there are potential issu= es with it that we do not fully understand) and without operational experien= ce supporting its existence.... That said, as I have pointed out over the previous many years, this protocol= is quite underspecified, and this is but one of the areas in which this is t= he case. I am comforted by the fact that you agree with that sentiment (alth= ough, also, saddened by the state of the specification and protocol.) > How do I set the 'A' flag in RFC5444 RREPs correctly? One could assume tha= t, because Section 5.2. demands that AckReqs should be requested by adding a= n appropriate message TLV, the same applies to RREP_ACKs, but that kind of g= uesswork could lead to interoperability issues. Yes, very much so. > Why doesn't the draft remind me that (and how) a RREP "with the 'A' flag s= et" should be handled? Why doesn't it remind me that (and how) a RREP_ACK sh= ould be handled? Agree completely. > Using other sources, i'd probably be able to cobble *something* together, b= ut I'd guess that the probability that another programmer will come up with t= he same interpretation is not that high. >=20 > So, what I was basically saying is just: Having two ways of ensuring bidir= ectionality is confusing (and maybe standing in the way of interoperability?= ), and one of the ways is confusing in itself, and I think that needs to be s= orted out-- by ditching one of the approaches and being more specific in cas= e RREP_ACKs are here to stay. >=20 Yes having ambiguities and underspecified bits and pieces on a protocol spec= ification is bad. As is having possibly non-interoperable options specified.= =20 So, I think that we are in violent agreement that the protocol & specificati= on has serious problems here... Best, Thomas > Cheers, > Lotte Steenbrink >=20 >=20 >>=20 >> --=20 >> Thomas Heide Clausen >> http://www.thomasclausen.org >>=20 >> "Today's scientists have substituted mathematics for=20 >> experiments, and they wander off through equation=20 >> after equation, and eventually build a structure=20 >> which has no relation to reality." >> - Nikola Tesla,=20 >> Modern Mechanics and Inventions, July, 1934 >>=20 >>> On 29 mai 2014, at 15:05, Lotte Steenbrink wrote: >>>=20 >>> Hello Yuichi, >>>=20 >>>> Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI : >>>>=20 >>>> Hi Charlie, >>>>=20 >>>> It says in sec.4 that "AODVv2 only supports bidirectional links=E2=80=9D= . But, if you remove RREP_ACK from the spec, how does AODVv2 itself ensure a= ll links are bi-directional? >>>=20 >>> AODVv2 proposes the inclusion of an AckReq TLV to ensure bidirectional c= onnectivity. My point was that, given the existence of this AckReq mechanism= , the additional inclusion of RREP_ACK seems redundant. >>>=20 >>> Cheers, >>> Lotte >>>=20 >>> [1] http://tools.ietf.org/html/draft-ietf-manet-dymo-26#section-5.2 >>>=20 >>>> AODVv2 requires all routes to implement other protocol for verifying bi= -directionality of links? I am sure that would cause interoperability proble= ms. >>>> Also, this is related to tickets #26 and #27, I think. >>>>=20 >>>> Regards, >>>> Yuichi >>>> (2014/05/29 2:34), Charlie Perkins wrote: >>>>>=20 >>>>> Hello Lotte, >>>>>=20 >>>>> I am O.K. with removing the RREP_ACK from the draft. There was >>>>> some discussion a while back about compatibility, but I have not >>>>> seen anyone defending the RREP_ACK in this discussion and it was >>>>> not present in the previous DYMO drafts. >>>>>=20 >>>>> If anyone would prefer to keep RREP_ACK, then I will try to fashion >>>>> some more detailed specification for handling it, which will be >>>>> basically the way it was handled by AODV. >>>>>=20 >>>>> Regards, >>>>> Charlie P. >>>>>=20 >>>>>=20 >>>>>> On 4/22/2014 12:39 PM, manet issue tracker wrote: >>>>>> #41: AckReq vs RREP_ACK >>>>>>=20 >>>>>> In Section 13.5., the AODVv2 Draft briefly describes a mechanism cal= led >>>>>> RREP_ACK, which seems to serve a similar purpose as the AckReqs >>>>>> described >>>>>> in section 5.2. >>>>>> While RFC 3561, which is referenced in section 13.5., explains that a= >>>>>> RREP-ACK is sent when a packet with the 'A' bit set is received, the= >>>>>> AODVv2 does not describe how a RREP_ACK is triggered. >>>>>> Additionally, the draft does not specify how a RREP_ACK should be >>>>>> handled. >>>>>> If the feature of a RREP_ACK is really needed, a more thorough >>>>>> explanation >>>>>> should be added. Otherwise, removing it could be a step towards de- >>>>>> cluttering the draft. >>>>>=20 >>>>> _______________________________________________ >>>>> manet mailing list >>>>> manet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/manet >>>>=20 >>>> --=20 >>>> Hitachi, Ltd., Yokohama Research Laboratory >>>> Yuichi Igarashi >>>> Mail=EF=BC=9A yuichi.igarashi.hb@hitachi.com >>>> Tel =EF=BC=9A +81-(0)50-3135-3457 >>>=20 >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >=20 --Apple-Mail-0B654C5A-BD6E-4716-A805-2ACB66AF797A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Lotte,
On 29 mai 2014, at 17= :15, Lotte Steenbrink <l= otte.steenbrink@fu-berlin.de> wrote:

Hello,

Am 29.05.2014 um 15:43 schrieb Thomas H= eide Clausen <ietf@thomasclause= n.org>:

It would be interest= ing to understand why AckReq was included in the first place - given that th= at seems redundant with the well-known rrep_ack mechanism, and given that (i= t seems to me) that there are potential huge downsides to AckReq. 

Of course. I forgot to check w= hether my E-Mail client messed up the order of my mails again before I sent m= y reply, that's why my reply was a bit redundant. Sorry about that.

The reason I opted for a removal of RREP_ACKs instead of Ac= kReqs was that, to me, the description of RREP_ACKs in the AODVv2 draft seem= ed like an afterthought. Being somewhat new to the topic, I'm as familiar wi= th RREP_ACKs as I am with AckReqs, with the difference being that I'd have n= o idea how to implement RREP_ACKs, at least not from the AODVV2 specificatio= n:

Lotte, my question was a= ctually not as much directed as you, as it was to the authors of the protoco= l....RREP_ACK is well-known, there's operational experiences with it, etc., w= hereas AckReq seems "new" (and, as I indicated, I think - without having ana= lyzed it in details - that there are potential issues with it that we do not= fully understand) and without operational experience supporting its existen= ce....

That said, as I have pointed out over the pr= evious many years, this protocol is quite underspecified, and this is but on= e of the areas in which this is the case. I am comforted by the fact that yo= u agree with that sentiment (although, also, saddened by the state of the sp= ecification and protocol.)


How do I set the 'A' flag in RFC5444 RREPs correctly? O= ne could assume that, because Section 5.2. demands that AckReqs should be re= quested by adding an appropriate message TLV, the same applies to RREP_ACKs,= but that kind of guesswork could lead to interoperability issues.

Yes, very much so.

Why doesn't the draft remind me that (and h= ow) a RREP "with the 'A' flag set" should be handled? Why doesn't it remind m= e that (and how) a RREP_ACK should be handled?

Agree completely.

Using other sources, i'd probably be able to cobble *something* together, b= ut I'd guess that the probability that another programmer will come up with t= he same interpretation is not that high.

So, what I= was basically saying is just: Having two ways of ensuring bidirectionality i= s confusing (and maybe standing in the way of interoperability?), and one of= the ways is confusing in itself, and I think that needs to be sorted out-- b= y ditching one of the approaches and being more specific in case RREP_ACKs a= re here to stay.


Yes having ambiguities and underspecified bits and pieces on a protocol spe= cification is bad. As is having possibly non-interoperable options specified= . 

So, I think that we are in violent agreemen= t that the protocol & specification has serious problems here...

Best,

Thomas

Cheers,
Lotte Steenbrink
<= div>


=
-- 
Thomas Heide Clausen

"Today's scientists have substituted mathematics for 
&nbs= p; experiments, and they wander off through equation 
&n= bsp; after equation, and eventually  build a structure 
=
  which has no relation to reality."
 - Nikola= Tesla, 
    Modern Mechanics and Inventions, J= uly, 1934

On 29 mai 2014, at 15:05, Lotte Steenbrink <= ;lotte.steenbrink@fu-berlin= .de> wrote:

Hello Yuichi,

<= div>
Am 28.05.2014 um 21:03 schrieb Yuichi IGARASHI <yuichi.igarashi.hb@hitachi.com>:
Hi Char= lie,

It says in sec.4 that "AODVv2 only supports bidirectional links=E2= =80=9D. But, if you remove RREP_ACK from the spec, how does AODVv2 itself en= sure all links are bi-directional?

AODVv2 p= roposes the inclusion of an AckReq TLV to ensure bidirectional connectivity.= My point was that, given the existence of this AckReq mechanism, the additi= onal inclusion of RREP_ACK seems redundant.

Cheers,=
Lotte


AODVv2 requires all routes to implement other protocol for verifying bi-di= rectionality of links? I am sure that would cause interoperability problems.=
Also, this is related to tickets #26 and #27, I think.

Regards,Yuichi
(2014/05/29 2:34), Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the= draft.  There was
some discussion a while back about compatibility,= but I have not
seen anyone defending the RREP_ACK in this discussion and= it was
not present in the previous DYMO drafts.

If anyone would p= refer to keep RREP_ACK, then I will try to fashion
some more detailed spe= cification for handling it, which will be
basically the way it was handle= d by AODV.

Regards,
Charlie P.


On 4/22/2014 12:39 PM, m= anet issue tracker wrote:
#41: AckReq vs RREP_A= CK

 In Section 13.5., the AODVv2 Draft briefly describes a mech= anism called
 RREP_ACK, which seems to serve a similar purpose as t= he AckReqs
described
 in section 5.2.
 While RFC 3561, w= hich is referenced in section 13.5., explains that a
 RREP-ACK is s= ent when a packet with the 'A' bit set is received, the
 AODVv2 doe= s not describe how a RREP_ACK is triggered.
 Additionally, the draf= t does not specify how a RREP_ACK should be
handled.
 If the fea= ture of a RREP_ACK is really needed, a more thorough
explanation
&nbs= p;should be added. Otherwise, removing it could be a step towards de-
&n= bsp;cluttering the draft.


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

<= br>--
Hitachi, Ltd., Yokohama Research Laboratory
Yuichi Igarashi Mail=EF=BC=9A yuichi.ig= arashi.hb@hitachi.com
Tel =EF=BC=9A +81-(0)50-3135-3457

___________= ____________________________________
manet mailing list
manet@ietf.org
<= span>https://www.iet= f.org/mailman/listinfo/manet

= --Apple-Mail-0B654C5A-BD6E-4716-A805-2ACB66AF797A-- From nobody Fri May 30 15:08:10 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC711A08F9 for ; Fri, 30 May 2014 15:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCJs4RR4Hmk9 for ; Fri, 30 May 2014 15:08:05 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567711A08C0 for ; Fri, 30 May 2014 15:08:05 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so2122606yha.12 for ; Fri, 30 May 2014 15:08: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; bh=qmorMFFljNnARX4fN0Zzx/1AqKDAeF6Kk6IGd9M+cAg=; b=uFDm/Qc0QbYMENYvplRNjkakDlaflxty6OaPAyqn63GSdInMKSa+v4WO1QF1artwn6 F9nfViKeqJ/mbpubqSi44tXy8Rfb0OjTpIKZgT36+wEYnEwZXipXEy2RxBU0snGCFcgW 8OnrTWAvRJrU48GXHqLbvo3crssXxXZj8bWXYj6V6q+FtoJ3CcrzkSn8+Bf9ldtPzoE8 xFGIoP4QPn0G0dHJfkz7Jt9j50D4Oynb2KtqOPb/mV9ARCktGmtEC/icfgVmwa8ACp/I bq083yZ/2z4Nii3o6OPuAMGD68/51fO5Eak52LnFqdk0ODzI44UkqQujZMTr9FfBq0Fg IjBg== MIME-Version: 1.0 X-Received: by 10.236.101.198 with SMTP id b46mr25262656yhg.68.1401487680690; Fri, 30 May 2014 15:08:00 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Fri, 30 May 2014 15:08:00 -0700 (PDT) In-Reply-To: <53861E28.1070700@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> Date: Sat, 31 May 2014 00:08:00 +0200 Message-ID: From: Abdussalam Baryun To: Charlie Perkins Content-Type: multipart/alternative; boundary=20cf30050b225d625b04faa547d8 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/8OLlgLh-Qt16ciUE0ZGLEXAJMHM Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , "manet@ietf.org" Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 22:08:07 -0000 --20cf30050b225d625b04faa547d8 Content-Type: text/plain; charset=UTF-8 I usually like to wait for authors defend, but I do defend. I don't think removing them is required, IMHO each of the items have advantages to the protocol, I don't see what is the problem in them from reading this ticket 41, my reply below, On Wednesday, May 28, 2014, Charlie Perkins wrote: > > Hello Lotte, > > I am O.K. with removing the RREP_ACK from the draft. There was > some discussion a while back about compatibility, but I have not > seen anyone defending the RREP_ACK in this discussion and it was > not present in the previous DYMO drafts. As RFC3561 has it this will need it as will. > > If anyone would prefer to keep RREP_ACK, then I will try to fashion > some more detailed specification for handling it, which will be > basically the way it was handled by AODV. Yes, it is easy to add details which should be details of the optional used as was in RFC3561. > > > On 4/22/2014 12:39 PM, manet issue tracker wrote: > >> #41: AckReq vs RREP_ACK >> >> In Section 13.5., the AODVv2 Draft briefly describes a mechanism called >> RREP_ACK, which seems to serve a similar purpose as the AckReqs >> described >> in section 5.2. > > I don't agree they have exactly similar effects if they were used separately or jointly. Furthermore, RREP_ACK is a message and the AckReq is not a message, so it is not correct to compare them as if they are similar items to see verses. >> While RFC 3561, which is referenced in section 13.5., explains that a >> RREP-ACK is sent when a packet with the 'A' bit set is received, the >> AODVv2 does not describe how a RREP_ACK is triggered. > > I agree that it needs to be added. > >> Additionally, the draft does not specify how a RREP_ACK should be >> handled. > > Same as to be from RFC3561. > >> If the feature of a RREP_ACK is really needed, a more thorough >> explanation >> should be added. Otherwise, removing it could be a step towards de- >> cluttering the draft. > > This RREP_ACK message is optional used as was done in RFC3561. AB --20cf30050b225d625b04faa547d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I usually like to wait for authors defend, but I do defend. I=C2=A0don'= t think removing them=C2=A0is required, IMHO=C2=A0each of the items have ad= vantages to the protocol, I don't see what is the problem in them from = reading this ticket 41,=C2=A0my reply below,

On Wednesday, May 28, 2014, Charlie Perkins wrote:

Hello Lotte,

I am O.K. with removing the RREP_ACK from the draft. =C2=A0There was
some discussion a while back about compatibility, but I have not
seen anyone defending the RREP_ACK in this discussion and it was
not present in the previous DYMO drafts.

As= RFC3561 has it this will need it as will.=C2=A0
=C2=A0

If anyone would prefer to keep RREP_ACK, then I will try to fashion
some more detailed specification for handling it, which will be
basically the way it was handled by AODV.

Y= es, it is easy to add details which should be details of the=C2=A0optional = used=C2=A0as was in RFC3561.=C2=A0
=C2=A0


On 4/22/2014 12:39 PM, manet issue tracker wrote:
#41: AckReq vs RREP_ACK

=C2=A0 In Section 13.5., the AODVv2 Draft briefly describes a mechanism cal= led
=C2=A0 RREP_ACK, which seems to serve a similar purpose as the AckReqs desc= ribed
=C2=A0 in section 5.2.

I don&#= 39;t agree they have exactly similar effects if they were used separately o= r jointly. Furthermore, RREP_ACK is a message and the AckReq is not a messa= ge, so it is not correct=C2=A0to compare them as if they are similar items = to see verses.=C2=A0


=C2=A0 Additionally, the draft does not specify how a RREP_ACK should be ha= ndled.

Same as to be from RFC3= 561.=C2=A0=C2=A0

=C2=A0 If the feature of a RREP_ACK is really needed, a more thorough expla= nation
=C2=A0 should be added. Otherwise, removing it could be a step towards de-<= br> =C2=A0 cluttering the draft.

T= his RREP_ACK message=C2=A0is optional used as was done in RFC3561.=C2=A0=C2= =A0

=C2=A0
=C2=A0AB
--20cf30050b225d625b04faa547d8-- From nobody Fri May 30 19:57:06 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DD71A06F4 for ; Fri, 30 May 2014 19:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-vv1l5ib-XN for ; Fri, 30 May 2014 19:57:01 -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 F32BE1A067F for ; Fri, 30 May 2014 19:57:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=kWomP7Lu11CSls2RJ4UopH7zobUDp3N6GX5lRISRa5rVJEZ2bCOb0hXTSdr7YP/X; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WqZTH-00070n-MN; Fri, 30 May 2014 22:56:35 -0400 Message-ID: <538944E1.1000102@earthlink.net> Date: Fri, 30 May 2014 19:56:33 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Abdussalam Baryun References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090400020908010606050305" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7de04c2c1e408d9e4e616d020159a5366350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/ocGMSDB6b1TghBSUffRq1aS6Z4E Cc: draft-ietf-manet-aodvv2@tools.ietf.org, manet@ietf.org Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 02:57:03 -0000 This is a multi-part message in MIME format. --------------090400020908010606050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Abdussalam, On 5/30/2014 3:08 PM, Abdussalam Baryun wrote: > I usually like to wait for authors defend, but I do defend. In most cases, I don't have much to defend. I want to synthesize all constructive commentary and suggestions to make a satisfactory resolution. > I don't think removing them is required, IMHO each of the items have > advantages to the protocol, I don't see what is the problem in them > from reading this ticket 41, my reply below, The case for removing RREP_ACK is to simplify the protocol. The case for including RREP_ACK is to have an AODVv2-specific mechanism and, along the way, to enable better compatibility with previous approaches. I do not have any strong preference. So far, most people seem to want to keep RREP_ACK, so for the upcoming revision I will supply additional text as needed to clarify the specification. In *general*, I don't like having redundant mechanisms, because it's confusing to explain the differences, and it's more places to put bugs in the implementation and in the specification. But that is a *general* guideline, and each case has to be judged on the claimed merits for the various approaches. A small bit of follow-up below... > > On Wednesday, May 28, 2014, Charlie Perkins wrote: > > > I am O.K. with removing the RREP_ACK from the draft. ... > > > As RFC3561 has it this will need it as will. I don't agree that presence of a feature in RFC 3561 means that the feature has to be present also in AODVv2. > > > While RFC 3561, which is referenced in section 13.5., > explains that a > RREP-ACK is sent when a packet with the 'A' bit set is > received, the > AODVv2 does not describe how a RREP_ACK is triggered. > > > I agree that it needs to be added. > > > Additionally, the draft does not specify how a RREP_ACK > should be handled. > > > Same as to be from RFC3561. > > Roughly speaking, RREP_ACK is a mechanism for managing the blacklist. Regards, Charlie P. --------------090400020908010606050305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hello Abdussalam,

On 5/30/2014 3:08 PM, Abdussalam Baryun wrote:
I usually like to wait for authors defend, but I do defend.

In most cases, I don't have much to defend.  I want to synthesize
all constructive commentary and suggestions to make a satisfactory
resolution.

I don't think removing them is required, IMHO each of the items have advantages to the protocol, I don't see what is the problem in them from reading this ticket 41, my reply below,

The case for removing RREP_ACK is to simplify the protocol.

The case for including RREP_ACK is to have an AODVv2-specific
mechanism and, along the way, to enable better compatibility
with previous approaches.

I do not have any strong preference.  So far, most people seem
to want to keep RREP_ACK, so for the upcoming revision I will
supply additional text as needed to clarify the specification.

In *general*, I don't like having redundant mechanisms, because
it's confusing to explain the differences, and it's more places to
put bugs in the implementation and in the specification.  But that
is a *general* guideline, and each case has to be judged on the
claimed merits for the various approaches.

A small bit of follow-up below...


On Wednesday, May 28, 2014, Charlie Perkins wrote:

I am O.K. with removing the RREP_ACK from the draft.  ...

As RFC3561 has it this will need it as will.

I don't agree that presence of a feature in RFC 3561 means that
the feature has to be present also in AODVv2.

 

  While RFC 3561, which is referenced in section 13.5., explains that a
  RREP-ACK is sent when a packet with the 'A' bit set is received, the
  AODVv2 does not describe how a RREP_ACK is triggered.

I agree that it needs to be added. 
 

  Additionally, the draft does not specify how a RREP_ACK should be handled.

Same as to be from RFC3561.  
 

Roughly speaking, RREP_ACK is a mechanism for managing the blacklist.


Regards,
Charlie P.

--------------090400020908010606050305-- From nobody Sat May 31 12:57:11 2014 Return-Path: X-Original-To: manet@ietfa.amsl.com Delivered-To: manet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6B91A008F for ; Sat, 31 May 2014 12:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLeqwfSFca2F for ; Sat, 31 May 2014 12:57:08 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BEF1A008E for ; Sat, 31 May 2014 12:57:08 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n15so2657672wiw.9 for ; Sat, 31 May 2014 12:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/H7dIceh0nwxBG3/HJB06e6RR3Hi3+sd2G6to2RKKAM=; b=tjYNLD9OsUO7hIxQ1FwBqUldMk8w6+lulfq5LwPkqSKRjiZrYyEuHcYDOXDso1YTaO bF69auHCyjZUKaObLpVK6pfEdkX5vcXr9hdqLXoimZg7sxHI0tQAYwkoQVkVNmun/3x9 LYzez/y209YGO5mF25txlzIXFplMP3XVkwn5geX9QEITXxTSexSbYgtfvGCmbp1zeaN+ Kpc5qEC2PeOmDqIminAxUqr6MSCctosrMNpRNUUJf90s5us66+TpYD1Cl5CIuFkiyqNn nta7+MBoSc8rhwZSxCmkXSBJiiF68jnvQPMXAmKyjlxUKF2/Efw4JyvijH0vnumRbZmL lc7Q== MIME-Version: 1.0 X-Received: by 10.180.13.139 with SMTP id h11mr8820835wic.34.1401566222646; Sat, 31 May 2014 12:57:02 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.194.118.134 with HTTP; Sat, 31 May 2014 12:57:02 -0700 (PDT) In-Reply-To: <538944E1.1000102@earthlink.net> References: <069.fc91ee99d41a5c71f95d237ce124f2e9@trac.tools.ietf.org> <53861E28.1070700@earthlink.net> <538944E1.1000102@earthlink.net> Date: Sat, 31 May 2014 21:57:02 +0200 X-Google-Sender-Auth: 3x_bMV8sRj5rK6BlgSOa-0x36U4 Message-ID: From: Jiazi YI To: Charlie Perkins Content-Type: multipart/alternative; boundary=001a11c24448d485c604fab79007 Archived-At: http://mailarchive.ietf.org/arch/msg/manet/VOGaZKulwnuDDQ682Q-Lbbn9dXc Cc: "draft-ietf-manet-aodvv2@tools.ietf.org" , manet Subject: Re: [manet] #41 (aodvv2): AckReq vs RREP_ACK X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 19:57:10 -0000 --001a11c24448d485c604fab79007 Content-Type: text/plain; charset=UTF-8 On Sat, May 31, 2014 at 4:56 AM, Charlie Perkins < charles.perkins@earthlink.net> wrote: > > The case for removing RREP_ACK is to simplify the protocol. > > The case for including RREP_ACK is to have an AODVv2-specific > mechanism and, along the way, to enable better compatibility > with previous approaches. > Maybe I missed something here. By saying "better compatibility with previous approaches", do you mean RFC 3561? Jiazi --001a11c24448d485c604fab79007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, May 31, 2014 at 4:56 AM, Charlie Perkins <= charles.= perkins@earthlink.net> wrote:
=20 =20 =20
<snip> The case for removing RREP_ACK is to simplify the protocol.

The case for including RREP_ACK is to have an AODVv2-specific
mechanism and, along the way, to enable better compatibility
with previous approaches.

<= ;snip>=C2=A0

Maybe I missed something here. By = saying "better compatibility with previous approaches", do you me= an RFC 3561?

Jiazi

--001a11c24448d485c604fab79007--