From nobody Fri May 1 04:06:49 2015 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 756211B3036 for ; Fri, 1 May 2015 04:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 js-1V9Ja2133 for ; Fri, 1 May 2015 04:06:40 -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 305B41B30F7 for ; Fri, 1 May 2015 04:06:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,350,1427756400"; d="scan'208,217";a="462856733" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 01 May 2015 12:06:37 +0100 X-IronPort-AV: E=Sophos;i="5.13,350,1427756400"; d="scan'208,217";a="100534299" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 01 May 2015 12:06:37 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.48]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Fri, 1 May 2015 12:06:36 +0100 From: "Dearlove, Christopher (UK)" To: "Alvaro Retana (aretana)" , "draft-ietf-manet-olsrv2-multitopology@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-olsrv2-multitopology Thread-Index: AQHQg112wY785zE83UyKabbZ8ayPuJ1mz9oA Date: Fri, 1 May 2015 11:06:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40ECD687GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology 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, 01 May 2015 11:06:47 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40ECD687GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Alvaro Thanks for your comments. Comments inline below. Not yet discussed with co-author. Christopher -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Alvaro Retana (are= tana) Sent: 30 April 2015 16:51 To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org Cc: manet@ietf.org Subject: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology *** WARNING *** This message originates from outside our organisation, either from an exter= nal partner or the internet. Consider carefully whether you should click on any links, open any attachme= nts or reply. For information regarding Red Flags that you can look out for in emails you= receive, click here. If you feel the email is suspicious, please follow this process. Hi! I have some concerns about the operation in a mixed environment of MT-OLSRv= 2 and non-MT-OLSRv2 routers as explained in Sections 4 and 12. In short, = the operation in a mixed environment needs to at least be clarified probabl= y using stronger language in some places, but there may be some parts where= it has to be rethought (see my comments below). It may be beneficial to h= ave a live conversation about this topic as it may be slower through e-mail= (and it may be that I need help seeing things clearer) - if you want to, p= lease give me some options and we'll then summarize for the list. I would like to have at least an agreement from the authors about the path = forward before starting the IETF Last Call. Thanks! Alvaro. Major: 1. Section 3. "It is assumed, but outside the scope of this specificatio= n, that the network layer is able to choose which topology to use for each = packet...This selection of topology must be consistent, ...This is necessar= y to avoid the possibility of a packet "looping" in the network." While ho= w the selection is done may be out of scope, being a little stronger about = the need for consistency (s/must/MUST) would be nice. I suspect that we didn't use MUST as that was outside this protocol. But I= have no problem with this being a MUST. 1. Sections 4 and 12. 4 reads: "..the single link metric used by these = non-MT-OLSRv2 routers must be included in the set of link metrics for each = OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 inte= rface of a non-MT-OLSRv2 router in the MANET", and then 12 adds "Note that = if there is any possibility that there are any routers not implementing MT-= OLSRv2, then the MANET will be connected, to the maximum extent possible, u= sing the link metric type LINK_METRIC_TYPE." I would think that there is = always a possibility that non-MT-OLSRv2 routers exist..does this then mean = that the only metric type would be LINK_METRIC_TYPE everywhere? I guess th= at theoretically you can constrain the movement of nodes so that they only = may be present in a subset of the MANET, but their existence in a network = (as characterized: "any possibility that there are any routers not implemen= ting MT-OLSRv2") would then seem to cause a specific behavior. First, I don't agree that there will always be the possibility of non-MT no= des. Plenty of MANETs will be closed systems (cryptographically enforced ev= en) and then we will have complete control over whether there are non-MT no= des. So that is a real case. But so also is the mixed case, so we need to handle that (if we didn't, we'= d have a different design). Yes, with the mixed case, the only metric is that type. Which means that on= ly packets that use that metric type are universally transportable and deli= verable. That poses two issues. The first is whether the network is connect= ed using the MT-only nodes. You note one possibility, location/movement res= triction. There are at least two more: a dense network so that the MT nodes= themselves are sufficient, and where MT nodes are most of the nodes. I can= see use cases in the latter two cases. The second is that some nodes can't receive packets of those additional typ= es. Again I can see use cases. If packets are from high capacity streams th= en no use going to nodes that can't handle those. There could also be a use= to separate different levels of trust (though that has some implications o= n revealing that). I'm sure there are others. 1. Section 12: Related to the consistency in making forwarding decisions= , the text in the last bullet implies that different topologies may be used= to forward a packet in some cases. Even though you also wrote that "All = routers must make the same decision for the same packet." * For example, "..then routing may work if the first router implemen= ting MT-OLSRv2 to receive the packet supports the appropriate link metric t= ype". Just saying that "routing may work" doesn't provide a lot of confide= nce. What about the other routers in the path? Didn't you say before that= the topology selection must be consistent? How do you prevent looping if = the topology used in the first couple of hops may not exist elsewhere? * "If such a router is the destination, then the packet will never r= each its destination, as the source will not have a suitable routing table = entry for the destination. Network management may be required to ensure th= at the MANET still functions in these cases." How would network management= ensure that the MANET still works? The obvious answer is to ensure that t= he "base topology" exist everywhere, which goes back to my question above a= bout using the link metric type LINK_METRIC_TYPE everywhere. I (we) clearly need to look at those sections. The rules is clear, you can = only forward packets consistently. I think that those points are really mea= nt to address cases that shouldn't happen (what if you address a packet to = someone who can't receive it?) and should probably be clearer that the role= of management is to prevent the wasted resources of partly doing that. Tha= t said, right this second (when I haven't re-read that text in detail) I'm = not sure when that happens. I think the principles should be: first, forwarding restrictions to prevent= looping. Second, given how things are, manage what you try to do so as to = not waste resources on what isn't going to work. Third, try to organise thi= ngs so that you aren't in that position. In that order. 1. Section 4: "If all routers in the MANET implement MT-OLSRv2, then the= re are no restrictions on how these sets of link metrics are selected." Is= n't a minimum restriction the fact that they should somehow be consistent a= cross interfaces? If not then the packets will either not reach their dest= ination or be forwarded using different topologies. I think here we have two different levels being considered. This is conside= ring what the restrictions are within the protocol. You're considering oper= ational considerations of what you deploy. We can make that clearer. Conceptually, his is nothing new. Without MT we can build a MANET using two= frequencies, equip some nodes to use A, some to use B and some to use A an= d B. We use the multi-interface capabilities of OLSRv2. It's all legal OLSR= v2. It also won't work if you do it badly (in particular not enough dual ch= annel nodes). We need to sensibly equip and deploy. That's true here (thoug= h the rules aren't the same). Minor: 1. For clarity while others review it, please change "RFC XXXX" to the d= raft-ietf-manet-tlv-naming reference. The RFC Editor should take care of f= ixing the references. XXXX appears in just two places, one is the top left of the document, the o= ther matches it in the abstract. Neither is a reference, and we can't do th= at in the top left one. 1. Section 1.1 "This specification is published to facilitate collecting= such experience, with the intent that in a reasonable period of time after= the acceptance of this specification as an Experimental RFC (as soon as po= ssible after experimental evidence is collected), an OLSRv2 Multi-Topology = Routing Extension will be proposed for advancement onto Standards Track." = How long are a "reasonable period" and "as soon as possible"? I understand= what the intent is here, defining the experiment in terms of collection of= experience is fine, but bounding it with ill-defined (and prone to all kin= ds of interpretation) terms doesn't help anyone. I would rather you focus = on what you want to do (collect experience) and then we can think about cha= nging the status whenever we're ready to do so. If I read this correctly, you're saying take out the reasonable length of t= ime and as soon as possible phrases and just say after stuff is done. Fine = by me. Thomas, can you shed any light here since you know people using this? Nits: 1. Section 1. s/However in some MANETs it would be desirable to be route= packets/However in some MANETs it would be desirable to be able to route p= ackets Thanks. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40ECD687GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Alvaro<= /p>

 <= /p>

Thanks for your comments.=

 <= /p>

Comments inline below. No= t yet discussed with co-author.

 <= /p>

Christopher

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
____________________________________= ______________________________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 

 <= /p>

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Alvaro Retana (aretana)
Sent: 30 April 2015 16:51
To: draft-ietf-manet-olsrv2-multitopology@tools.ietf.org
Cc: manet@ietf.org
Subject: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology<= o:p>

 

 

*** WARNING ***=

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.

Hi!

 

I have some concerns about = the operation in a mixed environment of MT-OLSRv2  and non-MT-OLSRv2 r= outers as explained in Sections 4 and 12.  In short, the operation in a mixed environment needs to at least be clarified probably using = stronger language in some places, but there may be some parts where it has = to be rethought (see my comments below).  It may be benefici= al to have a live conversation about this topic as it may be slower through e-mail (and it may be that I need help seeing t= hings clearer) — if you want to, please give me some options and we&#= 8217;ll then summarize for the list.

 

I would like to have a= t least an agreement from the authors about the path forward before startin= g the IETF Last Call.

 

Thanks!

 

Alvaro.

 

 

Major:

  1. Section 3. "It is assumed, but outside the scope of = this specification, that the network layer is able to choose which top= ology to use for each packet…This selection of topology must be = consistent, …This is necessary to avoid the possibility of a packet "looping"= in the network.”  While how the selection is done may be out of= scope, being a little stronger about the need for consistency (s/must= /MUST) would be nice.

I suspect that we didn’t use MUST= as that was outside this protocol.  But I have no problem with this being a MUST.

  1. Sections 4 and 12.  4 reads: “..the single lin= k metric used by these non-MT-OLSRv2 routers must be included in the s= et of link metrics for each OLSRv2 interface of an MT-OLSRv2 router th= at may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANE= T”, and then 12 adds "Note that if there is any possibility= that there are any routers not implementing MT-OLSRv2, then the MANET= will be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE.”   I would thi= nk that there is always a possibility that non-MT-OLSRv2 routers exist..doe= s this then mean that the only metric type would be LINK_METRIC_T= YPE everywhere?  I guess that theoretically you can constrain the movement of nodes so that they only may be  present in a subset of th= e MANET, but their existence in a network (as characterized: "any poss= ibility that there are any routers not implementing MT-OLSRv2”) would= then seem to cause a specific behavior.   

First, I don’t agree that there w= ill always be the possibility of non-MT nodes. Plenty of MANETs will be closed systems (cryptographically enforced even) and then we will = have complete control over whether there are non-MT nodes. So that is a rea= l case.

But so also is the mixed case, so we ne= ed to handle that (if we didn’t, we’d have a different design).=

Yes, with the mixed case, the only metr= ic is that type. Which means that only packets that use that metric type are universally transportable and deliverable. That poses two = issues. The first is whether the network is connected using the MT-only nod= es. You note one possibility, location/movement restriction. There are at l= east two more: a dense network so that the MT nodes themselves are sufficient, and where MT nodes are most o= f the nodes. I can see use cases in the latter two cases.=

The second is that some nodes can’= ;t receive packets of those additional types. Again I can see use cases. If packets are from high capacity streams then no use going to node= s that can’t handle those. There could also be a use to separate diff= erent levels of trust (though that has some implications on revealing that)= . I’m sure there are others.

  1. Section 12: Related to the consistency in making&n= bsp;forwarding decisions, the text in the last bullet implies that differen= t topologies may be used to forward a packet in some cases.  Even though you also wrote  that "All routers must ma= ke the same decision for the same packet."
    • For example, “..then routing may work if the f= irst router implementing MT-OLSRv2 to receive the packet supports the = appropriate link metric type”.  Just saying that “rou= ting may work” doesn’t provide a lot of confidence.  What about the other routers in the pat= h?  Didn’t you say before that the topology selection must be co= nsistent?  How do you prevent looping if the topology used in the firs= t couple of hops may not exist elsewhere?
    • "If such a router is the destination, then the packet wil= l never reach its destination, as the source will not have a suitable&= nbsp;routing table entry for the destination.  Network management = ;may be required to ensure that the MANET still functions in these cases.&= #8221;  How would network management ensure that the MANET still works= ?  The obvious answer is to ensure that the “base topology&= #8221; exist everywhere, which goes back to my question above about us= ing the link metric type LINK_METRIC_TYPE everywhere.

I (we) clearly need to look at those se= ctions. The rules is clear, you can only forward packets consistently. I think that those points are really meant to address cases that shouldn&#= 8217;t happen (what if you address a packet to someone who can’t rece= ive it?) and should probably be clearer that the role of management is to p= revent the wasted resources of partly doing that. That said, right this second (when I haven’t re-read that text= in detail) I’m not sure when that happens.

I think the principles should be: first= , forwarding restrictions to prevent looping. Second, given how things are, manage what you try to do so as to not waste resources on = what isn’t going to work. Third, try to organise things so that you a= ren’t in that position. In that order.

  1. Section 4: "If all routers in the MANET implement MT= -OLSRv2, then there are no restrictions on how these sets of link metr= ics are selected.”  Isn’t a minimum restriction the fact t= hat they should somehow be consistent across interfaces?  If not then the packets wil= l either not reach their destination or be forwarded using different topolo= gies.

I think here we have two different leve= ls being considered. This is considering what the restrictions are within the protocol. You’re considering operational consideratio= ns of what you deploy. We can make that clearer.

Conceptually, his is nothing new. Witho= ut MT we can build a MANET using two frequencies, equip some nodes to use A, some to use B and some to use A and B. We use the multi-in= terface capabilities of OLSRv2. It’s all legal OLSRv2. It also won= 217;t work if you do it badly (in particular not enough dual channel nodes)= . We need to sensibly equip and deploy. That’s true here (though the rules aren’t the same).

 

Minor:

  1. For clarity while others review it, please change “RFC X= XXX” to the draft-ietf-manet-tlv-naming reference.  The RFC Edit= or should take care of fixing the references.

XXXX appears in just two places, one is= the top left of the document, the other matches it in the abstract. Neither is a reference, and we can’t do that in the top le= ft one.

  1. Section 1.1 "This specification is published to faci= litate collecting such experience, with the intent that in a reasonabl= e period of time after the acceptance of this specification as an Expe= rimental RFC (as soon as possible after experimental evidence is collected), a= n OLSRv2 Multi-Topology Routing Extension will be proposed for advance= ment onto Standards Track.”  How long are a “reasonab= le period” and “as soon as possible”?  I unders= tand what the intent is here, defining the experiment in terms of collection of experience is f= ine, but bounding it with ill-defined (and prone to all kinds of interpreta= tion) terms doesn’t help anyone.  I would rather you focus on wh= at you want to do (collect experience) and then we can think about changing the status whenever we’re ready to = do so.

If I read this correctly, you’re = saying take out the reasonable length of time and as soon as possible phrases and just say after stuff is done. Fine by me. Thomas, can you shed= any light here since you know people using this?

Nits:

  1. Section 1. s/However in some MANETs it would be desirable to b= e route packets/However in some MANETs it would be desirable to be able to = route packets

Thanks.

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40ECD687GLKXM0002VGREEN_-- From nobody Fri May 1 08:39:31 2015 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 838B31A1C04 for ; Fri, 1 May 2015 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zXB4HKYQA2Ta for ; Fri, 1 May 2015 08:39:28 -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 DE47C1A01CB for ; Fri, 1 May 2015 08:39:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1430494767; x=1431704367; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=etxAZwJxHkhmXVQmLFKXjO+IIBdjvOS5lba6gGXeyfE=; b=IgYN8m5gzQHIbqcKb2ZDLCa0NjOe/6r2I82HRDj1Ckh12ga/7E4C8EUl BjvppU9vMiFlQWACV+Wu8alKRr7taCAaQPjl87xB3gqVlsaWjqRr+FbqY dwXCaExAIyNJ6zmTiQ1k9BMctm6VatixSrRDGUS/SQbaI2apu8mefmJHV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQBQBbnUNV/5JdJa1cFoJ2U1wFx0AKhTZOAoFaTAEBAQEBAYELhCEBAQQBAQE3NBsCAQgkEgkHJwsUBwEGAwIEExSIFw3HEgEBAQEBAQQBAQEBAQEBARqLOIUMhC0FkW+ECoZAgSM9gw6JYYNeg1AjYIMUbwGBQ4EBAQEB X-IronPort-AV: E=Sophos;i="5.13,350,1427760000"; d="scan'208";a="413214253" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP; 01 May 2015 15:39:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t41FdRfa010565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 May 2015 15:39:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.36]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 1 May 2015 10:39:26 -0500 From: "Charles Eckel (eckelcu)" To: "manet@ietf.org" Thread-Topic: [hackathon] RIOT@IETF 93 Hackathon Thread-Index: AQHQg4nsg0J+QYGuz0eQ9YK+5mvqPZ1nIWWA Date: Fri, 1 May 2015 15:39:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.81.226] Content-Type: text/plain; charset="us-ascii" Content-ID: <16364074531ED7449590AF21A5C1C9BE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [manet] FW: [hackathon] RIOT@IETF 93 Hackathon 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, 01 May 2015 15:39:29 -0000 FYI, There will be an IETF Hackathon in Prague, July 18-19. We are in the process of determining the set of technologies included and are using hackathon@ietf.org for all discussions related to the hackathon. I thought this working group might be interested to work with RIOT and related technologies at the hackathon. If so, please subscribe the list (https://www.ietf.org/mailman/listinfo/hackathon) and participate in the discussions there. Cheers, Charles On 4/30/15, 1:02 PM, "Matthias Waehlisch" wrote: >Hi Charles, all, > > several people from the RIOT community (http://www.riot-os.org) will >attend the upcoming IETF meeting and are pleased to work on IETF-related >topics during the Hackathon. We plan to give an introduction to RIOT >such that non-RIOTers can easily start with implementing their own ideas >on this operating system for constrained devices. > > So far we have the following champions assigned to topics: > > (1) Lotte Steenbrink: update of AODVv2 (see draft-ietf-manet-aodvv2) > =20 > (2) Hauke Petersen: CoAP for service discovery in the IoT (see >draft-jimenez-p2psip-coap-reload) > > (3) Martine Lenders: general IoT network stack and boarder gateway >between the IoT and current Internet > > (4) Kaspar Schleiser: ICN > > > Anybody who is interested in working on these topics is more than >welcome to join! If you have your own topic and want to implement this >on RIOT, let us know in advance and we will tailor introduction etc. > > > >Thanks > matthias > >--=20 >Matthias Waehlisch >. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST >. Takustr. 9, D-14195 Berlin, Germany >.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl >:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net > >_______________________________________________ >hackathon mailing list >hackathon@ietf.org >https://www.ietf.org/mailman/listinfo/hackathon From nobody Fri May 1 14:00:39 2015 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 CDA0E1B2E4F for ; Fri, 1 May 2015 14:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.21 X-Spam-Level: X-Spam-Status: No, score=-12.21 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, MANGLED_LIST=2.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 E-BvSH-hqcwB for ; Fri, 1 May 2015 14:00:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1B0E1B2E11 for ; Fri, 1 May 2015 14:00:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24400; q=dns/txt; s=iport; t=1430514033; x=1431723633; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rK3DDBnXWUzICTXZWZ/EBEJdCRVBkT9QB+OdSdIMZXs=; b=f+y62c64ZtQ/xDuKLbgzwsU1Ne4Q5gFj4MnIpMtY9NLLSdXiBUcPQ/iG hg3nLsfp9qlFlzFUp85sIxsLVtT1NfDOw7W7Mo4/TXqeIPaeGVT/+VGII RXBkGtvqgKeK9J2FUOw1bkn1gyTSfn/6tERRlX5KbI6FH/Yaj37WPK4nt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BPBAA/6ENV/5RdJa1cgkVHU1wFxUwJh1gCgVM4FAEBAQEBAQGBCoQhAQEEeRACAQg4BwcyFBECBAENBR+IDMccAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s4hQUHhC0Fj0uCJIZPg3uBI4Y8jh4jgWUiHIFRb4FEgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,352,1427760000"; d="scan'208,217";a="146384840" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 01 May 2015 21:00:32 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t41L0WMf026375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 May 2015 21:00:32 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.76]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Fri, 1 May 2015 16:00:32 -0500 From: "Alvaro Retana (aretana)" To: "Dearlove, Christopher (UK)" , "draft-ietf-manet-olsrv2-multitopology@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-olsrv2-multitopology Thread-Index: AQHQg112wY785zE83UyKabbZ8ayPuJ1mz9oAgADd44A= Date: Fri, 1 May 2015 21:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D1695E2DABB95aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] AD Review of draft-ietf-manet-olsrv2-multitopology 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, 01 May 2015 21:00:38 -0000 --_000_D1695E2DABB95aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 5/1/15, 7:06 AM, "Dearlove, Christopher (UK)" > wrote: Christopher: Hi! . . . 1. Sections 4 and 12. 4 reads: =93..the single link metric used by thes= e non-MT-OLSRv2 routers must be included in the set of link metrics for eac= h OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 in= terface of a non-MT-OLSRv2 router in the MANET=94, and then 12 adds "Note t= hat if there is any possibility that there are any routers not implementing= MT-OLSRv2, then the MANET will be connected, to the maximum extent possibl= e, using the link metric type LINK_METRIC_TYPE.=94 I would think that the= re is always a possibility that non-MT-OLSRv2 routers exist..does this then= mean that the only metric type would be LINK_METRIC_TYPE everywhere? I gu= ess that theoretically you can constrain the movement of nodes so that they= only may be present in a subset of the MANET, but their existence in a ne= twork (as characterized: "any possibility that there are any routers not im= plementing MT-OLSRv2=94) would then seem to cause a specific behavior. First, I don=92t agree that there will always be the possibility of non-MT = nodes. Plenty of MANETs will be closed systems (cryptographically enforced = even) and then we will have complete control over whether there are non-MT = nodes. So that is a real case. Yes. I think that the text needs to tightened so that it doesn=92t talk ab= out =93any possibility=94, but characterizes better the fact that in many n= etworks non-MT nodes won=92t be present. Maybe the text should be more alo= ng the lines of =93if present=94=85 But so also is the mixed case, so we need to handle that (if we didn=92t, w= e=92d have a different design). Yes, with the mixed case, the only metric is that type. Which means that on= ly packets that use that metric type are universally transportable and deli= verable. That poses two issues. The first is whether the network is connect= ed using the MT-only nodes. You note one possibility, location/movement res= triction. There are at least two more: a dense network so that the MT nodes= themselves are sufficient, and where MT nodes are most of the nodes. I can= see use cases in the latter two cases. The second is that some nodes can=92t receive packets of those additional t= ypes. Again I can see use cases. If packets are from high capacity streams = then no use going to nodes that can=92t handle those. There could also be a= use to separate different levels of trust (though that has some implicatio= ns on revealing that). I=92m sure there are others. Again, it would be good to include this type of discussion. This second possibility doesn=92t make me feel too good. On one hand, we c= ould say that it is just too bad that these nodes can=92t receive some of t= he traffic..but on the other, what if they need to? This is related to the= comment below about the NMS having to make sure the network works.. 1. Section 12: Related to the consistency in making forwarding decisions= , the text in the last bullet implies that different topologies may be used= to forward a packet in some cases. Even though you also wrote that "All = routers must make the same decision for the same packet." * For example, =93..then routing may work if the first router implem= enting MT-OLSRv2 to receive the packet supports the appropriate link metric= type=94. Just saying that =93routing may work=94 doesn=92t provide a lot = of confidence. What about the other routers in the path? Didn=92t you say= before that the topology selection must be consistent? How do you prevent= looping if the topology used in the first couple of hops may not exist els= ewhere? * "If such a router is the destination, then the packet will never r= each its destination, as the source will not have a suitable routing table = entry for the destination. Network management may be required to ensure th= at the MANET still functions in these cases.=94 How would network manageme= nt ensure that the MANET still works? The obvious answer is to ensure that= the =93base topology=94 exist everywhere, which goes back to my question a= bove about using the link metric type LINK_METRIC_TYPE everywhere. I (we) clearly need to look at those sections. The rules is clear, you can = only forward packets consistently. I think that those points are really mea= nt to address cases that shouldn=92t happen (what if you address a packet t= o someone who can=92t receive it?) and should probably be clearer that the = role of management is to prevent the wasted resources of partly doing that.= That said, right this second (when I haven=92t re-read that text in detail= ) I=92m not sure when that happens. I think the principles should be: first, forwarding restrictions to prevent= looping. Second, given how things are, manage what you try to do so as to = not waste resources on what isn=92t going to work. Third, try to organise t= hings so that you aren=92t in that position. In that order. Right. Again, some more text clarifying would be helpful. As is, the text= gives the impression that you=92re talking about the general case, where e= xplaining a little about destinations not on a specific topology and how th= ey can=92t possibly be reachable (for example) would go a long way. 1. Section 4: "If all routers in the MANET implement MT-OLSRv2, then the= re are no restrictions on how these sets of link metrics are selected.=94 = Isn=92t a minimum restriction the fact that they should somehow be consiste= nt across interfaces? If not then the packets will either not reach their = destination or be forwarded using different topologies. I think here we have two different levels being considered. This is conside= ring what the restrictions are within the protocol. You=92re considering op= erational considerations of what you deploy. We can make that clearer. Thanks! In the end I think the text just needs some clarification. . . . 1. Section 1.1 "This specification is published to facilitate collecting= such experience, with the intent that in a reasonable period of time after= the acceptance of this specification as an Experimental RFC (as soon as po= ssible after experimental evidence is collected), an OLSRv2 Multi-Topology = Routing Extension will be proposed for advancement onto Standards Track.=94= How long are a =93reasonable period=94 and =93as soon as possible=94? I = understand what the intent is here, defining the experiment in terms of col= lection of experience is fine, but bounding it with ill-defined (and prone = to all kinds of interpretation) terms doesn=92t help anyone. I would rathe= r you focus on what you want to do (collect experience) and then we can thi= nk about changing the status whenever we=92re ready to do so. If I read this correctly, you=92re saying take out the reasonable length of= time and as soon as possible phrases and just say after stuff is done. Fin= e by me. Yes. I think we have a path forward: make the text clearer (specially in section= s 4 and 12). I=92ll go ahead and issue the IETF Last Call. Thanks! Alvaro. --_000_D1695E2DABB95aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 5/1/15, 7:06 AM, "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com= > wrote:

Christopher:

Hi!

. . .


  1. Sectio= ns 4 and 12.  4 reads: =93..the single link metric used by these = non-MT-OLSRv2 routers must be included in the set of link metrics for = each OLSRv2 interface of an MT-OLSRv2 router that may be heard on an OLSRv2 interface of a non-MT-OLSRv2 router in the MANE= T=94, and then 12 adds "Note that if there is any possibility tha= t there are any routers not implementing MT-OLSRv2, then the MANET wil= l be connected, to the maximum extent possible, using the link metric type LINK_METRIC_TYPE.=94   I would think t= hat there is always a possibility that non-MT-OLSRv2 routers exist..does th= is then mean that the only metric type would be LINK_METRIC_TYPE = everywhere?  I guess that theoretically you can constrain the movement of nodes so that they only may be  present in a subset of th= e MANET, but their existence in a network (as characterized: "any poss= ibility that there are any routers not implementing MT-OLSRv2=94) would the= n seem to cause a specific behavior.   

    2. First, I don=92t agree that there will always be = the possibility of non-MT nodes. Plenty of MANETs will be closed systems (cryptographically enforced even) and the= n we will have complete control over whether there are non-MT nodes. So tha= t is a real case.

Yes.  I think that the text needs to tightened so that it doesn= =92t talk about =93any possibility=94, but characterizes better the fact th= at in many networks non-MT nodes won=92t be present.  Maybe the text s= hould be more along the lines of =93if present=94=85

But so also is the mixed case, so we need to hand= le that (if we didn=92t, we=92d have a different design).

Yes, with the mixed case, the only metric is that= type. Which means that only packets that use that metric type are universally transportable and deliverable. That p= oses two issues. The first is whether the network is connected using the MT= -only nodes. You note one possibility, location/movement restriction. There= are at least two more: a dense network so that the MT nodes themselves are sufficient, and where MT nodes= are most of the nodes. I can see use cases in the latter two cases.

The second is that some nodes can=92t receive pac= kets of those additional types. Again I can see use cases. If packets are from high capacity streams then no use g= oing to nodes that can=92t handle those. There could also be a use to separ= ate different levels of trust (though that has some implications on reveali= ng that). I=92m sure there are others.

Again, it would be good to include this type of discussion.

This second possibility doesn=92t make me feel too good.  On one = hand, we could say that it is just too bad that these nodes can=92t receive= some of the traffic..but on the other, what if they need to?  This is= related to the comment below about the NMS having to make sure the network works..

  1. Section 12: Related to the consistency in making forwarding de= cisions, the text in the last bullet implies that different topologies= may be used to forward a packet in some cases.  Even though you also wrote  that "All routers must ma= ke the same decision for the same packet."
    • For ex= ample, =93..then routing may work if the first router implementin= g MT-OLSRv2 to receive the packet supports the appropriate link metric= type=94.  Just saying that =93routing may work=94 doesn=92t provide a lot of confidence.  What about the other routers in the pat= h?  Didn=92t you say before that the topology selection must be consis= tent?  How do you prevent looping if the topology used in the first co= uple of hops may not exist elsewhere?
    • "= If such a router is the destination, then the packet will never reach = its destination, as the source will not have a suitable routing table = entry for the destination.  Network management may be required to ensure that the MANET still functions in these cases.= =94  How would network management ensure that the MANET still works? &= nbsp;The obvious answer is to ensure that the =93base topology=94 exis= t everywhere, which goes back to my question above about using the link metric type LINK_METRIC_TYPE everywhere.

I (we) clearly need to look at those sections. Th= e rules is clear, you can only forward packets consistently. I think that those points are really meant to addres= s cases that shouldn=92t happen (what if you address a packet to someone wh= o can=92t receive it?) and should probably be clearer that the role of mana= gement is to prevent the wasted resources of partly doing that. That said, right this second (when I haven=92t re-re= ad that text in detail) I=92m not sure when that happens.=

I think the principles should be: first, forwardi= ng restrictions to prevent looping. Second, given how things are, manage what you try to do so as to not waste resourc= es on what isn=92t going to work. Third, try to organise things so that you= aren=92t in that position. In that order.

Right.  Again, some more text clarifying would be helpful.  = As is, the text gives the impression that you=92re talking about the genera= l case, where explaining a little about destinations not on a specific topo= logy and how they can=92t possibly be reachable (for example) would go a long way.

  1. Sectio= n 4: "If all routers in the MANET implement MT-OLSRv2, then there= are no restrictions on how these sets of link metrics are selected.= =94  Isn=92t a minimum restriction the fact that they should somehow be consistent across interfaces?  If not then the packets wil= l either not reach their destination or be forwarded using different topolo= gies.

I think here we have two different levels being c= onsidered. This is considering what the restrictions are within the protocol. You=92re considering operational con= siderations of what you deploy. We can make that clearer.

Thanks!  In the end I think the text just needs some clarificatio= n.

. . .


  1. Sectio= n 1.1 "This specification is published to facilitate collecting s= uch experience, with the intent that in a reasonable period of time af= ter the acceptance of this specification as an Experimental RFC (as soon as possible after experimental evidence is collected), a= n OLSRv2 Multi-Topology Routing Extension will be proposed for advance= ment onto Standards Track.=94  How long are a =93reasonable perio= d=94 and =93as soon as possible=94?  I understand what the intent is here, defining the experiment in terms of collection of experience is f= ine, but bounding it with ill-defined (and prone to all kinds of interpreta= tion) terms doesn=92t help anyone.  I would rather you focus on what y= ou want to do (collect experience) and then we can think about changing the status whenever we=92re ready to do s= o.

If I read this correctly, you=92re saying take ou= t the reasonable length of time and as soon as possible phrases and just say after stuff is done. Fine by me. <= /p>


Yes.


I think we have a path forward: make the text clearer (specially in se= ctions 4 and 12).

I=92ll go ahead and issue the IETF Last Call.

Thanks!

Alvaro.
--_000_D1695E2DABB95aretanaciscocom_-- From nobody Fri May 1 14:22:10 2015 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 C39F01A01F0; Fri, 1 May 2015 14:22:07 -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, 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 Pjs3r7qQfwi2; Fri, 1 May 2015 14:22:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6251A0099; Fri, 1 May 2015 14:22:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150501212206.22977.57032.idtracker@ietfa.amsl.com> Date: Fri, 01 May 2015 14:22:06 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] Last Call: (Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Experimental RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:22:08 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Multi-Topology Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2)' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification describes an extension to the Optimized Link State Routing Protocol version 2 (OLSRv2) to support multiple routing topologies, while retaining interoperability with OLSRv2 routers that do not implement this extension. This specification updates RFC 7181 by creating an interoperable extension to it. This specification updates RFC 7188 and RFC XXXX by modifying and extending TLV registries and descriptions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun May 3 02:59:11 2015 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 D7A5B1A0174 for ; Sun, 3 May 2015 02:59:08 -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 JxjxY0Dm0xXn for ; Sun, 3 May 2015 02:59:06 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE7B31A0196 for ; Sun, 3 May 2015 02:59:05 -0700 (PDT) Received: by widdi4 with SMTP id di4so92604642wid.0 for ; Sun, 03 May 2015 02:59:04 -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=OAP1a/MgoTXUTNs9ouoPJJO9cH29LRKnQGu8TUwBCyI=; b=UO7+7u3umoYQVpX94p9A5HCvyS2RMlKz8z21N5/uSCstxejrT1vgZHU8GmsDjdvWAw E3C1/XgTeUZY499q5vqwJqYzehTwREH+WHUu1zWIxEKuBeVYZTKzRcBQ9cvhpOqd9X3c jmLo3AAU0vWKYb1Q/drWxBSPonvEa24j+elbTTnihcroBeSAabqaiRyshJ5erDbDeywS bU6FRNorOmMCFk1qLC2CzPuEbwfj0LXrKDuh92Bd0E4LcyFlnn74UFczbnhYFCnWtCoT f17mtq4TpvUwOHJ0LwE0RjgWSKdgK5VGeMKjh6GQugCLMtWVUzH9VoGFPYcHtjeRNytR Y64A== MIME-Version: 1.0 X-Received: by 10.194.121.38 with SMTP id lh6mr32075962wjb.2.1430647144273; Sun, 03 May 2015 02:59:04 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.226.139 with HTTP; Sun, 3 May 2015 02:59:04 -0700 (PDT) In-Reply-To: <5516C0C2.80401@tu-dresden.de> References: <5516C0C2.80401@tu-dresden.de> Date: Sun, 3 May 2015 11:59:04 +0200 X-Google-Sender-Auth: 63g1lXcqPdh43mxnKSFxex1eDMw Message-ID: From: Jiazi YI To: Frank Fitzek Content-Type: multipart/alternative; boundary=089e01177917d55d8f05152a7e40 Archived-At: Cc: manet Subject: Re: [manet] my olsrv2-multipath notes 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, 03 May 2015 09:59:09 -0000 --089e01177917d55d8f05152a7e40 Content-Type: text/plain; charset=UTF-8 Hi, I'm not an expert in network coding, but it is surely a very interesting combination with multi-path routing. I'm not sure I'll be in Prague or not yet -- but in any case, I would be glad to continue the discussion. btw, I tried several times to subscribe to the list of network coding research group (nwcrg), but never get the confirmation. So I'm CCing Brian also :) Is any action required from the list moderator? best Jiazi On Sat, Mar 28, 2015 at 3:54 PM, Frank Fitzek wrote: > Dear all, > > I am very pleased to see multi path support for MANET coming. I have > attend some of the last meetings of MANET and intend to come to Prague and > I would be happy to hear more about the multi path initiative. > > My reasearch group has a strong interest in coding for multi path MANET. > We already used network coding for the BATMAN routing protocol (single > route), but see even more potential for multi path approaches (where each > path is composed out of multi hops). > > In case you are not familiar with network coding, here a small example why > it will impact any multi hop system. > > Consider the following topology with one source S sending to the > destination D over three hops with different error probabilities > > S <--- e1 ---> R1 <--- e2 ---> R2 <--- e3 ---> D > > A standard FEC end to end code would need to send enough packets for a > COMBINED error 1 - (1-e1)(1-e2)(1-e3). Here S is doing the endcoding, and D > the decoding. > > If we use network coding and allow the relays to recode, the combined > error is just 1 - min((1-e1);(1-e2);(1-e3). This means the performance is > determined by the worst performing hop but not the full chain. Therefore > less packets are used for such a system. > > For multipath we get even bigger gains, but they are harder to describe > here in a short email. > > Maybe you find this interesting and we can talk about this here on the > mailing list or in Prague. > > All the best > FF > > > > Am 28.03.2015 um 00:52 schrieb Jiazi YI: > > Dear Justin, > > Thanks very much for your comments, please check inline: > > >> >> Bullet point in introduction regarding FEC coding isn't fully correct. >> Multi-path can help FEC encoding but isn't a requirement (packets can get >> lost in all sorts of ways and in all kinds of distributions). FEC coding >> can work with ANY of them and work, provided the code aligns to the loss >> patterns. Having multiple paths can help select a better encoding for >> better performance but it's not a requirement. >> > > We didn't mean to say that FEC requires multi-path routing. Maybe "The > single path routing is not adapted " used is too strong. We will rephrase > it. > > > >> >> In the applicability statement it's mentioned that no new messages are >> introduced to OLSRv2 which is true but misleading as message tlv types are >> introduced and required. This should also be stated at this time or >> earlier. Some mention of source route headers being applied to each packet >> also needs to happen here along with the appropriate RFC references >> (RFC0791 and RFC6554) >> > > Yes, agree. > > >> >> Protocol Overview and Functioning section needs a little bit of >> reorganizing. Here is how I would do it: OLSRv2 and NHDP are used >> with TLVs added to messages, identifying MP-OLSRv2 functionality. >> Multi-path routes are invoked on demand. Multi-path algorithms choices. >> Source routing headers are used based on these multiple paths. >> > > Agree. > > >> >> HELLO and TC messages section. Some mention of WHY TLVs are required >> should be done (i.e. if you add an address of an OLSRv2 only router in a >> source route header you're gonna have a bad time) >> > > Will do. > > >> >> HELLO and TC Message Generation: change "is" to "MUST be" A single >> Message-Type-Specific TLV with Type := MP_OLSRv2 MUST be added to the >> message....actually the TLV only needs to be added if the router is willing >> to participate in the source routing. There is nothing broken with a non >> MP-OLSRv2 (plain OLSRv2) router from implementing the source routing when >> other MP-OLSRv2 routers exist. Should this be allowed? I say yes but then >> more clarity is needed on what is appropriate and what isn't. >> > > We will clarify it in the next revision. > > >> >> Multi-path Dijkstra Algorithm: As this is an experimental protocol and >> the algorithm choice doesn't effect any functionality of other parts of the >> network I think it would be appropriate to have a default method but allow >> for other algorithm choices. The requirements if any and likely good >> quality of what paths an algorithm selects should be presented. >> > > It's a good point. We will have the multipath-dijkstra algorithm as the > default algorithm, and also allow other alternatives. Different approaches > of the multipath computing can be an experiment point also. > > >> >> Security Considerations should also reference source forwarding >> security documents not just manet related security documents. >> > > Yes. I'm thinking about having the Security Consideration section of RFC > 6554 (An IPv6 Routing Header for Source Routes with the Routing Protocol > for Low-Power and Lossy Networks) and RFC 5095 (Deprecation of Type 0 > Routing Headers in IPv6). Those two describe the security issues related to > IP source routing. > > Regarding the language issue, we (a French and a Chinese as co-authors > :) will do our best -- and try to find some help from native English > speakers. > > A new revision will be submitted afterwards. > > regards > > Jiazi > > > >> >> Justin >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> >> > > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet > > > -- > Frank Fitzek > Professor > Chair of Communication Networks > Institute of Communication Technology > TU Dresden > > phone: +49 351 463 33945 > fax: +49 351 463 37163 > mobile: +49 173 548 2947 > web: www.fitzek.net > skype: fitzek > > 5G Lab Germany Coordinator 5Glab.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --089e01177917d55d8f05152a7e40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I'm not an expert in netw= ork coding, but it is surely a very interesting combination with multi-path= routing.=C2=A0

I'm not sure I'll be in Pr= ague or not yet -- but in any case, I would be glad to continue the discuss= ion.=C2=A0

btw, I tried several times to subscribe= to the list of network coding research group (nwcrg), but never get the co= nfirmation. So I'm CCing Brian also :) Is any action required from the = list moderator?=C2=A0

best

Jiazi


On Sat, Mar 28, 2015 at 3:54 PM, Frank Fitzek <f= rank.fitzek@tu-dresden.de> wrote:
=20 =20 =20
Dear all,

I am very pleased to see multi path support for MANET coming. I have attend some of the last meetings of MANET and intend to come to Prague and I would be happy to hear more about the multi path initiative.

My reasearch group has a strong interest in coding for multi path MANET. We already used network coding for the BATMAN routing protocol (single route), but see even more potential for multi path approaches (where each path is composed out of multi hops).

In case you are not familiar with network coding, here a small example why it will impact any multi hop system.

Consider the following topology with one source S sending to the destination D over three hops with different error probabilities

S <--- e1 ---> R1 <--- e2 ---> R2 <--- e3 ---> D

A standard FEC end to end code would need to send enough packets for a COMBINED error 1 - (1-e1)(1-e2)(1-e3). Here S is doing the endcoding, and D the decoding.

If we use network coding and allow the relays to recode, the combined error is just 1 - min((1-e1);(1-e2);(1-e3). This means the performance is determined by the worst performing hop but not the full chain. Therefore less packets are used for such a system.

For multipath we get even bigger gains, but they are harder to describe here in a short email.

Maybe you find this interesting and we can talk about this here on the mailing list or in Prague.

All the best
FF



Am 28.03.2015 um 00:52 schrieb Jiazi YI:
Dear Justin,

Thanks very much for your comments, please check inline:
=C2=A0

Bullet point in introduction regarding FEC coding isn't fully correct.=C2=A0 Multi-path can help FEC encoding but isn't a requirement (packets can get lost in all sorts of ways and in all kinds of distributions). FEC coding can work with ANY of them and work, provided the code aligns to the loss patterns.=C2=A0 Having multiple paths ca= n help select a better encoding for better performance but it's not a requirement.

We didn't mean to say that FEC requires multi-path routing.=C2=A0 Maybe "The single path routing is not ada= pted " used is too strong. We will rephrase it.=C2=A0

=C2=A0

In the applicability statement it's mentioned that no new messages are introduced to OLSRv2 which is true but misleading as message tlv types are introduced and required.=C2=A0 This should also be stated at this time or earlier.=C2=A0 Some mention of source route headers being applied to each packet also needs to happen here along with the appropriate RFC references (RFC0791 and RFC6554)

Yes, agree.=C2=A0
=C2=A0

Protocol Overview and Functioning section needs a little bit of reorganizing. Here is how I would do it: =C2=A0OLSRv= 2 and NHDP are used with=C2=A0TLVs added to messages, identifying MP-OLSRv2 functionality. Multi-path routes are invoked on demand. Multi-path algorithms choices. Source routing headers are used based on these multiple paths.

Agree.=C2=A0
=C2=A0

HELLO and TC messages section.=C2=A0 Some mention of WHY TLVs are required should be done (i.e. if you add an address of an OLSRv2 only router in a source route header you're gonna have a bad time)

Will do.=C2=A0
=C2=A0

HELLO and TC Message Generation: change "is"= to "MUST be" A single Message-Type-Specific TLV wi= th Type :=3D MP_OLSRv2 MUST be added to the message....actually the TLV only needs to be added if the router is willing to participate in the source routing.=C2=A0 There is nothing broken with a non MP-OLSRv2 (plain OLSRv2) router from implementing the source routing when other MP-OLSRv2 routers exist.=C2=A0 Should this be allowed?=C2= =A0 I say yes but then more clarity is needed on what is appropriate and what isn't.

We will clarify it in the next revision.=C2=A0
=C2=A0

Multi-path Dijkstra Algorithm: =C2=A0As this is an experimental protocol and the algorithm choice doesn'= t effect any functionality of other parts of the network I think it would be appropriate to have a default method but allow for other algorithm choices.=C2=A0 The requirements if any and likely good quality of what paths an algorithm selects should be presented.

It's a good point. We will have the multipath-dijkstra algorithm as the default algorithm, and also allow other alternatives. Different approaches of the multipath computing can be an experiment point also.=C2=A0
=C2=A0

Security Considerations should also reference source forwarding security documents not just manet related security documents.

Yes. I'm thinking about having the Security Consideration section of RFC 6554 (An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks) and RFC 5095 (Deprecation of Type 0 Routing Headers in IPv6). Those two describe the security issues related to IP source routing.=C2=A0

Regarding the language issue, we (a French and a Chinese as co-authors :) will do our best -- and try to find some help from native English speakers.=C2=A0

A new revision will be submitted afterwards.=C2=A0

regards

Jiazi

=C2=A0

Justin



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




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


--=20
Frank Fitzek=20
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net<=
/a>
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de

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


--089e01177917d55d8f05152a7e40-- From nobody Sun May 3 03:12:11 2015 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 C55E31A036C for ; Sun, 3 May 2015 03: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 vfOti2ywITG7 for ; Sun, 3 May 2015 03:12:09 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D761A0369 for ; Sun, 3 May 2015 03:12:09 -0700 (PDT) Received: by wiun10 with SMTP id n10so84124608wiu.1 for ; Sun, 03 May 2015 03:12:08 -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=rE8QNdMGCxCpB42jjLUnbfcxYJBAqXAfP4awbJNgf5I=; b=CRN37iTpFP1uhyogYg/uGwsFBXMRcoiQlMBqQSpKqL9IaK7EfK0FVe4KhoBXBS1mWe 8XVpOWi8CIL1P2CNvUyLZFxraeqWbWcrLWUzaSCRnIwqq4jLDdHJgS0KJfOhPEG9aMfE Ch3EUiv9dW7DpzKbd79WX5U1GbqP4vLxENS0mT/qj2qXKAcy0TrKo0w08jOz3x/Irq8b 7nA0kpVq3BaKohMCSpr1fdW8xsYfQuuyYyo1sGM4mhY+af0Wfngh1YRtasnUupXX6RWe L1N9+nFrGX7qP4Lr44UfKz5fFPOF39j0ZtZn4staqxNGJ2j//XpjNw72pfI0WgmiCalx MWCA== MIME-Version: 1.0 X-Received: by 10.194.179.2 with SMTP id dc2mr22854628wjc.120.1430647928399; Sun, 03 May 2015 03:12:08 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.226.139 with HTTP; Sun, 3 May 2015 03:12:08 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 May 2015 12:12:08 +0200 X-Google-Sender-Auth: OeflidshJBRMB4gqly6XR0Q7sAk Message-ID: From: Jiazi YI To: Justin Dean Content-Type: multipart/alternative; boundary=089e013d1954922a4d05152aadbd Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] my olsrv2-multipath notes 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, 03 May 2015 10:12:10 -0000 --089e013d1954922a4d05152aadbd Content-Type: text/plain; charset=UTF-8 Hi, Regarding Justin's comment: > ....actually the TLV only needs to be added if the router is willing to > participate in the source routing. There is nothing broken with a non > MP-OLSRv2 (plain OLSRv2) router from implementing the source routing when > other MP-OLSRv2 routers exist. Should this be allowed? I say yes but then > more clarity is needed on what is appropriate and what isn't. > > I think it's very good point. As far as I can see, a non MP-OLSRv2 router can be added to the source routing header, as long as it implements appropriate source routing mechanism. Then it would be better to change the MP-OLSRv2 TLV (identifying an MP-OLSRv2 router) to SR-OLSRv2 TLV (identifying an OLSRv2/MP-OLSRv2 router supporting source routing). By doing so, more OLSRv2 routers (don't support multi-path but support source routing) can be used in the source route. Plus, the SR-OLSRv2 TLV is more general, and could possible used for other purpose. best Jiazi --089e013d1954922a4d05152aadbd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Regarding Justin's comment:
=C2=A0
<= div>....actually the TLV only needs to be added if the router is willing to= participate in the source routing.=C2=A0 There is nothing broken with a no= n MP-OLSRv2 (plain OLSRv2) router from implementing the source routing when= other MP-OLSRv2 routers exist.=C2=A0 Should this be allowed?=C2=A0 I say y= es but then more clarity is needed on what is appropriate and what isn'= t.


I think it= 9;s very good point. As far as I can see, a non MP-OLSRv2 router can be add= ed to the source routing header, as long as it implements appropriate sourc= e routing mechanism.=C2=A0

Then it would be better= to change the MP-OLSRv2 TLV (identifying an MP-OLSRv2 router) to SR-OLSRv2= TLV (identifying an OLSRv2/MP-OLSRv2 router supporting source routing).=C2= =A0
By doing so, more OLSRv2 routers (don't support multi-pat= h but support source routing) can be used in the source route. Plus, the SR= -OLSRv2 TLV is more general, and could possible used for other purpose.=C2= =A0

best

Jiazi
= =C2=A0
--089e013d1954922a4d05152aadbd-- From nobody Tue May 5 07:14:03 2015 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 547971A00C3 for ; Tue, 5 May 2015 07:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 tRTdXP3JE_sK for ; Tue, 5 May 2015 07:13:58 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932C51AD065 for ; Tue, 5 May 2015 07:13:34 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so129393899lbb.3 for ; Tue, 05 May 2015 07:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dlGTlnF3BHEZhPkEnXMNqUTr5YXNuGDdyDioEhwBnso=; b=pIg+afGV9/X84bZXNzSb4x9GkNmAYFl/LFsdC4S4NXbHsNQRq6oWa/v/5LdphWyxB+ H6uwMcytUieT6SoiBRrizjSPFKsmyGFURIaqHa02pphlmv1JayLv7XFf5k4qUr4bVp9P 5Mi0nhHavKNoIK6iHY0/AKdD4kK9/48bb29BjDCyQlTfLFi37PABpqw2fVJGupGy50WQ 3882amYMKPbOSs0etUcgLh6snqGTl+BCZFL0A6/4qVOFwlnirJuiP+rRJXqeGsZ5sDzG OoBpEUk47ZH/sEdPVyEdMzE9VtfYVypEoKEkM/J+4LZUGx9HEzfjZ5ciwSpdnmmHBsJc X6/w== MIME-Version: 1.0 X-Received: by 10.152.29.161 with SMTP id l1mr23643890lah.76.1430835212905; Tue, 05 May 2015 07:13:32 -0700 (PDT) Received: by 10.112.18.73 with HTTP; Tue, 5 May 2015 07:13:32 -0700 (PDT) Date: Tue, 5 May 2015 19:43:32 +0530 Message-ID: From: Debarshi Sanyal To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0158cbf098f25d0515564852 Archived-At: Subject: [manet] Regarding use of Reed-Solomon code in wireless networks 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, 05 May 2015 14:14:00 -0000 --089e0158cbf098f25d0515564852 Content-Type: text/plain; charset=UTF-8 Hi, We were working on design of wormhole detection methods in MANETs. To achieve detection, we propose to measure the time taken for a test nonce to move from one node to it's neighbor node. Now to combat channel errors, is it worth to encode the nonce with Reed-Solomon code? Our understanding is that propagation time between neighbor nodes in commodity wi-fi setups is much smaller than the time taken to encode and decode a nonce (say, 64 bytes long). We would be immensely thankful if you could throw some light on this since we do not have access to hardware platforms to get real measurements. Regards, Debarshi Kumar Sanyal --089e0158cbf098f25d0515564852 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

We were working on desig= n of wormhole detection methods in MANETs.=C2=A0
To achieve detec= tion, we propose to measure the time taken for a test nonce to move from on= e node to it's neighbor node.

Now to combat ch= annel errors, is it worth to encode the nonce with Reed-Solomon code?=C2=A0=

Our understanding is that propagation time betwee= n neighbor nodes in commodity wi-fi setups is much smaller than the time ta= ken to encode and decode a nonce (say, 64 bytes long).=C2=A0

=
We would be immensely thankful if you could throw some light on = this since we do not have access to hardware platforms to get real measurem= ents.

=C2=A0


Regards,
Debarshi Kumar Sanyal

=
--089e0158cbf098f25d0515564852-- From nobody Tue May 5 17:37:02 2015 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 8894B1B2AA3 for ; Tue, 5 May 2015 17:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 mU0tOxKASGZg for ; Tue, 5 May 2015 17:36:59 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1572F1B2A98 for ; Tue, 5 May 2015 17:36:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t460avKU025109; Tue, 5 May 2015 17:36:57 -0700 Received: from XCH-BLV-206.nw.nos.boeing.com (xch-blv-206.nw.nos.boeing.com [10.57.37.16]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t460al6n024737 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 5 May 2015 17:36:47 -0700 Received: from XCH-BLV-103.nw.nos.boeing.com ([169.254.3.89]) by XCH-BLV-206.nw.nos.boeing.com ([169.254.6.127]) with mapi id 14.03.0235.001; Tue, 5 May 2015 17:36:46 -0700 From: "Goff, Thomas" To: "manet@ietf.org" Thread-Topic: DLEP 09 Credit-Windowing Thread-Index: AdCHkp013avgEtLAQPCN4W/W24DqHQ== Date: Wed, 6 May 2015 00:36:45 +0000 Message-ID: <6506326C46439D46B51105888E9958C920022826@XCH-BLV-103.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [manet] DLEP 09 Credit-Windowing 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, 06 May 2015 00:37:01 -0000 All, I wonder if it would make sense to consider some possible changes to the cu= rrent DLEP credit-windowing specification, specifically: - Use absolute credits by advertising a current receive window rather than= granting incremental credits. This would avoid having to handle synchroni= zation and overflow issues and in some cases might improve adapting to degr= aded link conditions (a modem could immediately shrink its window instead o= f waiting for the peer to run out of all previously granted credits). - Support the use of unidirectional credit-windowing where each DLEP parti= cipant can decided if credits should be used for data it receives (on a per= -destination basis). My understanding is that credit-windowing and flow co= ntrol is not needed for traffic flowing from the modem to a router in most = use cases. I also think it would be helpful if DLEP described how credit accounting sh= ould be performed. For example, say credits apply to layer 2 frames sent b= etween the router and modem. A possible modified section 8 based on draft-ietf-manet-dlep-09 is included= below. Tom 8. Credit-Windowing DLEP includes an OPTIONAL Protocol Extension for a credit-windowing scheme analogous to the one documented in [RFC5578]. In this scheme, per-destination traffic between the router and modem is treated as two unidirectional flows. When credit-windowing is supported by the DLEP session, each DLEP participant (modem and router) independently controls if credit-windowing will be used when receiving data associated with a destination. Credits are managed independently in each direction on a destination-specific basis; that is, separate credit counts are maintained for each destination requiring the service. Credits do not apply to the DLEP session that exists between routers and modems. If the OPTIONAL credit-windowing extension is used, a DLEP participant advertises a current Receive Window to inform its peer how much data it can receive to/from the associated destination, in bytes. Credit accounting is performed based on the Layer 2 frames sent between DLEP peers. For Ethernet this includes the Ethernet header, payload, and frame check sequence. When unidirectional credit-windowing is used, a DLEP participant SHOULD NOT forward data for the associated destination unless the current Receive Window of its DLEP peer has sufficient credits, in bytes. The length of each associated Layer 2 frame SHOULD be deducted from the peer's current Receive Window after being forwarded. A peer's destination-specific current Receive Window SHOULD be set to the advertised value when a Credit Window Status data item is received. If a peer is able to support the OPTIONAL credit-windowing extension then it MUST include a Extensions Supported data item (Section 7.7) including the value DLEP_EXT_CREDITS (value TBD) in the appropriate Peer Initialization or Peer Initialization ACK signal. 8.1. Credit-Windowing Signals The credit-windowing extension introduces no additional DLEP signals. However, if a peer has advertised during session initialization that it supports the credit-windowing extension then the following DLEP signals MAY contain additional credit-windowing data items: 8.1.1. Destination Up Signal The Destination Up signal MAY contain one of each of the following data items: o Credit Window Status (Section 8.2.1) The use of unidirectional credits is enabled when the Destination Up signal includes a Credit Window Status data item. In this case, destination-specific credit-windowing MUST be performed for traffic sent to the associated destination flowing toward the originator of the Destination Up signal. If the Destination Up signal does not contain the Credit Window Status data item, unidirectional credits MUST NOT be used for that destination. 8.1.2. Destination Up ACK Signal The Destination Up ACK signal MAY contain one of each of the following data items: o Credit Window Status (Section 8.2.1) The use of unidirectional credits is enabled if the Destination Up ACK signal includes a Credit Window Status data item. In this case, destination-specific credit-windowing MUST be performed for traffic sent from the associated destination when the destination is physical (unicast), or to the associated destination when the destination is logical (multicast or broadcast), flowing toward the originator of the Destination Up ACK signal. If the Destination Up ACK signal does not contain the Credit Window Status data item, unidirectional credits MUST NOT be used for that destination. 8.1.3. Destination Update Signal If the originator's corresponding Destination Up or Destination Up ACK signal contained the Credit Window Status data item, the Destination Update signal MUST contain one of each of the following data items: o Credit Window Status (Section 8.2.2) If the recipient's (i.e., the DLEP peer's) corresponding Destination Up or Destination Up ACK signal contained the Credit Window Status data item, the Destination Update signal MAY contain one of each of the following data items: o Credit Request (Section 8.2.2) 8.2. Credit-Windowing Data Items The credit-windowing extension introduces 2 additional data items. If a peer has advertised during session initialization that it supports the credit-windowing extension then it MUST correctly process the following data items without error. +------------+-----------------------+----------------+ | Data Item | Description | Section | +------------+-----------------------+----------------+ | TBD | Credit Window Status | Section 8.2.1 | | TBD | Credit Request | Section 8.2.2 | +------------+-----------------------+----------------+ 8.2.1. Credit Window Status The Credit Window Status data item is sent by a DLEP participant to indicate the current amount of data that can be received for a given destination, in bytes. If the credit-window extension is supported by the DLEP participants (both the router and the modem), the Credit Window Status data item MAY be included in the Destination Up or Destination Up ACK signal to enable unidirectional credit-windowing for a given destination. Subsequent Destination Update signals MUST also contain the Credit Window Status data item if a DLEP participant enabled credit-windowing (by including a Credit Window Status data item in the initial Destination Up or Destination Up ACK signal). The Credit Window Status data item contains the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length | Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Window Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 8 Receive Window Value: A 64-bit unsigned integer, indicating the current number of credits available on the sender's Receive Window, for the destination referred to by the signal. 8.2.2. Credit Request If the use of unidirectional credits was enabled by the DLEP peer, the Credit Request data item MAY be sent from either DLEP participant, via the Destination Update signal (Section 6.13), to indicate the desire for additional credits from the partner in order for data transfer to proceed for the destination. If the recipient's corresponding Destination Up signal (Section 6.9) or Destination Up ACK signal (Section 6.10) included a Credit Window Status data item, the recipient SHOULD reply by sending a Destination Update signal that includes a Credit Window Status data item indicating the current number of credits that can be received for the given destination. The Credit Request data item MUST be silently ignored if the corresponding Destination Up signal or Destination Up ACK signal sent by the recipient did NOT contain a Credit Window Status data item. The Credit Request data item contains the following fields: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Item Type| Length | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Data Item Type: TBD Length: 0 From nobody Wed May 6 06:05:31 2015 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 6520F1A8ADE; Wed, 6 May 2015 06:05:29 -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] 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 RuYYHkYWP_Bx; Wed, 6 May 2015 06:05:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 803281A8AE1; Wed, 6 May 2015 06:05:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150506130523.32612.13396.idtracker@ietfa.amsl.com> Date: Wed, 06 May 2015 06:05:23 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-10.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 13:05:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-10.txt Pages : 65 Date : 2015-05-06 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-10 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 6 07:11:56 2015 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 5100E1A00D6; Wed, 6 May 2015 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 gyvMwcfkz_bK; Wed, 6 May 2015 07:11:49 -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 237FF1AC410; Wed, 6 May 2015 07:11:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,379,1427756400"; d="scan'208";a="549617098" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 06 May 2015 15:11:44 +0100 X-IronPort-AV: E=Sophos;i="5.13,379,1427756400"; d="scan'208";a="97063361" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 06 May 2015 15:11:44 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Wed, 6 May 2015 15:11:44 +0100 From: "Dearlove, Christopher (UK)" To: "ietf@ietf.org" , IETF Announcement List Thread-Topic: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 Thread-Index: AQHQe66zLKdXpQNsekeLQXwvZ9kqFZ1vFVlg Date: Wed, 6 May 2015 14:11:43 +0000 Message-ID: References: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> In-Reply-To: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 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, 06 May 2015 14:11:52 -0000 This meeting does not, according to the webex link, appear to be happening. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: manet [mailto:manet-bounces@ietf.org] On Behalf Of IESG Secretary Sent: 20 April 2015 22:11 To: IETF Announcement List Cc: manet@ietf.org Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 ----------------------! 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 Mobile Ad-hoc Networks (manet) working group will hold a virtual interi= m meeting as follows: Date: Wednesday, May 6, 2015 Time: 1100-1300 EDT (1500-1700 UTC) JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=3Dm2f5c335024d36b7e80e2653ea0774769 Meeting number: 649 415 639 Meeting password: 12345 JOIN BY PHONE 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=3Dm0e3fb44d1bbbef98f5b0cf9e4651cd1e Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session. _______________________________________________ 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 Wed May 6 07:25:57 2015 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 1F68F1ACD27; Wed, 6 May 2015 07:25:56 -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 1NCs1AahNuLC; Wed, 6 May 2015 07:25:53 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0509E1ACD33; Wed, 6 May 2015 07:25:47 -0700 (PDT) Received: by oica37 with SMTP id a37so8677812oic.0; Wed, 06 May 2015 07:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=b1E6xLJTDXZAv6WtG4tZxwLFTBBTJzwAJFFuRa7f+6s=; b=LqJK95jtQN5jNzgrSCBKyNTfA8kSypUJ16cFaQGAC5I8gthySj4/D1hs+UEB4rcEJZ 8+35L7m6ZvIZkqlFwDiBEVFAxb9oXIQFxy93zId+h9qLxvX77oCyN2lMIIUu0A+jX1uT qXKTlS3F/qpzoeqHN6O2MFIC3mBy9lE6dSYPdR6MuLqaSBeg9uwznpcz8wulySiRnAco Nid/53elu5QNoh38ocONU8iGs0UdDiJiUiZEfAVsXqr85GTrMv7VL6xL8PKbzlSyGxyM 2WVuw9LiaPhY++1knDEen4qvqZPRPOjta4HA2Z4f5FDrQ8gHfUmG+4abRRJKp0AQQzXe pA4A== X-Received: by 10.182.196.34 with SMTP id ij2mr26661219obc.71.1430922346532; Wed, 06 May 2015 07:25:46 -0700 (PDT) MIME-Version: 1.0 References: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> In-Reply-To: From: Justin Dean Date: Wed, 06 May 2015 14:25:45 +0000 Message-ID: To: "Dearlove, Christopher (UK)" , "ietf@ietf.org" , IETF Announcement List Content-Type: multipart/alternative; boundary=089e0153870c2a947205156a92d2 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 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, 06 May 2015 14:25:56 -0000 --089e0153870c2a947205156a92d2 Content-Type: text/plain; charset=UTF-8 It hasn't yet started. Im in the room now but you should be able to join at 11. In 35 mins or so. On Wed, May 6, 2015, 10:12 AM Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > This meeting does not, according to the webex link, appear to be happening. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > __________________________________________________________________________ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 20 April 2015 22:11 > To: IETF Announcement List > Cc: manet@ietf.org > Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 > > ----------------------! 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. > -------------------------------------------------------- > > The Mobile Ad-hoc Networks (manet) working group will hold a virtual > interim meeting as follows: > > Date: Wednesday, May 6, 2015 > Time: 1100-1300 EDT (1500-1700 UTC) > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=m2f5c335024d36b7e80e2653ea0774769 > Meeting number: 649 415 639 > Meeting password: 12345 > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=m0e3fb44d1bbbef98f5b0cf9e4651cd1e > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automatically > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0153870c2a947205156a92d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It hasn't yet started. Im in the room now but you should= be able to join at 11. In 35 mins or so.


On Wed, May 6, 2015, 10:12 AM=C2=A0Dearlove,= Christopher (UK) <chri= s.dearlove@baesystems.com> wrote:
= This meeting does not, according to the webex link, appear to be happening.=

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP



-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of IESG Secretary
Sent: 20 April 2015 22:11
To: IETF Announcement List
Cc: manet@ietf.org<= br> Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

The Mobile Ad-hoc Networks (manet) working group will hold a virtual interi= m meeting as follows:

Date: Wednesday, May 6, 2015
Time: 1100-1300 EDT (1500-1700 UTC)


JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=3Dm2f5= c335024d36b7e80e2653ea0774769
Meeting number: 649 415 639
Meeting password: 12345


JOIN BY PHONE
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639

Toll-free dialing restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf


Add this meeting to your calendar:
https://ietf.webex.com/ietf/j.php?MTID=3Dm0e3= fb44d1bbbef98f5b0cf9e4651cd1e


Can't join the meeting? Contact support here:
https://ietf.w= ebex.com/ietf/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your c= oncerns with the host or do not join the session.

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

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

_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet
--089e0153870c2a947205156a92d2-- From nobody Wed May 6 07:27:59 2015 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 417C71ACD33; Wed, 6 May 2015 07:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 8L0rf6e-oJ-i; Wed, 6 May 2015 07:27:53 -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 D91CD1ACD26; Wed, 6 May 2015 07:27:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,379,1427756400"; d="scan'208,217";a="463951129" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 06 May 2015 15:27:31 +0100 X-IronPort-AV: E=Sophos;i="5.13,379,1427756400"; d="scan'208,217";a="101039828" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 06 May 2015 15:27:29 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0224.002; Wed, 6 May 2015 15:27:29 +0100 From: "Dearlove, Christopher (UK)" To: Justin Dean , "ietf@ietf.org" Thread-Topic: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 Thread-Index: AQHQe66zLKdXpQNsekeLQXwvZ9kqFZ1vFVlg///zmoCAABDikA== Date: Wed, 6 May 2015 14:27:28 +0000 Message-ID: References: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE71E0GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 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, 06 May 2015 14:27:56 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE71E0GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHN1cmUgaWYgSeKAmWxsIG1ha2UgaXQuIEJ1dCBteSBtaXN0YWtlIG9uIHRpbWluZywgZm9y Z290IHdlIHdlcmUgbm93IFVUQysxLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlv ciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0ICB8ICBFOiBjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hu b2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3 LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lz dGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQg JiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQpGcm9tOiBKdXN0aW4gRGVhbiBb bWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tXQ0KU2VudDogMDYgTWF5IDIwMTUgMTU6MjYNClRv OiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgaWV0ZkBpZXRmLm9yZzsgSUVURiBBbm5vdW5j ZW1lbnQgTGlzdA0KQ2M6IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW21hbmV0XSBNQU5F VCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZzogNiBNYXkgMjAxNQ0KDQoNCioqKiBXQVJOSU5H ICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRp b24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29u c2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9w ZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBS ZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUs IGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBm ZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vzczxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRm Pi4NCg0KSXQgaGFzbid0IHlldCBzdGFydGVkLiBJbSBpbiB0aGUgcm9vbSBub3cgYnV0IHlvdSBz aG91bGQgYmUgYWJsZSB0byBqb2luIGF0IDExLiBJbiAzNSBtaW5zIG9yIHNvLg0KDQpPbiBXZWQs IE1heSA2LCAyMDE1LCAxMDoxMiBBTSBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMu ZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMu Y29tPj4gd3JvdGU6DQpUaGlzIG1lZXRpbmcgZG9lcyBub3QsIGFjY29yZGluZyB0byB0aGUgd2Vi ZXggbGluaywgYXBwZWFyIHRvIGJlIGhhcHBlbmluZy4NCg0KLS0NCkNocmlzdG9waGVyIERlYXJs b3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVs bGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAg RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIElFU0cg U2VjcmV0YXJ5DQpTZW50OiAyMCBBcHJpbCAyMDE1IDIyOjExDQpUbzogSUVURiBBbm5vdW5jZW1l bnQgTGlzdA0KQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFttYW5ldF0gTUFORVQgV0cgVmlydHVhbCBJbnRlcmltIE1lZXRpbmc6IDYgTWF5IDIwMTUN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24s IGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuDQpD b25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywg b3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGlj aW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9y dGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIE1vYmlsZSBBZC1ob2MgTmV0 d29ya3MgKG1hbmV0KSB3b3JraW5nIGdyb3VwIHdpbGwgaG9sZCBhIHZpcnR1YWwgaW50ZXJpbSBt ZWV0aW5nIGFzIGZvbGxvd3M6DQoNCkRhdGU6IFdlZG5lc2RheSwgTWF5IDYsIDIwMTUNClRpbWU6 IDExMDAtMTMwMCBFRFQgKDE1MDAtMTcwMCBVVEMpDQoNCg0KSk9JTiBXRUJFWCBNRUVUSU5HDQpo dHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMmY1YzMzNTAyNGQzNmI3ZTgw ZTI2NTNlYTA3NzQ3NjkNCk1lZXRpbmcgbnVtYmVyOiA2NDkgNDE1IDYzOQ0KTWVldGluZyBwYXNz d29yZDogMTIzNDUNCg0KDQpKT0lOIEJZIFBIT05FDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRv bGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSkNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBu dW1iZXIgKFVTL0NhbmFkYSkgQWNjZXNzIGNvZGU6IDY0OSA0MTUgNjM5DQoNClRvbGwtZnJlZSBk aWFsaW5nIHJlc3RyaWN0aW9uczoNCmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9y ZXN0cmljdGlvbnMucGRmDQoNCg0KQWRkIHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyOg0K aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTBlM2ZiNDRkMWJiYmVmOThm NWIwY2Y5ZTQ2NTFjZDFlDQoNCg0KQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBw b3J0IGhlcmU6DQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMNCg0KDQpJTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2lu aW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29y ZGluZ3MuIElmIHlvdSBkbyBub3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5 b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBt YWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQNCg0KKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNClRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRl bmRlZA0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQNCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0 ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLg0KWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2Ug aXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcg0KZGlzdHJpYnV0ZSBpdHMgY29udGVu dHMgdG8gYW55IG90aGVyIHBlcnNvbi4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0 QGlldGYub3JnPG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbWFuZXQNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE71E0GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vdCBzdXJlIGlmIEnigJlsbCBtYWtlIGl0 LiBCdXQgbXkgbWlzdGFrZSBvbiB0aW1pbmcsIGZvcmdvdCB3ZSB3ZXJlIG5vdyBVVEMmIzQzOzEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj4tLQ0KPG86cD48L286cD48 L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3RTdFIj5DaHJp c3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4NCjwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojQkVCRUJFIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAwN0UiPjxicj4NCjwv c3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+VDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RDdEN0QiPjogJm5ic3A7JiM0Mzs0 NCAoMCkxMjQ1IDI0MjE5NCAmbmJzcDt8ICZuYnNwOzxiPkU6DQo8L2I+PGEgaHJlZj0ibWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1z LmNvbTwvYT48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDAw N0UiPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNBOEI5MiI+ QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQ YXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJyPg0KPGEgaHJl Zj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzQThC OTI7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlIExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAx MzM3NDUxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzNB OEI5MiI+UmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKdXN0aW4gRGVhbiBbbWFpbHRv OmJlYmVtYXN0ZXJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA2IE1heSAyMDE1IDE1 OjI2PGJyPg0KPGI+VG86PC9iPiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgaWV0ZkBpZXRm Lm9yZzsgSUVURiBBbm5vdW5jZW1lbnQgTGlzdDxicj4NCjxiPkNjOjwvYj4gbWFuZXRAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTUFORVQgV0cgVmlydHVhbCBJbnRl cmltIE1lZXRpbmc6IDYgTWF5IDIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xp ZCBibGFjayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dy b3VuZDp3aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij5UaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwg ZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwv ZW0+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24g YW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+ DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48 L3NwYW4+PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQi PlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlv dSByZWNlaXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVt cy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdz LnBkZiI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNz PC9hPi48L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPkl0 IGhhc24ndCB5ZXQgc3RhcnRlZC4gSW0gaW4gdGhlIHJvb20gbm93IGJ1dCB5b3Ugc2hvdWxkIGJl IGFibGUgdG8gam9pbiBhdCAxMS4gSW4gMzUgbWlucyBvciBzby48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFdlZCwgTWF5IDYsIDIwMTUsIDEwOjEyIEFNJm5ic3A7RGVhcmxvdmUs IENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbSI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVldGluZyBkb2VzIG5v dCwgYWNjb3JkaW5nIHRvIHRoZSB3ZWJleCBsaW5rLCBhcHBlYXIgdG8gYmUgaGFwcGVuaW5nLjxi cj4NCjxicj4NCi0tPGJyPg0KQ2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNp cGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2U8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCjxicj4NClQ6ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIx OTQgJm5ic3A7fCAmbmJzcDtFOiA8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PC9hPjxicj4NCjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNm b3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIg OEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0i X2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KQkFFIFN5c3RlbXMgQXBwbGll ZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxicj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBX YWxlcyBObzogMDEzMzc0NTE8YnI+DQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNo IFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBtYW5ldCBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXQt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBJRVNHIFNlY3JldGFyeTxicj4NClNl bnQ6IDIwIEFwcmlsIDIwMTUgMjI6MTE8YnI+DQpUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdDxi cj4NCkNjOiA8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5t YW5ldEBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbbWFuZXRdIE1BTkVUIFdHIFZpcnR1YWwg SW50ZXJpbSBNZWV0aW5nOiA2IE1heSAyMDE1PGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSEgV0FSTklORyAhIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdp bmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVy bmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0KQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Ljxicj4NCkZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycg bGluayBvbiBJVCBtYXR0ZXJzIGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lv dXMgZW1haWwgbWVzc2FnZXMuPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaGUgTW9iaWxlIEFkLWhvYyBOZXR3 b3JrcyAobWFuZXQpIHdvcmtpbmcgZ3JvdXAgd2lsbCBob2xkIGEgdmlydHVhbCBpbnRlcmltIG1l ZXRpbmcgYXMgZm9sbG93czo8YnI+DQo8YnI+DQpEYXRlOiBXZWRuZXNkYXksIE1heSA2LCAyMDE1 PGJyPg0KVGltZTogMTEwMC0xMzAwIEVEVCAoMTUwMC0xNzAwIFVUQyk8YnI+DQo8YnI+DQo8YnI+ DQpKT0lOIFdFQkVYIE1FRVRJTkc8YnI+DQo8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tMmY1YzMzNTAyNGQzNmI3ZTgwZTI2NTNlYTA3NzQ3NjkiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMmY1YzMz NTAyNGQzNmI3ZTgwZTI2NTNlYTA3NzQ3Njk8L2E+PGJyPg0KTWVldGluZyBudW1iZXI6IDY0OSA0 MTUgNjM5PGJyPg0KTWVldGluZyBwYXNzd29yZDogMTIzNDU8YnI+DQo8YnI+DQo8YnI+DQpKT0lO IEJZIFBIT05FPGJyPg0KMS04NzctNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpPGJyPg0KMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKSBBY2Nlc3MgY29kZTogNjQ5IDQxNSA2Mzk8YnI+DQo8YnI+DQpUb2xsLWZyZWUgZGlhbGlu ZyByZXN0cmljdGlvbnM6PGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3Rv bGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LndlYmV4 LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBkZjwvYT48YnI+DQo8YnI+DQo8YnI+DQpB ZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXI6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTBlM2ZiNDRkMWJiYmVmOThmNWIwY2Y5ZTQ2 NTFjZDFlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhw P01USUQ9bTBlM2ZiNDRkMWJiYmVmOThmNWIwY2Y5ZTQ2NTFjZDFlPC9hPjxicj4NCjxicj4NCjxi cj4NCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYzwvYT48YnI+DQo8YnI+DQo8YnI+DQpJTVBPUlRB TlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVk aW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJl Y29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBq b2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJl Y29yZGluZ3MuIElmIHlvdSBkbyBub3QNCiBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNj dXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lv bi48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0PC9hPjxicj4N Cjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFy ZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJyPg0KcmVjaXBpZW50IGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGll bnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRl ci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ug bm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE71E0GLKXM0002VGREEN_-- From nobody Wed May 6 09:18:33 2015 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 19FC91A0218 for ; Wed, 6 May 2015 09:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 DeXvU1mjm-Sw for ; Wed, 6 May 2015 09:18:28 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 698441A014C for ; Wed, 6 May 2015 09:18:28 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@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.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,380,1427774400"; d="jpg'145?scan'145,208,217,145";a="17371737" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 06 May 2015 12:18:27 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 6 May 2015 12:18:26 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Wed, 6 May 2015 12:18:27 -0400 From: "Ratliff, Stanley" To: MANET IETF Thread-Topic: DLEP-10 synopsis Thread-Index: AdCIF3d40Kw8Nb5mTWm2dYuzIkvsoA== Date: Wed, 6 May 2015 16:18:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.250.250.20] Content-Type: multipart/related; boundary="_004_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP-10 synopsis 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, 06 May 2015 16:18:31 -0000 --_004_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_ Content-Type: multipart/alternative; boundary="_000_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_" --_000_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Working Group, The MANET WG interim meeting was held today, and at that meeting, there was= a request for the synopsis of changes that went into DLEP-10. They are: - Added text noting the support for EUI-64 format MAC addresses, a= s well as EUI-48. The restriction is that the MAC addresses sent by the mod= em MUST be consistent with the attachment the modem shares with the router = (e.g., if the modem is attached via EUI-48, then all MAC addresses MUST be = expressed as EUI-48. If the modem is attached with a EUI-64 MAC, then all M= AC addresses MUST be in EUI-64). - Added text clarifying the fact that the Peer Initialization sign= al is NOT covered by heartbeats; implementations desirous of timing-out a P= eer Initialization signal will need to provide another mechanism. - Made consistent the restriction that receipt of an unknown data = item MUST result in termination of the peer session. The other changes were minor (spelling, punctuation, etc.) Regards, Stan ________________________________ Stan Ratliff | Architect, Applied Research VT iDirect | 13861 Sunrise Valley Drive, Suite 300, Herndon, VA 20171, US= A T: +1 703 544-8520 | F: +1 222 123-4567 sratliff@idirect.net | www.idirect.net Connect with iDirect: Twitter.com/iDirect | = Facebook.com/iDirect [cid:image001.jpg@01D087F6.C064A3F0] Advancing a Connected World --_000_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Working Group,

 

The MANET WG interim meeting was held today, and at = that meeting, there was a request for the synopsis of changes that went int= o DLEP-10. They are:

 

-     &= nbsp;    Added text noting the support for EUI-64 format MAC= addresses, as well as EUI-48. The restriction is that the MAC addresses se= nt by the modem MUST be consistent with the attachment the modem shares wit= h the router (e.g., if the modem is attached via EUI-48, then all MAC addresses MUST be expressed as EUI-48= . If the modem is attached with a EUI-64 MAC, then all MAC addresses MUST b= e in EUI-64).

-     &= nbsp;    Added text clarifying the fact that the Peer Initia= lization signal is NOT covered by heartbeats; implementations desirous of t= iming-out a Peer Initialization signal will need to provide another mechani= sm.

-     &= nbsp;    Made consistent the restriction that receipt of an = unknown data item MUST result in termination of the peer session.

 

The other changes were minor (spelling, punctuation,= etc.)

 

Regards,

Stan

 

Stan Ratliff  |  Architect, Applied Research<= /span>

VT iDirect  |  13861 Sunrise Valley Drive, Suite 300, Hernd= on, VA 20171, USA

T: +1 703 544-8520  |  F: +1 222 123-4567

sratliff@i= direct.net  |  www.idirect.net

Connect with iDirect: Twitter.com/iDi= rect  |  Facebook.com/i= Direct

 

<= /p>

Advancing a Connected World

 <= /span>

 

--_000_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_-- --_004_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3003; creation-date="Wed, 06 May 2015 16:18:26 GMT"; modification-date="Wed, 06 May 2015 16:18:26 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcG BwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz/2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwM DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAaAIMDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9B/8A gpJ+2j8YvgF8cfCug+CfD76X4daaG4/tm6sxeW/iWTaWewUgN5Sbc7gu24JUPGHRSreXftg/sxeI P24PijYfEbQNH1G2tte0PS4p4Zx/yD7hBqkMiF1O1tvmQkSL8rpLHIpKNuqT9nG+/aT1mSZPjBZ/ EJfBfytqDeJl0NNNjUMDlhPAJQqtghtykEDbziv0k0C3s30m3FjtazEY8nYdykeueuTnnvknknmv AoYf69zSqN8rafK1a1vvP3HNM4/1Nq4Wll9Og69JTjKtSnzxqKWr5nd2ku19OiS0PgP44f8ABSr4 k+FP2vtD0D4e+ErrXPBtnL/ZMei/ZN1/4ocbTJNGxG+ExqAU5CiNvNmAWSEN+g2lzNd2cMjwtbyS KryRMQTGSASCQcEjoSDjjqa+Pf23B44tPHGrT/BeDVpPFEVsE1NvDq6RNfRgsdgcXStKiFxKcLtj Lhz97zCPS/8AgmfdfEq5/ZsL/FhPE8fiptXvNo19Y1vjbBh5e4RgJj72NoxjFdWCrTjiJUW3Jbp2 0Xknc+a4mwOExOR4bM8JTpUfZpQlFTvWqN3fPOPZfzWu7rZWSqfBn9vG5+In7bHjD4L6t4Rh0G98 M29zdWepjVTcjUxE8O0eT5EewvFP5gw7YCH61h+O/wDgo14gs/2qPGvws8E/DBvHGo+C9LOoSTxa 99le8kEUDNCsf2eQDD3CpuL9VbjjnyX9stLf9mf/AIK0fCn4lSyR2Oj+MIY7DUrl+EWQBrSRmPAw IpLc89AjE9BWt/wRo0KX4peM/jB8ZtQjf7X4v1trG1ZxgxRb2uXUZGefNgBGf+Wdewfma2Fu/wDg r18StN+Llr4Bn/Zw1CPxpfRma30c+K8XMyeU82R/oeP9XG7cnopr61+AHxE8SfFH4ZafrPirwfde A9avJJVuNFnuhdSWqq7BWMgRAdwAP3RjPWvi34hnP/BwN4F740s9R/1B7/8Az+NfoeIEH8PU559a TA8m+Cfxo8cfEn4r+MdD8SfDG+8HaD4fkMek65LqYnj19fNdAyRiJTGNio/3m+9jtmvl3wB/wWR8 f/FTRdc1Hwv+zvqHiDTfDbH+0Z7DxQZBaL8xBZBZbuVVjhQfun61uf8ABOP4s+K/G37dn7Qmja34 m8QaxpGi6hImnWV9qEtxb2Ci9nQCJHYrGNqgfKBwBXH/APBBiJY/CfxeDKNv9pWuQ3/XOcfyotYD 6W/Zw/bgsf2q/wBm3XPHHg/Qby71rQ4bhJfDss6iaS7SIyRwLIqkFZcqFfb3Py8Gu4/Zr+Knif4q /C2LW/Gfge6+HWtS3MkTaLcXwvJI0UhVfzAiZDdfuivz2/4Jc65daF+zJ+1Rd6XdXFg1jpbXWnz2 khie2kW1vyjxsuCrLtQgg5BANUNf/aJ+IEH/AAR50PxQvjvxkviaTx09lJqy61cC+eDE+Imm37yg wvyk44pcoH6sfak3Yz3x+NAuVLbf4sZxX5wftNfEr4ufsh/sTaf4rb4o614j8VfFa804i5njCxeH YPsUszQ2oJKhnPlqX2qWxk5b5qh/Zg+JPxg8JftWeB7XRbL9pvWvh/rWy08Rn4l6NLIkEj5BuIJk 3rHGDtYbmXAyORzT5QP0mM6jrx1P1rI8a/EXQ/ht4WvNc8RapY6Ho+nqHub2+mWCCEMyqu5mIALM yqB1LEAAkgH4A8Daz8Sv29v2nfjlp8fxS8aeCbb4dtJb+GtP8P6mLC0abzZooftO1SZY8wAvzn95 95Rhav8A7bPgD4lTf8EqdSl+Kfij7R4s8J6hamVtB1ANZa/BJe20KC9URL5pUSlwoVP3kcbZJzRy gfeXw+8f6R8U/BeneIdBvF1DR9WiE9pcqrKs8ZJAYBgDg47gUV8YfsbfsHN8Sf2WfAuvf8Ls+P2g /wBqaTFP/Z2keLRa2NnnPyQxGAlEHYEk+popWApf8FNP2TPjf8b/AIv+EtW8C65LrHhXz4YP7Dlu ls4PD9yTg6g23aZVAOfMBM8WXEW0uHj8v/ay/a71r9gX4hW3w50nxDPf/wBjaTpNxfT3D+WLq4lX VJpm8pThFZYYQI1woSNF5Ar9OZFBjPH8QFVL7QLC+m8yexs5pIydrPCrMvGOCR6E/ma8jFYC0nOl Nxcmr9T9M4c46Ulh8DmWFhWo4eMkopKDk3s5tRfM4+i5t5NvU/PX4uf8E7fi9rn7Zfh/XPh54wut J8G3jtqdt4ia8X7Z4fR9hltSjEm4LqcLkFJkG2fLRJIf0WsbGS2t1SSTzGCgFyAGYgYycADnrwBV e3+5D/tOc++C2P5D8q0q6sLhI0XKUW7tny/EHFGMzilh6WLUbUI8kWopSavvJ7yfT9NXf56/4KB/ sIR/tx+AvD+lR+IIfDOoeH9Sa8ivpLA3oaJ4XSSLYJY+S3lNu3ceXjBzx2H7HP7MVv8Ask/s9aH4 Fh1BNWk0xp57m/W3+z/bZpZnlZtm5toG4IAWOFRRmvVaK7eZnzZ83+I/2CLrxB/wUK0L46DxZDbw aLam1/sT+zCzz/6HcW2ftHmgL/ry+PKP3QPevo4KRGB/EB+dOopAfO/7LP7Ct1+zd+0T8TvHkvim 31pPiLcNOtiumtbHT83Es2DIZXEmBJtzsX7ue9eE+Bf+COfxH+Fmj+INN8L/ALQlx4d0zxQW/tK3 svDBQ3SlWXBf7XuBCuRkYOckYzivv6iq5mwPnn4Mf8E9dB+AX7KXiz4Z+H9Tl8/xhY3lvf6zdW6t JNNPAYRIYlKqFRTxGCMgfe5NeZ6r/wAEmdQ1H9hTTfgwPH1mklj4ifXTq/8AYbbGBWXEIt/tHGDJ 1MhGB0zX2lRSuB4P+0V+wnpH7Sv7Lug/DfWNWurSbw9FZ/Y9WtYgHint4DD5nlEkFXVnBQt/EOcq DXGfCL/gnN4h0z45+G/H3xK+KV98QtS8G2cdnotpDpS6XawCNSEeULI/msNzNk4JYqSW2ivquii4 Hx/49/4Je65F8WPHfiX4c/FS48CW/wAToJoPEdhLoMepLMJcl/IcyIYss8hBwWXfhWGK7C0/4Jte HdO/Yd1T4JW+vaslnrDLdXGssqtcPdrcRXIl8vhdnmQoPLB+4CM5Oa+kKKLsD5L+Gf7Ffx++D/gL SvDHh/8AaI0ey0TRLcWtlA3w9tpTDGOi7muCxx6kk0V9aUUXA//Z --_004_ce867501a70b470d9585f4eaf0715d95VAUSDITCHM2idirectnet_-- From nobody Wed May 6 09:32:06 2015 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 6F8B91B2C0D for ; Wed, 6 May 2015 09:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nSiuumg1gqrP for ; Wed, 6 May 2015 09:32:02 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF99E1B2C06 for ; Wed, 6 May 2015 09:30:40 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtp (envelope-from ) id <1Yq2DX-002Wle-8J>; Wed, 06 May 2015 18:30:39 +0200 Received: from [141.22.28.170] (helo=frankenbook-pro.cpt.haw-hamburg.de) by inpost2.zedat.fu-berlin.de (Exim 4.85) for manet@ietf.org with esmtpsa (envelope-from ) id <1Yq2DX-003nrB-60>; Wed, 06 May 2015 18:30:39 +0200 From: Lotte Steenbrink Content-Type: multipart/mixed; boundary="Apple-Mail=_1E2EFC61-3B86-45DD-9AFB-023C02067D80" Message-Id: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> Date: Wed, 6 May 2015 18:30:40 +0200 To: manet@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 141.22.28.170 X-ZEDAT-Hint: A Archived-At: Subject: [manet] RFC 5444 translation tables 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, 06 May 2015 16:32:04 -0000 --Apple-Mail=_1E2EFC61-3B86-45DD-9AFB-023C02067D80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, as promised in today's interim meeting, the updated section on RFC 5444 = messages in AODVv2. The idea is that this section merely details how to = translate the generic AODVv2 packet format which is used throughout the = draft into RFC 5444 messages. The primary goal was to make the = representation more readable, but we've made some tweaks to the way data = elements are encoded, too. I'd be very grateful about any feedback on = both whether our representation is easy to understand (and what might be = improved) as well as if there's anything that's illegal or could be = arranged more elegantly in terms of RFC 5444-ish-ness.=20 It's important to know that DEFAULT_METRIC_TYPE now has the value 0, so = not supplying an exttype for MetricType implicitly sets the metric type = to DEFAULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still = has the value 3, so as to remain consistent with RFC6551 and enable the = explicit declaration of hop count as the metric type.=20 In case there's any other context missing, please let me know. Victoria = has edited the draft pretty heavily to increase its readability and = clarity, so once the new revision is out, it should help provide some = more context, too. Regards, Lotte --Apple-Mail=_1E2EFC61-3B86-45DD-9AFB-023C02067D80 Content-Disposition: attachment; filename="RFC5444 section - Lotte 2.txt" Content-Type: text/plain; name="RFC5444 section - Lotte 2.txt" Content-Transfer-Encoding: quoted-printable The following sections show how AODVv2 data elements are represented in RFC 5444 messages. See Section 12 for more information about the Message TLVs and Address Block TLVs AODVv2 defines, and the type numbers allocated. 8.1. RREQ 8.1.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | msg_hop_limit | | MAX_HOPCOUNT | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | | Message Type | | RREQ | +---------------+-----------------+---------------------------------+ 8.1.2. Message TLV Block A RREQ contains no Message TLVs. 8.1.3. Address Block A RREQ contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. +-------------------------+-----------------------------------------+ | Data Elements | Address Block | +-------------------------+-----------------------------------------+ | OrigAddr/OrigPrefixLen |
and | | TargAddr/TargPrefixLen |
and | +-------------------------+-----------------------------------------+ 8.1.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each Address. 8.1.4.1. Address Block TLVs for OrigAddr Perkins, et al. Expires October 31, 2015 [Page 47] =0C Internet-Draft AODVv2 April 2015 +-------------+------------+------------+---------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+------------+------------+---------------------------+ | OrigSeqNum | OrigSeqNum | 0 | Sequence Number of | | | | | RREQ_Gen, the router | | | | | which initiated route | | | | | discovery. | | OrigMetric | Metric | MetricType | Metric for the route to | | /MetricType | | (optional) | OrigAddr, using | | | | | MetricType. | +-------------+------------+------------+---------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. 8.1.4.2. Address Block TLVs for TargAddr +----------------+------------+------------+------------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +----------------+------------+------------+------------------------+ | TargSeqNum | TargSeqNum | 0 | The last known | | (optional) | | | TargSeqNum for | | | | | TargAddr. | +----------------+------------+------------+------------------------+ 8.2. RREP 8.2.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | msg_hop_limit | | from | | | | corresponding RREQ. | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | | Message Type | | RREP | +---------------+-----------------+---------------------------------+ 8.2.2. Message TLV Block A RREP may contain the AckReq message TLV in order to monitor adjacency, as described in Section 6.2. Perkins, et al. Expires October 31, 2015 [Page 48] =0C Internet-Draft AODVv2 April 2015 +--------------------+-----------+-----------------+--------+ | Data Element | TLV Type | Extension Type | Value | +--------------------+-----------+-----------------+--------+ | AckReq (optional) | AckReq | 0 | None | +--------------------+-----------+-----------------+--------+ 8.2.3. Address Block A RREP contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. +-------------------------+-----------------------------------------+ | Data Elements | Address Block | +-------------------------+-----------------------------------------+ | OrigAddr/OrigPrefixLen |
and | | TargAddr/TargPrefixLen |
and | +-------------------------+-----------------------------------------+ 8.2.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each Address. 8.2.4.1. Address Block TLVs for OrigAddr No Address Block TLVs apply to OrigAddr in a RREP. 8.2.4.2. Address Block TLVs for TargAddr +-------------+------------+-------------+--------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+------------+-------------+--------------------------+ | TargSeqNum | TargSeqNum | 0 | Sequence number of | | | | | RREP_Gen, the router | | | | | which created the RREP. | | TargMetric | Metric | MetricType | Metric for the route to | | /MetricType | | (optional) | TargAddr, using | | | | | MetricType. | +-------------+------------+-------------+--------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. Perkins, et al. Expires October 31, 2015 [Page 49] =0C Internet-Draft AODVv2 April 2015 8.3. RREP_Ack 8.3.1. Message Header +----------------+------------------+-----------+ | Data Element | Header Field | Value | +----------------+------------------+-----------+ | msg_hop_limit | | 1 | | Message Type | | RREP_Ack | +----------------+------------------+-----------+ 8.3.2. Message TLV Block A RREP_Ack contains no Message TLVs. 8.3.3. Address Block A RREP_Ack contains no Address Block. 8.3.4. Address Block TLV Block A RREP_Ack contains no Address Block TLV Block. 8.4. RERR 8.4.1. Message Header +----------------+------------------+---------------+ | Data Element | Header Field | Value | +----------------+------------------+---------------+ | msg_hop_limit | | MAX_HOPCOUNT | | Message Type | | RERR | +----------------+------------------+---------------+ 8.4.2. Message TLV Block A RERR may contain the PktSource message TLV as detailed in Section 7.4. +-------------+-----------+-----------+-----------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+-----------+-----------+-----------------------------+ | PktSource | PktSource | 0 | The source IP address of | | (optional) | | | the packet triggering RERR | | | | | generation. | +-------------+-----------+-----------+-----------------------------+ Perkins, et al. Expires October 31, 2015 [Page 50] =0C Internet-Draft AODVv2 April 2015 8.4.3. Address Block A RERR contains one Address, the Unreachable Address, for each route that is no longer valid. Each address has an associated prefix length. +------------------------------+------------------------------------+ | Data Element | Address Block | +------------------------------+------------------------------------+ | AddressList/PrefixLengthList |
and | +------------------------------+------------------------------------+ 8.4.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following section shows the TLVs that apply to each Unreachable Address in the RERR. 8.4.4.1. Address Block TLVs for Unreachable Addresses +------------+--------+------------+--------------------------------+ | Data | TLV | Extension | Value | | Element | Type | Type | | +------------+--------+------------+--------------------------------+ | SeqNum | SeqNum | 0 | Sequence Number associated | | (optional) | | | with invalid route to the | | | | | Unreachable Address. | | MetricType | Metric | MetricType | None. Extension Type set to | | (optional) | | | MetricType of the route to the | | | | | Unreachable Address. | +------------+--------+------------+--------------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. --Apple-Mail=_1E2EFC61-3B86-45DD-9AFB-023C02067D80 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_1E2EFC61-3B86-45DD-9AFB-023C02067D80-- From nobody Wed May 6 10:40:27 2015 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 413A31A01CB for ; Wed, 6 May 2015 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 XkReM_byl1Q3 for ; Wed, 6 May 2015 10:40:22 -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 E2D691A8722 for ; Wed, 6 May 2015 10:40:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,380,1427756400"; d="scan'208,217";a="464014425" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 06 May 2015 18:40:00 +0100 X-IronPort-AV: E=Sophos;i="5.13,380,1427756400"; d="scan'208,217";a="101071114" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 06 May 2015 18:40:00 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0224.002; Wed, 6 May 2015 18:40:00 +0100 From: "Dearlove, Christopher (UK)" To: "manet@ietf.org" Thread-Topic: DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnA== Date: Wed, 6 May 2015 17:39:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7250GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: [manet] DLEP-10 comments 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, 06 May 2015 17:40:26 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7250GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Reading DLEP-10 here are my comments. These fall somewhere between a quick = glance and a detailed analysis. Terminology Early in the document there are references to signals and data items, witho= ut explaining the difference (which is given later). Why is the term signal= s used rather than the far more common messages? Introduction Seems to suggest that only cable/DSL have configuration issues. Is it worth being explicit that independent of routing protocol? Authorship In one place the draft refers to authors, in another to co-authors and WG. = Personally I tend to go with an impersonal style, but even if not, consiste= ncy is suggested. Transport mechanism and security Not totally consistent here. The draft is about UDP and TCP, then in sectio= n 2 TLS is suggested, but in section 10 DTLS. TBDs and IANA/RFCEd I think the TBDs scattered through the document will be a nuisance when it = comes to IANA and RFC Editor. In my experience IANA like tables in their se= ction (with TBDs in them) that they can directly copy, rather than lists th= at need numbers, that then someone (RFC Editor?) has to backfill through th= e report. I'm not saying they won't, I'm saying the interactions I've had w= ith them make this not what I think they'll like. In particular I'm sure th= ey won't like the "could we have some experimental values" but will want a = definite number, preferably in a table. And you will need an allocation pol= icy, and if Expert Review, nominated experts. I'd get some advice here. Section 5.0 (i.e. 5 before 5.1) This was initially confusing, how can something be optional at one end but = mandatory at the other - until you realise how things are driven, in 5.1. T= hat could be easier for the new reader. And on a related point, Appendices A and B are what I wanted. Could use ref= erences to them so the reader will go and look. Section 5.4 top of page 15, should that e.g. be an i.e.? Section 6 This has some misstements. It says the signal header is a TLV, no, it's jus= t a type and length. The signal (I still want to call it a message) is a TL= V, but the header is not. It also refers to data items following a signal. That should be following a= signal header. In fourth paragraph, add a comma after invalid (before and disallowed). It'= s ambiguous without, and the RFC Editor will put it (Oxford comma) in so mi= ght as well do it now. Tables Should these have captions? Should format pictures have captions? (I tend t= owards yes and no respectively). Section 7.3 top of page 20 The wording about own timing and heuristics doesn't look interoperable frie= ndly. 8.1 Version This is version 0.9 in draft -10. Should that have been updated in the upda= te from -09 to -10? That illustrates a problem with this approach - and ano= ther thing embedded in document to update for the RFC. UTF-8 Is it expected to have to verify the UTF-8 is valid in any way, or is any b= yte sequence acceptable? Incidentally 8.7 includes the one use of 1-octet in the draft, all the rest= are in bits. 8.10 and similar Add/Drop that only has two allowed values. Action on receiving other values= ? Should this be a bitfield with 7 bits reserved? (But you don't have any o= ther bitfields.) 8.18 I make 32 bits of microseconds a little over an hour maximum. Fine - unless= you deal with deep space probes (or other forms of DTN). Just to check we'= re happy with that. (We can be, but it should be deliberate, not an acciden= t.) Resources This is a bit vague on what the point is. Nits I'd rather see "use" rather than "utilize" in some places. a priori without a hyphen. -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7250GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Reading DLEP-10 here are my comments. These fall som= ewhere between a quick glance and a detailed analysis.

 

Terminology

 

Early in the document there are references to signal= s and data items, without explaining the difference (which is given later).= Why is the term signals used rather than the far more common messages?

 

Introduction

 

Seems to suggest that only cable/DSL have configurat= ion issues.

 

Is it worth being explicit that independent of routi= ng protocol?

 

Authorship

 

In one place the draft refers to authors, in another= to co-authors and WG. Personally I tend to go with an impersonal style, bu= t even if not, consistency is suggested.

 

Transport mechanism and security

 

Not totally consistent here. The draft is about UDP = and TCP, then in section 2 TLS is suggested, but in section 10 DTLS.

 

TBDs and IANA/RFCEd

 

I think the TBDs scattered through the document will= be a nuisance when it comes to IANA and RFC Editor. In my experience IANA = like tables in their section (with TBDs in them) that they can directly cop= y, rather than lists that need numbers, that then someone (RFC Editor?) has to backfill through the report. I̵= 7;m not saying they won’t, I’m saying the interactions I’= ve had with them make this not what I think they’ll like. In particul= ar I’m sure they won’t like the “could we have some exper= imental values” but will want a definite number, preferably in a table. And = you will need an allocation policy, and if Expert Review, nominated experts= .

 

I’d get some advice here.

 

Section 5.0 (i.e. 5 before 5.1)

 

This was initially confusing, how can something be o= ptional at one end but mandatory at the other – until you realise how= things are driven, in 5.1. That could be easier for the new reader.

 

And on a related point, Appendices A and B are what = I wanted. Could use references to them so the reader will go and look.=

 

Section 5.4 top of page 15, should that e.g. be an i= .e.?

 

Section 6

 

This has some misstements. It says the signal header= is a TLV, no, it’s just a type and length. The signal (I still want = to call it a message) is a TLV, but the header is not.

 

It also refers to data items following a signal. Tha= t should be following a signal header.

 

In fourth paragraph, add a comma after invalid (befo= re and disallowed). It’s ambiguous without, and the RFC Editor will p= ut it (Oxford comma) in so might as well do it now.

 

Tables

 

Should these have captions? Should format pictures h= ave captions? (I tend towards yes and no respectively).

 

Section 7.3 top of page 20

 

The wording about own timing and heuristics doesn= 217;t look interoperable friendly.

 

8.1 Version

 

This is version 0.9 in draft -10. Should that have b= een updated in the update from -09 to -10? That illustrates a problem with = this approach – and another thing embedded in document to update for = the RFC.

 

UTF-8

 

Is it expected to have to verify the UTF-8 is valid = in any way, or is any byte sequence acceptable?

 

Incidentally 8.7 includes the one use of 1-octet in = the draft, all the rest are in bits.

 

8.10 and similar

 

Add/Drop that only has two allowed values. Action on= receiving other values? Should this be a bitfield with 7 bits reserved? (B= ut you don’t have any other bitfields.)

 

8.18

 

I make 32 bits of microseconds a little over an hour= maximum. Fine – unless you deal with deep space probes (or other for= ms of DTN). Just to check we’re happy with that. (We can be, but it s= hould be deliberate, not an accident.)

 

Resources

 

This is a bit vague on what the point is.=

 

Nits

 

I’d rather see “use” rather than &= #8220;utilize” in some places.

 

a priori without a hyphen.

 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________= ________________________________________________

T:  +44 (0)1245 24= 2194  |  E: chris.dearlove@baesystems.com

BAE Systems Appli= ed Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Esse= x CM2 8HN.
www.baesystems.com/ai

B= AE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guil= dford, Surrey, GU2 7YP

 

 

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7250GLKXM0002VGREEN_-- From nobody Wed May 6 12:21:15 2015 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 6C2B01A9171 for ; Wed, 6 May 2015 12:21:14 -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 59QacHPBRMWH for ; Wed, 6 May 2015 12:21:12 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7E41A914D for ; Wed, 6 May 2015 12:21:11 -0700 (PDT) Received: by wiun10 with SMTP id n10so34189521wiu.1 for ; Wed, 06 May 2015 12:21:10 -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=K10Dh8pAkVZfoSA4XsENkn5Yap75gNMDXAW9zOGi/G0=; b=rUi8QoGFRfZ8Q+L+pqnxzWz/btiuThTFZmVZYq2Lz9E1mGE/hFQmdpc90A2OL5Z5Pb 1OH9dC3iMIBwHlz91/5viWD+/p9ZDfLG89DL8naKunU8Zgqq//snFBqAs8mXPiOewNwr TJ5zrirRsOHT+EV2wKSpk/YF2xscIHwt9CwdCy3dRQWh1ESHfm7dE0hflmhJ/qrhgRb4 AQFYR1Z2D9m0SLnw3Bn3jymR2XgJV2JhXWVWyARUi0HtnNObtiQ3rk1PUW2/vXcUxH+y cLK8VIfbsyrtjpARwEd05C0YSy8KnVZN6lU4z0+SOLZ+LVoVgxUTN1YYpqwwK0S/xbuQ SL7g== X-Received: by 10.180.20.14 with SMTP id j14mr2885112wie.45.1430940070505; Wed, 06 May 2015 12:21:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 6 May 2015 12:20:49 -0700 (PDT) In-Reply-To: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> From: Henning Rogge Date: Wed, 6 May 2015 21:20:49 +0200 Message-ID: To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: MANET IETF Subject: Re: [manet] RFC 5444 translation tables 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, 06 May 2015 19:21:14 -0000 Hi, just a few quick comments... > 8.3. RREP_Ack > > 8.3.1. Message Header > > +----------------+------------------+-----------+ > | Data Element | Header Field | Value | > +----------------+------------------+-----------+ > | msg_hop_limit | | 1 | > | Message Type | | RREP_Ack | > +----------------+------------------+-----------+ Setting msg_hop_limit to 1 is similar to not setting the field at all. Not setting it at all saves 1 byte. ;) > 8.4. RERR > > 8.4.2. Message TLV Block > > A RERR may contain the PktSource message TLV as detailed in > Section 7.4. > > +-------------+-----------+-----------+-----------------------------+ > | Data | TLV Type | Extension | Value | > | Element | | Type | | > +-------------+-----------+-----------+-----------------------------+ > | PktSource | PktSource | 0 | The source IP address of | > | (optional) | | | the packet triggering RERR | > | | | | generation. | > +-------------+-----------+-----------+-----------------------------+ Putting the Packet Source into an message TLV prevents you from compressing= it. Henning Rogge On Wed, May 6, 2015 at 6:30 PM, Lotte Steenbrink wrote: > Hi all, > as promised in today's interim meeting, the updated section on RFC 5444 m= essages in AODVv2. The idea is that this section merely details how to tran= slate the generic AODVv2 packet format which is used throughout the draft i= nto RFC 5444 messages. The primary goal was to make the representation more= readable, but we've made some tweaks to the way data elements are encoded,= too. I'd be very grateful about any feedback on both whether our represent= ation is easy to understand (and what might be improved) as well as if ther= e's anything that's illegal or could be arranged more elegantly in terms of= RFC 5444-ish-ness. > It's important to know that DEFAULT_METRIC_TYPE now has the value 0, so n= ot supplying an exttype for MetricType implicitly sets the metric type to D= EFAULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still has the= value 3, so as to remain consistent with RFC6551 and enable the explicit d= eclaration of hop count as the metric type. > > In case there's any other context missing, please let me know. Victoria h= as edited the draft pretty heavily to increase its readability and clarity,= so once the new revision is out, it should help provide some more context,= too. > > Regards, > Lotte > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed May 6 13:22:32 2015 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 D5D771B2EE5 for ; Wed, 6 May 2015 13:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 ZZasz0rJ3KAb for ; Wed, 6 May 2015 13:22:29 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id F04FF1B2EE6 for ; Wed, 6 May 2015 13:22:28 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t46KMMic026804; Wed, 6 May 2015 16:22:25 -0400 From: "Wiggins, David - 0665 - MITLL" To: "Goff, Thomas" , "manet@ietf.org" Thread-Topic: [manet] DLEP 09 Credit-Windowing Thread-Index: AQHQiDpbzEZ9hILyOUyRiccjyWBGow== Date: Wed, 6 May 2015 20:22:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3513774141_26397953" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-06_05:2015-05-05,2015-05-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505060238 Archived-At: Subject: Re: [manet] DLEP 09 Credit-Windowing 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, 06 May 2015 20:22:31 -0000 --B_3513774141_26397953 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I read through draft 10. Looks good. Just fix the minor version as Christopher pointed out. Authors, thanks for all of your efforts to clean it up. Regarding this: On 5/5/15, 8:36 PM, "Goff, Thomas" wrote: >- Support the use of unidirectional credit-windowing where each DLEP >participant can decided if credits should be used for data it receives >(on a per-destination basis). My understanding is that credit-windowing >and flow control is not needed for traffic flowing from the modem to a >router in most use cases. I think this part is possible with the current draft. The router will still have to advertise support of the credit-windowing extension to enable its peer to use credits because "an implementation MUST NOT emit any signal or data item associated with an optional extension that was not specified in the received initialization signal from its peer." (3.1) However, whenever the router sends a Destination Up, it can simply omit the Credit Grant data item. "If the Destination Up signal does not contain the Credit Grant data item, credits MUST NOT be used for that destination." (9.1.1) So it seems the use of flow control is already controllable per destination. If I have misunderstood something, please let me know. David --B_3513774141_26397953 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFEPydR2eDhPfe95H 5z9Tul9DDBZFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDUwNjIwMjIyMVowDQYJKoZIhvcNAQEBBQAEggEA0zwTVFPhP6d3DiRnBnkuQiEVVEs3sB3V 6TuDtbZE39Ej4/s6dyCwJSmlsjqRT1tE9L+o/VypoXXVIkZWTmRRtqHqFUiV2h7AFFQMrOHw Ftcjtfeuj4qdeJGcM/Ao8okJQ4KGXicHH2yv4X04uvwYYMxVWGzy07wNdHEEr6b+V/ruY9lP EWs6NQiXcfv16yLvV8u/v/w8/spNQLzPZo+/wX2DBAA86IVtfeYAjRWoBXTHFTHaGcob3cLo +EIdaBLqWFdaGAOkUrmjQsnYKYbYyqNoSc7J11L52e1SpVwjNsg7TzDcq6MjDWSfG51doKWa ZbsI2w2mQIUSu18dPmq3Yg== --B_3513774141_26397953-- From nobody Wed May 6 14:10:55 2015 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 E8C0F1B2F73 for ; Wed, 6 May 2015 14:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PHVIGhmaJwZT for ; Wed, 6 May 2015 14:10:52 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 95DC21B2F72 for ; Wed, 6 May 2015 14:10:52 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.201 as permitted sender) identity=mailfrom; client-ip=10.250.250.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@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.201; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,380,1427774400"; d="scan'208";a="17373367" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.201]) by ironport.idirect.net with ESMTP; 06 May 2015 17:10:52 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM1.idirect.net (10.250.250.201) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 6 May 2015 17:10:51 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Wed, 6 May 2015 17:10:51 -0400 From: "Ratliff, Stanley" To: "Wiggins, David - 0665 - MITLL" , "Goff, Thomas" , "manet@ietf.org" Thread-Topic: [manet] DLEP 09 Credit-Windowing Thread-Index: AQHQiDpbzEZ9hILyOUyRiccjyWBGo51vcZgA Date: Wed, 6 May 2015 21:10:50 +0000 Message-ID: References: In-Reply-To: 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: Subject: Re: [manet] DLEP 09 Credit-Windowing 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, 06 May 2015 21:10:54 -0000 David,=20 Your analysis of credit-window control by destination is spot-on. That was = the intent.=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, David - > 0665 - MITLL > Sent: Wednesday, May 06, 2015 4:22 PM > To: Goff, Thomas; manet@ietf.org > Subject: Re: [manet] DLEP 09 Credit-Windowing >=20 > I read through draft 10. Looks good. Just fix the minor version as Chri= stopher > pointed out. Authors, thanks for all of your efforts to clean it up. >=20 > Regarding this: >=20 > On 5/5/15, 8:36 PM, "Goff, Thomas" wrote: > >- Support the use of unidirectional credit-windowing where each DLEP > >participant can decided if credits should be used for data it receives > >(on a per-destination basis). My understanding is that > >credit-windowing and flow control is not needed for traffic flowing > >from the modem to a router in most use cases. >=20 > I think this part is possible with the current draft. The router will st= ill have to > advertise support of the credit-windowing extension to enable its peer to > use credits because "an implementation MUST NOT emit any signal or data > item associated with an optional extension that was not specified in the > received initialization signal from its peer." (3.1) However, whenever th= e > router sends a Destination Up, it can simply omit the Credit Grant data i= tem. > "If the Destination Up signal does not contain the Credit Grant data item= , > credits MUST NOT be used for that destination." (9.1.1) So it seems the = use > of flow control is already controllable per destination. >=20 > If I have misunderstood something, please let me know. >=20 > David From nobody Wed May 6 14:45:49 2015 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 084951B2FBE for ; Wed, 6 May 2015 14:45:48 -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 P-pM22YEAPck for ; Wed, 6 May 2015 14:45:46 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8CE1B2FB9 for ; Wed, 6 May 2015 14:45:46 -0700 (PDT) Received: by wgin8 with SMTP id n8so25563920wgi.0 for ; Wed, 06 May 2015 14:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=8jp4UMf7pTvruqePbdYbsKvA8NV+R1WXq91y7LyIlxs=; b=HGqKz9B0Q+4GU73W3PP2XPLNVSQoRlk0NwfzmfSzgfoepkZ7kZ4Q0KgKz8lRP6xKj1 rm+aYRoC6bvp7rVeWW8vu1416b5Clc1qgWLBb0qcYbr2YTk3kaWKuHUjGOYE/VjVr+Z9 XLt+6TsKGEpRIDLMIrlYaQeCRhVtQcPQgJas7HJV4Y4/ng9IigJzunUGaZkWy+LGIO5Q eGcZxRPWCBzIZePgSOsnM57yqctbVd67DsMySnoPEYZFfrT/hJXxqcM7NBnTk1sWx1vJ f29lRjeRz3pMh0k0rueKQTw0+u8jCcwfNU9u4vccMcldj8kFZ+j0+AqU7+DBwnioQqQ5 jtUA== MIME-Version: 1.0 X-Received: by 10.181.11.137 with SMTP id ei9mr885935wid.48.1430948745270; Wed, 06 May 2015 14:45:45 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.226.139 with HTTP; Wed, 6 May 2015 14:45:45 -0700 (PDT) Date: Wed, 6 May 2015 23:45:45 +0200 X-Google-Sender-Auth: ojZhD31RKAVbfkZg_gIZvQ0RIuc Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=f46d043892d7a75c05051570b7e2 Archived-At: Subject: [manet] Reactive path accumulation with RFC 5444 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, 06 May 2015 21:45:48 -0000 --f46d043892d7a75c05051570b7e2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, As promised in the interim, here is the link to our paper on the reactive path accumulation using RFC 5444. *Path Accumulation Extensions for the LOADng Routing Protocol in Sensor Networks* Internet of Vehicles =E2=80=93 Technologies and Services Lecture Notes in Computer Science Volume 8662, 2014, pp 150-159 http://www.thomasclausen.net/wp-content/uploads/2014/12/Path-Accumulation-E= xtensions-for-the-LOADng-Routing-Protocol-in-Sensor-Networks.pdf In the paper, we didn't introduce the exact RREQ/RREP format because of the page limit. Generally speaking, to record the order of accumulated path, the addresses of intermediate routers are associated with a PATH_ORDER TLV. It is implemented and tested. There are some more to do if we are using multiple interfaces, but it's totally feasible. We have started an Internet Draft on it, but haven't submitted yet. cheers Jiazi --f46d043892d7a75c05051570b7e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

As promised in the inte= rim, here is the link to our paper on the reactive path accumulation using = RFC 5444.=C2=A0

Path Accumulation Extensions fo= r the LOADng Routing Protocol in Sensor Networks

Internet of Vehicles =E2=80=93 Technologies and Services
<= div>Lecture Notes in Computer Science Volume 8662, 2014, pp 150-159


In the paper, we didn'= t introduce the exact RREQ/RREP format because of the page limit.=C2=A0
Generally speaking, to record the order of accumulated path, the add= resses of intermediate routers are associated with a PATH_ORDER TLV.=C2=A0<= /div>
It is implemented and tested. There are some more to do if we are= using multiple interfaces, but it's totally feasible.=C2=A0
= We have started an Internet Draft on it, but haven't submitted yet.=C2= =A0

cheers

Jiazi
--f46d043892d7a75c05051570b7e2-- From nobody Wed May 6 16:19:04 2015 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 8F7DE1B2F5B for ; Wed, 6 May 2015 16:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VtvYKiqvLOfs for ; Wed, 6 May 2015 16:19:01 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F4B1B2A5A for ; Wed, 6 May 2015 16:19:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id t46NJ0TK019099; Wed, 6 May 2015 18:19:00 -0500 Received: from XCH-PHX-211.sw.nos.boeing.com (xch-phx-211.sw.nos.boeing.com [130.247.25.140]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id t46NIqqt018596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 6 May 2015 18:18:53 -0500 Received: from XCH-BLV-103.nw.nos.boeing.com ([169.254.3.89]) by XCH-PHX-211.sw.nos.boeing.com ([169.254.11.126]) with mapi id 14.03.0235.001; Wed, 6 May 2015 16:18:52 -0700 From: "Goff, Thomas" To: "Ratliff, Stanley" , "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" Thread-Topic: [manet] DLEP 09 Credit-Windowing Thread-Index: AQHQiDpbzEZ9hILyOUyRiccjyWBGo51vcZgAgAAHmKA= Date: Wed, 6 May 2015 23:18:51 +0000 Message-ID: <6506326C46439D46B51105888E9958C920022FCC@XCH-BLV-103.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [manet] DLEP 09 Credit-Windowing 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, 06 May 2015 23:19:03 -0000 Just to clarify, by unidirectional credit-windowing I was referring to credit granting by only one DLEP participant (e.g. the modem) for a destination; the other participant (e.g. the router) would not grant credits for that destination. Is this supported by the current DLEP credit-windowing approach? My interpretation of section 9.2.1, specifically: If the initialization completes successfully, the receiver MUST respond to the Destination Up signal with a Destination Up ACK signal that contains a Credit Window Status data item, initializing its receive window. is that the receiver is effectively granting initial credits by "initializing its receive window". At that point credit windowing is active for the destination in both directions and each side is responsible for granting credits on its receive window. Is that a misinterpretation? Tom > -----Original Message----- > From: Ratliff, Stanley [mailto:sratliff@idirect.net] > Sent: Wednesday, May 06, 2015 2:11 PM > To: Wiggins, David - 0665 - MITLL; Goff, Thomas; manet@ietf.org > Subject: RE: [manet] DLEP 09 Credit-Windowing >=20 > David, >=20 > Your analysis of credit-window control by destination is spot-on. That > was the intent. >=20 > Regards, > Stan >=20 >=20 > > -----Original Message----- > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, > David - > > 0665 - MITLL > > Sent: Wednesday, May 06, 2015 4:22 PM > > To: Goff, Thomas; manet@ietf.org > > Subject: Re: [manet] DLEP 09 Credit-Windowing > > > > I read through draft 10. Looks good. Just fix the minor version as > Christopher > > pointed out. Authors, thanks for all of your efforts to clean it up. > > > > Regarding this: > > > > On 5/5/15, 8:36 PM, "Goff, Thomas" wrote: > > >- Support the use of unidirectional credit-windowing where each DLEP > > >participant can decided if credits should be used for data it > receives > > >(on a per-destination basis). My understanding is that > > >credit-windowing and flow control is not needed for traffic flowing > > >from the modem to a router in most use cases. > > > > I think this part is possible with the current draft. The router will > still have to > > advertise support of the credit-windowing extension to enable its peer > to > > use credits because "an implementation MUST NOT emit any signal or > data > > item associated with an optional extension that was not specified in > the > > received initialization signal from its peer." (3.1) However, whenever > the > > router sends a Destination Up, it can simply omit the Credit Grant > data item. > > "If the Destination Up signal does not contain the Credit Grant data > item, > > credits MUST NOT be used for that destination." (9.1.1) So it seems > the use > > of flow control is already controllable per destination. > > > > If I have misunderstood something, please let me know. > > > > David From nobody Wed May 6 18:05:33 2015 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 4AE561B3001 for ; Wed, 6 May 2015 18:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ET74fJGOtg4G for ; Wed, 6 May 2015 18:05:30 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F50D1B3000 for ; Wed, 6 May 2015 18:05:30 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.202 as permitted sender) identity=mailfrom; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.202; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,382,1427774400"; d="scan'208";a="7140526" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.202]) by ironport2.idirect.net with ESMTP; 06 May 2015 21:05:30 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM2.idirect.net (10.250.250.202) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 6 May 2015 21:05:29 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Wed, 6 May 2015 21:05:29 -0400 From: "Ratliff, Stanley" To: "Goff, Thomas" , "Wiggins, David - 0665 - MITLL" , "manet@ietf.org" Thread-Topic: [manet] DLEP 09 Credit-Windowing Thread-Index: AQHQiDpbzEZ9hILyOUyRiccjyWBGo51vcZgAgAAHmKCAADgVwA== Date: Thu, 7 May 2015 01:05:28 +0000 Message-ID: <7e493bffa65140ae95393608141406af@VAUSDITCHM2.idirect.net> References: <6506326C46439D46B51105888E9958C920022FCC@XCH-BLV-103.nw.nos.boeing.com> In-Reply-To: <6506326C46439D46B51105888E9958C920022FCC@XCH-BLV-103.nw.nos.boeing.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: Subject: Re: [manet] DLEP 09 Credit-Windowing 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, 07 May 2015 01:05:32 -0000 Tom,=20 You are correct - credits are on a per-destination basis, but once you turn= them on, it's bi-directional. It is possible for a router implementation t= o be minimal - for an example, the router would initialize the window to th= e maximum value, then=20 - as packets come in from the modem, they are counted.=20 - when the window is <=3D some pre-determined value (e.g., 50%? of max; 8= 0%? Of max, pick a number), then issue a credit grant to the radio, alterin= g window back up to maximum.=20 In other words, the router simply tries to keep the window at maximum. Havi= ng implemented that before, I can say it's pretty straightforward.=20 Regards, Stan > -----Original Message----- > From: Goff, Thomas [mailto:Thomas.Goff@boeing.com] > Sent: Wednesday, May 06, 2015 7:19 PM > To: Ratliff, Stanley; Wiggins, David - 0665 - MITLL; manet@ietf.org > Subject: RE: [manet] DLEP 09 Credit-Windowing >=20 > Just to clarify, by unidirectional credit-windowing I was referring to cr= edit > granting by only one DLEP participant (e.g. the modem) for a destination;= the > other participant (e.g. the router) would not grant credits for that > destination. Is this supported by the current DLEP credit-windowing > approach? >=20 > My interpretation of section 9.2.1, specifically: >=20 > If the initialization completes successfully, the receiver MUST > respond to the Destination Up signal with a Destination Up ACK signal > that contains a Credit Window Status data item, initializing its > receive window. >=20 > is that the receiver is effectively granting initial credits by "initiali= zing its > receive window". At that point credit windowing is active for the destin= ation > in both directions and each side is responsible for granting credits on i= ts > receive window. Is that a misinterpretation? >=20 > Tom >=20 > > -----Original Message----- > > From: Ratliff, Stanley [mailto:sratliff@idirect.net] > > Sent: Wednesday, May 06, 2015 2:11 PM > > To: Wiggins, David - 0665 - MITLL; Goff, Thomas; manet@ietf.org > > Subject: RE: [manet] DLEP 09 Credit-Windowing > > > > David, > > > > Your analysis of credit-window control by destination is spot-on. That > > was the intent. > > > > Regards, > > Stan > > > > > > > -----Original Message----- > > > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Wiggins, > > David - > > > 0665 - MITLL > > > Sent: Wednesday, May 06, 2015 4:22 PM > > > To: Goff, Thomas; manet@ietf.org > > > Subject: Re: [manet] DLEP 09 Credit-Windowing > > > > > > I read through draft 10. Looks good. Just fix the minor version as > > Christopher > > > pointed out. Authors, thanks for all of your efforts to clean it up. > > > > > > Regarding this: > > > > > > On 5/5/15, 8:36 PM, "Goff, Thomas" wrote: > > > >- Support the use of unidirectional credit-windowing where each > > > >DLEP participant can decided if credits should be used for data it > > receives > > > >(on a per-destination basis). My understanding is that > > > >credit-windowing and flow control is not needed for traffic flowing > > > >from the modem to a router in most use cases. > > > > > > I think this part is possible with the current draft. The router > > > will > > still have to > > > advertise support of the credit-windowing extension to enable its > > > peer > > to > > > use credits because "an implementation MUST NOT emit any signal or > > data > > > item associated with an optional extension that was not specified in > > the > > > received initialization signal from its peer." (3.1) However, > > > whenever > > the > > > router sends a Destination Up, it can simply omit the Credit Grant > > data item. > > > "If the Destination Up signal does not contain the Credit Grant data > > item, > > > credits MUST NOT be used for that destination." (9.1.1) So it seems > > the use > > > of flow control is already controllable per destination. > > > > > > If I have misunderstood something, please let me know. > > > > > > David From nobody Wed May 6 21:54:05 2015 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 B90821AC414 for ; Wed, 6 May 2015 21:54:04 -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 W7IqEbdNQLFB for ; Wed, 6 May 2015 21:54:03 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104B61AC409 for ; Wed, 6 May 2015 21:54:03 -0700 (PDT) Received: by wizk4 with SMTP id k4so227168658wiz.1 for ; Wed, 06 May 2015 21:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=cFDwrJjAdQLB0tWLTVmAfNHXidKGVfNYdx6T2MXwHEQ=; b=G0FAmtZRLXV+vk4ZAmK2uhTqMiXxvvZFmuHCpFLH0CeX+L+y5TaKbpB3iFB7Tn7XhU wcszyIoPTAig+51XdnbmBpIBaf0lZ+jNTqTnSjOy3KhO3ls9AH5LLT7/v+5R9A3f8ZA6 g11fH5dnA9LZj87IQf4xnbdtn5r5J1xjXBYvGvNwqQJynya8cXhFFHPKqiz/0zRh5mf/ tGKx5VJvbu3lHs+PlYcYP+bqru4ao7t+5lM7popUHosQTAu8L5geN1ahmjJ0FmAQy5oe ZNKGYg473p0qoRMXMFGJiLkgFEZHws5R4rv08ACzNVthZtqxGG23Qf9SuM+nlr50Kmg7 3rkw== X-Received: by 10.194.250.98 with SMTP id zb2mr3783899wjc.90.1430974441807; Wed, 06 May 2015 21:54:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 6 May 2015 21:53:41 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 7 May 2015 06:53:41 +0200 Message-ID: To: Jiazi YI Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet Subject: Re: [manet] Reactive path accumulation with RFC 5444 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, 07 May 2015 04:54:04 -0000 Ahh, so the "list of ordered addresses for source routing" is more restricted to reactive protocols. Olsrd2 with source routing doesn't need it (as an example). Henning Rogge On Wed, May 6, 2015 at 11:45 PM, Jiazi YI wrote: > Dear all, > > As promised in the interim, here is the link to our paper on the reactive > path accumulation using RFC 5444. > > Path Accumulation Extensions for the LOADng Routing Protocol in Sensor > Networks > > Internet of Vehicles =E2=80=93 Technologies and Services > Lecture Notes in Computer Science Volume 8662, 2014, pp 150-159 > > http://www.thomasclausen.net/wp-content/uploads/2014/12/Path-Accumulation= -Extensions-for-the-LOADng-Routing-Protocol-in-Sensor-Networks.pdf > > In the paper, we didn't introduce the exact RREQ/RREP format because of t= he > page limit. > Generally speaking, to record the order of accumulated path, the addresse= s > of intermediate routers are associated with a PATH_ORDER TLV. > It is implemented and tested. There are some more to do if we are using > multiple interfaces, but it's totally feasible. > We have started an Internet Draft on it, but haven't submitted yet. > > cheers > > Jiazi > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Thu May 7 00:35:24 2015 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 3B6841B2A73 for ; Thu, 7 May 2015 00:35:23 -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 c4uoz7LO_nWc for ; Thu, 7 May 2015 00:35:21 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C0411B2A76 for ; Thu, 7 May 2015 00:35:21 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so6948954wic.1 for ; Thu, 07 May 2015 00:35:19 -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=xYuzechnoHkcR0i4F0xVD9con++HdCyl2hw/o0yOaCw=; b=cMgLROb6M2Rf/iKeFhhDx6XvpxaH8bFO9hGfeePKlv5w1x0YtxKx96lWF9tJe7Knf1 CJYmdxA4RggxLYJpu9vZnlJ1yGw8muZGgjov+6V0YIupaP7xcWohgZr0aG3KCP7BKwEH TF+5XPRQfLUJWgCQe+lUNEJULZ1F6Yag0Rgb5U8FhTwiiDTvWSfZzD90gJPLzjLiWTVE eonWz+XA9Wyad/YY1rgcBYG/Y+OFkkPLOvSaHTKCDFYF+DTDv3UBk164d/pmzqlqwo/j 6qRAEYzUvnsuuCj6x6BS101p1HsoWB2MGQV5luISvr25ulnuKSZYsLK+Nz4SU82eJR89 fIhQ== MIME-Version: 1.0 X-Received: by 10.194.179.2 with SMTP id dc2mr4882473wjc.120.1430984119881; Thu, 07 May 2015 00:35:19 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.226.139 with HTTP; Thu, 7 May 2015 00:35:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 May 2015 09:35:19 +0200 X-Google-Sender-Auth: tp_GJksBp_vHthlAXQz5bEORqsI Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=089e013d1954251487051578f432 Archived-At: Cc: manet Subject: Re: [manet] Reactive path accumulation with RFC 5444 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, 07 May 2015 07:35:23 -0000 --089e013d1954251487051578f432 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No. I think we are only talking about reactive protocol here. Because of lack of global topology information, reactive protocol needs to accumulate the path information in the RREQ/RREP message to enable source routing. This concerns RFC5444. For OLSRv2, which has (reduced) global information, we only need to use the appropriate source routing header in data packets, which has nothing to do with RFC5444 messages. It's what olsrv2-multipath do. best Jiazi On Thu, May 7, 2015 at 6:53 AM, Henning Rogge wrote: > Ahh, > > so the "list of ordered addresses for source routing" is more > restricted to reactive protocols. Olsrd2 with source routing doesn't > need it (as an example). > > Henning Rogge > > On Wed, May 6, 2015 at 11:45 PM, Jiazi YI wrote: > > Dear all, > > > > As promised in the interim, here is the link to our paper on the reacti= ve > > path accumulation using RFC 5444. > > > > Path Accumulation Extensions for the LOADng Routing Protocol in Sensor > > Networks > > > > Internet of Vehicles =E2=80=93 Technologies and Services > > Lecture Notes in Computer Science Volume 8662, 2014, pp 150-159 > > > > > http://www.thomasclausen.net/wp-content/uploads/2014/12/Path-Accumulation= -Extensions-for-the-LOADng-Routing-Protocol-in-Sensor-Networks.pdf > > > > In the paper, we didn't introduce the exact RREQ/RREP format because of > the > > page limit. > > Generally speaking, to record the order of accumulated path, the > addresses > > of intermediate routers are associated with a PATH_ORDER TLV. > > It is implemented and tested. There are some more to do if we are using > > multiple interfaces, but it's totally feasible. > > We have started an Internet Draft on it, but haven't submitted yet. > > > > cheers > > > > Jiazi > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > > > --089e013d1954251487051578f432 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No. I think we are only talking about reactive protocol he= re. Because of lack of global topology information, reactive protocol needs= to accumulate the path information in the RREQ/RREP message to enable sour= ce routing. This concerns RFC5444.=C2=A0

For OLSRv2, whi= ch has (reduced) global information, we only need to use the appropriate so= urce routing header in data packets, which has nothing to do with RFC5444 m= essages. It's what olsrv2-multipath do.=C2=A0

= best

Jiazi
<= br>
On Thu, May 7, 2015 at 6:53 AM, Henning Rogge= <hrogge@gmail.com> wrote:
= Ahh,

so the "list of ordered addresses for source routing" is more
restricted to reactive protocols. Olsrd2 with source routing doesn't need it (as an example).

Henning Rogge

On Wed, May 6, 2015 at 11:45 PM, Jiazi YI <ietf@jiaziyi.com> wrote:
> Dear all,
>
> As promised in the interim, here is the link to our paper on the react= ive
> path accumulation using RFC 5444.
>
> Path Accumulation Extensions for the LOADng Routing Protocol in Sensor=
> Networks
>
> Internet of Vehicles =E2=80=93 Technologies and Services
> Lecture Notes in Computer Science Volume 8662, 2014, pp 150-159
>
> http://www.thomasclausen.net/wp-content/uploads/20= 14/12/Path-Accumulation-Extensions-for-the-LOADng-Routing-Protocol-in-Senso= r-Networks.pdf
>
> In the paper, we didn't introduce the exact RREQ/RREP format becau= se of the
> page limit.
> Generally speaking, to record the order of accumulated path, the addre= sses
> of intermediate routers are associated with a PATH_ORDER TLV.
> It is implemented and tested. There are some more to do if we are usin= g
> multiple interfaces, but it's totally feasible.
> We have started an Internet Draft on it, but haven't submitted yet= .
>
> cheers
>
> Jiazi
>
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>

--089e013d1954251487051578f432-- From nobody Thu May 7 03:00:48 2015 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 7CDB51A0141 for ; Thu, 7 May 2015 03:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 mnpyNogeQqx2 for ; Thu, 7 May 2015 03:00:43 -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 9F3121A0123 for ; Thu, 7 May 2015 03:00:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,384,1427756400"; d="scan'208,217";a="549897402" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 07 May 2015 11:00:42 +0100 X-IronPort-AV: E=Sophos; i="5.13,384,1427756400"; d="scan'208,217"; a="97174304" Received: from glkxh0003v.greenlnk.net ([10.109.2.34]) by baemasmds017.greenlnk.net with ESMTP; 07 May 2015 11:00:41 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0003V.GREENLNK.net ([10.109.2.34]) with mapi id 14.03.0224.002; Thu, 7 May 2015 11:00:40 +0100 From: "Dearlove, Christopher (UK)" To: Lotte Steenbrink , "manet@ietf.org" Thread-Topic: [manet] RFC 5444 translation tables Thread-Index: AQHQiBo0ZM63Aqka3kqbkDjZ519xRZ1wR18Q Date: Thu, 7 May 2015 10:00:40 +0000 Message-ID: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> In-Reply-To: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7A14GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] RFC 5444 translation tables 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, 07 May 2015 10:00:47 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7A14GLKXM0002VGREEN_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable There is a style question that all existing TLVs have names like LINK_STATU= S, while here TLVs have names like OrigSeqNum. I don't think IANA enforce s= uch issues, and different people will have different opinions on the import= ance of consistent style. (Naming can matter, we're spending cycles on an I= D just about TLV names.) (I haven't checked if planning to use message specific TLV numbering range.) -- Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte Steenbrink Sent: 06 May 2015 17:31 To: manet@ietf.org Subject: [manet] RFC 5444 translation tables ----------------------! 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. -------------------------------------------------------- Hi all, as promised in today's interim meeting, the updated section on RFC 5444 mes= sages in AODVv2. The idea is that this section merely details how to transl= ate the generic AODVv2 packet format which is used throughout the draft int= o RFC 5444 messages. The primary goal was to make the representation more r= eadable, but we've made some tweaks to the way data elements are encoded, t= oo. I'd be very grateful about any feedback on both whether our representat= ion is easy to understand (and what might be improved) as well as if there'= s anything that's illegal or could be arranged more elegantly in terms of R= FC 5444-ish-ness. It's important to know that DEFAULT_METRIC_TYPE now has the value 0, so not= supplying an exttype for MetricType implicitly sets the metric type to DEF= AULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still has the v= alue 3, so as to remain consistent with RFC6551 and enable the explicit dec= laration of hop count as the metric type. In case there's any other context missing, please let me know. Victoria has= edited the draft pretty heavily to increase its readability and clarity, s= o once the new revision is out, it should help provide some more context, t= oo. Regards, Lotte _______________________________________________ manet mailing list manet@ietf.org https://www.ietf.org/mailman/listinfo/manet ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7A14GLKXM0002VGREEN_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

There is a style question= that all existing TLVs have names like LINK_STATUS, while here TLVs have n= ames like OrigSeqNum. I don’t think IANA enforce such issues, and different people will have different opinions on the importance of con= sistent style. (Naming can matter, we’re spending cycles on an ID jus= t about TLV names.)

 <= /p>

(I haven’t checked = if planning to use message specific TLV numbering range.)=

 <= /p>

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
____________________________________= ______________________________________

T: &nb= sp;+44 (0)1245 242194  |  E: chris.dearlove@baesyst= ems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP=

 

 <= /p>

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte Steenbrink
Sent: 06 May 2015 17:31
To: manet@ietf.org
Subject: [manet] RFC 5444 translation tables

 

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

Hi all,
as promised in today's interim meeting, the updated section on RFC 5444 mes= sages in AODVv2. The idea is that this section merely details how to transl= ate the generic AODVv2 packet format which is used throughout the draft int= o RFC 5444 messages. The primary goal was to make the representation more readable, but we've made some twe= aks to the way data elements are encoded, too. I'd be very grateful about a= ny feedback on both whether our representation is easy to understand (and w= hat might be improved) as well as if there's anything that's illegal or could be arranged more elegantly in = terms of RFC 5444-ish-ness.
It's important to know that DEFAULT_METRIC_TYPE now has the value 0, so not= supplying an exttype for MetricType implicitly sets the metric type to DEF= AULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still has the v= alue 3, so as to remain consistent with RFC6551 and enable the explicit declaration of hop count as the metri= c type.

In case there's any other context missing, please let me know. Victoria has= edited the draft pretty heavily to increase its readability and clarity, s= o once the new revision is out, it should help provide some more context, t= oo.

Regards,
Lotte



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

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

--_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EE7A14GLKXM0002VGREEN_-- From nobody Thu May 7 09:56:51 2015 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 EA5F81A024C for ; Thu, 7 May 2015 09:56:50 -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 uZkh6avJmZTh for ; Thu, 7 May 2015 09:56:46 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804E51ACDAF for ; Thu, 7 May 2015 09:56:46 -0700 (PDT) Received: by wizk4 with SMTP id k4so250579650wiz.1 for ; Thu, 07 May 2015 09:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+aWxFxXqQIcskDt9f23QXo3QUdGn645rUgq3iXhxwvU=; b=bqf4LpQRTtTB1LuXuMREC51GZLJuc3TPuzKsWsPI/Wn7Z7tIl9lL+2/YUIK1BByUq1 QJi4IAYoP1FSuBL0A0Mf9qOIf6nIIqxiEd1FkS9G2RCYon2u+x0NQlN7pBY2JxDJvqai i+/Q0YHwnP1WndZHQ2X1fCwOUXOQHMsR3UbxmT2IIeFiADT7mBknmYPaTnDnz/t5cbFN NPK91iK1H1l4mpBhTaq+mttIidfEGiSYztpubt/itVjhe2j8yJJ3H2Z/AAsXVEAXbjvw PSWfZMDKLNKn/DLF04jHqRFlCaXPTnh+0IR7mvgky9x/eXouATNywYHtHa7tAIXlls3V lOIw== X-Received: by 10.194.192.226 with SMTP id hj2mr1048282wjc.51.1431017805349; Thu, 07 May 2015 09:56:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Thu, 7 May 2015 09:56:24 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Thu, 7 May 2015 18:56:24 +0200 Message-ID: To: Debarshi Sanyal Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Regarding use of Reed-Solomon code in wireless networks 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, 07 May 2015 16:56:51 -0000 On Tue, May 5, 2015 at 4:13 PM, Debarshi Sanyal wrote: > Hi, > > We were working on design of wormhole detection methods in MANETs. > To achieve detection, we propose to measure the time taken for a test nonce > to move from one node to it's neighbor node. > > Now to combat channel errors, is it worth to encode the nonce with > Reed-Solomon code? > > Our understanding is that propagation time between neighbor nodes in > commodity wi-fi setups is much smaller than the time taken to encode and > decode a nonce (say, 64 bytes long). It depends on a lot of things... while transmission might be fast, media access can be very slow in the presence of traffic and hidden terminals. Henning Rogge From nobody Thu May 7 12:44:12 2015 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 558EE1A8FD5; Thu, 7 May 2015 12:44:11 -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] 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 AwQoPe_tzVG8; Thu, 7 May 2015 12:44:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA9E1A9118; Thu, 7 May 2015 12:44:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150507194405.25186.68407.idtracker@ietfa.amsl.com> Date: Thu, 07 May 2015 12:44:05 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-tlv-naming-02.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:44:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : TLV Naming in the MANET Generalized Packet/Message Format Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-tlv-naming-02.txt Pages : 16 Date : 2015-05-07 Abstract: TLVs (type-length-value structures) as defined by RFC5444 have both a type (one octet) and a type extension (one octet), together forming a full type (of two octets). RFC5444 sets up IANA registries for TLV types, specifying that an allocation of a TLV type entails creation of an IANA registry for the corresponding type extensions. In some cases, reserving all 256 type extensions for use for a common purpose for a given TLV is meaningful, and thus it makes sense to record a common name for such a TLV type (and all of its type extensions) in the corresponding IANA registries. An example of such is a LINK_METRIC TLV Type, with its type extensions reserved for use to be indicating the "kind" of metric expressed by the value of the TLV. In some other cases, there may not be 256 full types that share a common purpose and, as such, it is not meaningful to record a common name for all the type extensions for a TLV type in the corresponding IANA registries. Rather, it is appropriate to record an individual name per full type. This document reorganizes the naming of already allocated TLV types and type extensions in those registries to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-tlv-naming-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-tlv-naming-02 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 8 05:37:37 2015 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 CB1561A004D for ; Fri, 8 May 2015 05:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Ccu7OhyMSIzS for ; Fri, 8 May 2015 05:37:34 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35951A004A for ; Fri, 8 May 2015 05:37:33 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so52103030lbb.2 for ; Fri, 08 May 2015 05:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZHl7TsQbhAxAQ+CM/nJRtWhhJzZL1KZzDRP5L1NM/1s=; b=IaKr5yuzkCMVlGDy23GB88yJEVk59DQgrJDWig7uK6rN7MHpch1uJaCMyYGoblcvs+ Ny1diiK6pJ9T2UpPtVyoy1YRWVbkgAxQY34xU9em0V1fDSZKRdk6hG0gr+jFXru6aeqo GxfSGKloSzJw9No27Om40P2/x+p3GWJHso+EyuKn5Jyyu6DEFgtrmpf9LMjN5tpq/vIz ufJTHBFTu8Af2T/+QpN5IHQXdc1w8AydjPCl10TvT/UQ/EOr5gvL6USYqcQzLEb/PBMP mDpy1PG/wBstDPnEP2hfY5iL8+B03ewCQNoIFCl0E3cQnz6c5EixW0rxzGm90YlpKZav ubnA== MIME-Version: 1.0 X-Received: by 10.152.7.209 with SMTP id l17mr2806209laa.100.1431088652409; Fri, 08 May 2015 05:37:32 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Fri, 8 May 2015 05:37:32 -0700 (PDT) In-Reply-To: References: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> Date: Fri, 8 May 2015 13:37:32 +0100 Message-ID: From: Victoria Mercieca To: manet@ietf.org Content-Type: multipart/alternative; boundary=001a11c33c0ac4e0210515914a7a Archived-At: Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 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, 08 May 2015 12:37:37 -0000 --001a11c33c0ac4e0210515914a7a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I was not able to join the meeting - is there a recording I could listen to or did anyone write any notes they wouldn't mind sending? Regards, Victoria Mercieca. On Wed, May 6, 2015 at 3:27 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Not sure if I=E2=80=99ll make it. But my mistake on timing, forgot we we= re now > UTC+1. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > *From:* Justin Dean [mailto:bebemaster@gmail.com] > *Sent:* 06 May 2015 15:26 > *To:* Dearlove, Christopher (UK); ietf@ietf.org; IETF Announcement List > *Cc:* manet@ietf.org > *Subject:* Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > It hasn't yet started. Im in the room now but you should be able to join > at 11. In 35 mins or so. > > > > On Wed, May 6, 2015, 10:12 AM Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com> wrote: > > This meeting does not, according to the webex link, appear to be happenin= g. > > -- > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > _________________________________________________________________________= _ > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of IESG Secretary > Sent: 20 April 2015 22:11 > To: IETF Announcement List > Cc: manet@ietf.org > Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 > > ----------------------! 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. > -------------------------------------------------------- > > The Mobile Ad-hoc Networks (manet) working group will hold a virtual > interim meeting as follows: > > Date: Wednesday, May 6, 2015 > Time: 1100-1300 EDT (1500-1700 UTC) > > > JOIN WEBEX MEETING > https://ietf.webex.com/ietf/j.php?MTID=3Dm2f5c335024d36b7e80e2653ea077476= 9 > Meeting number: 649 415 639 > Meeting password: 12345 > > > JOIN BY PHONE > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639 > > Toll-free dialing restrictions: > http://www.webex.com/pdf/tollfree_restrictions.pdf > > > Add this meeting to your calendar: > https://ietf.webex.com/ietf/j.php?MTID=3Dm0e3fb44d1bbbef98f5b0cf9e4651cd1= e > > > Can't join the meeting? Contact support here: > https://ietf.webex.com/ietf/mc > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automaticall= y > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c33c0ac4e0210515914a7a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I was not able to join the meet= ing - is there a recording I could listen to or did anyone write any notes = they wouldn't mind sending?

Regards,
Victoria Mercieca.

On Wed, May 6, 2015 at 3:27 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Not sure if I=E2=80=99ll = make it. But my mistake on timing, forgot we were now UTC+1.<= /span>

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
____________________________________= ______________________________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<= u>

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

=C2=A0

From: Justin Dean [mailto:bebemaster@gmail.com]
Sent: 06 May 2015 15:26
To: Dearlove, Christopher (UK); ietf@ietf.org; IETF Announcement List
Cc: manet@ietf.o= rg
Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015=

=C2=A0

=C2=A0

*** WARNING ***<= /b>

This message originates from outside our organ= isation, either from an external partner or the internet.
Co= nsider carefully whether you should click on any links, open any attachment= s or reply.
Fo= r information regarding Red Flags that you can look out for in emails you rec= eive, click here.
If= you feel the email is suspicious, please follow this process.=

It hasn't yet started. Im in the room now but you should be able to = join at 11. In 35 mins or so.

=C2=A0

On Wed, May 6, 2015, 10:12 AM=C2=A0Dearlove, Christo= pher (UK) <chris.dearlove@baesystems.com> wrote:

This meeting does not, according to the webex link, = appear to be happening.

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
__________________________________________________________________________<= br>
T: =C2=A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN.
www.baesystems.c= om/ai
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP



-----Original Message-----
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of IESG Secretary
Sent: 20 April 2015 22:11
To: IETF Announcement List
Cc: manet@ietf.org<= br> Subject: [manet] MANET WG Virtual Interim Meeting: 6 May 2015

----------------------! 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 instru= ctions on reporting suspicious email messages.
--------------------------------------------------------

The Mobile Ad-hoc Networks (manet) working group will hold a virtual interi= m meeting as follows:

Date: Wednesday, May 6, 2015
Time: 1100-1300 EDT (1500-1700 UTC)


JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=3Dm2f5= c335024d36b7e80e2653ea0774769
Meeting number: 649 415 639
Meeting password: 12345


JOIN BY PHONE
1-8= 77-668-4493 Call-in toll free number (US/Canada)
1-6= 50-479-3208 Call-in toll number (US/Canada) Access code: 649 415 639
Toll-free dialing restrictions:
http://www.webex.com/pdf/tollfree_restrictions.pdf


Add this meeting to your calendar:
https://ietf.webex.com/ietf/j.php?MTID=3Dm0e3= fb44d1bbbef98f5b0cf9e4651cd1e


Can't join the meeting? Contact support here:
https://ietf.w= ebex.com/ietf/mc


IMPORTANT NOTICE: Please note that this WebEx service allows audio and othe= r information sent during the session to be recorded, which may be discover= able in a legal matter. By joining this session, you automatically consent = to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not j= oin the session.

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

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

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


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


--001a11c33c0ac4e0210515914a7a-- From nobody Fri May 8 06:36:27 2015 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 8B5191A0AF8 for ; Fri, 8 May 2015 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EZQ0RmoAqfT8 for ; Fri, 8 May 2015 06:36:19 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9734A1A040B for ; Fri, 8 May 2015 06:36:18 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,391,1427774400"; d="scan'208,217";a="7171010" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport2.idirect.net with ESMTP; 08 May 2015 09:36:18 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 8 May 2015 09:36:17 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Fri, 8 May 2015 09:36:17 -0400 From: "Ratliff, Stanley" To: Victoria Mercieca , "manet@ietf.org" Thread-Topic: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 Thread-Index: AQHQe66ZicghVG5gBEywTHaqX8DwOp1yIDQhgAAP1QA= Date: Fri, 8 May 2015 13:36:16 +0000 Message-ID: References: <20150420211128.30629.58872.idtracker@ietfa.amsl.com> In-Reply-To: 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: multipart/alternative; boundary="_000_ce1abeaae43a4d0ebfc15a0c3281b844VAUSDITCHM2idirectnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] MANET WG Virtual Interim Meeting: 6 May 2015 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, 08 May 2015 13:36:25 -0000 --_000_ce1abeaae43a4d0ebfc15a0c3281b844VAUSDITCHM2idirectnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmljdG9yaWEvQWxsIOKAkw0KDQpUaGUgbWVldGluZyB3YXMgcmVjb3JkZWQuIFVSTHMgZm9yIGZl dGNoaW5nIGFyZToNCg0KU3RyZWFtaW5nIFVSTDogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2xkci5waHA/UkNJRD04YjVmNWQ4MGM4NzQ4NDE5OTcwZjA0ODg4ZDAyNWMzNw0KDQpEb3dubG9h ZCBVUkw6IGh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9MTJhYzdmNGI3 M2Y5NjE1ODVkY2Y0ZjcwZGU3Yzk0NDENCg0KUmVnYXJkcywNClN0YW4NCg0KRnJvbTogbWFuZXQg W21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmljdG9yaWEgTWVy Y2llY2ENClNlbnQ6IEZyaWRheSwgTWF5IDA4LCAyMDE1IDg6MzggQU0NClRvOiBtYW5ldEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFttYW5ldF0gTUFORVQgV0cgVmlydHVhbCBJbnRlcmltIE1lZXRp bmc6IDYgTWF5IDIwMTUNCg0KSGkgYWxsLA0KDQpJIHdhcyBub3QgYWJsZSB0byBqb2luIHRoZSBt ZWV0aW5nIC0gaXMgdGhlcmUgYSByZWNvcmRpbmcgSSBjb3VsZCBsaXN0ZW4gdG8gb3IgZGlkIGFu eW9uZSB3cml0ZSBhbnkgbm90ZXMgdGhleSB3b3VsZG4ndCBtaW5kIHNlbmRpbmc/DQoNClJlZ2Fy ZHMsDQpWaWN0b3JpYSBNZXJjaWVjYS4NCg0KT24gV2VkLCBNYXkgNiwgMjAxNSBhdCAzOjI3IFBN LCBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj4gd3JvdGU6DQpOb3Qgc3Vy ZSBpZiBJ4oCZbGwgbWFrZSBpdC4gQnV0IG15IG1pc3Rha2Ugb24gdGltaW5nLCBmb3Jnb3Qgd2Ug d2VyZSBub3cgVVRDKzEuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9yIFByaW5j aXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQ8dGVsOiUyQjQ0JTIwJTI4MCUyOTEy NDUlMjAyNDIxOTQ+ICB8ICBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86 Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+DQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50 ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVs bXNmb3JkLCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6Ly93d3cu YmFlc3lzdGVtcy5jb20vYWk+DQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1p dGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBObzogMDEzMzc0NTENClJlZ2lzdGVy ZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3 WVANCg0KDQpGcm9tOiBKdXN0aW4gRGVhbiBbbWFpbHRvOmJlYmVtYXN0ZXJAZ21haWwuY29tPG1h aWx0bzpiZWJlbWFzdGVyQGdtYWlsLmNvbT5dDQpTZW50OiAwNiBNYXkgMjAxNSAxNToyNg0KVG86 IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGll dGYub3JnPjsgSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0 bzptYW5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbWFuZXRdIE1BTkVUIFdHIFZpcnR1YWwg SW50ZXJpbSBNZWV0aW5nOiA2IE1heSAyMDE1DQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1l c3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZy b20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVs bHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNo bWVudHMgb3IgcmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0 IHlvdSBjYW4gbG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxo dHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90 bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5l dC5lbnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1l bnRzL0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KDQpJdCBoYXNu J3QgeWV0IHN0YXJ0ZWQuIEltIGluIHRoZSByb29tIG5vdyBidXQgeW91IHNob3VsZCBiZSBhYmxl IHRvIGpvaW4gYXQgMTEuIEluIDM1IG1pbnMgb3Igc28uDQoNCk9uIFdlZCwgTWF5IDYsIDIwMTUs IDEwOjEyIEFNIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspIDxjaHJpcy5kZWFybG92ZUBiYWVz eXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20+PiB3cm90ZToN ClRoaXMgbWVldGluZyBkb2VzIG5vdCwgYWNjb3JkaW5nIHRvIHRoZSB3ZWJleCBsaW5rLCBhcHBl YXIgdG8gYmUgaGFwcGVuaW5nLg0KDQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQ cmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQpUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAl MjkxMjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFp bHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8v d3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2Ug TGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdp c3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBH VTIgN1lQDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbWFuZXQgW21h aWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn Pl0gT24gQmVoYWxmIE9mIElFU0cgU2VjcmV0YXJ5DQpTZW50OiAyMCBBcHJpbCAyMDE1IDIyOjEx DQpUbzogSUVURiBBbm5vdW5jZW1lbnQgTGlzdA0KQ2M6IG1hbmV0QGlldGYub3JnPG1haWx0bzpt YW5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFttYW5ldF0gTUFORVQgV0cgVmlydHVhbCBJbnRlcmlt IE1lZXRpbmc6IDYgTWF5IDIwMTUNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAh IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig ZnJvbSB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxk IGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xs b3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3Ig aW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K VGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgKG1hbmV0KSB3b3JraW5nIGdyb3VwIHdpbGwgaG9s ZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIGFzIGZvbGxvd3M6DQoNCkRhdGU6IFdlZG5lc2Rh eSwgTWF5IDYsIDIwMTUNClRpbWU6IDExMDAtMTMwMCBFRFQgKDE1MDAtMTcwMCBVVEMpDQoNCg0K Sk9JTiBXRUJFWCBNRUVUSU5HDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tMmY1YzMzNTAyNGQzNmI3ZTgwZTI2NTNlYTA3NzQ3NjkNCk1lZXRpbmcgbnVtYmVyOiA2NDkg NDE1IDYzOQ0KTWVldGluZyBwYXNzd29yZDogMTIzNDUNCg0KDQpKT0lOIEJZIFBIT05FDQoxLTg3 Ny02NjgtNDQ5Mzx0ZWw6MS04NzctNjY4LTQ0OTM+IENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAo VVMvQ2FuYWRhKQ0KMS02NTAtNDc5LTMyMDg8dGVsOjEtNjUwLTQ3OS0zMjA4PiBDYWxsLWluIHRv bGwgbnVtYmVyIChVUy9DYW5hZGEpIEFjY2VzcyBjb2RlOiA2NDkgNDE1IDYzOQ0KDQpUb2xsLWZy ZWUgZGlhbGluZyByZXN0cmljdGlvbnM6DQpodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZy ZWVfcmVzdHJpY3Rpb25zLnBkZg0KDQoNCkFkZCB0aGlzIG1lZXRpbmcgdG8geW91ciBjYWxlbmRh cjoNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW0wZTNmYjQ0ZDFiYmJl Zjk4ZjViMGNmOWU0NjUxY2QxZQ0KDQoNCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qg c3VwcG9ydCBoZXJlOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jDQoNCg0KSU1QT1JU QU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1 ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSBy ZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkg am9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCBy ZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1 c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9u Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFu ZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq DQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUg aW50ZW5kZWQNCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkDQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIg c3lzdGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci4NCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3Ig dXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3INCmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQpt YW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1h aWx0bzptYW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWFuZXQNCg0K --_000_ce1abeaae43a4d0ebfc15a0c3281b844VAUSDITCHM2idirectnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VmljdG9yaWEvQWxsIOKAkw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5UaGUgbWVldGluZyB3YXMgcmVjb3JkZWQuIFVSTHMgZm9yIGZldGNoaW5nIGFyZToNCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RyZWFtaW5nIFVSTDoN CjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sZHIucGhwP1JDSUQ9OGI1ZjVk ODBjODc0ODQxOTk3MGYwNDg4OGQwMjVjMzciPg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2xkci5waHA/UkNJRD04YjVmNWQ4MGM4NzQ4NDE5OTcwZjA0ODg4ZDAyNWMzNzwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRvd25sb2FkIFVSTDoNCjxhIGhy ZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9sc3IucGhwP1JDSUQ9MTJhYzdmNGI3M2Y5 NjE1ODVkY2Y0ZjcwZGU3Yzk0NDEiPg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5w aHA/UkNJRD0xMmFjN2Y0YjczZjk2MTU4NWRjZjRmNzBkZTdjOTQ0MTwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+U3RhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+VmljdG9yaWEgTWVyY2llY2E8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBNYXkgMDgsIDIwMTUgODozOCBBTTxicj4NCjxiPlRvOjwvYj4gbWFuZXRAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFttYW5ldF0gTUFORVQgV0cgVmlydHVhbCBJbnRl cmltIE1lZXRpbmc6IDYgTWF5IDIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSB3YXMgbm90IGFibGUgdG8gam9pbiB0aGUgbWVldGluZyAtIGlz IHRoZXJlIGEgcmVjb3JkaW5nIEkgY291bGQgbGlzdGVuIHRvIG9yIGRpZCBhbnlvbmUgd3JpdGUg YW55IG5vdGVzIHRoZXkgd291bGRuJ3QgbWluZCBzZW5kaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmljdG9yaWEgTWVyY2llY2Eu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgTWF5IDYsIDIwMTUgYXQgMzoyNyBQTSwgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykg Jmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Tm90IHN1 cmUgaWYgSeKAmWxsIG1ha2UgaXQuIEJ1dCBteSBtaXN0YWtlIG9uIHRpbWluZywgZm9yZ290IHdl IHdlcmUgbm93IFVUQyYjNDM7MS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0U3RSI+LS0NCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t R0IiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+ DQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRl bGxpZ2VuY2U8YnI+DQo8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDAwN0UiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAl MjgwJTI5MTI0NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQNCiAoMCkxMjQ1IDI0 MjE5NDwvYT4gJm5ic3A7fCAmbmJzcDs8Yj5FOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRl YXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVj aG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uPGJy Pg0KPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojM0E4QjkyO3RleHQtZGVjb3JhdGlvbjpub25lIj53d3cuYmFl c3lzdGVtcy5jb20vYWk8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNl IExpbWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3 NDUxPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzNBOEI5MiI+UmVn aXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwg R1UyIDdZUDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gSnVzdGluIERlYW4gW21haWx0bzo8YSBocmVm PSJtYWlsdG86YmViZW1hc3RlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5iZWJlbWFzdGVy QGdtYWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDYgTWF5IDIwMTUgMTU6MjY8YnI+ DQo8Yj5Ubzo8L2I+IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyA8YSBocmVmPSJtYWlsdG86 aWV0ZkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaWV0ZkBpZXRmLm9yZzwvYT47IElFVEYg QW5ub3VuY2VtZW50IExpc3Q8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzptYW5ldEBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21hbmV0XSBNQU5FVCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZzogNiBN YXkgMjAxNTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRp bmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFu Zz0iRU4tR0IiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1H QiIgc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMzMzOTcyIj4qKiogV0FSTklORyAqKio8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3 aGl0ZSI+DQo8ZW0+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzk3MiI+VGhp cyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhl ciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Ljwvc3Bhbj48L2VtPjxp PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Q29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGluZm9ybWF0 aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBs YW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPlJlZCBGbGFnczwvc3Bhbj48L2k+PC9zdHJv bmc+PGVtPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzM5NzIiPiB0aGF0IHlv dSBjYW4gbG9vayBvdXQNCiBmb3IgaW4gZW1haWxzIHlvdSByZWNlaXZlLCBjbGljayA8YSBocmVm PSJodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9SZWQlMjBGbGFncy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCmhl cmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMz MzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3BpY2lvdXMsIHBsZWFz ZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20vaG93 d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxpbmclMjBXaXRoJTIwU3Vz cGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5rIj4NCnRoaXMgcHJvY2VzczwvYT4u PC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLUdCIj5JdCBoYXNuJ3Qg eWV0IHN0YXJ0ZWQuIEltIGluIHRoZSByb29tIG5vdyBidXQgeW91IHNob3VsZCBiZSBhYmxlIHRv IGpvaW4gYXQgMTEuIEluIDM1IG1pbnMgb3Igc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t R0IiPk9uIFdlZCwgTWF5IDYsIDIwMTUsIDEwOjEyIEFNJm5ic3A7RGVhcmxvdmUsIENocmlzdG9w aGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1HQiI+VGhpcyBtZWV0aW5nIGRvZXMgbm90LCBhY2NvcmRpbmcgdG8gdGhlIHdl YmV4IGxpbmssIGFwcGVhciB0byBiZSBoYXBwZW5pbmcuPGJyPg0KPGJyPg0KLS08YnI+DQpDaHJp c3RvcGhlciBEZWFybG92ZTxicj4NClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXI8YnI+DQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K PGJyPg0KVDogJm5ic3A7PGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAyNDIxOTQi IHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPiAmbmJzcDt8ICZuYnNw O0U6DQo8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQo8YnI+DQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBh cmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVm PSJodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpIiB0YXJnZXQ9Il9ibGFuayI+d3d3LmJhZXN5 c3RlbXMuY29tL2FpPC9hPjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExp bWl0ZWQ8YnI+DQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUx PGJyPg0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQs IFN1cnJleSwgR1UyIDdZUDxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tPGJyPg0KRnJvbTogbWFuZXQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFuZXQt Ym91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgSUVTRyBTZWNyZXRhcnk8YnI+DQpTZW50OiAyMCBBcHJpbCAyMDE1 IDIyOjExPGJyPg0KVG86IElFVEYgQW5ub3VuY2VtZW50IExpc3Q8YnI+DQpDYzogPGEgaHJlZj0i bWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+ PGJyPg0KU3ViamVjdDogW21hbmV0XSBNQU5FVCBXRyBWaXJ0dWFsIEludGVyaW0gTWVldGluZzog NiBNYXkgMjAxNTxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZy b20gdGhlIGludGVybmV0Ljxicj4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91 bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48YnI+ DQpGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVy cyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2Vz Ljxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KPGJyPg0KVGhlIE1vYmlsZSBBZC1ob2MgTmV0d29ya3MgKG1hbmV0KSB3b3Jr aW5nIGdyb3VwIHdpbGwgaG9sZCBhIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIGFzIGZvbGxvd3M6 PGJyPg0KPGJyPg0KRGF0ZTogV2VkbmVzZGF5LCBNYXkgNiwgMjAxNTxicj4NClRpbWU6IDExMDAt MTMwMCBFRFQgKDE1MDAtMTcwMCBVVEMpPGJyPg0KPGJyPg0KPGJyPg0KSk9JTiBXRUJFWCBNRUVU SU5HPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTJmNWMzMzUwMjRkMzZiN2U4MGUyNjUzZWEwNzc0NzY5IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTJmNWMzMzUwMjRkMzZiN2U4MGUyNjUz ZWEwNzc0NzY5PC9hPjxicj4NCk1lZXRpbmcgbnVtYmVyOiA2NDkgNDE1IDYzOTxicj4NCk1lZXRp bmcgcGFzc3dvcmQ6IDEyMzQ1PGJyPg0KPGJyPg0KPGJyPg0KSk9JTiBCWSBQSE9ORTxicj4NCjxh IGhyZWY9InRlbDoxLTg3Ny02NjgtNDQ5MyIgdGFyZ2V0PSJfYmxhbmsiPjEtODc3LTY2OC00NDkz PC9hPiBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVTL0NhbmFkYSk8YnI+DQo8YSBocmVmPSJ0 ZWw6MS02NTAtNDc5LTMyMDgiIHRhcmdldD0iX2JsYW5rIj4xLTY1MC00NzktMzIwODwvYT4gQ2Fs bC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKSBBY2Nlc3MgY29kZTogNjQ5IDQxNSA2Mzk8YnI+ DQo8YnI+DQpUb2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlvbnM6PGJyPg0KPGEgaHJlZj0iaHR0 cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiIHRhcmdldD0i X2JsYW5rIj5odHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25zLnBk ZjwvYT48YnI+DQo8YnI+DQo8YnI+DQpBZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXI6 PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTBl M2ZiNDRkMWJiYmVmOThmNWIwY2Y5ZTQ2NTFjZDFlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9p ZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTBlM2ZiNDRkMWJiYmVmOThmNWIwY2Y5ZTQ2 NTFjZDFlPC9hPjxicj4NCjxicj4NCjxicj4NCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRh Y3Qgc3VwcG9ydCBoZXJlOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9tYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYzwvYT48 YnI+DQo8YnI+DQo8YnI+DQpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMg V2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVy aW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxl IGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1dG9tYXRp Y2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QNCiBjb25zZW50 IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBv ciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1hbmV0QGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbWFuZXQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21hbmV0PC9hPjxicj4NCjxicj4NCioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KVGhpcyBlbWFp bCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkPGJy Pg0KcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQ8YnI+DQpyZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lz dGVtIGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yPGJyPg0KZGlzdHJpYnV0ZSBp dHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjxicj4NCjxi cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K bWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_ce1abeaae43a4d0ebfc15a0c3281b844VAUSDITCHM2idirectnet_-- From nobody Sat May 9 15:54:18 2015 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 C38ED1A1B65; Sat, 9 May 2015 15:54:15 -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] 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 h3q3viyKIEBr; Sat, 9 May 2015 15:54:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BC21A1B2D; Sat, 9 May 2015 15:54:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150509225414.22853.82140.idtracker@ietfa.amsl.com> Date: Sat, 09 May 2015 15:54:14 -0700 Archived-At: Cc: draft-ietf-manet-tlv-naming.shepherd@ietf.org, manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-tlv-naming.ad@ietf.org, draft-ietf-manet-tlv-naming@ietf.org Subject: [manet] Barry Leiba's No Objection on draft-ietf-manet-tlv-naming-02: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 22:54:15 -0000 Barry Leiba has entered the following ballot position for draft-ietf-manet-tlv-naming-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Abstract isn't very abstract -- which is to say it's very long. Can you let the Introduction do the heavy lifting, and cut the Abstract back to, say, the last two paragraphs with a little editing (to expand "TLV" there and to replace "those registries" with something like "the MANET TLV registries defined in RFC 5444")? Other than that, I have no comment but that this is a fine thing to do, and it doesn't surprise me that Adrian brought it up. From nobody Sun May 10 17:22:26 2015 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 D13B71A6FF7 for ; Sun, 10 May 2015 17:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ecarbN1qinHh for ; Sun, 10 May 2015 17:22:20 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C65CC1A1BEE for ; Sun, 10 May 2015 17:22:19 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so83452074lbb.0 for ; Sun, 10 May 2015 17:22: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:date:message-id:subject:from:to :cc:content-type; bh=2LMPQBqf5CaTo0cBI6ezBRtyRO5nX1VjC6R6YX5LHP0=; b=g2VkEMTGeTLGRi6D5fcNOt7X4UdKWTz/3MA559QXaXeulpvDk+YsGOQK1WJl9YmpW3 JnThUr+i4dx7/Iv5TIklMRsFMWJk8LKHpBuGqKJykQ4AAWjxNK2H77XpvzllJGelZHsL AzvWYTWIcpJ4cL6kK7pH2Bs3FlOze91xxLf/ObZpzh/VehkpRQ9wGKbiMbO9aQjXxEAc JfZ5KPOzp8oLe+XpQksXsU4PBOUZRsu+1xoP4R7aAQ0gaNqZ8550beMRAUy8KuZorX3p tMUUpSUxS9GdIXVA6NX+fVK2Au/7Ru1DT5eKkr0yPyisvgXCQqYHQhkWZuM3VsTuG2c7 yKHw== MIME-Version: 1.0 X-Received: by 10.152.87.113 with SMTP id w17mr6174394laz.104.1431303738206; Sun, 10 May 2015 17:22:18 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Sun, 10 May 2015 17:22:16 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 May 2015 20:22:16 -0400 Message-ID: From: Stan Ratliff To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11c35384e1b0a90515c35e69 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 00:22:24 -0000 --001a11c35384e1b0a90515c35e69 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris, Thanks for the thorough review. I have attempted to address these issues; a DLEP-11 should be posted right after this email. Working group, Technically, WGLC on DLEP has expired (I believe it was May 8). So, we request On Wed, May 6, 2015 at 1:39 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Reading DLEP-10 here are my comments. These fall somewhere between a > quick glance and a detailed analysis. > > > > Terminology > > > > Early in the document there are references to signals and data items, > without explaining the difference (which is given later). Why is the term > signals used rather than the far more common messages? > The term came out of our early discussions, in that the modem and router are "signalling" each other concerning characteristics of the link. To be honest, this is one that I would like to leave as-is (leaving Signals instead of Messages). I have added verbiage attempting to explain the difference, and standardizing on "Signal". > > > Introduction > > > > Seems to suggest that only cable/DSL have configuration issues. > Removed the cable/DSL reference (it was not really necessary). > > > Is it worth being explicit that independent of routing protocol? > The document speaks to the characteristics of the link. While I think your question is valid, I believe that the focus on link characteristics takes care of routing protocol independence (that, and the fact that we never mention a routing protocol). > > > Authorship > > > > In one place the draft refers to authors, in another to co-authors and WG= . > Personally I tend to go with an impersonal style, but even if not, > consistency is suggested. > Made consistent references to co-authors. > > > Transport mechanism and security > > > > Not totally consistent here. The draft is about UDP and TCP, then in > section 2 TLS is suggested, but in section 10 DTLS. > A left-over from our older UDP days. Thank you for the catch. > > > TBDs and IANA/RFCEd > > > > I think the TBDs scattered through the document will be a nuisance when i= t > comes to IANA and RFC Editor. In my experience IANA like tables in their > section (with TBDs in them) that they can directly copy, rather than list= s > that need numbers, that then someone (RFC Editor?) has to backfill throug= h > the report. I=E2=80=99m not saying they won=E2=80=99t, I=E2=80=99m saying= the interactions I=E2=80=99ve had > with them make this not what I think they=E2=80=99ll like. In particular = I=E2=80=99m sure > they won=E2=80=99t like the =E2=80=9Ccould we have some experimental valu= es=E2=80=9D but will want > a definite number, preferably in a table. And you will need an allocation > policy, and if Expert Review, nominated experts. > > > > I=E2=80=99d get some advice here. > Good point. I've removed TDB from the textual descriptions of the signals, referring back to the table where the signals are listed. > > > Section 5.0 (i.e. 5 before 5.1) > > > > This was initially confusing, how can something be optional at one end bu= t > mandatory at the other =E2=80=93 until you realise how things are driven,= in 5.1. > That could be easier for the new reader. > > > > And on a related point, Appendices A and B are what I wanted. Could use > references to them so the reader will go and look. > I've added text to (hopefully) make those points clearer. > > > Section 5.4 top of page 15, should that e.g. be an i.e.? > Yep. > > > Section 6 > > > > This has some misstements. It says the signal header is a TLV, no, it=E2= =80=99s > just a type and length. The signal (I still want to call it a message) is= a > TLV, but the header is not. > > > > It also refers to data items following a signal. That should be following > a signal header. > > > > In fourth paragraph, add a comma after invalid (before and disallowed). > It=E2=80=99s ambiguous without, and the RFC Editor will put it (Oxford co= mma) in so > might as well do it now. > Done. > > > Tables > > > > Should these have captions? Should format pictures have captions? (I tend > towards yes and no respectively). > Have added captions to the tables. To be honest, I kind of like the captions on both... I wait for consensus on that one. ;-) > > > Section 7.3 top of page 20 > > > > The wording about own timing and heuristics doesn=E2=80=99t look interope= rable > friendly. > This is another one I didn't specifically address, because I'm sure how to make it clearer. Henning hit an issue with a DLEP implementation where the Peer Initialization signal wasn't responded to. Since heartbeats weren't specifically setup - not until Peer Initialization ACK - the implementation "hung". This just basically tries to say "You need to timeout the Peer Init signal on your own, because Heartbeats aren't in play"... > > > 8.1 Version > > > > This is version 0.9 in draft -10. Should that have been updated in the > update from -09 to -10? That illustrates a problem with this approach =E2= =80=93 and > another thing embedded in document to update for the RFC. > Changed to version 1.0. > > > UTF-8 > > > > Is it expected to have to verify the UTF-8 is valid in any way, or is any > byte sequence acceptable? > Added text. > > > Incidentally 8.7 includes the one use of 1-octet in the draft, all the > rest are in bits. > > > > 8.10 and similar > > > > Add/Drop that only has two allowed values. Action on receiving other > values? Should this be a bitfield with 7 bits reserved? (But you don=E2= =80=99t have > any other bitfields.) > Fair point, but it looks like everything works.... if there's a lot of interest in making everything bitfields, then we can see what we can do, but at this point, with multiple implementations out there using what's currently documented, I'm less willing to make changes. > > > 8.18 > > > > I make 32 bits of microseconds a little over an hour maximum. Fine =E2=80= =93 > unless you deal with deep space probes (or other forms of DTN). Just to > check we=E2=80=99re happy with that. (We can be, but it should be deliber= ate, not > an accident.) > That's a REALLY good point. Other opinions on this? > > > Resources > > > > This is a bit vague on what the point is. > Yeah. Intentionally so, I'm afraid. It's a legacy item (just for equivalent feature/function) with RFC 5578. It's pretty vague there, too. > > > Nits > > > > I=E2=80=99d rather see =E2=80=9Cuse=E2=80=9D rather than =E2=80=9Cutilize= =E2=80=9D in some places. > > > a priori without a hyphen. > Done on both items above. Regards, Stan > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c35384e1b0a90515c35e69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chris,=C2=A0

Thanks for the thorough re= view. I have attempted to address these issues; a DLEP-11 should be posted = right after this email.=C2=A0

Working group,=C2=A0=
Technically, WGLC on DLEP has expired (I believe it was May 8). = So, we request=C2=A0

On Wed, May 6, 2015 at 1:39 PM, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:

Reading DLEP-10 here are my comments. These fall som= ewhere between a quick glance and a detailed analysis.

=C2=A0

Terminology

=C2=A0

Early in the document there are references to signal= s and data items, without explaining the difference (which is given later).= Why is the term signals used rather than the far more common messages?

=

The term came out of our early= discussions, in that the modem and router are "signalling" each = other concerning characteristics of the link. To be honest, this is one tha= t I would like to leave as-is (leaving Signals instead of Messages). I have= added verbiage attempting to explain the difference, and standardizing on = "Signal".=C2=A0

=C2=A0
=

=C2=A0

Introduction

=C2=A0

Seems to suggest that only cable/DSL have configurat= ion issues.


Removed the cab= le/DSL reference (it was not really necessary).
=C2=A0

=C2=A0

Is it worth being explicit that independent of routi= ng protocol?


The document s= peaks to the characteristics of the link. While I think your question is va= lid, I believe that the focus on link characteristics takes care of routing= protocol independence (that, and the fact that we never mention a routing = protocol).
=C2=A0

=C2=A0

Authorship

=C2=A0

In one place the draft refers to authors, in another= to co-authors and WG. Personally I tend to go with an impersonal style, bu= t even if not, consistency is suggested.

<= br>
Made consistent references to co-authors.=C2=A0

=C2=A0

Transport mechanism and security

=C2=A0

Not totally consistent here. The draft is about UDP = and TCP, then in section 2 TLS is suggested, but in section 10 DTLS.


A left-over from our older UDP da= ys. Thank you for the catch.=C2=A0
=C2=A0

=C2=A0

TBDs and IANA/RFCEd

=C2=A0

I think the TBDs scattered through the document will= be a nuisance when it comes to IANA and RFC Editor. In my experience IANA = like tables in their section (with TBDs in them) that they can directly cop= y, rather than lists that need numbers, that then someone (RFC Editor?) has to backfill through the report. I=E2= =80=99m not saying they won=E2=80=99t, I=E2=80=99m saying the interactions = I=E2=80=99ve had with them make this not what I think they=E2=80=99ll like.= In particular I=E2=80=99m sure they won=E2=80=99t like the =E2=80=9Ccould = we have some experimental values=E2=80=9D but will want a definite number, preferably in a table. An= d you will need an allocation policy, and if Expert Review, nominated exper= ts.

=C2=A0

I=E2=80=99d get some advice here.


Good point. I've removed TDB from the tex= tual descriptions of the signals, referring back to the table where the sig= nals are listed.=C2=A0
=C2=A0

=C2=A0

Section 5.0 (i.e. 5 before 5.1)

=C2=A0

This was initially confusing, how can something be o= ptional at one end but mandatory at the other =E2=80=93 until you realise h= ow things are driven, in 5.1. That could be easier for the new reader.

=C2=A0

And on a related point, Appendices A and B are what = I wanted. Could use references to them so the reader will go and look.

<= /div>

I've added text to (hopeful= ly) make those points clearer.=C2=A0
=C2=A0

=C2=A0

Section 5.4 top of page 15, should that e.g. be an i= .e.?


Yep.=C2=A0
= =C2=A0

=C2=A0

Section 6

=C2=A0

This has some misstements. It says the signal header= is a TLV, no, it=E2=80=99s just a type and length. The signal (I still wan= t to call it a message) is a TLV, but the header is not.

=C2=A0

It also refers to data items following a signal. Tha= t should be following a signal header.

=C2=A0

In fourth paragraph, add a comma after invalid (befo= re and disallowed). It=E2=80=99s ambiguous without, and the RFC Editor will= put it (Oxford comma) in so might as well do it now.


Done.=C2=A0
=C2=A0

=C2=A0

Tables

=C2=A0

Should these have captions? Should format pictures h= ave captions? (I tend towards yes and no respectively).


Have added captions to the tables. To be hones= t, I kind of like the captions on both... I wait for consensus on that one.= ;-)
=C2=A0

=C2=A0

Section 7.3 top of page 20

=C2=A0

The wording about own timing and heuristics doesn=E2= =80=99t look interoperable friendly.


<= /div>
This is another one I didn't specifically address, because I&= #39;m sure how to make it clearer. Henning hit an issue with a DLEP impleme= ntation where the Peer Initialization signal wasn't responded to. Since= heartbeats weren't specifically setup - not until Peer Initialization = ACK - the implementation "hung". This just basically tries to say= "You need to timeout the Peer Init signal on your own, because Heartb= eats aren't in play"...=C2=A0
=C2=A0

=C2=A0

8.1 Version

=C2=A0

This is version 0.9 in draft -10. Should that have b= een updated in the update from -09 to -10? That illustrates a problem with = this approach =E2=80=93 and another thing embedded in document to update fo= r the RFC.


Changed to versi= on 1.0.=C2=A0
=C2=A0

<= /u>

=C2=A0

UTF-8

=C2=A0

Is it expected to have to verify the UTF-8 is valid = in any way, or is any byte sequence acceptable?


Added text.=C2=A0
=C2=A0

=C2=A0

Incidentally 8.7 includes the one use of 1-octet in = the draft, all the rest are in bits.

=C2=A0

8.10 and similar

=C2=A0

Add/Drop that only has two allowed values. Action on= receiving other values? Should this be a bitfield with 7 bits reserved? (B= ut you don=E2=80=99t have any other bitfields.)


Fair point, but it looks like everything works.... if = there's a lot of interest in making everything bitfields, then we can s= ee what we can do, but at this point, with multiple implementations out the= re using what's currently documented, I'm less willing to make chan= ges.=C2=A0
=C2=A0

=C2=A0

8.18

=C2=A0

I make 32 bits of microseconds a little over an hour= maximum. Fine =E2=80=93 unless you deal with deep space probes (or other f= orms of DTN). Just to check we=E2=80=99re happy with that. (We can be, but = it should be deliberate, not an accident.)


That's a REALLY good point. Other opinions on this?=C2= =A0
=C2=A0

=

=C2=A0

Resources

=C2=A0

This is a bit vague on what the point is.

<= /div>

Yeah. Intentionally so, I'm afrai= d. It's a legacy item (just for equivalent feature/function) with RFC 5= 578. It's pretty vague there, too.=C2=A0
=C2=A0
<= div>

=C2=A0

Nits

=C2=A0

I=E2=80=99d rather see =E2=80=9Cuse=E2=80=9D rather = than =E2=80=9Cutilize=E2=80=9D in some places.=C2=A0

=C2=A0

a priori without a hyphen.


Done on both items above.=C2=A0

=
Regards,
Stan



=C2=A0

=C2=A0

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence
_____________________________________________________= _____________________

T: =C2= =A0+44 (0)1245 242194 =C2=A0| =C2=A0E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford= Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<= u>

BAE Systems Applied Intellig= ence Limited
Registered in England & Wales No: 01337451

Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

=C2=A0

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


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


--001a11c35384e1b0a90515c35e69-- From nobody Sun May 10 21:44:42 2015 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 4F8B01A0018; Sun, 10 May 2015 21:44: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] 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 D6wyy0EF9boI; Sun, 10 May 2015 21:44:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C681A0024; Sun, 10 May 2015 21:44:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511044436.24382.96746.idtracker@ietfa.amsl.com> Date: Sun, 10 May 2015 21:44:36 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 04:44:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-11.txt Pages : 65 Date : 2015-05-10 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-11 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 10 22:57:42 2015 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 A77041A00FE for ; Sun, 10 May 2015 22:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.916 X-Spam-Level: X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_203=0.994, T_RP_MATCHES_RCVD=-0.01] 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 yjgRF096cZWg for ; Sun, 10 May 2015 22:57:39 -0700 (PDT) Received: from atcmail.atc.tcs.com (atcmail.atc.tcs.com [203.200.212.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4A11A00E4 for ; Sun, 10 May 2015 22:57:38 -0700 (PDT) Received: from localhost.localdomain ([172.20.94.178]) (authenticated bits=0) by atcmail.atc.tcs.com (8.14.4/8.14.4) with ESMTP id t4B5vXld031628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 11 May 2015 11:27:33 +0530 Message-ID: <555044CD.5060003@atc.tcs.com> Date: Mon, 11 May 2015 11:27:33 +0530 From: Vigneswaran R User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: manet@ietf.org References: <20150511044436.24382.96746.idtracker@ietfa.amsl.com> In-Reply-To: <20150511044436.24382.96746.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-11.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, 11 May 2015 05:57:41 -0000 Hello, A couple of observations, In 8.4, "The IPv4 Connection Point data item contains the following fields:" Supposed to be IPv6.. In 8.18, "The Latency data item data item MUST appear in the Peer" 'data item' repeated twice. Thanks. Vignesh On 05/11/2015 10:14 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. > > Title : Dynamic Link Exchange Protocol (DLEP) > Authors : Stan Ratliff > Bo Berry > Cisco Systems > Darryl Satterwhite > Rick Taylor > Filename : draft-ietf-manet-dlep-11.txt > Pages : 65 > Date : 2015-05-10 > > Abstract: > When routing devices rely on modems to effect communications over > wireless links, they need timely and accurate knowledge of the > characteristics of the link (speed, state, etc.) in order to make > forwarding decisions. In mobile or other environments where these > characteristics change frequently, manual configurations or the > inference of state through routing or transport protocols does not > allow the router to make the best decisions. A bidirectional, event- > driven communication channel between the router and the modem is > necessary. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-dlep-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-11 > > > 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.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Mon May 11 01:56:23 2015 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 7300B1A8700 for ; Mon, 11 May 2015 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 O9nOSf75FXoi for ; Mon, 11 May 2015 01:56:20 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3359F1A86F2 for ; Mon, 11 May 2015 01:56:20 -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; Mon, 11 May 2015 09:55:45 +0100 From: Rick Taylor To: Stan Ratliff , "Dearlove, Christopher (UK)" Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Mon, 11 May 2015 08:55:43 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 08:56:22 -0000 Comments inline...=0A= =0A= =0A= =0A= > 8.18____=0A= >=0A= > __ __=0A= >=0A= > I make 32 bits of microseconds a little over an hour maximum. Fine = =96=0A= > unless you deal with deep space probes (or other forms of DTN). Just= =0A= > to check we=92re happy with that. (We can be, but it should be=0A= > deliberate, not an accident.)=0A= >=0A= >=0A= > That's a REALLY good point. Other opinions on this?=0A= =0A= My opinion is to keep the 32bit milliseconds. For the vast majority of =0A= use-cases this is believed to be plenty. For DTN (and other =0A= long-latency environments) I would suggest an extension rather than =0A= forcing everyone to use a 64bit value or some kind of BIGNUM.=0A= =0A= For DTN, the per-hop latency is often much lower than the full end to =0A= end latency for a bundle, and I'm not sure any of the space agencies =0A= have rolled out DLEP on their deep-space links yet ;) That's not to say = =0A= that they shouldn't.=0A= =0A= Cheers,=0A= =0A= Rick Taylor=0A= From nobody Mon May 11 01:58:10 2015 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 5CCFD1A7018 for ; Mon, 11 May 2015 01:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hTlPtEKO1bVZ for ; Mon, 11 May 2015 01:58:04 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 619E01A8706 for ; Mon, 11 May 2015 01:58:04 -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; Mon, 11 May 2015 09:57:33 +0100 From: Rick Taylor To: Stan Ratliff , "Dearlove, Christopher (UK)" Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Mon, 11 May 2015 08:57:31 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016755EE7D@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 08:58:08 -0000 Doh! *micro*seconds...=0A= =0A= On 11/05/15 09:56, Rick Taylor wrote:=0A= > Comments inline...=0A= > =0A= >=0A= >=0A= >> 8.18____=0A= >>=0A= >> __ __=0A= >>=0A= >> I make 32 bits of microseconds a little over an hour maximum. Fine = =96=0A= >> unless you deal with deep space probes (or other forms of DTN). Jus= t=0A= >> to check we=92re happy with that. (We can be, but it should be=0A= >> deliberate, not an accident.)=0A= >>=0A= >>=0A= >> That's a REALLY good point. Other opinions on this?=0A= >=0A= > My opinion is to keep the 32bit milliseconds. For the vast majority of=0A= > use-cases this is believed to be plenty. For DTN (and other=0A= > long-latency environments) I would suggest an extension rather than=0A= > forcing everyone to use a 64bit value or some kind of BIGNUM.=0A= >=0A= > For DTN, the per-hop latency is often much lower than the full end to=0A= > end latency for a bundle, and I'm not sure any of the space agencies=0A= > have rolled out DLEP on their deep-space links yet ;) That's not to say= =0A= > that they shouldn't.=0A= >=0A= > Cheers,=0A= >=0A= > Rick Taylor=0A= >=0A= > _______________________________________________=0A= > manet mailing list=0A= > manet@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Mon May 11 02:09:25 2015 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 076711ACD36 for ; Mon, 11 May 2015 02:09:25 -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 lejYjKa2nRkq for ; Mon, 11 May 2015 02:09:23 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53F5F1A8A28 for ; Mon, 11 May 2015 02:08:51 -0700 (PDT) Received: by wgic8 with SMTP id c8so95175413wgi.1 for ; Mon, 11 May 2015 02:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=iYP+zwtrMJD1My8Srg6r3BEuisdHeYyJ8xhcq2Vwjz8=; b=ZIsS1PMg1SEzTEJl+g+EHQhesb4twzmMF8VWaYRs2LcA1Kt9q08pxIAfGP+EIXyk0p gJN9g+ZgPZSXGoYj7xhZ1xa8AXYhZzAsxpKoPgK5MkHLMKkOPSfgsG5et/nX/SsJWacS 90jp7gBMpkRqsGh5dCfJMwaKoLbWc85RZZXVC5fVHmbIB6SOLjQqvxr400C+NXCyqYzT 1Yot9dHIeYsFPXUd9Af7s5eNSGokbEBpqCjUME4JR1BqhruJDA1Y5GcncAyo3yBSPn1d qGzpsICfXiAZoV/ppyL5dq4E8hb//mA1YzuKu4VP72SmVsSC2E3Bth/cmsjRn35q2EZ4 nvLg== X-Received: by 10.194.192.226 with SMTP id hj2mr18720977wjc.51.1431335330093; Mon, 11 May 2015 02:08:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Mon, 11 May 2015 02:08:29 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Mon, 11 May 2015 11:08:29 +0200 Message-ID: To: Rick Taylor Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 09:09:25 -0000 On Mon, May 11, 2015 at 10:55 AM, Rick Taylor wrote: > Comments inline... > > > >> 8.18____ >> >> __ __ >> >> I make 32 bits of microseconds a little over an hour maximum. Fine = =E2=80=93 >> unless you deal with deep space probes (or other forms of DTN). Just >> to check we=E2=80=99re happy with that. (We can be, but it should be >> deliberate, not an accident.) >> >> >> That's a REALLY good point. Other opinions on this? > > My opinion is to keep the 32bit milliseconds. For the vast majority of > use-cases this is believed to be plenty. For DTN (and other > long-latency environments) I would suggest an extension rather than > forcing everyone to use a 64bit value or some kind of BIGNUM. > > For DTN, the per-hop latency is often much lower than the full end to > end latency for a bundle, and I'm not sure any of the space agencies > have rolled out DLEP on their deep-space links yet ;) That's not to say > that they shouldn't. Maybe moving it to 64 bit would make it "good enough" for everyone... and it might simplify processing in the DLEP code because most of the data we collect is 64 bit anyways. 64 bit in microseconds would be more than half a million years... good enough even for intergalactic radio communication. ;) Henning Rogge From nobody Mon May 11 02:30:02 2015 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 3219D1A8833 for ; Mon, 11 May 2015 02:30:02 -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 5GHkJhcrV9jG for ; Mon, 11 May 2015 02:30:00 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA81E1A87BE for ; Mon, 11 May 2015 02:29:59 -0700 (PDT) Received: by wgin8 with SMTP id n8so122285037wgi.0 for ; Mon, 11 May 2015 02:29:58 -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=lFn+LGvkkcHYcULHngKeTPidqLNtdFzJncqsV6mlpAg=; b=FKwFWywzDFiAVr/wm9rGeHQ4jGaX5ykAtJCTxBtaOX2AFYR2mjRJ0nAM2sOJR2mKhO joJTslBvRo/h0H3jraRiDbt65TbqlbkKOUXVJMESwxZa4eMpEXtWfI5htRczjJLosR+1 doBy1Ni/pG0OQACXeYqaNELwTw8bkDtya7lu1BkBfyZX98bUdFbdf/5OK8g5UGhIxtn8 oMEuYjtJLsL8aLF6NZTkZqYR9YimDDIHoQerPVFGmfmQ9o9pU0U8pZVVyqvEqfdHtaTW qqZMqZn2uL5/uBkWpjvqkXT+Z0HH22mw4oY/FRKD2G1ayDXXpUv63zMKnRPOaPRzDbpt ozZQ== X-Received: by 10.194.63.9 with SMTP id c9mr17967216wjs.143.1431336598506; Mon, 11 May 2015 02:29:58 -0700 (PDT) Received: from [192.168.101.23] ([85.133.27.55]) by mx.google.com with ESMTPSA id i13sm12327302wic.13.2015.05.11.02.29.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 May 2015 02:29:57 -0700 (PDT) References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> Mime-Version: 1.0 (1.0) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> X-Mailer: iPhone Mail (12F70) From: Christopher Dearlove Date: Mon, 11 May 2015 10:29:48 +0100 To: Rick Taylor Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 09:30:02 -0000 I don't have a strong opinion, I just wanted to be sure that a positive deci= sion was made. You could, as a third option, use 32 bits with a value of all ones meaning t= hat value or anything higher. Again not a strong opinion, just an option. Is it worth listing what issues remain and crossing them off as decisions ma= de? I don't think it will be a long list. -- =20 Christopher Dearlove christopher.dearlove@gmail.com (iPhone) chris@mnemosyne.demon.co.uk (home) > On 11 May 2015, at 09:55, Rick Taylor wro= te: >=20 > Comments inline... > >=20 >=20 >> 8.18____ >>=20 >> __ __ >>=20 >> I make 32 bits of microseconds a little over an hour maximum. Fine =E2= =80=93 >> unless you deal with deep space probes (or other forms of DTN). Just >> to check we=E2=80=99re happy with that. (We can be, but it should be >> deliberate, not an accident.) >>=20 >>=20 >> That's a REALLY good point. Other opinions on this? >=20 > My opinion is to keep the 32bit milliseconds. For the vast majority of=20 > use-cases this is believed to be plenty. For DTN (and other=20 > long-latency environments) I would suggest an extension rather than=20 > forcing everyone to use a 64bit value or some kind of BIGNUM. >=20 > For DTN, the per-hop latency is often much lower than the full end to=20 > end latency for a bundle, and I'm not sure any of the space agencies=20 > have rolled out DLEP on their deep-space links yet ;) That's not to say=20= > that they shouldn't. >=20 > Cheers, >=20 > Rick Taylor >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Mon May 11 06:05:18 2015 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 0C4C01A6F39 for ; Mon, 11 May 2015 06:05:17 -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 4ub30FQqYtKu for ; Mon, 11 May 2015 06:05:14 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCD81A6F10 for ; Mon, 11 May 2015 06:05:14 -0700 (PDT) Received: by laat2 with SMTP id t2so92602980laa.1 for ; Mon, 11 May 2015 06:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PqEtG5WVncNt4Rdd2hwItyGVNSkQs7MlHRwJ3n5B9DU=; b=roxCCqTOY3eq4bTp2QWaoh95briflk8JoGZSIjBmfBp7IcN8QlS5/QIFuDSRK14CDN 4N0ZIoizRbYmdqbLondT5GzCiOkVAebPhMBxvptPVRmvVupK2AG2Sgtqz5ugCJIzOrta dMzYSVAFzsIX53JuM3rHCw+1ugpe6/ABpf4UCkCIfPfrJZLa3jvHBcXjqNiGBdKdkEjW umEpyxBFS12fsQegN/5o6UtA0bDModgYQBBahVKIyZtPM+/bO+AqH38/n6sB/aVzL/9Y OxHVb2jY8iwpH1WWmVIbpZ2ydWwjS7jV++4NHBQGoE7N3IV1fzOmJZ4DABitIPsO40vx Wl4w== MIME-Version: 1.0 X-Received: by 10.112.124.166 with SMTP id mj6mr8047398lbb.104.1431349512475; Mon, 11 May 2015 06:05:12 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Mon, 11 May 2015 06:05:12 -0700 (PDT) In-Reply-To: <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> Date: Mon, 11 May 2015 09:05:12 -0400 Message-ID: From: Stan Ratliff To: Christopher Dearlove Content-Type: multipart/alternative; boundary=047d7bfcf7a63d98190515ce072d Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 13:05:17 -0000 --047d7bfcf7a63d98190515ce072d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable All, I'm with Henning on this one - most of the DLEP data items are 64-bit quantities as is, and expanding the field to a 64-bit quantity solves all problems (from what I can see, anyway). On Mon, May 11, 2015 at 5:29 AM, Christopher Dearlove < christopher.dearlove@gmail.com> wrote: > I don't have a strong opinion, I just wanted to be sure that a positive > decision was made. > > You could, as a third option, use 32 bits with a value of all ones meanin= g > that value or anything higher. Again not a strong opinion, just an option= . > > Is it worth listing what issues remain and crossing them off as decisions > made? I don't think it will be a long list. > Sure, we could. I took a shot at the list, based on items you brought up in your review that I didn't specifically address. From what I can see, the list (with proposed resolutions where possible) is: 1. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as is, with 'Signal' used instead of 'Message'. 2. Explicit statement that DLEP is independent of all routing protocols. Proposed solution: Leave as-is, no routing protocols are even mentioned 3. Peer Initialization timeout verbiage. Proposed solution: None at this time. I don't have ideas on how to make the text clearer. Suggestions? 4. Use of bitfields instead of octets. Proposed solution: Leave text as-is. All things considered, this is a fairly minor, cosmetic item, and would cause churn with existing implementations. 5. Definition of "Resources" term is vague. Proposed solution: Leave text as-is. This is an item for backward compatibility with RFC 5578, and is specified pretty much the same as what is in that draft. Does that list look ok? Regards, Stan > > -- > Christopher Dearlove > christopher.dearlove@gmail.com (iPhone) > chris@mnemosyne.demon.co.uk (home) > > > On 11 May 2015, at 09:55, Rick Taylor > wrote: > > > > Comments inline... > > > > > > > >> 8.18____ > >> > >> __ __ > >> > >> I make 32 bits of microseconds a little over an hour maximum. Fine = =E2=80=93 > >> unless you deal with deep space probes (or other forms of DTN). Jus= t > >> to check we=E2=80=99re happy with that. (We can be, but it should b= e > >> deliberate, not an accident.) > >> > >> > >> That's a REALLY good point. Other opinions on this? > > > > My opinion is to keep the 32bit milliseconds. For the vast majority of > > use-cases this is believed to be plenty. For DTN (and other > > long-latency environments) I would suggest an extension rather than > > forcing everyone to use a 64bit value or some kind of BIGNUM. > > > > For DTN, the per-hop latency is often much lower than the full end to > > end latency for a bundle, and I'm not sure any of the space agencies > > have rolled out DLEP on their deep-space links yet ;) That's not to sa= y > > that they shouldn't. > > > > Cheers, > > > > Rick Taylor > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www.ietf.org/mailman/listinfo/manet > --047d7bfcf7a63d98190515ce072d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

I'm with Henning on this= one - most of the DLEP data items are 64-bit quantities as is, and expandi= ng the field to a 64-bit quantity solves all problems (from what I can see,= anyway).=C2=A0

On Mon, May 11, 2015 at 5:29 AM, Christopher Dearlove <christopher.dearlove@gmail.com> wrote:
I don't have a strong opinion, I just wanted to be sure = that a positive decision was made.

You could, as a third option, use 32 bits with a value of all ones meaning = that value or anything higher. Again not a strong opinion, just an option.<= br>
Is it worth listing what issues remain and crossing them off as decisions m= ade? I don't think it will be a long list.

Sure, we could. I took a shot at the list, based on items you broug= ht up in your review that I didn't specifically address. From what I ca= n see, the list (with proposed resolutions where possible) is:=C2=A0
<= div>
1. "Signal vs. Message" verbiage. Proposed sol= ution: Leave DLEP text as is, with 'Signal' used instead of 'Me= ssage'.

2. Explicit statement that DLEP is ind= ependent of all routing protocols.=C2=A0 Proposed solution: Leave as-is, no= routing protocols are even mentioned

3. Peer Init= ialization timeout verbiage.=C2=A0 Proposed solution: None at this time. I = don't have ideas on how to make the text clearer. Suggestions?

4. Use of bitfields instead of octets.=C2=A0 Proposed solu= tion: Leave text as-is. All things considered, this is a fairly minor, cosm= etic item, and would cause churn with existing implementations.=C2=A0
=

5. Definition of "Resources" term is vague.= =C2=A0 Proposed solution: =C2=A0Leave text as-is. This is an item for backw= ard compatibility with RFC 5578, and is specified pretty much the same as w= hat is in that draft.=C2=A0

Does that list look ok= ?

Regards,
Stan



=C2=A0

--
Christopher Dearlove
christo= pher.dearlove@gmail.com (iPhone)
chris@mnem= osyne.demon.co.uk (home)

> On 11 May 2015, at 09:55, Rick Taylor <rick@tropicalstormsoftware.com&= gt; wrote:
>
> Comments inline...
> <snip>
>
>
>>=C2=A0 =C2=A0 8.18____
>>
>>=C2=A0 =C2=A0 __ __
>>
>>=C2=A0 =C2=A0 I make 32 bits of microseconds a little over an hour = maximum. Fine =E2=80=93
>>=C2=A0 =C2=A0 unless you deal with deep space probes (or other form= s of DTN). Just
>>=C2=A0 =C2=A0 to check we=E2=80=99re happy with that. (We can be, b= ut it should be
>>=C2=A0 =C2=A0 deliberate, not an accident.)
>>
>>
>> That's a REALLY good point. Other opinions on this?
>
> My opinion is to keep the 32bit milliseconds. For the vast majority of=
> use-cases this is believed to be plenty.=C2=A0 For DTN (and other
> long-latency environments) I would suggest an extension rather than > forcing everyone to use a 64bit value or some kind of BIGNUM.
>
> For DTN, the per-hop latency is often much lower than the full end to<= br> > end latency for a bundle, and I'm not sure any of the space agenci= es
> have rolled out DLEP on their deep-space links yet ;)=C2=A0 That's= not to say
> that they shouldn't.
>
> Cheers,
>
> Rick Taylor
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet

--047d7bfcf7a63d98190515ce072d-- From nobody Mon May 11 07:57:02 2015 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 332461A8A1D for ; Mon, 11 May 2015 07:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 30fgtxPO78lX for ; Mon, 11 May 2015 07:56:59 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC4D1A8A0D for ; Mon, 11 May 2015 07:56:58 -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; Mon, 11 May 2015 15:56:34 +0100 From: Rick Taylor To: Stan Ratliff , Christopher Dearlove Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Mon, 11 May 2015 14:56:33 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 14:57:01 -0000 Comments inline...=0A= =0A= On 11/05/15 14:05, Stan Ratliff wrote:=0A= > All,=0A= >=0A= > I'm with Henning on this one - most of the DLEP data items are 64-bit=0A= > quantities as is, and expanding the field to a 64-bit quantity solves=0A= > all problems (from what I can see, anyway).=0A= =0A= +1, nice and easy=0A= =0A= >=0A= > On Mon, May 11, 2015 at 5:29 AM, Christopher Dearlove=0A= > >= =0A= > wrote:=0A= >=0A= > I don't have a strong opinion, I just wanted to be sure that a=0A= > positive decision was made.=0A= >=0A= > You could, as a third option, use 32 bits with a value of all ones=0A= > meaning that value or anything higher. Again not a strong opinion,=0A= > just an option.=0A= >=0A= > Is it worth listing what issues remain and crossing them off as=0A= > decisions made? I don't think it will be a long list.=0A= >=0A= >=0A= > Sure, we could. I took a shot at the list, based on items you brought up= =0A= > in your review that I didn't specifically address. From what I can see,= =0A= > the list (with proposed resolutions where possible) is:=0A= >=0A= > 1. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as= =0A= > is, with 'Signal' used instead of 'Message'.=0A= >=0A= > 2. Explicit statement that DLEP is independent of all routing=0A= > protocols. Proposed solution: Leave as-is, no routing protocols are=0A= > even mentioned=0A= >=0A= > 3. Peer Initialization timeout verbiage. Proposed solution: None at=0A= > this time. I don't have ideas on how to make the text clearer. Suggestion= s?=0A= >=0A= > 4. Use of bitfields instead of octets. Proposed solution: Leave text=0A= > as-is. All things considered, this is a fairly minor, cosmetic item, and= =0A= > would cause churn with existing implementations.=0A= >=0A= > 5. Definition of "Resources" term is vague. Proposed solution: Leave=0A= > text as-is. This is an item for backward compatibility with RFC 5578,=0A= > and is specified pretty much the same as what is in that draft.=0A= >=0A= > Does that list look ok?=0A= =0A= Looks good to me, but id-nits raises one issue:=0A= =0A= ** Downref: Normative reference to an Informational RFC: RFC 5578=0A= =0A= So that should probably be added to the list.=0A= =0A= And Vignesh raised two typos:=0A= =0A= In 8.4,=0A= =0A= "The IPv4 Connection Point data item contains the following fields:"=0A= =0A= Supposed to be IPv6..=0A= =0A= In 8.18,=0A= =0A= "The Latency data item data item MUST appear in the Peer"=0A= =0A= 'data item' repeated twice.=0A= =0A= Rick=0A= From nobody Mon May 11 16:04:26 2015 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 4E7081A92EE; Mon, 11 May 2015 16:04:25 -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] 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 coiJxHL9753D; Mon, 11 May 2015 16:04:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0DD1A92FA; Mon, 11 May 2015 16:04:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150511230422.8859.29777.idtracker@ietfa.amsl.com> Date: Mon, 11 May 2015 16:04:22 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-12.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 23:04:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-12.txt Pages : 65 Date : 2015-05-11 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make forwarding decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-12 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 11 16:09:41 2015 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 1E70A1A92F0 for ; Mon, 11 May 2015 16:09:37 -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 LDcbH7S8rJuQ for ; Mon, 11 May 2015 16:09:33 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888821A9166 for ; Mon, 11 May 2015 16:09:33 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so104825075lbb.3 for ; Mon, 11 May 2015 16:09:32 -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=SAVyQNQV23qbasBqfkzP8xJWggWVW0IP9Y9qzapsBlw=; b=w/AijuaH8AQxeXIkhPnZrL1c7gWBPSSLc+F/FUMeCoZ9es6T56Hv2ci30b3uF5PW52 7YFTDuyxvw5dYMrGMXWMkYAxNYzxopXJQtsxqwFer1qUY8f31cZcejEVD867gHRh1rIh oEtiudAZm5C1rM2jC2EFiPZuLTid0ax3pNUgyok2LPqPceqEpAAwrgD8SCwTy9+Q3OtF /H8xUztqiUyeQAyWMXuNBcWt6zuMwJQBFBw2Krqa7JesWWKUuJlt4z+4+933S/f/d/oi H40GMu4KORdzsSRtr24SN0AIPOIP4s/hNCcN59gLbghk+n9tRT23dSjDZ76Gr92K6fV1 ZaQw== MIME-Version: 1.0 X-Received: by 10.112.161.197 with SMTP id xu5mr9613840lbb.69.1431385771934; Mon, 11 May 2015 16:09:31 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Mon, 11 May 2015 16:09:31 -0700 (PDT) In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> Date: Mon, 11 May 2015 19:09:31 -0400 Message-ID: From: Stan Ratliff To: Rick Taylor Content-Type: multipart/alternative; boundary=001a11c3bfe6790b680515d67883 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 11 May 2015 23:09:37 -0000 --001a11c3bfe6790b680515d67883 Content-Type: text/plain; charset=UTF-8 OK, so we have a list, and now we need *consensus* on how to fix items on the list... ;-) I've submitted DLEP-12 to reflect the list below: 1. Latency has been changed to a 64-bit unsigned quantity. (FIXED) 2. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text as-is, with 'Signal' used instead of 'Message'. 3. Explicit statement that DLEP is independent of routing protocol. Proposed solution: Leave text as-is. 4. Peer Initialization timeout verbiage. Proposed solution: Leave current text as-is. 5. Use of bitfields instead of octets. Proposed solution: Leave text as-is. All things considered, this is a fairly minor, cosmetic item, and would cause churn with existing implementations. 6. Definition of "Resources" term is vague. Proposed solution: Leave text as-is. This is an item for backward compatibility with RFC 5578, and is specified pretty much the same as what is in that draft. 7. Downref to RFC 5578. (FIXED IN DLEP-12) 8. Typo in 8.4 referencing IPv4 instead of IPv6. (FIXED IN DLEP-12) 9. Typo in 8.18 referencing 'data item data item'. (FIXED IN DLEP-12) Calling for consensus on the "leave draft as is" items, or suggestions of text. Regards, Stan --001a11c3bfe6790b680515d67883 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK, so we have a list, and now we need *consensus* on how = to fix items on the list... ;-)=C2=A0

I've submitted= DLEP-12 to reflect the list below:=C2=A0
1. Latency has been changed to a 64-bit u= nsigned quantity. =C2=A0 (FIXED)

=
2. "Signal vs. Message" verbiage. Prop= osed solution: Leave DLEP text as-is, with 'Signal' used instead of= 'Message'.

3. Explicit statement that DLEP is independent of routing pro= tocol.=C2=A0 Proposed solution: Leave text as-is.=C2=A0

4. Peer Initialization ti= meout verbiage.=C2=A0 Proposed solution: Leave current text as-is.=C2=A0

5. Use o= f bitfields instead of octets.=C2=A0 Proposed solution: Leave text as-is. A= ll things considered, this is a fairly minor, cosmetic item, and would caus= e churn with existing implementations.

=
6. Definition of "Resources" ter= m is vague.=C2=A0 Proposed solution:=C2=A0 Leave text as-is. This is an ite= m for backward compatibility with RFC 5578, and is specified pretty much th= e same as what is in that draft.

=
7. Downref to RFC 5578. (FIXED IN DLEP-12)
=

8. Typo in = 8.4 referencing IPv4 instead of IPv6. =C2=A0 (FIXED IN DLEP-12)

9. Typo in 8.18 r= eferencing 'data item data item'. =C2=A0(FIXED IN DLEP-12)


Calling for consensus on the "leave draft as is= " items, or suggestions of text.=C2=A0

Regards,
Stan

--001a11c3bfe6790b680515d67883-- From nobody Tue May 12 01:16:13 2015 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 004A11A3BA5 for ; Tue, 12 May 2015 01:16:06 -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 Rlm4Ahw43EY9 for ; Tue, 12 May 2015 01:16:02 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1E01A3BA0 for ; Tue, 12 May 2015 01:16:02 -0700 (PDT) Received: by wicnf17 with SMTP id nf17so3765046wic.1 for ; Tue, 12 May 2015 01:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eKPrjFuMixiIZ51UeEcw1iUYwhS25H+M19n2YvJj8F0=; b=OAudnjmqWGdhA5rxQjzPCLih7wEwuFUUnTorRabBPOVgdr9493yU/WN3lEXuHn/RiQ +INFoxrOdrH8RN37+koM0ZQ8nT43pyNByGLvjtSaLwG1zZGcm8ZV84r0kwT+84JgUxlo LiB5cP3kxtcSvy6tD+679OA0gyxGwGUh+qNspZHE4ygJeo5gNRNPMm1KvA8psy+nb1j4 ooyyYN1KDn3ASYmRoFEKpX2idJeaFKVlfqAckgrDfyv4VlFoPmjX43aU57OcE5xB6rO/ KrAxkhcvpsLjaYQYZK+KCmUVt1JeIy83HK3oi/V2MN87mmOe54eThj9kMBn3GQXvTQD6 EQCA== X-Received: by 10.180.76.167 with SMTP id l7mr27884992wiw.85.1431418561440; Tue, 12 May 2015 01:16:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Tue, 12 May 2015 01:15:40 -0700 (PDT) In-Reply-To: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> From: Henning Rogge Date: Tue, 12 May 2015 10:15:40 +0200 Message-ID: To: Stan Ratliff Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 08:16:06 -0000 On Tue, May 12, 2015 at 1:09 AM, Stan Ratliff wrote: > OK, so we have a list, and now we need *consensus* on how to fix items on > the list... ;-) > > I've submitted DLEP-12 to reflect the list below: > > 5. Use of bitfields instead of octets. Proposed solution: Leave text as-is. > All things considered, this is a fairly minor, cosmetic item, and would > cause churn with existing implementations. The only items I could find where this could be relevant is the IPv4/IPv6-Address TLV (the Add/Remove field). This could easily be changed into a bitarray because it only uses a single bit, but I am not sure its worth the effort. Henning Rogge From nobody Tue May 12 02:10:08 2015 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 987061A03E3 for ; Tue, 12 May 2015 02:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 lo_zQjMmo_yr for ; Tue, 12 May 2015 02:10:02 -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 3C0F81A0381 for ; Tue, 12 May 2015 02:10:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="551251211" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 12 May 2015 10:10:00 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="97686009" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds017.greenlnk.net with ESMTP; 12 May 2015 10:10:01 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Tue, 12 May 2015 10:10:00 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEE56+AABMS9wAAA/PWkA== Date: Tue, 12 May 2015 09:09:59 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:10:06 -0000 V2hhdCBzaG91bGQgYSByZWNlaXZlciBkbyBpZiB0aGUgb2N0ZXQgaGFzIGEgdmFsdWUgb3RoZXIg dGhhbiAwIG9yIDE/IFNob3VsZCB0aGlzIGJlIG5vdGVkPyAoVGhhdCB3YXMgbXkgb3JpZ2luYWwg cG9pbnQsIGEgYml0ZmllbGQgd2FzIG9uZSB3YXkgdG8gaGFuZGxlIHRoYXQuKQ0KDQotLSANCkNo cmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpCQUUgU3lzdGVt cyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDogwqArNDQgKDAp MTI0NSAyNDIxOTQgwqB8IMKgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20NCg0KQkFF IFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJr LCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQp3d3cuYmFlc3lzdGVt cy5jb20vYWkNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lz dGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6 IFN1cnJleSBSZXNlYXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpo cm9nZ2VAZ21haWwuY29tXSANClNlbnQ6IDEyIE1heSAyMDE1IDA5OjE2DQpUbzogU3RhbiBSYXRs aWZmDQpDYzogUmljayBUYXlsb3I7IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBDaHJpc3Rv cGhlciBEZWFybG92ZTsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIERMRVAt MTAgY29tbWVudHMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAhIC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBv cmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgZnJvbSB0aGUg aW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hvdWxkIGNsaWNrIG9u IGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQpGb2xsb3cgdGhlICdS ZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rp b25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1lc3NhZ2VzLg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KT24gVHVlLCBN YXkgMTIsIDIwMTUgYXQgMTowOSBBTSwgU3RhbiBSYXRsaWZmIDxyYXRsaWZmc3RhbkBnbWFpbC5j b20+IHdyb3RlOg0KPiBPSywgc28gd2UgaGF2ZSBhIGxpc3QsIGFuZCBub3cgd2UgbmVlZCAqY29u c2Vuc3VzKiBvbiBob3cgdG8gZml4IGl0ZW1zIA0KPiBvbiB0aGUgbGlzdC4uLiA7LSkNCj4NCj4g SSd2ZSBzdWJtaXR0ZWQgRExFUC0xMiB0byByZWZsZWN0IHRoZSBsaXN0IGJlbG93Og0KPg0KPiA1 LiBVc2Ugb2YgYml0ZmllbGRzIGluc3RlYWQgb2Ygb2N0ZXRzLiAgUHJvcG9zZWQgc29sdXRpb246 IExlYXZlIHRleHQgYXMtaXMuDQo+IEFsbCB0aGluZ3MgY29uc2lkZXJlZCwgdGhpcyBpcyBhIGZh aXJseSBtaW5vciwgY29zbWV0aWMgaXRlbSwgYW5kIA0KPiB3b3VsZCBjYXVzZSBjaHVybiB3aXRo IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucy4NCg0KVGhlIG9ubHkgaXRlbXMgSSBjb3VsZCBmaW5k IHdoZXJlIHRoaXMgY291bGQgYmUgcmVsZXZhbnQgaXMgdGhlIElQdjQvSVB2Ni1BZGRyZXNzIFRM ViAodGhlIEFkZC9SZW1vdmUgZmllbGQpLg0KDQpUaGlzIGNvdWxkIGVhc2lseSBiZSBjaGFuZ2Vk IGludG8gYSBiaXRhcnJheSBiZWNhdXNlIGl0IG9ubHkgdXNlcyBhIHNpbmdsZSBiaXQsIGJ1dCBJ IGFtIG5vdCBzdXJlIGl0cyB3b3J0aCB0aGUgZWZmb3J0Lg0KDQpIZW5uaW5nIFJvZ2dlDQoqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0 byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5 b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5kZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQg b3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMg Y29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4KKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioK From nobody Tue May 12 02:18:13 2015 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 518661A1A8A for ; Tue, 12 May 2015 02:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KSdka-w0x0PC for ; Tue, 12 May 2015 02:18:08 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596AB1A1A30 for ; Tue, 12 May 2015 02:18:08 -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; Tue, 12 May 2015 10:17:33 +0100 From: Rick Taylor To: Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Tue, 12 May 2015 09:17:31 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:18:10 -0000 Comments inline...=0A= =0A= On 12/05/15 00:09, Stan Ratliff wrote:=0A= > OK, so we have a list, and now we need *consensus* on how to fix items=0A= > on the list... ;-)=0A= >=0A= > I've submitted DLEP-12 to reflect the list below:=0A= >=0A= > 1. Latency has been changed to a 64-bit unsigned quantity. (FIXED)=0A= >=0A= > 2. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text=0A= > as-is, with 'Signal' used instead of 'Message'.=0A= =0A= +1=0A= =0A= >=0A= > 3. Explicit statement that DLEP is independent of routing protocol.=0A= > Proposed solution: Leave text as-is.=0A= =0A= +1=0A= =0A= >=0A= > 4. Peer Initialization timeout verbiage. Proposed solution: Leave=0A= > current text as-is.=0A= =0A= +1=0A= =0A= >=0A= > 5. Use of bitfields instead of octets. Proposed solution: Leave text=0A= > as-is. All things considered, this is a fairly minor, cosmetic item, and= =0A= > would cause churn with existing implementations.=0A= =0A= The only valid values are 0 and 1 in the only place they are used IPv4/6 = =0A= address data items) so they are already bitfields with 7 bits reserved, =0A= so I don't think a change is needed.=0A= =0A= >=0A= > 6. Definition of "Resources" term is vague. Proposed solution: Leave=0A= > text as-is. This is an item for backward compatibility with RFC 5578,=0A= > and is specified pretty much the same as what is in that draft.=0A= =0A= +1 - We've gone round this so many times my head hurts, let's just put =0A= down the whip and leave the dead horse alone.=0A= =0A= >=0A= > 7. Downref to RFC 5578. (FIXED IN DLEP-12)=0A= >=0A= > 8. Typo in 8.4 referencing IPv4 instead of IPv6. (FIXED IN DLEP-12)=0A= >=0A= > 9. Typo in 8.18 referencing 'data item data item'. (FIXED IN DLEP-12)=0A= >=0A= =0A= Cheers,=0A= =0A= Rick=0A= =0A= From nobody Tue May 12 02:19:58 2015 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 4F5551A1ABE for ; Tue, 12 May 2015 02:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Yvzivz8daiSH for ; Tue, 12 May 2015 02:19:56 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9957E1A1A8A for ; Tue, 12 May 2015 02:19:55 -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; Tue, 12 May 2015 10:19:22 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Henning Rogge , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Tue, 12 May 2015 09:19:21 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F980167563453@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:19:57 -0000 On 12/05/15 10:09, Dearlove, Christopher (UK) wrote:=0A= > What should a receiver do if the octet has a value other than 0 or 1? Sho= uld this be noted? (That was my original point, a bitfield was one way to h= andle that.)=0A= >=0A= =0A= This is mentioned elsewhere in the text. A status code of 'invalid =0A= data' MUST be reported if the value is neither 1 or 0.=0A= =0A= Rick=0A= From nobody Tue May 12 02:23:07 2015 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 9E73F1A1AC6 for ; Tue, 12 May 2015 02:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 U36vsL9nbSf8 for ; Tue, 12 May 2015 02:23:05 -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 88D3D1A1ABE for ; Tue, 12 May 2015 02:23:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="465303495" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 12 May 2015 10:23:03 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="101681926" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasodc005.greenlnk.net with ESMTP; 12 May 2015 10:23:02 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Tue, 12 May 2015 10:23:02 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEcVOZg Date: Tue, 12 May 2015 09:23:02 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:23:06 -0000 Only defining 0 and 1 is not the same as defining a bitfield with 7 bits re= served. If you receive a 3 then if only 0 and 1 are defined this is neither= , but if a bitfield then this is a 1. Checking that a reserved field is 0s = is not a reason to reject a message in any protocol I've come across - in f= act you wouldn't even check. (Be liberal in what you receive.) -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 12 May 2015 10:18 To: Stan Ratliff Cc: Christopher Dearlove; Dearlove, Christopher (UK); manet@ietf.org Subject: Re: [manet] DLEP-10 comments ----------------------! 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. -------------------------------------------------------- Comments inline... On 12/05/15 00:09, Stan Ratliff wrote: > OK, so we have a list, and now we need *consensus* on how to fix items = > on the list... ;-) > > I've submitted DLEP-12 to reflect the list below: > > 1. Latency has been changed to a 64-bit unsigned quantity. (FIXED) > > 2. "Signal vs. Message" verbiage. Proposed solution: Leave DLEP text = > as-is, with 'Signal' used instead of 'Message'. +1 > > 3. Explicit statement that DLEP is independent of routing protocol. > Proposed solution: Leave text as-is. +1 > > 4. Peer Initialization timeout verbiage. Proposed solution: Leave = > current text as-is. +1 > > 5. Use of bitfields instead of octets. Proposed solution: Leave text = > as-is. All things considered, this is a fairly minor, cosmetic item, = > and would cause churn with existing implementations. The only valid values are 0 and 1 in the only place they are used IPv4/6 ad= dress data items) so they are already bitfields with 7 bits reserved, so I = don't think a change is needed. > > 6. Definition of "Resources" term is vague. Proposed solution: Leave > text as-is. This is an item for backward compatibility with RFC 5578, > and is specified pretty much the same as what is in that draft. +1 - We've gone round this so many times my head hurts, let's just put = down the whip and leave the dead horse alone. > > 7. Downref to RFC 5578. (FIXED IN DLEP-12) > > 8. Typo in 8.4 referencing IPv4 instead of IPv6. (FIXED IN DLEP-12) > > 9. Typo in 8.18 referencing 'data item data item'. (FIXED IN DLEP-12) > Cheers, Rick ******************************************************************** 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 Tue May 12 02:23:51 2015 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 4323C1A1B45 for ; Tue, 12 May 2015 02:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ZeDkkZP3ex5V for ; Tue, 12 May 2015 02:23:49 -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 594D01A1B0D for ; Tue, 12 May 2015 02:23:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="465303857" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 12 May 2015 10:23:46 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="101682109" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 12 May 2015 10:23:45 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Tue, 12 May 2015 10:23:45 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Henning Rogge , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEcbrQg Date: Tue, 12 May 2015 09:23:45 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563453@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F980167563453@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:23:50 -0000 If so, I missed it. Where is elsewhere? -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 12 May 2015 10:19 To: Dearlove, Christopher (UK); Henning Rogge; Stan Ratliff Cc: Christopher Dearlove; manet@ietf.org Subject: Re: [manet] DLEP-10 comments ----------------------! 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. -------------------------------------------------------- On 12/05/15 10:09, Dearlove, Christopher (UK) wrote: > What should a receiver do if the octet has a value other than 0 or 1? = > Should this be noted? (That was my original point, a bitfield was one = > way to handle that.) > This is mentioned elsewhere in the text. A status code of 'invalid data' M= UST be reported if the value is neither 1 or 0. Rick ******************************************************************** 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 Tue May 12 02:32:32 2015 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 2769B1A1B89 for ; Tue, 12 May 2015 02:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.103 X-Spam-Level: X-Spam-Status: No, score=-4.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-5, RDNS_NONE=0.793] 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 oS22o18T3MQT for ; Tue, 12 May 2015 02:32:29 -0700 (PDT) Received: from ukmta1.baesystems.com (unknown [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 611D91A1B8B for ; Tue, 12 May 2015 02:32:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="551263062" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 12 May 2015 10:32:28 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="97690460" Received: from glkxh0002v.greenlnk.net ([10.109.2.33]) by baemasmds017.greenlnk.net with ESMTP; 12 May 2015 10:32:27 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0002V.GREENLNK.net ([10.109.2.33]) with mapi id 14.03.0224.002; Tue, 12 May 2015 10:32:27 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEcv9+Q Date: Tue, 12 May 2015 09:32:27 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563453@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801675634C0@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801675634C0@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:32:31 -0000 Generic, rather than specific I would suggest adding where use of 0 and 1 = are defined a comment that any other value is (pick term of choice) to make= it clear that applies here. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 12 May 2015 10:29 To: Dearlove, Christopher (UK) Subject: Re: [manet] DLEP-10 comments ----------------------! 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. -------------------------------------------------------- On 12/05/15 10:23, Dearlove, Christopher (UK) wrote: > If so, I missed it. Where is elsewhere? > Section 6, final paragraph: If an unrecognized, or unexpected signal is received, or a received signal contains unrecognized, invalid, or disallowed duplicate data items, the receiving peer MUST terminate the session by issuing a Peer Termination signal (Section 7.7) with a Status data item (Section 8.2) containing the most relevant status code, and then close the TCP connection. The most relevant status code in this case would be "invalid data" ******************************************************************** 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 Tue May 12 02:36:42 2015 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 DF3881A1BBD for ; Tue, 12 May 2015 02:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 I603uhmXhYx9 for ; Tue, 12 May 2015 02:36:39 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6931A1BA7 for ; Tue, 12 May 2015 02:36:39 -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; Tue, 12 May 2015 10:36:16 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Tue, 12 May 2015 09:36:15 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:36:41 -0000 On 12/05/15 10:22, Dearlove, Christopher (UK) wrote:=0A= > Only defining 0 and 1 is not the same as defining a bitfield with 7 bits = reserved. If you receive a 3 then if only 0 and 1 are defined this is neith= er, but if a bitfield then this is a 1. Checking that a reserved field is 0= s is not a reason to reject a message in any protocol I've come across - in= fact you wouldn't even check. (Be liberal in what you receive.)=0A= >=0A= =0A= ... is a fair point. If I remember correctly, originally the Add/Remove = =0A= indicator for addresses had the values 1 or 2, this was changed to 1 or =0A= 0, as it seemed a bit more 'C', i.e. !Add =3D=3D Drop.=0A= =0A= In the case of the Add/Remove indicator (the only example in DLEP), I =0A= can't see any other values, or other bits (treating the value as a flag =0A= set) that could carry meaning, so a 'Boolean octet' is the only way to =0A= treat it. The more I think of it, treating the value as a bitfield is =0A= just misleading.=0A= =0A= Does that help?=0A= =0A= Rick=0A= From nobody Tue May 12 02:38:10 2015 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 F0B3D1A1BDE for ; Tue, 12 May 2015 02:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 NndPmPZ6EbK7 for ; Tue, 12 May 2015 02:38:05 -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 3EF1E1A1BC3 for ; Tue, 12 May 2015 02:38:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="465311666" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 12 May 2015 10:38:04 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="101685926" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 12 May 2015 10:38:03 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Tue, 12 May 2015 10:38:03 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEc55Og Date: Tue, 12 May 2015 09:38:03 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 09:38:09 -0000 As I said, my issue was what to do if receiving a value. A bitfield was one= (hack probably) to do it. I think my last suggestion (just add an explicit= comment that any other value is (insert term of choice)) is the way to go. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 12 May 2015 10:36 To: Dearlove, Christopher (UK); Stan Ratliff Cc: Christopher Dearlove; manet@ietf.org Subject: Re: [manet] DLEP-10 comments ----------------------! 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. -------------------------------------------------------- On 12/05/15 10:22, Dearlove, Christopher (UK) wrote: > Only defining 0 and 1 is not the same as defining a bitfield with 7 = > bits reserved. If you receive a 3 then if only 0 and 1 are defined = > this is neither, but if a bitfield then this is a 1. Checking that a = > reserved field is 0s is not a reason to reject a message in any = > protocol I've come across - in fact you wouldn't even check. (Be = > liberal in what you receive.) > ... is a fair point. If I remember correctly, originally the Add/Remove in= dicator for addresses had the values 1 or 2, this was changed to 1 or 0, as= it seemed a bit more 'C', i.e. !Add =3D=3D Drop. In the case of the Add/Remove indicator (the only example in DLEP), I can't= see any other values, or other bits (treating the value as a flag set) that could carry meaning, so a 'Boolean octet' is the only way to trea= t it. The more I think of it, treating the value as a bitfield is just mis= leading. Does that help? Rick ******************************************************************** 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 Tue May 12 03:07:18 2015 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 DE5131A8781 for ; Tue, 12 May 2015 03:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QrvudXjUGGxF for ; Tue, 12 May 2015 03:07:15 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 361A51A870E for ; Tue, 12 May 2015 03:07:15 -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; Tue, 12 May 2015 11:06:50 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Tue, 12 May 2015 10:06:50 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801675636C7@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 10:07:18 -0000 On 12/05/15 10:38, Dearlove, Christopher (UK) wrote:=0A= > As I said, my issue was what to do if receiving a value. A bitfield was o= ne (hack probably) to do it. I think my last suggestion (just add an explic= it comment that any other value is (insert term of choice)) is the way to g= o.=0A= >=0A= =0A= That does make sense, but I then worry about how far we propagate that =0A= text... do you want us to add "Any other value received MUST result in =0A= termination..." text to every data item?=0A= =0A= Just trying to scope the update,=0A= =0A= Rick=0A= From nobody Tue May 12 03:08:43 2015 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 802D51A8757 for ; Tue, 12 May 2015 03:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 yNWLgNxX-Mcg for ; Tue, 12 May 2015 03:08:39 -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 6A5341A86FE for ; Tue, 12 May 2015 03:08:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="551282527" Received: from unknown (HELO baemasmds017.greenlnk.net) ([10.15.207.104]) by ukmta1.baesystems.com with ESMTP; 12 May 2015 11:08:38 +0100 X-IronPort-AV: E=Sophos;i="5.13,414,1427756400"; d="scan'208";a="97698326" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasmds017.greenlnk.net with ESMTP; 12 May 2015 11:08:37 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Tue, 12 May 2015 11:08:37 +0100 From: "Dearlove, Christopher (UK)" To: Rick Taylor , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEd+XXw Date: Tue, 12 May 2015 10:08:37 +0000 Message-ID: References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801675636C7@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9801675636C7@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 10:08:41 -0000 No, I was just suggesting adding that values other than 0 or 1 were (pick y= our own adjective) at that point. Nothing more, the general comment will th= en pick up on that. -- = Christopher Dearlove Senior Principal Engineer BAE Systems Applied Intelligence __________________________________________________________________________ T: =A0+44 (0)1245 242194 =A0| =A0E: chris.dearlove@baesystems.com BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,= Chelmsford, Essex CM2 8HN. www.baesystems.com/ai BAE Systems Applied Intelligence Limited Registered in England & Wales No: 01337451 Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP -----Original Message----- From: Rick Taylor [mailto:rick@tropicalstormsoftware.com] = Sent: 12 May 2015 11:07 To: Dearlove, Christopher (UK); Stan Ratliff Cc: Christopher Dearlove; manet@ietf.org Subject: Re: [manet] DLEP-10 comments ----------------------! 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. -------------------------------------------------------- On 12/05/15 10:38, Dearlove, Christopher (UK) wrote: > As I said, my issue was what to do if receiving a value. A bitfield was o= ne (hack probably) to do it. I think my last suggestion (just add an explic= it comment that any other value is (insert term of choice)) is the way to g= o. > That does make sense, but I then worry about how far we propagate that text= ... do you want us to add "Any other value received MUST result in terminat= ion..." text to every data item? Just trying to scope the update, Rick ******************************************************************** 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 Tue May 12 03:22:10 2015 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 4CD941A875E for ; Tue, 12 May 2015 03:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4fmXhb-jEu0H for ; Tue, 12 May 2015 03:22:08 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C1C1A854D for ; Tue, 12 May 2015 03:22:08 -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; Tue, 12 May 2015 11:21:45 +0100 From: Rick Taylor To: "Dearlove, Christopher (UK)" , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AQHQi4CP9C7wMaa5jUmQ2HOaDC7XDA== Date: Tue, 12 May 2015 10:21:43 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F98016756377B@tss-server1.home.tropicalstormsoftware.com> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801675636C7@tss-server1.home.tropicalstormsoftware.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 10:22:09 -0000 On 12/05/15 11:08, Dearlove, Christopher (UK) wrote:=0A= > No, I was just suggesting adding that values other than 0 or 1 were (pick= your own adjective) at that point. Nothing more, the general comment will = then pick up on that.=0A= >=0A= =0A= Ok, sounds sensible... I'll wait for Stan to catch up with the conversation= .=0A= =0A= Thanks,=0A= =0A= Rick=0A= From nobody Tue May 12 04:01:18 2015 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 6187B1A1B95 for ; Tue, 12 May 2015 04:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.584 X-Spam-Level: X-Spam-Status: No, score=0.584 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QF-DVwIZaHOM for ; Tue, 12 May 2015 04:01:13 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726251A1BE6 for ; Tue, 12 May 2015 04:01:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,414,1427752800"; d="scan'208";a="42572871" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 12 May 2015 13:01:07 +0200 Received: from EXC-MBX01.tsn.tno.nl ([fe80::fd60:358a:bfaf:ca7c]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0195.001; Tue, 12 May 2015 13:00:56 +0200 From: "Velt, R. (Ronald) in 't" To: "manet@ietf.org" Thread-Topic: DLEP-11 comments Thread-Index: AdCMAscVvOaa4r1UT2+2AJwrYmZzPw== Date: Tue, 12 May 2015 11:00:54 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307DEE5B35@EXC-MBX01.tsn.tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [manet] DLEP-11 comments 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, 12 May 2015 11:01:17 -0000 Hi, Please find below my (belated) comments on DLEP version -11 (which should a= pply to -12 as well) Thanks, Ronald (Somewhat) Major ----------------------- * I think the document could benefit from a short applicability statement, = either as a separate section or added to the Assumptions section (2). In pa= rticular, the following should/could be addressed: - Is the modem assumed to act as a transparent layer 2 bridge for data traf= fic in all cases? (The text in section 2 on the signalling in Destination = Up messages of MAC addresses for delivering data traffic suggests as much, = but this could be made more explicit). - The Introduction mentions different methods of physically connecting mode= m devices to routers. It says, that in the case of Ethernet or serial attac= hment, routers are not aware of radio link related events and characteristi= cs. It goes on to state, that this is one of the challenges that DLEP addre= sses. However, given the reliance of DLEP on the use of MAC addresses, I do= n't see how DLEP could help in the case a modem is connected to router by m= eans of a serial link. - Although it has been stated that DLEP is agnostic to the routing protocol= being used, I wonder whether it works as well for a reactive MANET routing= protocol as for a pro-active MANET routing protocol. The Abstract says, th= at routers need characteristics of wireless links to make better _forwardin= g_ decisions. Shouldn't that be, at least in the case of pro-active MANET p= rotocols: better _routing_ decisions? After routes have been installed in t= he FIB, the forwarding is nothing more than a next hop lookup. Not sure how= in this works for reactive MANET protocols. * Section 7.5, Peer Update Signal - 2nd paragraph: If modems that do not track Layer 3 addresses are to silen= tly ignore a Peer Update signalling an address change, whereas modems that = _do_ track Layer 3 addresses are to respond with a Peer Update ACK, how sho= uld the router determine whether to retransmit or not? (In other words, HOW= would the router obtain the knowledge to do what the 4th paragraph of this= section says it SHOULD do?) Would it not be more robust if the modem were = required to always respond with a Peer Update ACK, which in the non-trackin= g case should contain a Status data item with an appropriate Status Code (e= .g., Request Denied)? Also note the last sentence of section 7.5, which sta= tes that a Peer Update signal MUST be acknowledged by the receiver issuing = a Peer Update ACK signal. This seems to contradict the "silent ignoring" ab= ove. - Why does the address update mechanism described here (i.e., Peer Update f= rom router to modem with address change causes Destination Update on the fa= r end of the radiolink) apply only to simple addresses and not to IPv4 or I= Pv6 attached subnets? * Section 7.7, Peer Termination Signal - 5th/6th paragraph: Interpreting the absence of a Status data item in the = Peer Termination as an implicit Status Code 'Success' does not make sense t= o me. I think that in a Peer Termination Signal, the Status data item shoul= d be seen more as a 'Reason' data item, reflecting _why_ the connection is = being torn down. In fact, a separate data item could have been specified fo= r this purpose. Barring that, in my view a more useful interpretation of th= e absence of a Status data item would be: 'Unspecified reason for terminati= on'. Note that at the time the peer initiating termination sends this sign= al, it is by no means certain that termination will indeed be graceful: Wha= t if the other side does not respond with a Peer Termination ACK signal? * Section 11, IANA considerations - Repositories for Signal Types and Data Item (Types) are requested, with p= rovisions for experimental types of both. However, I do not see similar pro= visions for signals and data items of Extensions. Section 3.2 claims: " The= requests for IANA-controlled registries in this document contain sufficien= t reserved space, both in terms of DLEP signals and DLEP data items, to acc= ommodate future extensions to the protocol and the data transferred". Howev= er, as it is now, it seems possible for IANA to allocate values for all sig= nals and data items currently defined in the document and reserve all the r= emaining values for experimental signals and data items, respectively, leav= ing no space for Extensions. (But it may well be that I don't understand ho= w this works!) = Minor ------- Section 1, Introduction: - First paragraph, 4th sentence: "It is also quite possible that link quali= ty and datarate varies" should be: It is also quite possible that link qual= ity and datarate vary ... - An example involving an 802.11g access point is given. Even though Wi-Fi = is ubiquitous these days, it wouldn't hurt to add an informative reference = to IEEE 802.11. Furthermore, "g" is an obsolete indication, as this amendme= nt has been rolled into IEEE 802.11 several revisions ago. Finally, there d= oes not seem to be anything "g"-specific about the example, as most, if not= all, PHY variants feature multiple transmission rates. Section 1.1, Protocol overview: - ( I agree with Christopher Dearlove's comment on the "signals" terminolog= y). - last sentence: "The specific algorithms ..... is outside ..." should be: = The specific algorithms ..... are outside ... Likewise: "is left": are left Section 1.2, Requirements - An old favourite: "NOT RECOMMENDED" is missing. (See Errata to RFC 2119). Section 2, Assumptions - 2nd paragraph, last sentence: "it is strongly recommended that implementa= tions ..." should be: it is strongly RECOMMENDED that implementations ... -4th paragraph; "It is recommended that DLEP implementations utilize IPv6 l= ink-local addresses ..." should/could be: It is RECOMMENDED that DLEP impl= ementations utilize IPv6 link-local addresses ..." Section 4, Metrics - 2nd paragraph: "As mentioned in the introduction section of this document= , DLEP allows for metrics to be sent within two contexts " ; I did not see = this mentioned in the Introduction - it talks about per-destination informa= tion, but does not mention "modem-wide" metrics. - 3rd paragraph: "In order to introduce a new metric type, DLEP modem imple= mentations MUST terminate the session with the router ... and re-establish = the session" should this not be: "In order to introduce a new metric type, = DLEP modem implementations MUST terminate the session with the router ... a= nd wait for the router to re-establish the session" ? - 5th paragraph: " however, the specific algorithms (precedence, etc.) for = utilizing the dual-context metrics is out of scope ..." should be: "... are= out of scope". Section 5 - " (see Appendix A and B for flow diagrams of the discovery signal)" shoul= d be: "(see Appendix A for flow diagrams of the discovery signal ", as the = flow diagrams in Appendix B do not show Peer Discovery signalling. Sections 5.1, 5.2 and 5.3 - All mention of UDP and TCP sockets in these sections is implementational = detail that is best avoided. It is conceivable that routers and /or modems = implement DLEP using a mechanism different from the socket paradigm. A prot= ocol specification should restrict itself to describing externally observab= le behaviour. Section 5.4, Common Session Flow - 4th paragraph: "In cases where metrics are provided at peer level, the re= ceiver MUST propagate the metrics to all destinations in its information ba= se that are accessed via the originator". Better would be: " ....to all ent= ries in its information base for destinations that are accessed via the or= iginator". (Makes it more clear that this is purely a peer-internal adminis= trative action). = Section 6, DLEP Signal Processing - Section could be renamed to DLEP Signal Structure and Processiing to bett= er cover its contents. Section 6.1, DLEP Signal Header - Definition of Signal Type: "One of the DLEP Signal Type values defined in= this document" should be: An 8-bit unsigned integer field specifying one o= f the DLEP Signal Type values defined in this document. - Definition of Length field: "The length, expressed as a 16-bit unsigned i= nteger, of all of the DLEP data items associated with this signal" should b= e: The length in bytes, expressed as a 16-bit unsigned integer, of all of t= he DLEP data items associated with this signal. Section 6.2, DLEP Generic Data Item - Definition of Length field: "The length, expressed as an 8-bit unsigned i= nteger, of the value field of the data item" should be: The length in bytes= , expressed as an 8-bit unsigned integer, of the value field of the data it= em. Section 7.3, Peer Initialization Signal - 4th paragraph: "timeout and retry heurestics" should be "timeout and retr= y heuristics" Sections 7.3 and 7.4 - The capitalisation of NO, NOT and BOTH in these sections is a bit questio= nable, as these are not RFC 2119 Imperatives. I think the associated MUSTs = provide sufficient emphasis. Section 7.10, Destination Up ACK Signal - last sentence: "retry heurestics" should be: retry heuristics. Section 7.12, Destination Down ACK Signal - last sentence: "retry heurestics" should be: retry heuristics. Section 7.15, Link Characteristics Request Signal - 2nd paragraph, last sentence: " Issuing a Link Characteristics Request wi= th ONLY the MAC Address data item is a mechanism a peer MAY use to request = metrics (via the Link Characteristics ACK) from its partner." The wording l= eaves open which sides the "peer" and "its partner" are. The remove any amb= iguity, this could be rephrased as: " Issuing a Link Characteristics Reques= t with ONLY the MAC Address data item is a mechanism a router MAY use to re= quest metrics (via the Link Characteristics ACK) from the modem." (Supposin= g that's the intended meaning!) Section 8.2, Status - 1st paragraph, last sentence: " ... to indicate the success or failure of= the previously received signal." This is not true for Status data items in= Peer Termination signals. See earlier comment on section 7.7. - Definition of Text field, 1st sentence: "describing an problem" should be= : describing a problem. Section 8.6, Heartbeat Interval - 2nd paragraph, 2nd sentence: "implementations MAY indicates the desire ..= ." should be: implementations MAY indicate the desire... - "non 0" -> non-0 ? Section 8.12, IPv4 Attached Subnet - First sentence: " The DLEP IPv4 Attached Subnet allows a device to declar= e that it has an IPv4 subnet (e.g., a stub network) attached, ..." add: or = that it has become aware of an IPv4 subnet being present at a remote destin= ation. - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentenc= e could be rephrased: In case a previously declared IPv4 Attached Subnet ne= eds to be withdrawn, the associated Destination MUST be brought down (via t= he Destination Down signal (Section 7.11)) and then a Destination Up signal= MUST be re-issued, without the IPv4 Attached Subnet data item. - Definition of Subnet Mask field: Technically, this is not a subnet mask, = but a prefix length. Section 8.13, IPv6 Attached Subnet - First sentence: " The DLEP IPv6 Attached Subnet allows a device to declar= e that it has an IPv6 subnet (e.g., a stub network) attached, ..." add: or = that it has become aware of an IPv6 subnet being present at a remote destin= ation. - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentenc= e could be rephrased: As in the case of the IPv4 attached Subnet data item = above, when a previously declared IPv6 Attached Subnet needs to be withdraw= n, the associated Destination MUST be brought down (via the Destination Dow= n signal (Section 7.11)) and then a Destination Up signal MUST be re-issued= , without the IPv6 Attached Subnet data item. - Definition of Subnet Mask field: Technically, this is not a subnet mask, = but a prefix length. Section 8.19, Resources (Receive) - RESR field: What if a received Resources (Receive) data item contains a R= ESR value greater than 100? Should the connection be torn down? Section 8.20, Resources (Transmit) - REST field: What if a received Resources (Transmit) data item contains a= REST value greater than 100? Should the connection be torn down? Section 8.21, Relative Link Quality (Receive) - RLQR field: What if a received Relative Link Quality (Receive) data item = contains a RLQR value greater than 100? Should the connection be torn down? Section 8.22, Relative Link Quality (Transmit) - RLQT field: What if a received Relative Link Quality (Transmit) data item= contains a RLQT value greater than 100? Should the connection be torn down? Section 8.23, Link Characteristics ACK Timer - 1st sentence: "The Link Characteristics ACK Timer data item MAY appear in= the Link Characteristics Request signal (Section 7.15) to indicate the des= ired number of seconds to the sender will wait for a response to the reques= t." should be: The Link Characteristics ACK Timer data item MAY appear in = the Link Characteristics Request signal (Section 7.15) to indicate the desi= red number of seconds the sender will wait for a response to the request. - Definition of Interval field: "has been lost" should be: "lost" Section 9, Credit-Windowing - Last paragraph: " MUST include a Extensions Supported data item" should b= e: MUST include an Extensions Supported data item. Section 9.1.3, Destination Update Signal - If the Destination Update Signal contains both the (mandatory) Credit Win= dow Status data item and the (optional) Credit Grant data item, does the Re= ceive Window value in the former already reflect the increment? = Section 9.2, Credit-Windowing Data Items - "MUST correctly process the following data items without error": "without= error" seems redundant. Section 9.2.1, Credit Grant - 2nd paragraph: "If the receiver of a Destination Up signal ... supports c= redits, the receiver MUST either reject the use of credits for this destin= ation ..." should this read: "... does not support credits, ...." ? - Below format diagram: 'Reserved' field should be: Credit Increment field? - What do credits represent? Bytes? Could not find this anywhere! = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Tue May 12 06:08:35 2015 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 60D341B2C77 for ; Tue, 12 May 2015 06:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 X6_latGurHao for ; Tue, 12 May 2015 06:08:33 -0700 (PDT) Received: from ironport2.idirect.net (ironport.idirect.net [198.180.159.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE261B2C70 for ; Tue, 12 May 2015 06:08:32 -0700 (PDT) Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport2.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (ironport2.idirect.net: no sender authenticity information available from domain of postmaster@webmail.idirect.net) identity=helo; client-ip=10.250.250.203; receiver=ironport2.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,415,1427774400"; d="scan'208";a="7216341" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport2.idirect.net with ESMTP; 12 May 2015 09:08:32 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 12 May 2015 09:08:31 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Tue, 12 May 2015 09:08:30 -0400 From: "Ratliff, Stanley" To: Rick Taylor , "Dearlove, Christopher (UK)" , Stan Ratliff Thread-Topic: [manet] DLEP-10 comments Thread-Index: AdCII4jm5VydMOaDT1Or4xxssYUUnAEkR89A Date: Tue, 12 May 2015 13:08:29 +0000 Message-ID: <5339c8813a714edaa29a2ede148befe8@VAUSDITCHM2.idirect.net> References: <38A5475DE83986499AEACD2CFAFC3F98016755EE25@tss-server1.home.tropicalstormsoftware.com> <44580E3B-4651-4731-B0AE-5E04BD15172F@gmail.com> <38A5475DE83986499AEACD2CFAFC3F98016755FEAD@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F980167563426@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756355A@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F9801675636C7@tss-server1.home.tropicalstormsoftware.com> <38A5475DE83986499AEACD2CFAFC3F98016756377B@tss-server1.home.tropicalstormsoftware.com> In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F98016756377B@tss-server1.home.tropicalstormsoftware.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: Cc: Christopher Dearlove , "manet@ietf.org" Subject: Re: [manet] DLEP-10 comments 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, 12 May 2015 13:08:34 -0000 I'm caught up. :-)=20 Will add some text for the add/drop indicators.=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Rick Taylor > Sent: Tuesday, May 12, 2015 6:22 AM > To: Dearlove, Christopher (UK); Stan Ratliff > Cc: Christopher Dearlove; manet@ietf.org > Subject: Re: [manet] DLEP-10 comments >=20 > On 12/05/15 11:08, Dearlove, Christopher (UK) wrote: > > No, I was just suggesting adding that values other than 0 or 1 were (pi= ck > your own adjective) at that point. Nothing more, the general comment will > then pick up on that. > > >=20 > Ok, sounds sensible... I'll wait for Stan to catch up with the conversati= on. >=20 > Thanks, >=20 > Rick >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Tue May 12 19:08:09 2015 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 3962D1A9028 for ; Tue, 12 May 2015 19: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 KPMoQpqMxYZV for ; Tue, 12 May 2015 19:08:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C741A8BC1 for ; Tue, 12 May 2015 19:08:00 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so19005904lbb.3 for ; Tue, 12 May 2015 19:07: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=BYvQu15w1gCWzU5GqQ3jRQek+JOTjmkx+OpbBeSRCE8=; b=jlMFfq+8WP9M4mV+pOrATWY6/Fc2A8+qotzhxuZNG87qFK7Jy4UosR/3SIBpMvP+kk C1bK45YrqdMW0lZ9qOBPGGmVmU1r8IGHREBW3+cOSL1ciNIBd0Sr3Gcllm5vvxyna6VC zzlZldnKCAzmU85XWcT5Mu+9oW/hjVyE/yq+LELvZQ5lvFgWv7fs2xOBM+JuiblghSVh jDB9hWGpp+AgWQ94RXdkHQX61vqgtFtENTufrEwmkXE+OkLX3mPir6sV6z2mw/aV2w4V XV2UZyl33AGfvu5IhypKMTowxq2PiBiJdheCQGxkRWeeRS3br4ocrcvHus3YWpVbhytL BF1w== MIME-Version: 1.0 X-Received: by 10.112.124.166 with SMTP id mj6mr14287516lbb.104.1431482878784; Tue, 12 May 2015 19:07:58 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Tue, 12 May 2015 19:07:58 -0700 (PDT) In-Reply-To: <72FB622921C13746AD6349E70A8D9F307DEE5B35@EXC-MBX01.tsn.tno.nl> References: <72FB622921C13746AD6349E70A8D9F307DEE5B35@EXC-MBX01.tsn.tno.nl> Date: Tue, 12 May 2015 22:07:58 -0400 Message-ID: From: Stan Ratliff To: "Velt, R. (Ronald) in 't" Content-Type: multipart/alternative; boundary=047d7bfcf7a67dfb3e0515ed1483 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-11 comments 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, 13 May 2015 02:08:07 -0000 --047d7bfcf7a67dfb3e0515ed1483 Content-Type: text/plain; charset=UTF-8 Ronald, Thank you for the review. I have incorporated most of your recommendations, save for two (I believe). I not my rationale inline below. With DLEP-13, I believe the outstanding review items have been addressed. Regards, Stan On Tue, May 12, 2015 at 7:00 AM, Velt, R. (Ronald) in 't < Ronald.intVelt@tno.nl> wrote: > Hi, > > Please find below my (belated) comments on DLEP version -11 (which should > apply to -12 as well) > > Thanks, > Ronald > > > > (Somewhat) Major > ----------------------- > > * I think the document could benefit from a short applicability statement, > either as a separate section or added to the Assumptions section (2). In > particular, the following should/could be addressed: > - Is the modem assumed to act as a transparent layer 2 bridge for data > traffic in all cases? (The text in section 2 on the signalling in > Destination Up messages of MAC addresses for delivering data traffic > suggests as much, but this could be made more explicit). > I disagree. After some reflection and discussion with the other authors, we came to the conclusion that mandating operation of a transparent bridge at layer 2 was overly pedantic. The key text is in paragraph 4 of section 2 (Assumptions): "DLEP assumes that the MAC address for delivering data traffic is the MAC specified in the Destination Up signal (Section 7.9). No manipulation or substitution is performed; the MAC address supplied in Destination Up is used as the OSI Layer 2 Destination MAC address. DLEP also assumes that MAC addresses MUST be unique within the context of a router-modem session." - The Introduction mentions different methods of physically connecting > modem devices to routers. It says, that in the case of Ethernet or serial > attachment, routers are not aware of radio link related events and > characteristics. It goes on to state, that this is one of the challenges > that DLEP addresses. However, given the reliance of DLEP on the use of MAC > addresses, I don't see how DLEP could help in the case a modem is connected > to router by means of a serial link. > - Although it has been stated that DLEP is agnostic to the routing > protocol being used, I wonder whether it works as well for a reactive MANET > routing protocol as for a pro-active MANET routing protocol. The Abstract > says, that routers need characteristics of wireless links to make better > _forwarding_ decisions. Shouldn't that be, at least in the case of > pro-active MANET protocols: better _routing_ decisions? After routes have > been installed in the FIB, the forwarding is nothing more than a next hop > lookup. Not sure how in this works for reactive MANET protocols. > I changed "forwarding" to "routing" in the abstract. As to operation with MANET reactive protocols? To be honest, I don't know. That is (at least to me) part of the reason why DLEP specifies the signals to traverse the modem-router connection, but does NOT specify what is done with the signals. As an example, I can see some avenues for experimentation with DLEP and reactive protocols, but I don't have any idea what the results would be. > > * Section 7.5, Peer Update Signal > - 2nd paragraph: If modems that do not track Layer 3 addresses are to > silently ignore a Peer Update signalling an address change, whereas modems > that _do_ track Layer 3 addresses are to respond with a Peer Update ACK, > how should the router determine whether to retransmit or not? (In other > words, HOW would the router obtain the knowledge to do what the 4th > paragraph of this section says it SHOULD do?) Would it not be more robust > if the modem were required to always respond with a Peer Update ACK, which > in the non-tracking case should contain a Status data item with an > appropriate Status Code (e.g., Request Denied)? Also note the last sentence > of section 7.5, which states that a Peer Update signal MUST be acknowledged > by the receiver issuing a Peer Update ACK signal. This seems to contradict > the "silent ignoring" above. > - Why does the address update mechanism described here (i.e., Peer Update > from router to modem with address change causes Destination Update on the > far end of the radiolink) apply only to simple addresses and not to IPv4 or > IPv6 attached subnets? > The original design of DLEP was that a router, by connecting to a given modem, would already have access to the connected subnets of the local modem. Only subnets on the far-end need to be advertised. > > * Section 7.7, Peer Termination Signal > - 5th/6th paragraph: Interpreting the absence of a Status data item in the > Peer Termination as an implicit Status Code 'Success' does not make sense > to me. I think that in a Peer Termination Signal, the Status data item > should be seen more as a 'Reason' data item, reflecting _why_ the > connection is being torn down. In fact, a separate data item could have > been specified for this purpose. Barring that, in my view a more useful > interpretation of the absence of a Status data item would be: 'Unspecified > reason for termination'. Note that at the time the peer initiating > termination sends this signal, it is by no means certain that termination > will indeed be graceful: What if the other side does not respond with a > Peer Termination ACK signal? > I think the text pretty clearly states that you MUST respond. > > * Section 11, IANA considerations > - Repositories for Signal Types and Data Item (Types) are requested, with > provisions for experimental types of both. However, I do not see similar > provisions for signals and data items of Extensions. Section 3.2 claims: " > The requests for IANA-controlled registries in this document contain > sufficient reserved space, both in terms of DLEP signals and DLEP data > items, to accommodate future extensions to the protocol and the data > transferred". However, as it is now, it seems possible for IANA to allocate > values for all signals and data items currently defined in the document and > reserve all the remaining values for experimental signals and data items, > respectively, leaving no space for Extensions. (But it may well be that I > don't understand how this works!) > I looked at this text, and don't see anything we need to change. The IANA reservations for experimental items in both registries will only be for two or three items, no more. The rest of the registry will be reserved. > > Minor > ------- > > Section 1, Introduction: > - First paragraph, 4th sentence: "It is also quite possible that link > quality and datarate varies" should be: It is also quite possible that link > quality and datarate vary ... > > - An example involving an 802.11g access point is given. Even though Wi-Fi > is ubiquitous these days, it wouldn't hurt to add an informative reference > to IEEE 802.11. Furthermore, "g" is an obsolete indication, as this > amendment has been rolled into IEEE 802.11 several revisions ago. Finally, > there does not seem to be anything "g"-specific about the example, as most, > if not all, PHY variants feature multiple transmission rates. > > Section 1.1, Protocol overview: > - ( I agree with Christopher Dearlove's comment on the "signals" > terminology). > Noted. Not changed, but noted... ;-) > > - last sentence: "The specific algorithms ..... is outside ..." should > be: The specific algorithms ..... are outside ... Likewise: "is left": are > left > > Section 1.2, Requirements > - An old favourite: "NOT RECOMMENDED" is missing. (See Errata to RFC 2119). > > Section 2, Assumptions > - 2nd paragraph, last sentence: "it is strongly recommended that > implementations ..." should be: it is strongly RECOMMENDED that > implementations ... > > -4th paragraph; "It is recommended that DLEP implementations utilize IPv6 > link-local addresses ..." should/could be: It is RECOMMENDED that DLEP > implementations utilize IPv6 link-local addresses ..." > > Section 4, Metrics > - 2nd paragraph: "As mentioned in the introduction section of this > document, DLEP allows for metrics to be sent within two contexts " ; I did > not see this mentioned in the Introduction - it talks about per-destination > information, but does not mention "modem-wide" metrics. > > - 3rd paragraph: "In order to introduce a new metric type, DLEP modem > implementations MUST terminate the session with the router ... and > re-establish the session" should this not be: "In order to introduce a new > metric type, DLEP modem implementations MUST terminate the session with the > router ... and wait for the router to re-establish the session" ? > > - 5th paragraph: " however, the specific algorithms (precedence, etc.) for > utilizing the dual-context metrics is out of scope ..." should be: "... are > out of scope". > > Section 5 > - " (see Appendix A and B for flow diagrams of the discovery signal)" > should be: "(see Appendix A for flow diagrams of the discovery signal ", as > the flow diagrams in Appendix B do not show Peer Discovery signalling. > > Sections 5.1, 5.2 and 5.3 > - All mention of UDP and TCP sockets in these sections is implementational > detail that is best avoided. It is conceivable that routers and /or modems > implement DLEP using a mechanism different from the socket paradigm. A > protocol specification should restrict itself to describing externally > observable behaviour. > > Section 5.4, Common Session Flow > - 4th paragraph: "In cases where metrics are provided at peer level, the > receiver MUST propagate the metrics to all destinations in its information > base that are accessed via the originator". Better would be: " ....to all > entries in its information base for destinations that are accessed via the > originator". (Makes it more clear that this is purely a peer-internal > administrative action). > > Section 6, DLEP Signal Processing > - Section could be renamed to DLEP Signal Structure and Processiing to > better cover its contents. > > Section 6.1, DLEP Signal Header > - Definition of Signal Type: "One of the DLEP Signal Type values defined > in this document" should be: An 8-bit unsigned integer field specifying one > of the DLEP Signal Type values defined in this document. > - Definition of Length field: "The length, expressed as a 16-bit unsigned > integer, of all of the DLEP data items associated with this signal" should > be: The length in bytes, expressed as a 16-bit unsigned integer, of all of > the DLEP data items associated with this signal. > > Section 6.2, DLEP Generic Data Item > - Definition of Length field: "The length, expressed as an 8-bit unsigned > integer, of the value field of the data item" should be: The length in > bytes, expressed as an 8-bit unsigned integer, of the value field of the > data item. > > Section 7.3, Peer Initialization Signal > - 4th paragraph: "timeout and retry heurestics" should be "timeout and > retry heuristics" > > Sections 7.3 and 7.4 > - The capitalisation of NO, NOT and BOTH in these sections is a bit > questionable, as these are not RFC 2119 Imperatives. I think the associated > MUSTs provide sufficient emphasis. > > Section 7.10, Destination Up ACK Signal > - last sentence: "retry heurestics" should be: retry heuristics. > > Section 7.12, Destination Down ACK Signal > - last sentence: "retry heurestics" should be: retry heuristics. > > Section 7.15, Link Characteristics Request Signal > - 2nd paragraph, last sentence: " Issuing a Link Characteristics Request > with ONLY the MAC Address data item is a mechanism a peer MAY use to > request metrics (via the Link Characteristics ACK) from its partner." The > wording leaves open which sides the "peer" and "its partner" are. The > remove any ambiguity, this could be rephrased as: " Issuing a Link > Characteristics Request with ONLY the MAC Address data item is a mechanism > a router MAY use to request metrics (via the Link Characteristics ACK) from > the modem." (Supposing that's the intended meaning!) > I didn't change anything here, either. Don't think the restriction is a requirement, though I do not have a use case yet for modems asking about metrics from a router, although it could... Regards, Stan > > Section 8.2, Status > - 1st paragraph, last sentence: " ... to indicate the success or failure > of the previously received signal." This is not true for Status data items > in Peer Termination signals. See earlier comment on section 7.7. > - Definition of Text field, 1st sentence: "describing an problem" should > be: describing a problem. > > Section 8.6, Heartbeat Interval > - 2nd paragraph, 2nd sentence: "implementations MAY indicates the desire > ..." should be: implementations MAY indicate the desire... > - "non 0" -> non-0 ? > > Section 8.12, IPv4 Attached Subnet > - First sentence: " The DLEP IPv4 Attached Subnet allows a device to > declare that it has an IPv4 subnet (e.g., a stub network) attached, ..." > add: or that it has become aware of an IPv4 subnet being present at a > remote destination. > - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. > Sentence could be rephrased: In case a previously declared IPv4 Attached > Subnet needs to be withdrawn, the associated Destination MUST be brought > down (via the Destination Down signal (Section 7.11)) and then a > Destination Up signal MUST be re-issued, without the IPv4 Attached Subnet > data item. > - Definition of Subnet Mask field: Technically, this is not a subnet mask, > but a prefix length. > > Section 8.13, IPv6 Attached Subnet > - First sentence: " The DLEP IPv6 Attached Subnet allows a device to > declare that it has an IPv6 subnet (e.g., a stub network) attached, ..." > add: or that it has become aware of an IPv6 subnet being present at a > remote destination. > - 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. > Sentence could be rephrased: As in the case of the IPv4 attached Subnet > data item above, when a previously declared IPv6 Attached Subnet needs to > be withdrawn, the associated Destination MUST be brought down (via the > Destination Down signal (Section 7.11)) and then a Destination Up signal > MUST be re-issued, without the IPv6 Attached Subnet data item. > - Definition of Subnet Mask field: Technically, this is not a subnet mask, > but a prefix length. > > Section 8.19, Resources (Receive) > - RESR field: What if a received Resources (Receive) data item contains a > RESR value greater than 100? Should the connection be torn down? > > Section 8.20, Resources (Transmit) > - REST field: What if a received Resources (Transmit) data item contains > a REST value greater than 100? Should the connection be torn down? > > Section 8.21, Relative Link Quality (Receive) > - RLQR field: What if a received Relative Link Quality (Receive) data item > contains a RLQR value greater than 100? Should the connection be torn down? > > Section 8.22, Relative Link Quality (Transmit) > - RLQT field: What if a received Relative Link Quality (Transmit) data > item contains a RLQT value greater than 100? Should the connection be torn > down? > > Section 8.23, Link Characteristics ACK Timer > - 1st sentence: "The Link Characteristics ACK Timer data item MAY appear > in the Link Characteristics Request signal (Section 7.15) to indicate the > desired number of seconds to the sender will wait for a response to the > request." should be: The Link Characteristics ACK Timer data item MAY > appear in the Link Characteristics Request signal (Section 7.15) to > indicate the desired number of seconds the sender will wait for a response > to the request. > - Definition of Interval field: "has been lost" should be: "lost" > > Section 9, Credit-Windowing > - Last paragraph: " MUST include a Extensions Supported data item" should > be: MUST include an Extensions Supported data item. > > Section 9.1.3, Destination Update Signal > - If the Destination Update Signal contains both the (mandatory) Credit > Window Status data item and the (optional) Credit Grant data item, does the > Receive Window value in the former already reflect the increment? > > Section 9.2, Credit-Windowing Data Items > - "MUST correctly process the following data items without error": > "without error" seems redundant. > > Section 9.2.1, Credit Grant > - 2nd paragraph: "If the receiver of a Destination Up signal ... supports > credits, the receiver MUST either reject the use of credits for this > destination ..." should this read: "... does not support credits, ...." ? > - Below format diagram: 'Reserved' field should be: Credit Increment field? > - What do credits represent? Bytes? Could not find this anywhere! > > > > This message may contain information that is not intended for you. If you > are not the addressee or if this message was sent to you by mistake, you > are requested to inform the sender and delete the message. TNO accepts no > liability for the content of this e-mail, for the manner in which you use > it and for damage of any kind resulting from the risks inherent to the > electronic transmission of messages. > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --047d7bfcf7a67dfb3e0515ed1483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ronald,=C2=A0

Thank you for the review.= I have incorporated most of your recommendations, save for two (I believe)= . I not my rationale inline below.=C2=A0

With DLEP= -13, I believe the outstanding review items have been addressed.=C2=A0

Regards,
Stan


On Tue, May 12, 2015 at 7:0= 0 AM, Velt, R. (Ronald) in 't <Ronald.intVelt@tno.nl> wrote:
Hi,

Please find below my (belated) comments on DLEP version -11 (which should a= pply to -12 as well)

Thanks,
Ronald

<start of comments>

(Somewhat) Major
-----------------------

* I think the document could benefit from a short applicability statement, = either as a separate section or added to the Assumptions section (2). In pa= rticular, the following should/could be addressed:
- Is the modem assumed to act as a transparent layer 2 bridge for data traf= fic in all cases?=C2=A0 (The text in section 2 on the signalling in Destina= tion Up messages of MAC addresses for delivering data traffic suggests as m= uch, but this could be made more explicit).

=
I disagree. After some reflection and discussion with the other author= s, we came to the conclusion that mandating operation of a transparent brid= ge at layer 2 was overly pedantic. The key text is in paragraph 4 of sectio= n 2 (Assumptions): =C2=A0"DLEP assumes that the MAC address for delive= ring data traffic is the MAC specified in the Destination Up signal (Sectio= n 7.9).=C2=A0 No manipulation or substitution is performed; the MAC address= supplied in Destination Up is used as the OSI Layer 2 Destination MAC addr= ess. DLEP also assumes that MAC addresses MUST be unique within the context= of a router-modem session."=C2=A0

- The Introduction mentions different methods of physically connecting mode= m devices to routers. It says, that in the case of Ethernet or serial attac= hment, routers are not aware of radio link related events and characteristi= cs. It goes on to state, that this is one of the challenges that DLEP addre= sses. However, given the reliance of DLEP on the use of MAC addresses, I do= n't see how DLEP could help in the case a modem is connected to router = by means of a serial link.
- Although it has been stated that DLEP is agnostic to the routing protocol= being used, I wonder whether it works as well for a reactive MANET routing= protocol as for a pro-active MANET routing protocol. The Abstract says, th= at routers need characteristics of wireless links to make better _forwardin= g_ decisions. Shouldn't that be, at least in the case of pro-active MAN= ET protocols: better _routing_ decisions? After routes have been installed = in the FIB, the forwarding is nothing more than a next hop lookup. Not sure= how in this works for reactive MANET protocols.

<= /div>
I changed "forwarding" to "routing" in the ab= stract. As to operation with MANET reactive protocols? To be honest, I don&= #39;t know. That is (at least to me) part of the reason why DLEP specifies = the signals to traverse the modem-router connection, but does NOT specify w= hat is done with the signals. As an example, I can see some avenues for exp= erimentation with DLEP and reactive protocols, but I don't have any ide= a what the results would be.=C2=A0
=C2=A0

* Section 7.5, Peer Update Signal
- 2nd paragraph: If modems that do not track Layer 3 addresses are to silen= tly ignore a Peer Update signalling an address change, whereas modems that = _do_ track Layer 3 addresses are to respond with a Peer Update ACK, how sho= uld the router determine whether to retransmit or not? (In other words, HOW= would the router obtain the knowledge to do what the 4th paragraph of this= section says it SHOULD do?) Would it not be more robust if the modem were = required to always respond with a Peer Update ACK, which in the non-trackin= g case should contain a Status data item with an appropriate Status Code (e= .g., Request Denied)? Also note the last sentence of section 7.5, which sta= tes that a Peer Update signal MUST be acknowledged by the receiver issuing = a Peer Update ACK signal. This seems to contradict the "silent ignorin= g" above.
- Why does the address update mechanism described here (i.e., Peer Update f= rom router to modem with address change causes Destination Update on the fa= r end of the radiolink) apply only to simple addresses and not to IPv4 or I= Pv6 attached subnets?

The original desi= gn of DLEP was that a router, by connecting to a given modem, would already= have access to the connected subnets of the local modem. Only subnets on t= he far-end need to be advertised.=C2=A0
=C2=A0

* Section 7.7, Peer Termination Signal
- 5th/6th paragraph: Interpreting the absence of a Status data item in the = Peer Termination as an implicit Status Code 'Success' does not make= sense to me. I think that in a Peer Termination Signal, the Status data it= em should be seen more as a 'Reason' data item, reflecting _why_ th= e connection is being torn down. In fact, a separate data item could have b= een specified for this purpose. Barring that, in my view a more useful inte= rpretation of the absence of a Status data item would be: 'Unspecified = reason for termination'. Note that=C2=A0 at the time the peer initiatin= g termination sends this signal, it is by no means certain that termination= will indeed be graceful: What if the other side does not respond with a Pe= er Termination ACK signal?

I think the = text pretty clearly states that you MUST respond.=C2=A0
=C2=A0

* Section 11, IANA considerations
- Repositories for Signal Types and Data Item (Types) are requested, with p= rovisions for experimental types of both. However, I do not see similar pro= visions for signals and data items of Extensions. Section 3.2 claims: "= ; The requests for IANA-controlled registries in this document contain suff= icient reserved space, both in terms of DLEP signals and DLEP data items, t= o accommodate future extensions to the protocol and the data transferred&qu= ot;. However, as it is now, it seems possible for IANA to allocate values f= or all signals and data items currently defined in the document and reserve= all the remaining values for experimental signals and data items, respecti= vely, leaving no space for Extensions. (But it may well be that I don't= understand how this works!)

I looked a= t this text, and don't see anything we need to change. The IANA reserva= tions for experimental items in both registries will only be for two or thr= ee items, no more. The rest of the registry will be reserved.=C2=A0
=C2=A0

Minor
-------

Section 1, Introduction:
- First paragraph, 4th sentence: "It is also quite possible that link = quality and datarate varies" should be: It is also quite possible that= link quality and datarate vary ...

- An example involving an 802.11g access point is given. Even though Wi-Fi = is ubiquitous these days, it wouldn't hurt to add an informative refere= nce to IEEE 802.11. Furthermore, "g" is an obsolete indication, a= s this amendment has been rolled into IEEE 802.11 several revisions ago. Fi= nally, there does not seem to be anything "g"-specific about the = example, as most, if not all, PHY variants feature multiple transmission ra= tes.

Section 1.1, Protocol overview:
- ( I agree with Christopher Dearlove's comment on the "signals&qu= ot; terminology).

Noted. Not changed, b= ut noted... ;-)
=C2=A0

- last sentence: "The specific algorithms ..... is outside ..." s= hould be:=C2=A0 The specific algorithms ..... are outside ... Likewise: &qu= ot;is left": are left

Section 1.2, Requirements
- An old favourite: "NOT RECOMMENDED" is missing. (See Errata to = RFC 2119).

Section 2, Assumptions
- 2nd paragraph, last sentence: "it is strongly recommended that imple= mentations ..." should be: it is strongly RECOMMENDED that implementat= ions ...

-4th paragraph; "It is recommended that DLEP implementations utilize I= Pv6 link-local addresses ..." should/could be: It is RECOMMENDED=C2=A0= that DLEP implementations utilize IPv6 link-local addresses ..."

Section 4, Metrics
- 2nd paragraph: "As mentioned in the introduction section of this doc= ument, DLEP allows for metrics to be sent within two contexts " ; I di= d not see this mentioned in the Introduction - it talks about per-destinati= on information, but does not mention "modem-wide" metrics.

- 3rd paragraph: "In order to introduce a new metric type, DLEP modem = implementations MUST terminate the session with the router ... and re-estab= lish the session" should this not be: "In order to introduce a ne= w metric type, DLEP modem implementations MUST terminate the session with t= he router ... and wait for the router to re-establish the session" ?
- 5th paragraph: " however, the specific algorithms (precedence, etc.)= for utilizing the dual-context metrics is out of scope ..." should be= : "... are out of scope".

Section 5
- " (see Appendix A and B for flow diagrams of the discovery signal)&q= uot; should be: "(see Appendix A for flow diagrams of the discovery si= gnal ", as the flow diagrams in Appendix B do not show Peer Discovery = signalling.

Sections 5.1, 5.2 and 5.3
- All mention of UDP and TCP sockets in these sections is implementational = detail that is best avoided. It is conceivable that routers and /or modems = implement DLEP using a mechanism different from the socket paradigm. A prot= ocol specification should restrict itself to describing externally observab= le behaviour.

Section 5.4, Common Session Flow
- 4th paragraph: "In cases where metrics are provided at peer level, t= he receiver MUST propagate the metrics to all destinations in its informati= on base that are accessed via the originator". Better would be: "= ....to all entries=C2=A0 in its information base for destinations that are= accessed via the originator". (Makes it more clear that this is purel= y a peer-internal administrative action).

Section 6, DLEP Signal Processing
- Section could be renamed to DLEP Signal Structure and Processiing to bett= er cover its contents.

Section 6.1, DLEP Signal Header
- Definition of Signal Type: "One of the DLEP Signal Type values defin= ed in this document" should be: An 8-bit unsigned integer field specif= ying one of the DLEP Signal Type values defined in this document.
- Definition of Length field: "The length, expressed as a 16-bit unsig= ned integer, of all of the DLEP data items associated with this signal"= ; should be: The length in bytes, expressed as a 16-bit unsigned integer, o= f all of the DLEP data items associated with this signal.

Section 6.2, DLEP Generic Data Item
- Definition of Length field: "The length, expressed as an 8-bit unsig= ned integer, of the value field of the data item" should be: The lengt= h in bytes, expressed as an 8-bit unsigned integer, of the value field of t= he data item.

Section 7.3, Peer Initialization Signal
- 4th paragraph: "timeout and retry heurestics" should be "t= imeout and retry heuristics"

Sections 7.3 and 7.4
- The capitalisation of NO, NOT and BOTH in these sections is a bit questio= nable, as these are not RFC 2119 Imperatives. I think the associated MUSTs = provide sufficient emphasis.

Section 7.10, Destination Up ACK Signal
- last sentence: "retry heurestics" should be: retry=C2=A0 heuris= tics.

Section 7.12, Destination Down ACK Signal
- last sentence: "retry heurestics" should be: retry=C2=A0 heuris= tics.

Section 7.15, Link Characteristics Request Signal
- 2nd paragraph, last sentence: " Issuing a Link Characteristics Reque= st with ONLY the MAC Address data item is a mechanism a peer MAY use to req= uest metrics (via the Link Characteristics ACK) from its partner." The= wording leaves open which sides the "peer" and "its partner= " are. The remove any ambiguity, this could be rephrased as: " Is= suing a Link Characteristics Request with ONLY the MAC Address data item is= a mechanism a router MAY use to request metrics (via the Link Characterist= ics ACK) from the modem." (Supposing that's the intended meaning!)=

I didn't change anything here, eit= her. Don't think the restriction is a requirement, though I do not have= a use case yet for modems asking about metrics from a router, although it = could...


Regards,
Stan
=C2=A0

Section 8.2, Status
- 1st paragraph, last sentence: " ... to indicate the success or failu= re of the previously received signal." This is not true for Status dat= a items in Peer Termination signals. See earlier comment on section 7.7. - Definition of Text field, 1st sentence: "describing an problem"= should be: describing a problem.

Section 8.6, Heartbeat Interval
- 2nd paragraph, 2nd sentence: "implementations MAY indicates the desi= re ..." should be: implementations MAY indicate the desire...
- "non 0" -> non-0 ?

Section 8.12, IPv4 Attached Subnet
- First sentence: " The DLEP IPv4 Attached Subnet allows a device to d= eclare that it has an IPv4 subnet (e.g., a stub network) attached, ..."= ; add: or that it has become aware of an IPv4 subnet being present at a rem= ote destination.
- 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentenc= e could be rephrased: In case a previously declared IPv4 Attached Subnet ne= eds to be withdrawn, the associated Destination MUST be brought down (via t= he Destination Down signal (Section 7.11)) and then a Destination Up signal= MUST be re-issued, without the IPv4 Attached Subnet data item.
- Definition of Subnet Mask field: Technically, this is not a subnet mask, = but a prefix length.

Section 8.13, IPv6 Attached Subnet
- First sentence: " The DLEP IPv6 Attached Subnet allows a device to d= eclare that it has an IPv6 subnet (e.g., a stub network) attached, ..."= ; add: or that it has become aware of an IPv6 subnet being present at a rem= ote destination.
- 1st paragraph: Capitalised NOT is NOT :-) an RFC 2119 Imperative. Sentenc= e could be rephrased: As in the case of the IPv4 attached Subnet data item = above, when a previously declared IPv6 Attached Subnet needs to be withdraw= n, the associated Destination MUST be brought down (via the Destination Dow= n signal (Section 7.11)) and then a Destination Up signal MUST be re-issued= , without the IPv6 Attached Subnet data item.
- Definition of Subnet Mask field: Technically, this is not a subnet mask, = but a prefix length.

Section 8.19, Resources (Receive)
- RESR field: What if a received Resources (Receive) data item contains a R= ESR value greater than 100? Should the connection be torn down?

Section 8.20, Resources (Transmit)
=C2=A0- REST field: What if a received Resources (Transmit) data item conta= ins a REST value greater than 100? Should the connection be torn down?

Section 8.21, Relative Link Quality (Receive)
- RLQR field: What if a received Relative Link Quality (Receive) data item = contains a RLQR value greater than 100? Should the connection be torn down?=

Section 8.22, Relative Link Quality (Transmit)
- RLQT field: What if a received Relative Link Quality (Transmit) data item= contains a RLQT value greater than 100? Should the connection be torn down= ?

Section 8.23, Link Characteristics ACK Timer
- 1st sentence: "The Link Characteristics ACK Timer data item MAY appe= ar in the Link Characteristics Request signal (Section 7.15) to indicate th= e desired number of seconds to the sender will wait for a response to the r= equest." should be:=C2=A0 The Link Characteristics ACK Timer data item= MAY appear in the Link Characteristics Request signal (Section 7.15) to in= dicate the desired number of seconds the sender will wait for a response to= the request.
- Definition of Interval field: "has been lost" should be: "= lost"

Section 9, Credit-Windowing
- Last paragraph: " MUST include a Extensions Supported data item"= ; should be: MUST include an Extensions Supported data item.

Section 9.1.3, Destination Update Signal
- If the Destination Update Signal contains both the (mandatory) Credit Win= dow Status data item and the (optional) Credit Grant data item, does the Re= ceive Window value in the former already reflect the increment?

Section 9.2, Credit-Windowing Data Items
- "MUST correctly process the following data items without error"= : "without error" seems redundant.

Section 9.2.1, Credit Grant
- 2nd paragraph: "If the receiver of a Destination Up signal ... suppo= rts credits, the receiver=C2=A0 MUST either reject the use of credits for t= his destination ..." should this read: "... does not support cred= its, ...." ?
- Below format diagram: 'Reserved' field should be: Credit Incremen= t field?
- What do credits represent? Bytes? Could not find this anywhere!

<enf of comments>

This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages.

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

--047d7bfcf7a67dfb3e0515ed1483-- From nobody Wed May 13 06:16:01 2015 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 D2E5B1A9234; Wed, 13 May 2015 06:15:57 -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] 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 W24jnxrKTGlq; Wed, 13 May 2015 06:15:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9531A9238; Wed, 13 May 2015 06:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513131549.5948.72719.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 06:15:49 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-13.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:15:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-13.txt Pages : 66 Date : 2015-05-12 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-13 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 06:55:09 2015 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 B73BA1B2BD0 for ; Wed, 13 May 2015 06:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 84Q-na6quWuv for ; Wed, 13 May 2015 06:55:04 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946371B2BD2 for ; Wed, 13 May 2015 06:55:03 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1YsX7l-001gOY-4u>; Wed, 13 May 2015 15:55:01 +0200 Received: from ws57.eduroam.haw-hamburg.de ([141.22.56.57]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1YsX7l-000UyM-1l>; Wed, 13 May 2015 15:55:01 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB7C291-BDA4-456E-B919-514172990F9D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: Date: Wed, 13 May 2015 15:55:00 +0200 Message-Id: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 141.22.56.57 X-ZEDAT-Hint: A Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 translation tables 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, 13 May 2015 13:55:07 -0000 --Apple-Mail=_BFB7C291-BDA4-456E-B919-514172990F9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Christopher, thanks for your feedback. Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) = : > There is a style question that all existing TLVs have names like = LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=92t think = IANA enforce such issues, and different people will have different = opinions on the importance of consistent style. (Naming can matter, = we=92re spending cycles on an ID just about TLV names.) > =20 Absolutely. In your opinion, would it suffice to adjust the current = names stylistically (see attached file), or do some names need extra = work in terms of clarification or consistency? (I was just wondering if = METRIC should be edited to make clear that it is not directly related to = LINK_METRIC...) Regards, Lotte > (I haven=92t checked if planning to use message specific TLV numbering = range.) > =20 > -- >=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > = __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai >=20 > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 > =20 >=20 > =20 > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte = Steenbrink > Sent: 06 May 2015 17:31 > To: manet@ietf.org > Subject: [manet] RFC 5444 translation tables > =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=20 > links, open any attachments or reply. > Follow the 'Report Suspicious Emails' link on IT matters > for instructions on reporting suspicious email messages. > -------------------------------------------------------- >=20 > Hi all, > as promised in today's interim meeting, the updated section on RFC = 5444 messages in AODVv2. The idea is that this section merely details = how to translate the generic AODVv2 packet format which is used = throughout the draft into RFC 5444 messages. The primary goal was to = make the representation more readable, but we've made some tweaks to the = way data elements are encoded, too. I'd be very grateful about any = feedback on both whether our representation is easy to understand (and = what might be improved) as well as if there's anything that's illegal or = could be arranged more elegantly in terms of RFC 5444-ish-ness.=20 > It's important to know that DEFAULT_METRIC_TYPE now has the value 0, = so not supplying an exttype for MetricType implicitly sets the metric = type to DEFAULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself = still has the value 3, so as to remain consistent with RFC6551 and = enable the explicit declaration of hop count as the metric type.=20 >=20 > In case there's any other context missing, please let me know. = Victoria has edited the draft pretty heavily to increase its readability = and clarity, so once the new revision is out, it should help provide = some more context, too. >=20 > Regards, > Lotte >=20 >=20 >=20 >=20 > _______________________________________________ > 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. > ******************************************************************** >=20 --Apple-Mail=_BFB7C291-BDA4-456E-B919-514172990F9D Content-Type: multipart/mixed; boundary="Apple-Mail=_314B6B33-27B9-4DFA-97C1-1FA6B2C509CD" --Apple-Mail=_314B6B33-27B9-4DFA-97C1-1FA6B2C509CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Christopher,
thanks for your feedback.

Am = 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.co= m>:

There is a style question that all existing TLVs have = names like LINK_STATUS, while here TLVs have names like OrigSeqNum. I = don=92t think IANA enforce such issues, and different people will have = different opinions on the importance of consistent style. (Naming can = matter, we=92re spending cycles on an ID just about TLV = names.)
 

Abs= olutely. In your opinion, would it suffice to adjust the current names = stylistically (see attached file), or do some names need extra work in = terms of clarification or consistency? (I was just wondering if METRIC = should be edited to make clear that it is not directly related to = LINK_METRIC...)

Regards,
Lotte

= --Apple-Mail=_314B6B33-27B9-4DFA-97C1-1FA6B2C509CD Content-Disposition: attachment; filename="RFC5444 section - Lotte 2 - TLV renaming.txt" Content-Type: text/plain; name="RFC5444 section - Lotte 2 - TLV renaming.txt" Content-Transfer-Encoding: quoted-printable The following sections show how AODVv2 data elements are represented in RFC 5444 messages. See Section 12 for more information about the Message TLVs and Address Block TLVs AODVv2 defines, and the type numbers allocated. 8.1. RREQ 8.1.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | msg_hop_limit | | MAX_HOPCOUNT | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | | Message Type | | RREQ | +---------------+-----------------+---------------------------------+ 8.1.2. Message TLV Block A RREQ contains no Message TLVs. 8.1.3. Address Block A RREQ contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. +-------------------------+-----------------------------------------+ | Data Elements | Address Block | +-------------------------+-----------------------------------------+ | OrigAddr/OrigPrefixLen |
and | | TargAddr/TargPrefixLen |
and | +-------------------------+-----------------------------------------+ 8.1.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each Address. 8.1.4.1. Address Block TLVs for OrigAddr Perkins, et al. Expires October 31, 2015 [Page 47] =0C Internet-Draft AODVv2 April 2015 +-------------+--------------+------------+-------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+--------------+------------ +------------------------+ | OrigSeqNum | ORIG_SEQ_NUM | 0 | Sequence Number of | | | | | RREQ_Gen, the router | | | | | which initiated route | | | | | discovery. | | OrigMetric | METRIC | METRIC_TYPE | Metric for the route | | /MetricType | | (optional) | to OrigAddr, using | | | | | MetricType. | +-------------+--------------+------------ +------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. 8.1.4.2. Address Block TLVs for TargAddr +----------------+--------------+------------+----------------------+ | Data Element | TLV Type | Extension | Value | | | | Type | | +----------------+--------------+------------+----------------------+ | TargSeqNum | TARG_SEQ_NUM | 0 | The last known | | (optional) | | | TargSeqNum for | | | | | TargAddr. | +----------------+--------------+------------+----------------------+ 8.2. RREP 8.2.1. Message Header +---------------+-----------------+---------------------------------+ | Data Element | Header Field | Value | +---------------+-----------------+---------------------------------+ | msg_hop_limit | | from | | | | corresponding RREQ. | | msg_hop_count | | Number of hops traversed so far | | | | by the message. | | Message Type | | RREP | +---------------+-----------------+---------------------------------+ 8.2.2. Message TLV Block A RREP may contain the AckReq message TLV in order to monitor adjacency, as described in Section 6.2. Perkins, et al. Expires October 31, 2015 [Page 48] =0C Internet-Draft AODVv2 April 2015 +--------------------+-----------+-----------------+--------+ | Data Element | TLV Type | Extension Type | Value | +--------------------+-----------+-----------------+--------+ | AckReq (optional) | ACK_REQ | 0 | None | +--------------------+-----------+-----------------+--------+ 8.2.3. Address Block A RREP contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. +-------------------------+-----------------------------------------+ | Data Elements | Address Block | +-------------------------+-----------------------------------------+ | OrigAddr/OrigPrefixLen |
and | | TargAddr/TargPrefixLen |
and | +-------------------------+-----------------------------------------+ 8.2.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following sections show the TLVs that apply to each Address. 8.2.4.1. Address Block TLVs for OrigAddr No Address Block TLVs apply to OrigAddr in a RREP. 8.2.4.2. Address Block TLVs for TargAddr +-------------+--------------+-------------+------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+--------------+-------------+------------------------+ | TargSeqNum | TARG_SEQ_NUM | 0 | Sequence number of | | | | | RREP_Gen, the router | | | | | which created the RREP.| | TargMetric | METRIC | METRIC_TYPE | Metric for the route | | /MetricType | | (optional) | to TargAddr, using | | | | | MetricType. | +-------------+--------------+-------------+------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. Perkins, et al. Expires October 31, 2015 [Page 49] =0C Internet-Draft AODVv2 April 2015 8.3. RREP_Ack 8.3.1. Message Header +----------------+------------------+-----------+ | Data Element | Header Field | Value | +----------------+------------------+-----------+ | msg_hop_limit | | 1 | | Message Type | | RREP_Ack | +----------------+------------------+-----------+ 8.3.2. Message TLV Block A RREP_Ack contains no Message TLVs. 8.3.3. Address Block A RREP_Ack contains no Address Block. 8.3.4. Address Block TLV Block A RREP_Ack contains no Address Block TLV Block. 8.4. RERR 8.4.1. Message Header +----------------+------------------+---------------+ | Data Element | Header Field | Value | +----------------+------------------+---------------+ | msg_hop_limit | | MAX_HOPCOUNT | | Message Type | | RERR | +----------------+------------------+---------------+ 8.4.2. Message TLV Block A RERR may contain the PktSource message TLV as detailed in Section 7.4. +-------------+------------+-----------+----------------------------+ | Data | TLV Type | Extension | Value | | Element | | Type | | +-------------+------------+-----------+----------------------------+ | PktSource | PKT_SOURCE | 0 | The source IP address of | | (optional) | | | the packet triggering RERR | | | | | generation. | +-------------+------------+-----------+----------------------------+ Perkins, et al. Expires October 31, 2015 [Page 50] =0C Internet-Draft AODVv2 April 2015 8.4.3. Address Block A RERR contains one Address, the Unreachable Address, for each route that is no longer valid. Each address has an associated prefix length. +------------------------------+------------------------------------+ | Data Element | Address Block | +------------------------------+------------------------------------+ | AddressList/PrefixLengthList |
and | +------------------------------+------------------------------------+ 8.4.4. Address Block TLV Block Address Block TLVs are always associated with addresses in the Address Block. The following section shows the TLVs that apply to each Unreachable Address in the RERR. 8.4.4.1. Address Block TLVs for Unreachable Addresses +------------+-------- +------------ +------------------------------+ | Data | TLV | Extension | Value | | Element | Type | Type | | +------------+-------- +------------ +------------------------------+ | SeqNum | SEQ_NUM | 0 | Sequence Number associated | | (optional) | | | with invalid route to the | | | | | Unreachable Address. | | MetricType | METRIC | METRIC_TYPE | None. Extension Type set to | | (optional) | | | MetricType of the route to | | | | | the Unreachable Address. | +------------+-------- +------------ +------------------------------+ MetricType, if not included, is assumed to be DEFAULT_METRIC_TYPE. --Apple-Mail=_314B6B33-27B9-4DFA-97C1-1FA6B2C509CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

(I haven=92t checked if planning to use message = specific TLV numbering range.)
 

--

Christopher Dearlove
Senior Principal Engineer
BAE Systems = Applied Intelligence
___________________________________________________________________= _______

T:  +44 (0)1245 = 242194  |  E: chris.dearlove@baesystems.com

BAE Systems Applied Intelligence, = Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 = 8HN.
www.baesystems.com/ai

BAE Systems Applied Intelligence = Limited
Registered in England & Wales No: = 01337451

Registered Office: Surrey Research Park, = Guildford, Surrey, GU2 7YP

 

 
From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte = Steenbrink
Sent: 06 May 2015 = 17:31
To: manet@ietf.org
Subject: [manet] RFC 5444 = translation tables
 

----------------------! = 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.
--------------------------------------------------------
<= br>Hi all,
as promised in today's interim meeting, the updated = section on RFC 5444 messages in AODVv2. The idea is that this section = merely details how to translate the generic AODVv2 packet format which = is used throughout the draft into RFC 5444 messages. The primary goal = was to make the representation more readable, but we've made some tweaks = to the way data elements are encoded, too. I'd be very grateful about = any feedback on both whether our representation is easy to understand = (and what might be improved) as well as if there's anything that's = illegal or could be arranged more elegantly in terms of RFC = 5444-ish-ness. 
It's = important to know that DEFAULT_METRIC_TYPE now has the value 0, so not = supplying an exttype for MetricType implicitly sets the metric type to = DEFAULT_METRIC_TYPE, which maps to Hop Count. Hop Count itself still has = the value 3, so as to remain consistent with RFC6551 and enable the = explicit declaration of hop count as the metric type. 

In case there's any = other context missing, please let me know. Victoria has edited the draft = pretty heavily to increase its readability and clarity, so once the new = revision is out, it should help provide some more context, = too.

Regards,
Lotte



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


= --Apple-Mail=_314B6B33-27B9-4DFA-97C1-1FA6B2C509CD-- --Apple-Mail=_BFB7C291-BDA4-456E-B919-514172990F9D-- From nobody Wed May 13 07:05:29 2015 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 259201B2C2E for ; Wed, 13 May 2015 07:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 TUiNzZLS32Sx for ; Wed, 13 May 2015 07:05:24 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (uk-ext-viruswalls.astrium.eads.net [194.62.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 09B8C1B2C43 for ; Wed, 13 May 2015 07:05:04 -0700 (PDT) Received: from uk-ext-viruswalls.astrium.eads.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7E2293238D for ; Wed, 13 May 2015 15:05:02 +0100 (BST) Received: from auk52782.uk.astrium.corp (unknown [10.201.208.4]) by uk-ext-viruswalls.astrium.eads.net (Postfix) with ESMTP id 6E58732374 for ; Wed, 13 May 2015 15:05:02 +0100 (BST) Received: from E2K3-PTH-BRIDGEHEAD.UKN.UKNroot.astrium.corp ([10.221.1.32]) by auk52782.uk.astrium.corp with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 May 2015 15:05:02 +0100 Received: from AUK52982.UKN.UKNROOT.ASTRIUM.CORP ([fe80::543e:db1:48aa:1c6]) by AUK52839.UKN.UKNROOT.ASTRIUM.CORP ([fe80::cdf2:d214:a3a9:7510%15]) with mapi id 14.03.0123.003; Wed, 13 May 2015 15:05:01 +0100 From: "MATTY, Steven" To: "'manet@ietf.org'" Thread-Topic: DLEP-13 question Thread-Index: AdCNhaNYRf7ou+lpRBSJUeKBBIzxHQ== Date: Wed, 13 May 2015 14:05:01 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.1.73] X-TM-AS-Product-Ver: IMSVA-8.5.0.1165-7.5.0.1018-21544.000 X-TM-AS-Result: No--17.297-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_D9712B947A4CCA43AB42F01B90AF1DECC6A64240AUK52982UKNUKNR_" MIME-Version: 1.0 X-OriginalArrivalTime: 13 May 2015 14:05:02.0042 (UTC) FILETIME=[CE0623A0:01D08D85] X-TM-AS-MML: disable X-imss-scan-details: No--17.297-5.0-31-10 X-TMASE-Version: IMSVA-8.5.0.1165-7.5.1018-21544.000 X-TMASE-Result: 10--17.297300-5.000000 X-TMASE-MatchedRID: dh83+NkbifmME64fNVJtEayBo9Jaui9GUrQk40lSPY6vloAnGr4qhlZm IDpOUQO+dUVZXChPjCDqRiUgB0CArEdb73gUDwkXQr2qXCJMSV/qvccKLF+4pxziuLhElX/VJZ4 4eKUvRYc/makG0+v97gFk6w4YcqmhSOWjYlTyoLGYcl4BgqVyk3G1ZiUO5FCl55TSoW/nwH457k FjOTI5JYBMc1fifV0YIE9ITYPIT1lcvC4hPS8YXiI9MxSOQ6CSLVEjAx3HjK6k7BPGf466/guVM ctAPCgtu7C4hieFwVKAMuqetGVeto1kLJo+k6Ny91FK7AgaIRSOhzOa6g8KrZU0QLbVYb/QZFKh 6UMoR9N7ZPtKVbD8IlcjiaLM87z6dKZtxBY7Vgs= Archived-At: Subject: [manet] DLEP-13 question 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, 13 May 2015 14:05:27 -0000 --_000_D9712B947A4CCA43AB42F01B90AF1DECC6A64240AUK52982UKNUKNR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stan et al, A quick question popped into my head whilst going through the latest DLEP= draft regarding the Relative Link Quality Receive (RLQR) and Transmit (R= LQT) data items. These are both defined as : "A non-dimensional 8-bit integer, 1-100, representing relative link qua= lity. A value of 100 represents a link of the highest quality. Any valu= e greater than 100 MUST be considered as invalid." My question is, should a value of 0 (zero) also be considered as invalid,= or would it worth specifying the range as 0-100 ? Regards Steve This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Airbus Defence and Space Limited disclaims any and all = liability if this email transmission was virus corrupted, altered or falsified. -o- Airbus Defence and Space Limited, Registered in England and Wales No. 244= 9259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England --_000_D9712B947A4CCA43AB42F01B90AF1DECC6A64240AUK52982UKNUKNR_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Stan et al,

 

A quick question popped into my head whilst going = through the latest DLEP draft regarding the Relative Link Quality Receive= (RLQR) and Transmit (RLQT) data items. These are both defined as :<= /o:p>

“A non-dimensional 8-bit integer,  &nbs= p;1-100, representing relative link quality.  A value of 100 represe= nts a link of the highest quality.  Any value greater than 100 MUST = be considered as invalid.”

 

My question is, should a value of 0 (zero) also be= considered as invalid, or would it worth specifying the range as 0-100 ?=

 

Regards

 

Steve

 

This email (i=
ncluding any attachments) may contain confidential
and/or privileged information or information otherwise protected
from disclosure. If you are not the intended recipient, please
notify the sender immediately, do not copy this message or any
attachments and do not use it for any purpose or disclose its
content to any person, but delete this message and any attachments
from your system. Airbus Defence and Space Limited disclaims any and all =
liability if this email transmission was virus corrupted,
altered or falsified.
-o-
Airbus Defence and Space Limited, Registered in England and Wales No. 244=
9259
Registered Office:
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England
--_000_D9712B947A4CCA43AB42F01B90AF1DECC6A64240AUK52982UKNUKNR_-- From nobody Wed May 13 07:11:19 2015 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 5F0411B2C58 for ; Wed, 13 May 2015 07:11:18 -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 RnXoiLRogSqP for ; Wed, 13 May 2015 07:11:17 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD94B1B2C15 for ; Wed, 13 May 2015 07:11:16 -0700 (PDT) Received: by widdi4 with SMTP id di4so200494727wid.0 for ; Wed, 13 May 2015 07:11: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:content-transfer-encoding; bh=i2crZYmqMS6WnhyNe/bMdJ0y00Qk1D/dLq9of8FTNck=; b=k33cpTdnETQe1fmnozKVngqZdFDyLVKMu2VvVZ4RMIGWfhf4W2gG+uuNDYwQgqEKuz rTz27uJ99w+ZhPjD5alybxM1tO0ZBhuo5aooISXcflD/GgUeJFd7MuSCnykcW/DZLm1B xPsBw2iykz3fuD7TgoYzf6fiACe1HFt8tW/Nt5leJPY+F+XzPhSaTr7jeC4e0vlu1c5t YtuW3wKBHgaRGOmeSnnndjIgvREvQz82bfqXynBJxNNXl37OR6BQL8cK6tTM9EOkKMEF 0PMBCT8UXfxa9zjYVV/2+6cxuhms0+h+zXs/k/CcgeK2jQ87v0sKjowpVGnxS48GHxqT Revw== X-Received: by 10.180.88.72 with SMTP id be8mr39742667wib.45.1431526275390; Wed, 13 May 2015 07:11:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 13 May 2015 07:10:54 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> From: Henning Rogge Date: Wed, 13 May 2015 16:10:54 +0200 Message-ID: To: Lotte Steenbrink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Dearlove, Christopher \(UK\)" , "manet@ietf.org" Subject: Re: [manet] RFC 5444 translation tables 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, 13 May 2015 14:11:18 -0000 On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink wrote: > Hi Christopher, > thanks for your feedback. > > Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) > : > > There is a style question that all existing TLVs have names like > LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2=80=99t = think IANA > enforce such issues, and different people will have different opinions on > the importance of consistent style. (Naming can matter, we=E2=80=99re spe= nding > cycles on an ID just about TLV names.) > > > > Absolutely. In your opinion, would it suffice to adjust the current names > stylistically (see attached file), or do some names need extra work in te= rms > of clarification or consistency? (I was just wondering if METRIC should b= e > edited to make clear that it is not directly related to LINK_METRIC...) Maybe the name "PATH_METRIC" would make sense for the new TLV... this describes the usage of the TLV very well. Henning Rogge From nobody Wed May 13 07:13:20 2015 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 939B21B2C69 for ; Wed, 13 May 2015 07:13:18 -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 w4AxPJe51Nom for ; Wed, 13 May 2015 07:13:17 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46DA01B2C62 for ; Wed, 13 May 2015 07:13:17 -0700 (PDT) Received: by widdi4 with SMTP id di4so57571660wid.0 for ; Wed, 13 May 2015 07:13:16 -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=SBF2JsKiOANK8XUbmkwxKOC0qQ19ZqyAFht+kK/5RXQ=; b=t69mGkTjXc0lhA8Kq1D+XYsx/Y/0PG4pTgfqhWobZZakkxFgsRx+aK1923YU/4WLNw j7OTvzDIGlV1Nygj9beI6TH7EL94xC/FiZBGur/px3Lvhb2a6pefQmsTHdpm0QGNhXv1 T+fPn2P0PdmBxpgUTy4hy9mzWfHJZyyMP+EZoDrcYMoMSqPc03aHShtPDJbZB2aQl7R4 jWSLQKZts6iRNzVGADRLYycF0oAfN3l96hG8xrAgrK24V85Nr7VUEsIkeAb+fAFIeSmu pLBcPcdvWVo1GDjE9oK1UhFDUlJHlFg8Jxa3mV1Td4CDR/pU6kEFG3yLM4CcYBrN0Kb0 GFbA== X-Received: by 10.180.88.99 with SMTP id bf3mr39513469wib.75.1431526396058; Wed, 13 May 2015 07:13:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.0.5 with HTTP; Wed, 13 May 2015 07:12:55 -0700 (PDT) In-Reply-To: References: From: Henning Rogge Date: Wed, 13 May 2015 16:12:55 +0200 Message-ID: To: "MATTY, Steven" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-13 question 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, 13 May 2015 14:13:18 -0000 On Wed, May 13, 2015 at 4:05 PM, MATTY, Steven wrote: > > Hi Stan et al, > > > > A quick question popped into my head whilst going through the latest DLEP= draft regarding the Relative Link Quality Receive (RLQR) and Transmit (RLQ= T) data items. These are both defined as : > > =E2=80=9CA non-dimensional 8-bit integer, 1-100, representing relative = link quality. A value of 100 represents a link of the highest quality. An= y value greater than 100 MUST be considered as invalid.=E2=80=9D > > > > My question is, should a value of 0 (zero) also be considered as invalid,= or would it worth specifying the range as 0-100 ? I think you found another typo... RFC5578 defined metric as 0-100. Henning Rogge From nobody Wed May 13 07:22:19 2015 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 7F8E81B2CD7 for ; Wed, 13 May 2015 07:22:18 -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 NIoVg4kUdyLh for ; Wed, 13 May 2015 07:22:15 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C590F1B2CE2 for ; Wed, 13 May 2015 07:22:14 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so30797554lbb.0 for ; Wed, 13 May 2015 07:22:13 -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=GghCgWc/e64J/lPyaz3ZIuHhp8clqdDunOvDL9ZfDcI=; b=EcQjaIljq4R91cfzJ0aB5+lZ0e9xcIlGZY7UrmnHWmDoo6THbWFt+3R+YKubFvcIfZ zQa6L+veCU/AYBrqrTcqqkhfmWcuz+USfmhijsR2e1Jfhu1FCdnkz8DTAumXEMCaFau3 Xd0IgyHM8BtP/unua8Dbj8YFsdbJYavF46DykKHiv7vl8HT/oP9yTX2Of8AZfgV+M92z /ZdMbBFWvXr7qtYcPqkmgjL+V6S5ms+5KytHohDYFz+EYR61JeZGcZYH+kmdoRhajGJX OKOVw8JviH7jWuH6ls4DUbu0WY5qQYrM8T9C1wRC5ZjG9GhktczN6wg4L1VJQP5sF4eV pPVQ== MIME-Version: 1.0 X-Received: by 10.152.36.2 with SMTP id m2mr15964196laj.72.1431526933375; Wed, 13 May 2015 07:22:13 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Wed, 13 May 2015 07:22:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 10:22:13 -0400 Message-ID: From: Stan Ratliff To: Henning Rogge Content-Type: multipart/alternative; boundary=089e0158b82859b0950515f7565f Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-13 question 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, 13 May 2015 14:22:18 -0000 --089e0158b82859b0950515f7565f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable SIGH..... I guess there will be yet another "DLEP du jour" tonight... ;-) Regards, Stan On Wed, May 13, 2015 at 10:12 AM, Henning Rogge wrote: > On Wed, May 13, 2015 at 4:05 PM, MATTY, Steven > wrote: > > > > Hi Stan et al, > > > > > > > > A quick question popped into my head whilst going through the latest > DLEP draft regarding the Relative Link Quality Receive (RLQR) and Transmi= t > (RLQT) data items. These are both defined as : > > > > =E2=80=9CA non-dimensional 8-bit integer, 1-100, representing relativ= e link > quality. A value of 100 represents a link of the highest quality. Any > value greater than 100 MUST be considered as invalid.=E2=80=9D > > > > > > > > My question is, should a value of 0 (zero) also be considered as > invalid, or would it worth specifying the range as 0-100 ? > > I think you found another typo... > > RFC5578 defined metric as 0-100. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e0158b82859b0950515f7565f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SIGH.....=C2=A0

I guess there will be y= et another "DLEP du jour" tonight... ;-)

Regards,
Stan


On Wed, May 13, 2015 at 10:12 AM, Henning= Rogge <hrogge@gmail.com> wrote:
On Wed, May 13, 2015 at 4:05 PM, MATTY, Steven
<steven.matty@astrium.e= ads.net> wrote:
>
> Hi Stan et al,
>
>
>
> A quick question popped into my head whilst going through the latest D= LEP draft regarding the Relative Link Quality Receive (RLQR) and Transmit (= RLQT) data items. These are both defined as :
>
> =E2=80=9CA non-dimensional 8-bit integer,=C2=A0 =C2=A01-100, represent= ing relative link quality.=C2=A0 A value of 100 represents a link of the hi= ghest quality.=C2=A0 Any value greater than 100 MUST be considered as inval= id.=E2=80=9D
>
>
>
> My question is, should a value of 0 (zero) also be considered as inval= id, or would it worth specifying the range as 0-100 ?

I think you found another typo...

RFC5578 defined metric as 0-100.

Henning Rogge

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

--089e0158b82859b0950515f7565f-- From nobody Wed May 13 07:33:08 2015 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 BB1401B2D01 for ; Wed, 13 May 2015 07:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 wcp_SQqicW8M for ; Wed, 13 May 2015 07:33:04 -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 DAA001B2D09 for ; Wed, 13 May 2015 07:33:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,421,1427756400"; d="scan'208";a="465779393" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 13 May 2015 15:33:00 +0100 X-IronPort-AV: E=Sophos;i="5.13,421,1427756400"; d="scan'208";a="101918627" Received: from glkxh0001v.greenlnk.net ([10.109.2.32]) by baemasodc005.greenlnk.net with ESMTP; 13 May 2015 15:33:00 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0001V.GREENLNK.net ([10.109.2.32]) with mapi id 14.03.0224.002; Wed, 13 May 2015 15:33:00 +0100 From: "Dearlove, Christopher (UK)" To: Henning Rogge , Lotte Steenbrink Thread-Topic: [manet] RFC 5444 translation tables Thread-Index: AQHQiBo0ZM63Aqka3kqbkDjZ519xRZ1wR18QgAmgdwCAAARxAIAAFrJg Date: Wed, 13 May 2015 14:33:00 +0000 Message-ID: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] RFC 5444 translation tables 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, 13 May 2015 14:33:06 -0000 SSBkb24ndCBoYXZlIHRpbWUgdG8gbG9vayBhdCB0aGlzIHRvZGF5LCBidXQgSGVubmluZydzIHN1 Z2dlc3Rpb24gbG9va3MgZ29vZC4NCg0KLS0gDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0KU2VuaW9y IFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNClQ6IMKgKzQ0ICgwKTEyNDUgMjQyMTk0IMKgfCDCoEU6IGNocmlz LmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tDQoNCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3Jk LCBFc3NleCBDTTIgOEhOLg0Kd3d3LmJhZXN5c3RlbXMuY29tL2FpDQpCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSBMaW1pdGVkDQpSZWdpc3RlcmVkIGluIEVuZ2xhbmQgJiBXYWxlcyBO bzogMDEzMzc0NTENClJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3Vp bGRmb3JkLCBTdXJyZXksIEdVMiA3WVANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBIZW5uaW5nIFJvZ2dlIFttYWlsdG86aHJvZ2dlQGdtYWlsLmNvbV0gDQpTZW50OiAx MyBNYXkgMjAxNSAxNToxMQ0KVG86IExvdHRlIFN0ZWVuYnJpbmsNCkNjOiBEZWFybG92ZSwgQ2hy aXN0b3BoZXIgKFVLKTsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJGQyA1 NDQ0IHRyYW5zbGF0aW9uIHRhYmxlcw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBXQVJOSU5H ICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91 dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBv ciBmcm9tIHRoZSBpbnRlcm5ldC4NCkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91 bGQgY2xpY2sgb24gYW55IGxpbmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS4NCkZv bGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJzIGZv ciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpPbiBXZWQsIE1heSAxMywgMjAxNSBhdCAzOjU1IFBNLCBMb3R0ZSBTdGVlbmJyaW5rIDxsb3R0 ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZT4gd3JvdGU6DQo+IEhpIENocmlzdG9waGVyLA0KPiB0 aGFua3MgZm9yIHlvdXIgZmVlZGJhY2suDQo+DQo+IEFtIDA3LjA1LjIwMTUgdW0gMTI6MDAgc2No cmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KPiA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb20+Og0KPg0KPiBUaGVyZSBpcyBhIHN0eWxlIHF1ZXN0aW9uIHRoYXQgYWxsIGV4aXN0 aW5nIFRMVnMgaGF2ZSBuYW1lcyBsaWtlIA0KPiBMSU5LX1NUQVRVUywgd2hpbGUgaGVyZSBUTFZz IGhhdmUgbmFtZXMgbGlrZSBPcmlnU2VxTnVtLiBJIGRvbuKAmXQgdGhpbmsgDQo+IElBTkEgZW5m b3JjZSBzdWNoIGlzc3VlcywgYW5kIGRpZmZlcmVudCBwZW9wbGUgd2lsbCBoYXZlIGRpZmZlcmVu dCANCj4gb3BpbmlvbnMgb24gdGhlIGltcG9ydGFuY2Ugb2YgY29uc2lzdGVudCBzdHlsZS4gKE5h bWluZyBjYW4gbWF0dGVyLCANCj4gd2XigJlyZSBzcGVuZGluZyBjeWNsZXMgb24gYW4gSUQganVz dCBhYm91dCBUTFYgbmFtZXMuKQ0KPg0KPg0KPg0KPiBBYnNvbHV0ZWx5LiBJbiB5b3VyIG9waW5p b24sIHdvdWxkIGl0IHN1ZmZpY2UgdG8gYWRqdXN0IHRoZSBjdXJyZW50IA0KPiBuYW1lcyBzdHls aXN0aWNhbGx5IChzZWUgYXR0YWNoZWQgZmlsZSksIG9yIGRvIHNvbWUgbmFtZXMgbmVlZCBleHRy YSANCj4gd29yayBpbiB0ZXJtcyBvZiBjbGFyaWZpY2F0aW9uIG9yIGNvbnNpc3RlbmN5PyAoSSB3 YXMganVzdCB3b25kZXJpbmcgDQo+IGlmIE1FVFJJQyBzaG91bGQgYmUgZWRpdGVkIHRvIG1ha2Ug Y2xlYXIgdGhhdCBpdCBpcyBub3QgZGlyZWN0bHkgDQo+IHJlbGF0ZWQgdG8gTElOS19NRVRSSUMu Li4pDQoNCk1heWJlIHRoZSBuYW1lICJQQVRIX01FVFJJQyIgd291bGQgbWFrZSBzZW5zZSBmb3Ig dGhlIG5ldyBUTFYuLi4gdGhpcyBkZXNjcmliZXMgdGhlIHVzYWdlIG9mIHRoZSBUTFYgdmVyeSB3 ZWxsLg0KDQpIZW5uaW5nIFJvZ2dlDQoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKgpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQKcmVjaXBpZW50IGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQKcmVjaXBp ZW50IHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90aWZ5IHRoZSBzZW5k ZXIuCllvdSBzaG91bGQgbm90IGNvcHkgaXQgb3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3Ig ZGlzY2xvc2Ugb3IKZGlzdHJpYnV0ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi4K KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioK From nobody Wed May 13 09:21:01 2015 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 B6F9D1B2E75 for ; Wed, 13 May 2015 09:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 b9Fx1qonywNQ for ; Wed, 13 May 2015 09:20:58 -0700 (PDT) Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id ED5D01B2E4E for ; Wed, 13 May 2015 09:20:57 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t4DGKsQW029956; Wed, 13 May 2015 12:20:54 -0400 From: "Wiggins, David - 0665 - MITLL" To: Stan Ratliff Thread-Topic: [manet] DLEP-13 question Thread-Index: AdCNhaNYRf7ou+lpRBSJUeKBBIzxHQAIsumAAABTJoD//94ZgA== Date: Wed, 13 May 2015 16:20:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.25.59.174] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3514364453_6131840" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-05-13_05:2015-05-13,2015-05-13,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1505130118 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-13 question 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, 13 May 2015 16:20:59 -0000 --B_3514364453_6131840 Content-type: multipart/alternative; boundary="B_3514364453_6113070" --B_3514364453_6113070 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit You might also want to specify the invalid values for Prefix Length, as is now done for Add/Drop, Resources, and RLQ. Thanks for hanging in there! David From: Stan Ratliff Date: Wednesday, May 13, 2015 at 10:22 AM To: Henning Rogge Cc: "manet@ietf.org" Subject: Re: [manet] DLEP-13 question SIGH..... I guess there will be yet another "DLEP du jour" tonight... ;-) Regards, Stan --B_3514364453_6113070 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
You might also want to specif= y the invalid values for Prefix Length, as is now done for Add/Drop, Resourc= es, and RLQ.

Thanks for hanging in there!

David

From: = Stan Ratliff <ratliffstan@= gmail.com>
Date: Wednesday,= May 13, 2015 at 10:22 AM
To: Henn= ing Rogge <hrogge@gmail.com>
= Cc: "= manet@ietf.org" <manet@ietf.org&g= t;
Subject: Re: [manet] DLEP-13 qu= estion

SIGH..... 

I guess there will be yet another "DLEP du jour" tonigh= t... ;-)

Regards,
Stan

--B_3514364453_6113070-- --B_3514364453_6131840 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIMEgYJKoZIhvcNAQcCoIIMAzCCC/8CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CfUwggT1MIID3aADAgECAgpar+vgAAAAADYOMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTMwHhcNMTUwNDA2MTE1OTM4WhcNMTYwNDA1MTE1OTM4WjBiMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSEwHwYDVQQDExhXaWdnaW5zLkRhdmlkLlAuNTAwMTUyMDcwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDdVA0BrVjbk6NP8JFi7Lks3SHtN8CxSBqFLPNRVWGjTgLG W9pDcqqOrij0IHmGpAP404gR4dP9mUEb9KfOhKuDdFQFyZnVICDSRbyT4tGOxiTH7MIsV49d UwrWhj2P/ms6wf1E5L2QwJqjOTMPZj3IClWAkcZsAix5jHkLvNXI5OilCe2u2TDihM1x2kfB zgQpRy9tuXpxYtFZpoEb0XbqLIzS9FLkTbqlocSm4jwhPXTFQtFwbd6l4zzD4RVPgnpFxg/8 KpuV35lGkp5lbPvpkskz4+n3P9LoCvpoh1pgj3fS0CvCVRzWRAX+oNR/D7RmP1ug+7Ix+JCg iAB3vLdFAgMBAAGjggG8MIIBuDAdBgNVHQ4EFgQUofYOKn4e6iCZO59iu2f0FxOad4MwDgYD VR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUH AQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMw JwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcE MDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNV HSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMCMGA1UdEQQcMBqBGERhdmlkLldpZ2dpbnNAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIE Gh4YAEwATABVAHMAZQByAFMAaQBnAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQCgEybvvRIJ tAlKEfYZyf5DIlcT+LfePOiebFcPxZatSTQW/hJHv4RX/TN8N3bQrx4Jkxe17eQfsKvJXhOi R6as3vemCxYEMOFIKSsm5LEIC4D4GcXBRZ1CAJIHCY5ezXfKQUxBSdZAq82/fAoNEEP4KPEv Y07m7OVwXMWpu7kz3CeBVOqL7xlL53pPvkyxtijQRtZrZ5coE9Qh9tHzATi7DW8UWoUv3Yhj Qz9SnBn3T30ho0GtlTvMXso7UjGZFWLQI2JyR2QW5FYq8GGEq/5PRz/xslsKA5EoHxmSSeRh eei3gpFbnUrRS+5JSS6kgA/HVoM7CRFo/O8KYXU5z/ihMIIE+DCCA+CgAwIBAgIKWrCpkwAA AAA2DzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE1 MDQwNjEyMDAyNloXDTE2MDQwNTEyMDAyNlowYjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEhMB8GA1UEAxMYV2lnZ2lu cy5EYXZpZC5QLjUwMDE1MjA3MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAlEWD uIm5kuHghfe7O+eMLVena6sNfAZtHLp2mwXLrNshaHM6wVKmml8zhxeSmJJXTF3Owyn7imKs vHMWcIJD9EoFQyJoeBaFV5Ll75/fE2WKswtGn9ZSSejplI/Iy99SI/9Lna5B7/BDmPozGn66 jdzgl+JVFptqEUGx5NZlRUEEtVtXYUy+PllIq6SpR/242wFiYVslFqSoHu789mexaDDAl7p7 z3W9cYidPtZUoysjW0omzwZIoYMsIhTbUMnv+TkBuhJErBmaNvAXPf8Y3pNf3pYz8pnR4MyI ibFv2CS/2KLGxJRE9xt1nrgHT8Wx+E6Ro6IYkYLPSdE6YgYAgwIDAQABo4IBvzCCAbswHQYD VR0OBBYEFGww5LYEZSoVOkuJ7ZVJS+35ChrUMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0 cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2Nz cC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aG rYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQG CisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAjBgNVHREEHDAagRhEYXZp ZC5XaWdnaW5zQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABMAEwAVQBzAGUAcgBFAG4A YwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEATCsJT66TKeYNh9hrcC1wxRH08CricKt9JktB I1WWl48F4CqcYDZlLMpvHuSe6GezZzTUH4oq1y2q3um9Txh1NjLPT7j0k5SSwdr2V7d8upDN WOrXvCi59Cyz5RvuhleCPIE+6wPyDrQwfBRhte/cv8PVOrsG4tio4VOHi/nXcS+HLgC5qNxk 1/w1UBf8QkkNP8kIgum/uItm4QwVdVAJMuwe3te8dYjtp3M5nC2exfqQfk+Mmw/8fdZFpch0 rSYbpchMMOueBuy2UnWaYBF84uXldBH9fkONRX8AL8EQ3sQEOyzxqpwKQ/d0itjAGaPCCJCI VgnSYSWYoFiN9idyaTGCAeUwggHhAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0Et MwIKWq/r4AAAAAA2DjAJBgUrDgMCGgUAoF0wIwYJKoZIhvcNAQkEMRYEFGqxKDTLfSdUW/wq wTHRX16xh3IyMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1 MDUxMzE2MjA1M1owDQYJKoZIhvcNAQEBBQAEggEAIHjnXzj+Aue9DacNlW4nWVbCE0DnkAGW 9EHnj+i4bwbBNJeQm14w8rdIvjhfpqGjRB8WZcwc0Ef5lrOt7xQuwylv5XhiGBSidA6m592P BfuEJoHr3fCq0pZSSuK9YYuqOn+cb+AKSVQX8yOXNaMYByy8N2yLL8fBNip77p+6CVw1slJ0 8VmNzSQJfu3XyX/kKdWxRhWIklVHvJDYnA3KC686CucE5Hu4WtuCUJbv+mvGHboY4J4wquzV QZ6AnsF7iZwqIMSVCPDqC3WHWDEe4ulxhOEE/TvqjvUQZrRzq7ddKC/FxEkVeSTRg8tgS5ZK CLP/f48s4c4+2HvY2uNbjw== --B_3514364453_6131840-- From nobody Wed May 13 09:33:52 2015 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 9DC391B2D10; Wed, 13 May 2015 09:33: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] 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 PSLY2zgBJOsr; Wed, 13 May 2015 09:33:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E401B2EBF; Wed, 13 May 2015 09:33:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513163339.17555.40930.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 09:33:39 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-tlv-naming-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:33:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : TLV Naming in the MANET Generalized Packet/Message Format Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-tlv-naming-03.txt Pages : 15 Date : 2015-05-13 Abstract: This document reorganizes the naming of already allocated TLV (type- length-value) types and type extensions in the Mobile Ad hoc NETwork (MANET) registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-tlv-naming-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-tlv-naming-03 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 10:03:16 2015 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 067CD1B3091; Wed, 13 May 2015 10:03:15 -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] 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 ZbAdm-r0Bx3V; Wed, 13 May 2015 10:03:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9B1B3097; Wed, 13 May 2015 10:03:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150513170309.6350.40335.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 10:03:09 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-09.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:03:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Ad Hoc On-demand Distance Vector (AODVv2) Routing Authors : Charles E. Perkins Stan Ratliff John Dowdell Lotte Steenbrink Victoria Mercieca Filename : draft-ietf-manet-aodvv2-09.txt Pages : 96 Date : 2015-05-13 Abstract: The revised Ad Hoc On-demand Distance Vector (AODVv2) routing protocol is intended for use by mobile routers in wireless, multihop networks. AODVv2 determines unicast routes among AODVv2 routers within the network in an on-demand fashion, offering rapid convergence in dynamic topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-aodvv2-09 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 13 10:14:04 2015 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 53A6A1B30A1 for ; Wed, 13 May 2015 10:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KWyJ3ml9ULZH for ; Wed, 13 May 2015 10:14:01 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D24761B3068 for ; Wed, 13 May 2015 10:14:00 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) with esmtp (envelope-from ) id <1YsaEJ-002nYC-KX>; Wed, 13 May 2015 19:13:59 +0200 Received: from ws57.eduroam.haw-hamburg.de ([141.22.56.57]) by inpost2.zedat.fu-berlin.de (Exim 4.85) with esmtpsa (envelope-from ) id <1YsaEJ-000m1h-J5>; Wed, 13 May 2015 19:13:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Lotte Steenbrink In-Reply-To: Date: Wed, 13 May 2015 19:13:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> To: manet@ietf.org X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: 141.22.56.57 Archived-At: Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [manet] RFC 5444 translation tables 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, 13 May 2015 17:14:02 -0000 Hi all, FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses = all comments made in this thread. Any feedback is very welcome! Regards, Lotte Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) = : > I don't have time to look at this today, but Henning's suggestion = looks good. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > = __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great = Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 >=20 >=20 > -----Original Message----- > From: Henning Rogge [mailto:hrogge@gmail.com]=20 > Sent: 13 May 2015 15:11 > To: Lotte Steenbrink > Cc: Dearlove, Christopher (UK); manet@ietf.org > Subject: Re: [manet] RFC 5444 translation tables >=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 > On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink = wrote: >> Hi Christopher, >> thanks for your feedback. >>=20 >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) >> : >>=20 >> There is a style question that all existing TLVs have names like=20 >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=92t = think=20 >> IANA enforce such issues, and different people will have different=20 >> opinions on the importance of consistent style. (Naming can matter,=20= >> we=92re spending cycles on an ID just about TLV names.) >>=20 >>=20 >>=20 >> Absolutely. In your opinion, would it suffice to adjust the current=20= >> names stylistically (see attached file), or do some names need extra=20= >> work in terms of clarification or consistency? (I was just wondering=20= >> if METRIC should be edited to make clear that it is not directly=20 >> related to LINK_METRIC...) >=20 > Maybe the name "PATH_METRIC" would make sense for the new TLV... this = describes the usage of the TLV very well. >=20 > Henning Rogge > ******************************************************************** > 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 Wed May 13 10:28:57 2015 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 2F1851B30F5 for ; Wed, 13 May 2015 10:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 G13PXEU6Kl5N for ; Wed, 13 May 2015 10:28:54 -0700 (PDT) Received: from ironport.idirect.net (ironport2.idirect.net [198.180.159.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3D07D1A903F for ; Wed, 13 May 2015 10:28:19 -0700 (PDT) Received-SPF: None (ironport.idirect.net: no sender authenticity information available from domain of sratliff@idirect.net) identity=pra; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@idirect.net"; x-conformance=sidf_compatible Received-SPF: Fail (ironport.idirect.net: domain of sratliff@idirect.net does not designate 10.250.250.203 as permitted sender) identity=mailfrom; client-ip=10.250.250.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="sratliff@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.203; receiver=ironport.idirect.net; envelope-from="sratliff@idirect.net"; x-sender="postmaster@webmail.idirect.net"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.13,421,1427774400"; d="scan'208";a="17405684" Received: from unknown (HELO webmail.idirect.net) ([10.250.250.203]) by ironport.idirect.net with ESMTP; 13 May 2015 13:28:18 -0400 Received: from VAUSDITCHM2.idirect.net (10.250.250.202) by VAUSDITCHM3.idirect.net (10.250.250.203) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 13 May 2015 13:28:17 -0400 Received: from VAUSDITCHM2.idirect.net ([fe80::c422:556:6ad1:e682]) by VAUSDITCHM2.idirect.net ([fe80::b5b6:9e50:3403:e75d%15]) with mapi id 15.00.0995.028; Wed, 13 May 2015 13:28:16 -0400 From: "Ratliff, Stanley" To: "manet@ietf.org" Thread-Topic: [manet] I-D Action: draft-ietf-manet-aodvv2-09.txt Thread-Index: AQHQjZ65alh9g0+BK02WRvA/cbLrOZ16KCDw Date: Wed, 13 May 2015 17:28:16 +0000 Message-ID: References: <20150513170309.6350.40335.idtracker@ietfa.amsl.com> In-Reply-To: <20150513170309.6350.40335.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: Subject: Re: [manet] I-D Action: draft-ietf-manet-aodvv2-09.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: Wed, 13 May 2015 17:28:56 -0000 Hello working group participants,=20 Please, please, please attempt to carve some time out of your busy schedule= s and review & comment on AODVv2. There has been a tremendous effort to imp= rove the draft per the agreement in Dallas, and the editorial team is count= ing on your reviews to keep us on schedule. Some of you promised during the= interim meeting... I have a recording. ;-)=20 Regards, Stan > -----Original Message----- > From: manet [mailto:manet-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Wednesday, May 13, 2015 1:03 PM > To: i-d-announce@ietf.org > Cc: manet@ietf.org > Subject: [manet] I-D Action: draft-ietf-manet-aodvv2-09.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. >=20 > Title : Ad Hoc On-demand Distance Vector (AODVv2) Routi= ng > Authors : Charles E. Perkins > Stan Ratliff > John Dowdell > Lotte Steenbrink > Victoria Mercieca > Filename : draft-ietf-manet-aodvv2-09.txt > Pages : 96 > Date : 2015-05-13 >=20 > Abstract: > The revised Ad Hoc On-demand Distance Vector (AODVv2) routing > protocol is intended for use by mobile routers in wireless, multihop > networks. AODVv2 determines unicast routes among AODVv2 routers > within the network in an on-demand fashion, offering rapid > convergence in dynamic topologies. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-aodvv2/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-aodvv2-09 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-aodvv2-09 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet From nobody Wed May 13 17:52:57 2015 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 8074E1B324B for ; Wed, 13 May 2015 17:52:56 -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 zBC0qAUpV49s for ; Wed, 13 May 2015 17:52:55 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EA41B324A for ; Wed, 13 May 2015 17:52:54 -0700 (PDT) Received: by labbd9 with SMTP id bd9so46328126lab.2 for ; Wed, 13 May 2015 17:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GxcWeVTqjyxJQb+ns4r4sXz/ranUHYEn9fCc1/hAbc0=; b=UUSegwbzm3WFdgpM6UUaCiuU4Vpum/ex65wMCsoIhG1tmyng12R6HfFlfaxYnH+W5w 2/8rOE2jmMF4rIJVrHtB1ykElvzQm2bq4La3E7ucCcEbw3e87b307xmcszFCswikZr5/ ICP8vTJ/uVyjQeirMRD9ZXX+SE3XS55v3e4UmJO0dX7MGEgfkg1gKJ1jukfG95ZueX/f 8Krl8zmV0MaDKVar/uvjL1nRgkEvq6FyydzJNB5/JaRiT5gLXakGfyY7ApFnwMSEsrLL n9ccTBWgoEUKVWc2po79VVvx+16f4UmTA2tttmLpFvvtdBr6qE27udjRf8HORFlQSBZr hhug== MIME-Version: 1.0 X-Received: by 10.112.161.197 with SMTP id xu5mr1072314lbb.69.1431564773384; Wed, 13 May 2015 17:52:53 -0700 (PDT) Received: by 10.25.155.145 with HTTP; Wed, 13 May 2015 17:52:53 -0700 (PDT) Date: Wed, 13 May 2015 20:52:53 -0400 Message-ID: From: Stan Ratliff To: MANET IETF Content-Type: multipart/alternative; boundary=001a11c3bfe6ca67330516002560 Archived-At: Subject: [manet] DLEP-14 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, 14 May 2015 00:52:56 -0000 --001a11c3bfe6ca67330516002560 Content-Type: text/plain; charset=UTF-8 All, DLEP-14 has been posted, resolving review issues with RLQR/RLQT, and the ranges for attached subnets. At this point, having passed WGLC, and with the level of issues being discovered (no major technical points; relatively minor textual things), we formally request that a document shepherd be assigned, and that the request for document publication be sent to the IESG. Stan --001a11c3bfe6ca67330516002560 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
All,=C2=A0

DLEP-14 has been posted, res= olving review issues with RLQR/RLQT, and the ranges for attached subnets.= =C2=A0

At this point, having passed WGLC, and with= the level of issues being discovered (no major technical points; relativel= y minor textual things), we formally request that a document shepherd be as= signed, and that the request for document publication be sent to the IESG.= =C2=A0

Stan
--001a11c3bfe6ca67330516002560-- From nobody Wed May 13 18:39:54 2015 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 96A471B2DA2; Wed, 13 May 2015 18:39: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] 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 iBv2S_iVVeeO; Wed, 13 May 2015 18:39:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAB51B3040; Wed, 13 May 2015 18:39:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514013946.10894.70895.idtracker@ietfa.amsl.com> Date: Wed, 13 May 2015 18:39:46 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-dlep-14.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 01:39:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic Link Exchange Protocol (DLEP) Authors : Stan Ratliff Bo Berry Cisco Systems Darryl Satterwhite Rick Taylor Filename : draft-ietf-manet-dlep-14.txt Pages : 66 Date : 2015-05-13 Abstract: When routing devices rely on modems to effect communications over wireless links, they need timely and accurate knowledge of the characteristics of the link (speed, state, etc.) in order to make routing decisions. In mobile or other environments where these characteristics change frequently, manual configurations or the inference of state through routing or transport protocols does not allow the router to make the best decisions. A bidirectional, event- driven communication channel between the router and the modem is necessary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-dlep-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-14 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 14 01:57:34 2015 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 96F5D1B3556; Thu, 14 May 2015 01:57:32 -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] 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 H1ltdtJdsh9f; Thu, 14 May 2015 01:57:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC011B355C; Thu, 14 May 2015 01:57:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150514085727.17639.18004.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 01:57:27 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-tlv-naming-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 08:57:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : TLV Naming in the MANET Generalized Packet/Message Format Authors : Christopher Dearlove Thomas Heide Clausen Filename : draft-ietf-manet-tlv-naming-04.txt Pages : 15 Date : 2015-05-14 Abstract: This document reorganizes the naming of already allocated TLV (type- length-value) types and type extensions in the Mobile Ad hoc NETwork (MANET) registries defined by RFC 5444 to use names appropriately. It has no consequences in terms of any protocol implementation. This document also updates the Expert Review guidelines from RFC 5444, so as to establish a policy for consistent naming of future TLV type and type extension allocations. It makes no other changes to RFC 5444. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-tlv-naming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-tlv-naming-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-tlv-naming-04 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 14 07:22:28 2015 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 96C791B2AE2 for ; Thu, 14 May 2015 07:22:26 -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 lL40UN7tuDVj for ; Thu, 14 May 2015 07:22:25 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B0F81B2AD6 for ; Thu, 14 May 2015 07:22:25 -0700 (PDT) Received: by wguv19 with SMTP id v19so15177908wgu.1 for ; Thu, 14 May 2015 07:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ZvT5mAKdENkBMrJSijRmP7DithytIv0+nO8FBpRAj0M=; b=sKsDYSsn2jNe/BPHccKLxPxj13lA/KXofekVTWn4KAIxTLvTvlXQvgn5MQ8FGfd5Gq iSWHQHd9qj86Kz+U758vBww/rW2xVDJPk8l8U8KQWPkT7m013GNQNvPWvn/2+cFcDa6U eZ19ykHdKfOAd35rIpcetHxXV7uNo9eMNjmUXzMIao6Rlkgnw8tbLZ+T7s3e7HThLifE ZIkRXkEsyTH1eij/Q4R6rPsOiFwj8NgoDA9GrJKA3ALcHdLQrZq9pb157GOtXc8x1seN nthopEYq4yigEjgoyZeEO451srlYoOQHy3TDi2U2XYRSaSJJEKEePFGKYzld8IyIMFNx Fr0g== X-Received: by 10.181.13.44 with SMTP id ev12mr24225640wid.17.1431613343824; Thu, 14 May 2015 07:22:23 -0700 (PDT) Received: from [10.0.4.178] ([217.158.48.187]) by mx.google.com with ESMTPSA id o6sm13548679wiz.24.2015.05.14.07.22.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 07:22:23 -0700 (PDT) Message-ID: <5554AF9E.6090705@gmail.com> Date: Thu, 14 May 2015 15:22:22 +0100 From: John Dowdell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030800030403080808050505" Archived-At: Subject: Re: [manet] DLEP-14 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, 14 May 2015 14:22:26 -0000 This is a multi-part message in MIME format. --------------030800030403080808050505 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 Good work guys. John On 14/05/15 01:52, Stan Ratliff wrote: > All, > > DLEP-14 has been posted, resolving review issues with RLQR/RLQT, and > the ranges for attached subnets. > > At this point, having passed WGLC, and with the level of issues being > discovered (no major technical points; relatively minor textual > things), we formally request that a document shepherd be assigned, and > that the request for document publication be sent to the IESG. > > Stan > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet --------------030800030403080808050505 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit +1

Good work guys.

John

On 14/05/15 01:52, Stan Ratliff wrote:
All,

DLEP-14 has been posted, resolving review issues with RLQR/RLQT, and the ranges for attached subnets.

At this point, having passed WGLC, and with the level of issues being discovered (no major technical points; relatively minor textual things), we formally request that a document shepherd be assigned, and that the request for document publication be sent to the IESG.

Stan


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

--------------030800030403080808050505-- From nobody Thu May 14 07:25:06 2015 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 612FA1B2B27 for ; Thu, 14 May 2015 07:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qZ8gyEhp0oOv for ; Thu, 14 May 2015 07:25:02 -0700 (PDT) Received: from mail.tropicalstormsoftware.com (mail.tropicalstormsoftware.com [188.94.42.120]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C5EE1B2AF2 for ; Thu, 14 May 2015 07:24:58 -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; Thu, 14 May 2015 15:24:15 +0100 From: Rick Taylor To: John Dowdell , "manet@ietf.org" Thread-Topic: [manet] DLEP-14 Thread-Index: AQHQjeBPd4V4vC7lFEWmI/1VDMLpSg== Date: Thu, 14 May 2015 14:24:14 +0000 Message-ID: <38A5475DE83986499AEACD2CFAFC3F9801675AE13E@tss-server1.home.tropicalstormsoftware.com> References: <5554AF9E.6090705@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DLEP-14 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, 14 May 2015 14:25:04 -0000 I'm a fairly obvious +1=0A= =0A= Rick=0A= =0A= On 14/05/15 15:22, John Dowdell wrote:=0A= > +1=0A= >=0A= > Good work guys.=0A= >=0A= > John=0A= >=0A= > On 14/05/15 01:52, Stan Ratliff wrote:=0A= >> All,=0A= >>=0A= >> DLEP-14 has been posted, resolving review issues with RLQR/RLQT, and=0A= >> the ranges for attached subnets.=0A= >>=0A= >> At this point, having passed WGLC, and with the level of issues being=0A= >> discovered (no major technical points; relatively minor textual=0A= >> things), we formally request that a document shepherd be assigned, and= =0A= >> that the request for document publication be sent to the IESG.=0A= >>=0A= >> Stan=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> manet mailing list=0A= >> manet@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/manet=0A= >=0A= =0A= From nobody Thu May 14 10:20:57 2015 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 7027F1B2A0F for ; Thu, 14 May 2015 10:20:55 -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 o6vl3jU2IB03 for ; Thu, 14 May 2015 10:20:53 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033171ACE19 for ; Thu, 14 May 2015 10:20:27 -0700 (PDT) Received: by obbkp3 with SMTP id kp3so57855680obb.3 for ; Thu, 14 May 2015 10:20:26 -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=Wh/YZ1ULLRB9yJ4ijZjQhN4970Kegv1gADYMO8adaGk=; b=Ctso/NM0BUHBmW3x0N5ISK6iPsR9Nx/28l+CBWZCSxDMf3yIsrN8E4bnOjkjSzb/fx WF8ym51hZnnDXfi6KUKlFFe/Is/bp8n71fqCkyJ0vkaO7FiisPD6LCUcC01Bpxv+NURO DT7P+7s3cCS74Llk/xfrnN8ZTDGSH592aIuS5wf2Ob23iCR+C2rg8SrEwZaadohIV8nS YzH9RLJieg5cvi2C2KCpoXYMt1Xwae2OtjAJw89ASFRCG7RL2he6MM2kx0NpKxy/T+Fl KVv1rANxfc1/zPUr9MZKgv/2L+sKREn/Fz7mvoGe1NCx8h053hAFx2kV/qpVV9MY7bUh oYSg== MIME-Version: 1.0 X-Received: by 10.202.183.6 with SMTP id h6mr3686051oif.87.1431624026479; Thu, 14 May 2015 10:20:26 -0700 (PDT) Received: by 10.202.75.214 with HTTP; Thu, 14 May 2015 10:20:26 -0700 (PDT) In-Reply-To: References: <20150422064506.15307.76274.idtracker@ietfa.amsl.com> Date: Thu, 14 May 2015 13:20:26 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=001a113cd1ec8ce1b005160df14d Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-dat-metric-05.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: Thu, 14 May 2015 17:20:55 -0000 --001a113cd1ec8ce1b005160df14d Content-Type: text/plain; charset=UTF-8 +1 from me on moving this forward. Unless someone speaks up soon on why this shouldn't be last called I'm going to start the process. Justin On Fri, Apr 24, 2015 at 4:56 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Henning, > > Thanks for the update, I think also that it can go for last call, I will > try to review in the coming days, but short comments below. > > 1-I think the draft calls this metric as DAT metric, as you mention in the > draft in other sections, so we can mention this in the title or in Abstract > or in introduction. > > 2-suggest to add to the Abstract: > > The DAT metric document describes a new routing metric for > OLSRv2. It takes both the loss rate and the link speed into > account to provide additional information of the links within the MANET. > > 3- The applicability statement is excellent, however, my only comment is > that it mentions the word 'metric' (meaning this specification metric) but > could we clarify it in this section as DAT metric, or just say the metric > specification. > > Best Regards, > > AB > > On Wed, Apr 22, 2015 at 8:48 AM, Henning Rogge wrote: > >> On Wed, Apr 22, 2015 at 8:45 AM, wrote: >> > >> > A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> > This draft is a work item of the Mobile Ad-hoc Networks Working Group >> of the IETF. >> > >> > Title : Packet Sequence Number based directional >> airtime metric for OLSRv2 >> > Authors : Henning Rogge >> > Emmanuel Baccelli >> > Filename : draft-ietf-manet-olsrv2-dat-metric-05.txt >> > Pages : 17 >> > Date : 2015-04-21 >> >> Hi, >> >> I posted a last revision of the DAT metric draft based on a review I >> got from Fabian Nack. >> >> The change is small, I renamed two variables to make their usage more >> clear and fixed a mixup between two variable names in the metric >> update. >> >> I think DAT should be ready for last call... >> >> Henning Rogge >> >> _______________________________________________ >> 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 > > --001a113cd1ec8ce1b005160df14d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 from me on moving this forward.

Unless some= one speaks up soon on why this shouldn't be last called I'm going t= o start the process.

Justin


On Fri, Apr 24, 2015 at 4:56= AM, Abdussalam Baryun <abdussalambaryun@gmail.com>= wrote:
Hi = Henning,

Thanks for = the update, I think also that it can go for last call, I will try to review= in the coming days, but short comments below.
1-I think the draft=C2=A0calls this metric as DA= T metric, as you mention in the draft in other sections, so we can mention = this in the title or in Abstract or in introduction.

2-suggest to add to the Abstract:

The DAT metric=C2=A0document= describes a=C2=A0new routing metric for
OLSRv2. I= t takes both the loss rate and the link speed into
account to provide additional information=C2=A0of the links within the MAN= ET.

3- The applicabi= lity statement is excellent, however, my only comment is that it mentions t= he word 'metric' (meaning this specification metric) but could we c= larify it in this section as DAT metric, or just say the metric specificati= on.

Best Regards,

AB
=
On Wed, Apr 22, 2015 at 8:48 AM, Henning Rogge= <hrogge@gmail.com> wrote:
= On Wed, Apr 22, 2015 at 8:45 AM,=C2=A0 <internet-drafts@ietf.org> wrote:=
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>=C2=A0 This draft is a work item of the Mobile Ad-hoc Networks Working = Group of the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Packet Sequence Number based directional airtime metric for OLS= Rv2
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Henning Rogge
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Emmanuel Baccelli
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-manet-olsrv2-dat-metric-05.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 17
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-04-21

Hi,

I posted a last revision of the DAT metric draft based on a review I
got from Fabian Nack.

The change is small, I renamed two variables to make their usage more
clear and fixed a mixup between two variable names in the metric
update.

I think DAT should be ready for last call...

Henning Rogge

_______________________________________________
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


--001a113cd1ec8ce1b005160df14d-- From nobody Fri May 15 13:38:37 2015 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 A952A1A8EA9 for ; Fri, 15 May 2015 13:38:35 -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 hnAtSyDOvrBz for ; Fri, 15 May 2015 13:38:34 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87651A899F for ; Fri, 15 May 2015 13:37:36 -0700 (PDT) Received: by obbkp3 with SMTP id kp3so86560567obb.3 for ; Fri, 15 May 2015 13:37:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=J7dj6ioRbc4FNARcnfWLQSWXk/JtC5iAb2nWdGl6ESg=; b=AQcSkFplTDSXMddGIPIpzZ1NUHyaoboGnabjB3I1wMGj0GTYDfYo5+buRNegA+CIrx hsSB6LnIOHeOGuaq5O9rrtosoDKAZTg5BtMWLeKXYMF8XsHqXczoK2go7Np/rVEDe5z5 DKbYVjgCDwThJ8Ie3+L2Bdnvt4/wez8mtFzxNENq7mZAImoe4W31GkoNCDozLvIfEixi bnAu9DPhdlGsXip80MFBaq82NKmIGycEoD14qQaD3xcd7HoN3S/4i1I9fj6jqHbLxKji FQP8b+j6HqK2H9fGb1h8B0OVVSR+2ADsZN1LW1fr8VKcPns2vrpD7V3FHWhnoYxEceU8 yTRA== MIME-Version: 1.0 X-Received: by 10.182.196.34 with SMTP id ij2mr9869894obc.71.1431722256243; Fri, 15 May 2015 13:37:36 -0700 (PDT) Received: by 10.202.75.214 with HTTP; Fri, 15 May 2015 13:37:36 -0700 (PDT) Date: Fri, 15 May 2015 16:37:36 -0400 Message-ID: From: Justin Dean To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=089e0153870c802469051624d08a Archived-At: Subject: [manet] DAT and DLEP status 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, 15 May 2015 20:38:35 -0000 --089e0153870c802469051624d08a Content-Type: text/plain; charset=UTF-8 draft-ietf-manet-olsrv2-dat-metric-05 Since no objections were raised and I think the document is ready draft-ietf-manet-olsrv2-dat-metric-05 is now in WGLC. Proposed experimental status for this draft. It provides *a* method for calculating the routing metrics to be used with OLSRv2 routing. Please review the draft. https://datatracker.ietf.org/doc/draft-ietf-manet-dlep/ The WGLC has ended for dlep. Comments to the list have resulted in rapid updating of the draft. I'll be moving this forward shortly. Stan in another message requested that we move this forward and I've only seen +1s in response. As Stan likes to say silence will be taken as acceptance. Justin Dean --089e0153870c802469051624d08a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
draft-ietf-manet-olsrv2-dat-metric-05
Since no objecti= ons were raised and I think the document is ready=C2=A0draft-ietf-manet-olsrv2-dat-metric-0= 5 is now in WGLC.=C2=A0 Proposed experimental status for this draft.=C2=A0 = It provides a method for calculating the routing metrics to be used = with OLSRv2 routing.=C2=A0 Please review the draft.

https://datatracker.iet= f.org/doc/draft-ietf-manet-dlep/
The WGLC has ended for dlep.=C2=A0 Com= ments to the list have resulted in rapid updating of the draft.=C2=A0 I'= ;ll be moving this forward shortly. Stan in another message requested that = we move this forward and I've only seen +1s in response.=C2=A0 As Stan = likes to say silence will be taken as acceptance.

Justin Dean
--089e0153870c802469051624d08a-- From nobody Fri May 15 16:07:15 2015 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 4E0DF1A8A12 for ; Fri, 15 May 2015 16:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tUvfdWGkbwEo for ; Fri, 15 May 2015 16:07:11 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3481A8A1C for ; Fri, 15 May 2015 16:07:10 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.13,437,1427752800"; d="scan'208,217"; a="42748502" Received: from exc-cashub03.tsn.tno.nl (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 16 May 2015 01:07:08 +0200 Received: from EXC-MBX01.tsn.tno.nl ([fe80::fd60:358a:bfaf:ca7c]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0195.001; Sat, 16 May 2015 01:06:01 +0200 From: "Velt, R. (Ronald) in 't" To: Justin Dean , "manet@ietf.org" Thread-Topic: [manet] DAT and DLEP status Thread-Index: AQHQj08mCtWDneV+S02s51uNnxEsLp19p96A Date: Fri, 15 May 2015 23:06:00 +0000 Message-ID: <72FB622921C13746AD6349E70A8D9F307DEEACDD@EXC-MBX01.tsn.tno.nl> References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_72FB622921C13746AD6349E70A8D9F307DEEACDDEXCMBX01tsntnon_" MIME-Version: 1.0 Archived-At: Subject: Re: [manet] DAT and DLEP status 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, 15 May 2015 23:07:14 -0000 --_000_72FB622921C13746AD6349E70A8D9F307DEEACDDEXCMBX01tsntnon_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgSnVzdGluLA0KDQpGcm9tOiBtYW5ldCBbbWFpbHRvOm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKdXN0aW4gRGVhbg0KU2VudDogdnJpamRhZyAxNSBtZWkgMjAxNSAyMjoz OA0KVG86IG1hbmV0QGlldGYub3JnDQpTdWJqZWN0OiBbbWFuZXRdIERBVCBhbmQgRExFUCBzdGF0 dXMNCg0KZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItZGF0LW1ldHJpYy0wNQ0KU2luY2Ugbm8gb2Jq ZWN0aW9ucyB3ZXJlIHJhaXNlZCBhbmQgSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZHJh ZnQtaWV0Zi1tYW5ldC1vbHNydjItZGF0LW1ldHJpYy0wNSBpcyBub3cgaW4gV0dMQy4gIFByb3Bv c2VkIGV4cGVyaW1lbnRhbCBzdGF0dXMgZm9yIHRoaXMgZHJhZnQuICBJdCBwcm92aWRlcyBhIG1l dGhvZCBmb3IgY2FsY3VsYXRpbmcgdGhlIHJvdXRpbmcgbWV0cmljcyB0byBiZSB1c2VkIHdpdGgg T0xTUnYyIHJvdXRpbmcuICBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdC4NCg0KV2hlbiB3aWxsIFdH TEMgZm9yIHRoaXMgZHJhZnQgZW5kPw0KDQo8c25pcD4NCg0KVGhhbmtzLA0KUm9uYWxkDQoNCg0K SnVzdGluIERlYW4NClRoaXMgbWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlz IG5vdCBpbnRlbmRlZCBmb3IgeW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlm IHRoaXMgbWVzc2FnZSB3YXMgc2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0 ZWQgdG8gaW5mb3JtIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2Vw dHMgbm8gbGlhYmlsaXR5IGZvciB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBt YW5uZXIgaW4gd2hpY2ggeW91IHVzZSBpdCBhbmQgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1 bHRpbmcgZnJvbSB0aGUgcmlza3MgaW5oZXJlbnQgdG8gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNz aW9uIG9mIG1lc3NhZ2VzLgo= --_000_72FB622921C13746AD6349E70A8D9F307DEEACDDEXCMBX01tsntnon_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJOTCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEp1c3Rpbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4gbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5KdXN0aW4gRGVhbjxicj4NCjxiPlNlbnQ6PC9iPiB2cmlqZGFnIDE1IG1l aSAyMDE1IDIyOjM4PGJyPg0KPGI+VG86PC9iPiBtYW5ldEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbbWFuZXRdIERBVCBhbmQgRExFUCBzdGF0dXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5kcmFmdC1pZXRmLW1hbmV0LW9sc3J2Mi1kYXQtbWV0cmljLTA1PC9zcGFuPjxicj4NClNpbmNl IG5vIG9iamVjdGlvbnMgd2VyZSByYWlzZWQgYW5kIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIHJl YWR5Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPmRyYWZ0LWlldGYtbWFuZXQt b2xzcnYyLWRhdC1tZXRyaWMtMDUgaXMgbm93IGluIFdHTEMuJm5ic3A7IFByb3Bvc2VkIGV4cGVy aW1lbnRhbCBzdGF0dXMgZm9yIHRoaXMgZHJhZnQuJm5ic3A7IEl0IHByb3ZpZGVzDQo8aT5hPC9p PiBtZXRob2QgZm9yIGNhbGN1bGF0aW5nIHRoZSByb3V0aW5nIG1ldHJpY3MgdG8gYmUgdXNlZCB3 aXRoIE9MU1J2MiByb3V0aW5nLiZuYnNwOyBQbGVhc2UgcmV2aWV3IHRoZSBkcmFmdC48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZW4g d2lsbCBXR0xDIGZvciB0aGlzIGRyYWZ0IGVuZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jmx0O3NuaXAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmFs ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5KdXN0aW4gRGVhbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBzdHlsZT0iTUFSR0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5zLXNlcmlmJzsgRk9O VC1TSVpFOiA4cHQ7IG1zby1iaWRpLWZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJzsgbXNv LWJpZGktZm9udC1zaXplOiAxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48Zm9u dCBzdHlsZT0iRk9OVC1TSVpFOiAxMXB4IiBzaXplPSIzIj4NCjwvZm9udD48cCBzdHlsZT0iTUFS R0lOOiAwY20gMGNtIDBwdCIgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc3R5bGU9IkZPTlQtU0la RTogMTFweCIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQXJpYWwnLCdzYW5z LXNlcmlmJzsgRk9OVC1TSVpFOiA4cHQ7IG1zby1iaWRpLWZvbnQtc2l6ZTogOC41cHQiPlRoaXMg bWVzc2FnZSBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCBpbnRlbmRlZCBmb3Ig eW91LiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9yIGlmIHRoaXMgbWVzc2FnZSB3YXMg c2VudCB0byB5b3UgYnkgbWlzdGFrZSwgeW91IGFyZSByZXF1ZXN0ZWQgdG8gaW5mb3JtIHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGUgbWVzc2FnZS4gVE5PIGFjY2VwdHMgbm8gbGlhYmlsaXR5IGZv ciB0aGUgY29udGVudCBvZiB0aGlzIGUtbWFpbCwgZm9yIHRoZSBtYW5uZXIgaW4gd2hpY2ggeW91 IHVzZSBpdCBhbmQgZm9yIGRhbWFnZSBvZiBhbnkga2luZCByZXN1bHRpbmcgZnJvbSB0aGUgcmlz a3MgaW5oZXJlbnQgdG8gdGhlIGVsZWN0cm9uaWMgdHJhbnNtaXNzaW9uIG9mIG1lc3NhZ2VzLjxi cj48YnI+PC9zcGFuPjwvZm9udD48L3A+PC9ib2R5Pg0KPC9odG1sPg0K --_000_72FB622921C13746AD6349E70A8D9F307DEEACDDEXCMBX01tsntnon_-- From nobody Wed May 20 23:17:27 2015 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 B57701A0378 for ; Wed, 20 May 2015 23:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 HpCVYVMPRHoH for ; Wed, 20 May 2015 23:17:24 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4901A0371 for ; Wed, 20 May 2015 23:17:23 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so10546988lbb.2 for ; Wed, 20 May 2015 23:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fJK29SSnsYZzT2H6RQlztOt/U8JAou4Cs2t7BwzSEcs=; b=JLmXzA/+Lq1ylXBw2KA5HK4X6rDXNl0kz1oYzL0hfwEwhVznfLE7kHBUZCnEj67jXF 4GZJVesIGiRup9plN2tnnWGNk/V/jHHxSb3FAEHtZMMD1g9D3pCKAujEBVimniRgy9du 1NciGnb57tptA0lWhsoPUy90zAJVeYI3Uqs7o1/pBw7rdbYxNVyQ2NYDNmBfD+/TG1J+ 61Fj2ikRjOWLNMVF50ris2jeqPebi5xrcoC7plRFDhqe7PcEpxscc7cKRn9yK58yTCP4 OWakQ7Jmhm0qzopzd7mjiljbgSi2eA8hKvOfQaBOJmy+YTLvYWZLrivyZdx+60l5/EVi wXOA== MIME-Version: 1.0 X-Received: by 10.112.118.49 with SMTP id kj17mr879289lbb.62.1432189042128; Wed, 20 May 2015 23:17:22 -0700 (PDT) Received: by 10.112.18.73 with HTTP; Wed, 20 May 2015 23:17:21 -0700 (PDT) Date: Thu, 21 May 2015 11:47:21 +0530 Message-ID: From: Debarshi Sanyal To: "manet@ietf.org" Content-Type: multipart/alternative; boundary=047d7beb90861b7d5f0516917fca Archived-At: Subject: [manet] Advanced signal processing within SIFS interval in IEEE 802.11 wireless networks 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, 21 May 2015 06:17:25 -0000 --047d7beb90861b7d5f0516917fca Content-Type: text/plain; charset=UTF-8 Hi, In the IEEE 802.11 standard, SIFS time is defined as aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaroundTime The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g. Usually aMACProcessingDelay is very small so that the 10 us limit for SIFS can be obeyed. Now if the MAC frame is, say, encoded with Reed-Solomon code, is it possible to decode it, process it (say, perform a XOR on the bits using a predefined sequence) to generate a response and encode the response back with Reed-Solomon code within aMACProcessingDelay? Can anyone kindly provide some pointers in this direction - like is it possible for very small (how small?) MAC frames or is it not possible at all using current technology? We may use FPGA to implement RS code encoder and decoder. Thanks for your time. Regards, Debarshi Kumar Sanyal KIIT University, Bhubaneswar, India --047d7beb90861b7d5f0516917fca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In the IEEE 802.= 11 standard, SIFS time is defined as

aSIFSTime is:=C2=A0 aRxRFDelay + aRxPLCPDelay + aM= ACProcessingDelay + aRxTxTurnaroundTime

The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g.
Usually aMACProcessingDelay is very small so that the 10 us limit for SIFS can be obeyed.
=
Now if the MAC frame is, say, encoded with Reed-Solomon code, is = it possible to decode it, process it (say, perform a XOR on the bits using = a predefined sequence) to generate a response and encode the response back = with Reed-Solomon code within aMACProcessingDelay?

Can anyone kindly pro= vide some pointers in this direction - like is it possible for very small (= how small?) MAC frames or is it not possible at all using current technolog= y?
We may use FPGA to implement RS code encoder and decoder.

Thanks for your time.
<= br clear=3D"all">
Regards,
Debarshi Kumar Sanyal
KIIT Univer= sity, Bhubaneswar, India
--047d7beb90861b7d5f0516917fca-- From nobody Wed May 20 23:46:31 2015 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 8D5441A1A6B for ; Wed, 20 May 2015 23:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, RCVD_IN_DNSWL_MED=-2.3, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] 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 nfPSLnlNvNT2 for ; Wed, 20 May 2015 23:46:27 -0700 (PDT) Received: from mailout2.zih.tu-dresden.de (mailout2.zih.tu-dresden.de [141.30.67.73]) by ietfa.amsl.com (Postfix) with ESMTP id CD6031A1A46 for ; Wed, 20 May 2015 23:46:26 -0700 (PDT) Received: from mail.zih.tu-dresden.de ([141.76.14.4]) by mailout2.zih.tu-dresden.de with esmtp (Exim 4.63) (envelope-from ) id 1YvKFK-0001v4-MJ for manet@ietf.org; Thu, 21 May 2015 08:46:25 +0200 Received: from dhcp-114.q.wlan.net.bme.hu ([152.66.168.114]) by server-50.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from ) id 1YvKFH-000391-Nn for manet@ietf.org; Thu, 21 May 2015 08:46:19 +0200 Message-ID: <555D7F45.3060209@tu-dresden.de> Date: Thu, 21 May 2015 08:46:29 +0200 From: Frank Fitzek User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: manet@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030505060404030200020107" X-TUD-Virus-Scanned: mailout2.zih.tu-dresden.de Archived-At: Subject: Re: [manet] Advanced signal processing within SIFS interval in IEEE 802.11 wireless networks 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, 21 May 2015 06:46:30 -0000 This is a multi-part message in MIME format. --------------030505060404030200020107 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear all, according to our measurements this should be possible. There are two ways to look at it: - The standard Block Codes, RS codes, etc: They will work on a predefined set of packets/symbols and do the whole encoding in one push, so packets will be available at the time you need them in the encoded form - Network Codes: They are different and allow for recoding on the fly, so encoding takes place per node on a certain time instant, but even here our experience is that the recoding will be fast enough. If it is a simple XOR for sure no problem, but also higher finite field calculations should work Does it help? FF Am 21.05.2015 um 08:17 schrieb Debarshi Sanyal: > Hi, > > In the IEEE 802.11 standard, SIFS time is defined as > > aSIFSTime is:aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay > +aRxTxTurnaroundTime > > > The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g. > Usually aMACProcessingDelay is very small so that the 10 us limit for > SIFS can be obeyed. > > Now if the MAC frame is, say, encoded with Reed-Solomon code, is it > possible to decode it, process it (say, perform a XOR on the bits > using a predefined sequence) to generate a response and encode the > response back with Reed-Solomon code within aMACProcessingDelay? > > Can anyone kindly provide some pointers in this direction - like is it > possible for very small (how small?) MAC frames or is it not possible > at all using current technology? > We may use FPGA to implement RS code encoder and decoder. > > Thanks for your time. > > Regards, > Debarshi Kumar Sanyal > KIIT University, Bhubaneswar, India > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet -- Frank Fitzek Professor Chair of Communication Networks Institute of Communication Technology TU Dresden phone: +49 351 463 33945 fax: +49 351 463 37163 mobile: +49 173 548 2947 web: www.fitzek.net skype: fitzek 5G Lab Germany Coordinator 5Glab.de --------------030505060404030200020107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear all,

according to our measurements this should be possible. There are two ways to look at it:

- The standard Block Codes, RS codes, etc: They will work on a predefined set of packets/symbols and do the whole encoding in one push, so packets will be available at the time you need them in the encoded form

- Network Codes: They are different and allow for recoding on the fly, so encoding takes place per node on a certain time instant, but even here our experience is that the recoding will be fast enough. If it is a simple XOR for sure no problem, but also higher finite field calculations should work

Does it help?

FF

Am 21.05.2015 um 08:17 schrieb Debarshi Sanyal:
Hi,

In the IEEE 802.11 standard, SIFS time is defined as

aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaroundTime


The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g.
Usually aMACProcessingDelay is very small so that the 10 us limit for SIFS can be obeyed.

Now if the MAC frame is, say, encoded with Reed-Solomon code, is it possible to decode it, process it (say, perform a XOR on the bits using a predefined sequence) to generate a response and encode the response back with Reed-Solomon code within aMACProcessingDelay?

Can anyone kindly provide some pointers in this direction - like is it possible for very small (how small?) MAC frames or is it not possible at all using current technology?
We may use FPGA to implement RS code encoder and decoder.

Thanks for your time.

Regards,
Debarshi Kumar Sanyal
KIIT University, Bhubaneswar, India


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


-- 
Frank Fitzek 
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de
--------------030505060404030200020107-- From nobody Thu May 21 00:19:46 2015 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 D8CBF1A1BDD for ; Thu, 21 May 2015 00:19: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 diFAgY8sVjpJ for ; Thu, 21 May 2015 00:19:42 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F69D1A1BD1 for ; Thu, 21 May 2015 00:19:42 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so11433921lbb.0 for ; Thu, 21 May 2015 00:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JVb2ioV4/1zQma5nsbPQkPtT0uLBS113tKWbadENsBs=; b=i4PamBEYZZ4ce7wja6Ftpz/ETa+Kg/w5ABfpn1gImdbpo5oxwfd4cPKnyKy1FGlbPS DmCzuqAkOF8kKbspg+JEpdVcSbiy2iMFttamrpyWythj5RkkYDmbKOH3Yws3S8I8w6kj BlP9EE+2CNbGgU/g2VR0X059IwG+jC68jAamtRi4PR36WOxtdCcGlB1vLBdkBb6hPz9G ec8InfFzEMifrRxkQzK5HAu75Z8LgZiUpLTP0Tf+VrrDXdPT7YbHyaQ5CmtT+JhackNm XBHDqObzow4AqTPeVnrmYfrrg/795HtlMPIv/4ifUNN0GlCYyoBwPgaH2RJs0zwrG7YC K1Cg== MIME-Version: 1.0 X-Received: by 10.112.157.164 with SMTP id wn4mr1048925lbb.100.1432192780397; Thu, 21 May 2015 00:19:40 -0700 (PDT) Received: by 10.112.18.73 with HTTP; Thu, 21 May 2015 00:19:40 -0700 (PDT) In-Reply-To: <555D7F45.3060209@tu-dresden.de> References: <555D7F45.3060209@tu-dresden.de> Date: Thu, 21 May 2015 12:49:40 +0530 Message-ID: From: Debarshi Sanyal To: Frank Fitzek Content-Type: multipart/alternative; boundary=001a11c34374ecf29f0516925d21 Archived-At: Cc: "manet@ietf.org" Subject: Re: [manet] Advanced signal processing within SIFS interval in IEEE 802.11 wireless networks 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, 21 May 2015 07:19:45 -0000 --001a11c34374ecf29f0516925d21 Content-Type: text/plain; charset=UTF-8 Hi Frank, Thanks for the response. We are currently analyzing the case of RS-coded packets (not network coding). In fact MAC packets for a specific function will be RS-coded. Can you kindly point to any real measurements that specify the time for encoding and decoding RS codes for various numbers of information and parity bits? Especially for total size of encoded packet WITHIN 32 bytes. The available literature mainly deals with RS(255,x) codes. Regards, Debarshi Kumar Sanyal KIIT University, Bhubaneswar, India On 21 May 2015 at 12:16, Frank Fitzek wrote: > Dear all, > > according to our measurements this should be possible. There are two ways > to look at it: > > - The standard Block Codes, RS codes, etc: They will work on a predefined > set of packets/symbols and do the whole encoding in one push, so packets > will be available at the time you need them in the encoded form > > - Network Codes: They are different and allow for recoding on the fly, so > encoding takes place per node on a certain time instant, but even here our > experience is that the recoding will be fast enough. If it is a simple XOR > for sure no problem, but also higher finite field calculations should work > > Does it help? > > FF > > > Am 21.05.2015 um 08:17 schrieb Debarshi Sanyal: > > Hi, > > In the IEEE 802.11 standard, SIFS time is defined as > > aSIFSTime is: aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + > aRxTxTurnaroundTime > > The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g. > Usually aMACProcessingDelay is very small so that the 10 us limit for > SIFS can be obeyed. > > Now if the MAC frame is, say, encoded with Reed-Solomon code, is it > possible to decode it, process it (say, perform a XOR on the bits using a > predefined sequence) to generate a response and encode the response back > with Reed-Solomon code within aMACProcessingDelay? > > Can anyone kindly provide some pointers in this direction - like is it > possible for very small (how small?) MAC frames or is it not possible at > all using current technology? > We may use FPGA to implement RS code encoder and decoder. > > Thanks for your time. > > Regards, > Debarshi Kumar Sanyal > KIIT University, Bhubaneswar, India > > > _______________________________________________ > manet mailing listmanet@ietf.orghttps://www.ietf.org/mailman/listinfo/manet > > > -- > Frank Fitzek > Professor > Chair of Communication Networks > Institute of Communication Technology > TU Dresden > > phone: +49 351 463 33945 > fax: +49 351 463 37163 > mobile: +49 173 548 2947 > web: www.fitzek.net > skype: fitzek > > 5G Lab Germany Coordinator 5Glab.de > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --001a11c34374ecf29f0516925d21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Frank,

Thanks for the response.
We are currently analyzing the case of RS-coded packets (not network codin= g). In fact MAC packets for a specific function will be RS-coded.

Can you kindly point to any real measurements that specify the time for= encoding and decoding RS codes for various numbers of information and pari= ty bits? Especially for total size of encoded packet WITHIN 32 bytes.
The available literature mainly deals with RS= (255,x) codes.


Regards,
Debarshi Kumar Sanyal
KIIT Universit= y, Bhubaneswar, India



On 21 May 2015 at 12:16, Frank Fitzek <frank.fitzek@tu-dresden.de> wrote:
=20 =20 =20
Dear all,

according to our measurements this should be possible. There are two ways to look at it:

- The standard Block Codes, RS codes, etc: They will work on a predefined set of packets/symbols and do the whole encoding in one push, so packets will be available at the time you need them in the encoded form

- Network Codes: They are different and allow for recoding on the fly, so encoding takes place per node on a certain time instant, but even here our experience is that the recoding will be fast enough. If it is a simple XOR for sure no problem, but also higher finite field calculations should work

Does it help?

FF


Am 21.05.2015 um 08:17 schrieb Debarshi Sanyal:
Hi,

In the IEEE 802.11 standard, SIFS time is defined as

aSIFSTime is:=C2=A0 aRxRFDelay + aRxPLCPDelay + aMACProcessingDelay + aRxTxTurnaroundTime


The nominal value of aSIFSTime is 10 us in IEEE 802.11b/g.
Usually aMACProcessingDelay is very small so that the 10 us limit for SIFS can be obeyed.

Now if the MAC frame is, say, encoded with Reed-Solomon code, is it possible to decode it, process it (say, perform a XOR on the bits using a predefined sequence) to generate a response and encode the response back with Reed-Solomon code within aMAC= ProcessingDelay?

Can anyone kindly provide some pointers in this direction - like is it possible for very small (how small?) MAC frames or is it not possible at all using current technology?
We may use FPGA to implement RS code encoder and decoder.

Thanks for your time.

Regards,
Debarshi Kumar Sanyal
KIIT University, Bhubaneswar, India


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


--=20
Frank Fitzek=20
Professor
Chair of Communication Networks
Institute of Communication Technology
TU Dresden

phone:  +49 351 463 33945
fax:    +49 351 463 37163
mobile: +49 173 548 2947
web:    www.fitzek.net<=
/a>
skype:	fitzek

5G Lab Germany Coordinator 5Glab.de

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


--001a11c34374ecf29f0516925d21-- From nobody Mon May 25 15:09:03 2015 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 C9BB61A90EA; Mon, 25 May 2015 15:09:01 -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] 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 Z2Blx9VMp4GC; Mon, 25 May 2015 15:09:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B7C1A90D9; Mon, 25 May 2015 15:09:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 15:09:00 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 22:09:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Multi-path Extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) Authors : Jiazi Yi Benoit Parrein Filename : draft-ietf-manet-olsrv2-multipath-03.txt Pages : 19 Date : 2015-05-25 Abstract: This document specifies a multi-path extension for the Optimized Link State Routing Protocol version 2 (OLSRv2) to discover multiple disjoint paths, so as to improve reliability of the OLSRv2 protocol. The interoperability with OLSRv2 is retained. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-03 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.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 25 15:32:33 2015 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 957881A9133 for ; Mon, 25 May 2015 15:32:31 -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 q45yQ0eM01N9 for ; Mon, 25 May 2015 15:32:29 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AB21A912A for ; Mon, 25 May 2015 15:32:29 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so58978452wic.0 for ; Mon, 25 May 2015 15:32:28 -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:content-type; bh=aLsgNz/Pfbe65jxwrO5l4Jsfx2P/WaqUrT1fEy1xxUg=; b=C4Uwcicr8wakBOljb2t21LmWVFqSUsW1QPBwSkeODNU4z+2qRNg57BP7sBlgMV5peH CK7YcQerHpxropjJGKSKx92G0/CmcVoQlpnCMaISqEta7J6Vpfoy7bAIVriaFqFm9Ue8 +yu4Jj8dHSZE22+Ns3OLmCWt+2ZdyQjftW2jrnSK7EI692VtMxp0ZaRzF0tcdfWngXl3 fslkcIxv54E837OXkdD3CgdKeYjMpat6XJuX8r2D7Id8DN52fiOF8ZsIzIsUWGJULpXM tYtrpSRXzteXM0kRZHERMtRTbGyxTG9ur9Hu1OLb1c2PvSFFkWFzfK8z4m6JEtAKjC5s dB+w== MIME-Version: 1.0 X-Received: by 10.194.121.38 with SMTP id lh6mr42795575wjb.2.1432593147896; Mon, 25 May 2015 15:32:27 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.220.134 with HTTP; Mon, 25 May 2015 15:32:27 -0700 (PDT) In-Reply-To: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> References: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 00:32:27 +0200 X-Google-Sender-Auth: G-NY7DczephvE_ei0jQNuvOe9cI Message-ID: From: Jiazi YI To: manet Content-Type: multipart/alternative; boundary=089e01177917b028f90516ef9570 Archived-At: Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.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, 25 May 2015 22:32:31 -0000 --089e01177917b028f90516ef9570 Content-Type: text/plain; charset=UTF-8 Dear all, As you might have seen, a new revision of olsrv2-multipath has been submitted. Sorry for the relatively delayed submission -- the birth of my new "boss" gave lots of extra work in the last two months. This revision mainly addresses previous comments from Justin (thanks very much!). Other than the editorial issues, the main changes include: - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the name change, this also releases the requirement of joining the source-route header from MP-OLSR supported router, to source routing supported router. - Making multi-path Dijkstra as a "default" algorithm for obtaining multiple paths. Other algorithms are allowed, as long as they fit the requirements defined in the document. It won't impact the interoperability. - Providing references to RFC 6554 and RFC 5095, which describes the vulnerabilities of source routing. There is one thing that I'm not sure about for the moment: currently, we defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO and TC messages separately, to identify the originators that supports source routing. I'm wondering, maybe it's better to define a *Message TLV* instead, as this feature (identifying source routing support) can be useful for other messages types also? regards Jiazi On Tue, May 26, 2015 at 12:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Multi-path Extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) > Authors : Jiazi Yi > Benoit Parrein > Filename : draft-ietf-manet-olsrv2-multipath-03.txt > Pages : 19 > Date : 2015-05-25 > > Abstract: > This document specifies a multi-path extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-multipath-03 > > > 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.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --089e01177917b028f90516ef9570 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

As you might have seen,= a new revision of olsrv2-multipath has been submitted. Sorry for the relat= ively delayed submission -- the birth of my new "boss" gave lots = of extra work in the last two months.=C2=A0

This r= evision mainly addresses previous comments from Justin (thanks very much!).= Other than the editorial issues, the main changes include:

<= /div>
=C2=A0 =C2=A0- Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other= than the name change, this also releases the requirement of joining the so= urce-route header from MP-OLSR supported router, to source routing supporte= d router.=C2=A0

=C2=A0 - Making multi-path Dijkstr= a as a "default" algorithm for obtaining multiple paths. Other al= gorithms are allowed, as long as they fit the requirements defined in the d= ocument. It won't impact the interoperability.=C2=A0

=C2=A0 - Providing references to RFC 6554 and RFC 5095, which descri= bes the vulnerabilities of source routing.=C2=A0

T= here is one thing that I'm not sure about for the moment: currently, we= defined SR_OLSRv2 TLV as=C2=A0Message-Type-specific Message TLV for= HELLO and TC messages separately, to identify the originators that support= s source routing.=C2=A0
I'm wondering, maybe it's better = to define a Message TLV=C2=A0instead, as this feature (identifying s= ource routing support) can be useful for other messages types also?=C2=A0

regards

Jiazi


= On Tue, May 26, 2015 at 12:09 AM, <internet-drafts@ietf.org>= ; wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Mobile Ad-hoc Networks Working Group= of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Multi-path Extension for the Optimized Link State Routing Protocol version= 2 (OLSRv2)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jiaz= i Yi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Benoit Parrein
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-manet-olsrv2-multipath-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 19
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-05-25

Abstract:
=C2=A0 =C2=A0This document specifies a multi-path extension for the Optimiz= ed Link
=C2=A0 =C2=A0State Routing Protocol version 2 (OLSRv2) to discover multiple=
=C2=A0 =C2=A0disjoint paths, so as to improve reliability of the OLSRv2 pro= tocol.
=C2=A0 =C2=A0The interoperability with OLSRv2 is retained.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-manet-ol= srv2-multipath/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-manet-olsrv2-mul= tipath-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-= manet-olsrv2-multipath-03


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--089e01177917b028f90516ef9570-- From nobody Mon May 25 16:19:56 2015 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 7C1A41ACD83 for ; Mon, 25 May 2015 16:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.423 X-Spam-Level: * X-Spam-Status: No, score=1.423 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 PZHYGl_wq7ol for ; Mon, 25 May 2015 16:19:53 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E671ACD90 for ; Mon, 25 May 2015 16:19:52 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so82503981wgb.3 for ; Mon, 25 May 2015 16:19:51 -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=5mn80stbbLdLGlxaCijsTgY8mGHg2X7p9gxjEKR5low=; b=mXR28QzYbZFeMJilFZZhrECR5a8+Lp6lsfGDKAbPxHg/EMUA3F9w09hj9RuiLoMgIU QgUvvPPrFZvAZZDE2jIqrBD5p3QqMnLIDdoY7NyDzWtRpyQ8UrevGkpb5h2KiISu9veB sf2MnLxiZX6CU/CIignOdCsQHtmh9F/nP7VUXA0JqF5CDVqM8P6CS821iDxMSND1r3H2 fsuKioeetQY+ysFpunCDrDPLL3h/sBOLqrM/c61s5pvSjb2680KD1SXzcJSDxatbkuZR 9fsKlJw31s63a6re5r0qi5fNJFEi8JygpFY53BFjaWJv2o+CSfGd3uU6W+5a3puewNNl GMmA== MIME-Version: 1.0 X-Received: by 10.181.11.137 with SMTP id ei9mr34336974wid.48.1432595991602; Mon, 25 May 2015 16:19:51 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.220.134 with HTTP; Mon, 25 May 2015 16:19:51 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> Date: Tue, 26 May 2015 01:19:51 +0200 X-Google-Sender-Auth: fGfssBsXWzDIsGFY3tIiEc6PO6Q Message-ID: From: Jiazi YI To: Lotte Steenbrink Content-Type: multipart/alternative; boundary=f46d043892d72fac520516f03ff0 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] RFC 5444 translation tables 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, 25 May 2015 23:19:55 -0000 --f46d043892d72fac520516f03ff0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If I understand well, we still need the existence and the order in the address block, to identify the usage of addresses? For example, section 8.1: 8.1.3 . Address Block A RREQ contains two Addresses, OrigAddr and TargAddr, and each address has an associated prefix length. +-------------------------+------------------------------+ | Data Elements | Address Block | +-------------------------+------------------------------+ | OrigAddr/OrigPrefixLen |
+ | | TargAddr/TargPrefixLen |
+ | +-------------------------+------------------------------+ We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only address block TLV for TargAddr (TargSeqNum) is optional. It means if we don't have the TargSeqNum TLV, according to RFC5444, we won't be able to know what's the TargAddr. best Jiazi On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink < lotte.steenbrink@fu-berlin.de> wrote: > Hi all, > FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses > all comments made in this thread. Any feedback is very welcome! > > Regards, > Lotte > > Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com>: > > > I don't have time to look at this today, but Henning's suggestion looks > good. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer > > BAE Systems Applied Intelligence > > > _________________________________________________________________________= _ > > > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > > > -----Original Message----- > > From: Henning Rogge [mailto:hrogge@gmail.com] > > Sent: 13 May 2015 15:11 > > To: Lotte Steenbrink > > Cc: Dearlove, Christopher (UK); manet@ietf.org > > Subject: Re: [manet] RFC 5444 translation tables > > > > ----------------------! 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. > > -------------------------------------------------------- > > > > On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink < > lotte.steenbrink@fu-berlin.de> wrote: > >> Hi Christopher, > >> thanks for your feedback. > >> > >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) > >> : > >> > >> There is a style question that all existing TLVs have names like > >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2=80= =99t think > >> IANA enforce such issues, and different people will have different > >> opinions on the importance of consistent style. (Naming can matter, > >> we=E2=80=99re spending cycles on an ID just about TLV names.) > >> > >> > >> > >> Absolutely. In your opinion, would it suffice to adjust the current > >> names stylistically (see attached file), or do some names need extra > >> work in terms of clarification or consistency? (I was just wondering > >> if METRIC should be edited to make clear that it is not directly > >> related to LINK_METRIC...) > > > > Maybe the name "PATH_METRIC" would make sense for the new TLV... this > describes the usage of the TLV very well. > > > > Henning Rogge > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d043892d72fac520516f03ff0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If I understand well, we still need the existence and the = order in the address block, to identify the usage of addresses?=C2=A0
<= br>
For example, section 8.1:=C2=A0


On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink <= lotte.st= eenbrink@fu-berlin.de> wrote:
Hi all,
FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses al= l comments made in this thread. Any feedback is very welcome!

Regards,
Lotte

Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesystems.com>:<= br>
> I don't have time to look at this today, but Henning's suggest= ion looks good.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> ______________________________________________________________________= ____
>
> T:=C2=A0 +44 (0)1245 242194=C2=A0 |=C2=A0 E: chris.dearlove@baesystems.com
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN.
> www.baesyst= ems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >
>
>
> -----Original Message-----
> From: Henning Rogge [mailto:hrogge= @gmail.com]
> Sent: 13 May 2015 15:11
> To: Lotte Steenbrink
> Cc: Dearlove, Christopher (UK); mane= t@ietf.org
> Subject: Re: [manet] RFC 5444 translation tables
>
> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external partner o= r from the internet.
> Consider carefully whether you should click on any links, open any att= achments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for i= nstructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <lotte.steenbrink@fu-berlin.de> wrot= e:
>> Hi Christopher,
>> thanks for your feedback.
>>
>> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
>> <chris.dearlov= e@baesystems.com>:
>>
>> There is a style question that all existing TLVs have names like >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2= =80=99t think
>> IANA enforce such issues, and different people will have different=
>> opinions on the importance of consistent style. (Naming can matter= ,
>> we=E2=80=99re spending cycles on an ID just about TLV names.)
>>
>>
>>
>> Absolutely. In your opinion, would it suffice to adjust the curren= t
>> names stylistically (see attached file), or do some names need ext= ra
>> work in terms of clarification or consistency? (I was just wonderi= ng
>> if METRIC should be edited to make clear that it is not directly >> related to LINK_METRIC...)
>
> Maybe the name "PATH_METRIC" would make sense for the new TL= V... this describes the usage of the TLV very well.
>
> Henning Rogge
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

--f46d043892d72fac520516f03ff0-- From nobody Tue May 26 10:27:38 2015 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 890AF1ACD17; Tue, 26 May 2015 10:27:36 -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] 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 qRXHDZBREdNy; Tue, 26 May 2015 10:27:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7541F1ACD47; Tue, 26 May 2015 10:27:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 10:27:32 -0700 Archived-At: Cc: draft-ietf-manet-olsrv2-multitopology@ietf.org, manet@ietf.org, manet-chairs@ietf.org Subject: [manet] Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 17:27:36 -0000 Barry Leiba has entered the following ballot position for draft-ietf-manet-olsrv2-multitopology-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Let's please have a brief, non-blocking discussion of the "updates" status here. As I read this, I don't see how this updates either 7181 or 7188. It clearly doesn't update 7188: it's just using an extension mechanism that was specified in 7188. I also don't think it updates 7181, because it's specifying an optional (indeed, experimental) extension. Here: does someone reading 7181, with no interest in implementing this experimental extension, need to read (or even know about) this document? I think the answer is no. (There's also the spurious "XXXX" in the updates list, which should be removed.) From nobody Wed May 27 02:23:55 2015 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 8DD771A90BA for ; Wed, 27 May 2015 02:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 y2OHqohJVJTs for ; Wed, 27 May 2015 02:23:52 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949311A909F for ; Wed, 27 May 2015 02:23:51 -0700 (PDT) Received: by laat2 with SMTP id t2so2889215laa.1 for ; Wed, 27 May 2015 02:23:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Wmihw43zVXgNC8XGmQ80BciuNs+nppjUTmOI6yiiIcg=; b=WKk1eVtkDAVyezUmFYbi2rt1JTHFu8sHGZgoU6m5FUPkLcwaTuPhD0aa1JRHN9QByn GH4QtryzPOC+wwoUCffg8dGjcSqTDZRthGoCz/hpp+XYMzyuUV7qSMtQbU4Dher2BVlq FBTS/6Xpkf8iuP3H66RxC8fSkqf31ICZLWPj5ED3Y1yPsZDeOZ34o6zmUrLo2olRhgrf XpWb0J0lgmTtCzuGvxaSBxDTJ0CqkNEKEbQ4nS9Tkavjd05EXbjlcAc9VvAc9GAlWX2G E5wwJnlH8q2eM1DvjCaXEfCp62H7/MQsN1uoK1T39O8Hsz0xEEm8GBBePtbYPMZq7rwz sZ/Q== MIME-Version: 1.0 X-Received: by 10.152.170.165 with SMTP id an5mr25112563lac.100.1432718629881; Wed, 27 May 2015 02:23:49 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Wed, 27 May 2015 02:23:49 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> Date: Wed, 27 May 2015 10:23:49 +0100 Message-ID: From: Victoria Mercieca To: Jiazi YI Content-Type: multipart/alternative; boundary=089e011776a3ff4eeb05170cccda Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 09:23:54 -0000 --089e011776a3ff4eeb05170cccda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Jiazi, and thanks for your comments, This is part of an ongoing discussion. The current draft implies that because there are two addresses in a RREQ, then if one is marked as OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other address must be TargAddr. i.e in a RREQ, we can interpret an address without an associated TLV as TargAddr. By doing it this way, we save the length of the TLV we might have associated with TargAddr. Further, this applied to other messages - the meaning of an unmarked address is deduced from the message type. For RREP, an address without an associated TLV is OrigAddr. For RERR, all unmarked addresses are unreachable destinations. In RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiate from the unreachable addresses. If in future, we decided to add an new type of address into a message for some reason, that address MUST have a TLV associated with it to differentiate. That makes sense anyway, we would want to indicate what the new address means. The question is, is this acceptable? If not, maybe we have to accept adding a TLV to each of these messages so that there are no addresses without associated any Address Block TLVs. Also, the order of addresses in the Address Block doesn't matter in either case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section 8, page 46): "The addresses in an Address Block may appear in any order, and values in an Address Block TLV must be associated with the correct address in the Address Block. To indicate which address each value is associated with, the AODVv2 message representation uses lists where the order of the addresses in the AddressList matches the order of values in the other lists, e.g., SeqNumList in a RERR." Is this unclear? Kind regards, Victoria. On Tue, May 26, 2015 at 12:19 AM, Jiazi YI wrote: > If I understand well, we still need the existence and the order in the > address block, to identify the usage of addresses? > > For example, section 8.1: > > 8.1.3 . Address Block > > A RREQ contains two Addresses, OrigAddr and TargAddr, and each > address has an associated prefix length. > > +-------------------------+------------------------------+ > | Data Elements | Address Block | > +-------------------------+------------------------------+ > | OrigAddr/OrigPrefixLen |
+ | > | TargAddr/TargPrefixLen |
+ | > +-------------------------+------------------------------+ > > > We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only= address block TLV for TargAddr (TargSeqNum) is optional. It means if we do= n't have the TargSeqNum TLV, according to RFC5444, we won't be able to know= what's the TargAddr. > > > best > > > Jiazi > > > > > On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink < > lotte.steenbrink@fu-berlin.de> wrote: > >> Hi all, >> FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses >> all comments made in this thread. Any feedback is very welcome! >> >> Regards, >> Lotte >> >> Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) < >> chris.dearlove@baesystems.com>: >> >> > I don't have time to look at this today, but Henning's suggestion look= s >> good. >> > >> > -- >> > Christopher Dearlove >> > Senior Principal Engineer >> > BAE Systems Applied Intelligence >> > >> ________________________________________________________________________= __ >> > >> > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >> > >> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >> Baddow, Chelmsford, Essex CM2 8HN. >> > www.baesystems.com/ai >> > BAE Systems Applied Intelligence Limited >> > Registered in England & Wales No: 01337451 >> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >> > >> > >> > >> > -----Original Message----- >> > From: Henning Rogge [mailto:hrogge@gmail.com] >> > Sent: 13 May 2015 15:11 >> > To: Lotte Steenbrink >> > Cc: Dearlove, Christopher (UK); manet@ietf.org >> > Subject: Re: [manet] RFC 5444 translation tables >> > >> > ----------------------! WARNING ! ---------------------- This message >> originates from outside our organisation, either from an external partne= r >> 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. >> > -------------------------------------------------------- >> > >> > On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink < >> lotte.steenbrink@fu-berlin.de> wrote: >> >> Hi Christopher, >> >> thanks for your feedback. >> >> >> >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) >> >> : >> >> >> >> There is a style question that all existing TLVs have names like >> >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2=80= =99t think >> >> IANA enforce such issues, and different people will have different >> >> opinions on the importance of consistent style. (Naming can matter, >> >> we=E2=80=99re spending cycles on an ID just about TLV names.) >> >> >> >> >> >> >> >> Absolutely. In your opinion, would it suffice to adjust the current >> >> names stylistically (see attached file), or do some names need extra >> >> work in terms of clarification or consistency? (I was just wondering >> >> if METRIC should be edited to make clear that it is not directly >> >> related to LINK_METRIC...) >> > >> > Maybe the name "PATH_METRIC" would make sense for the new TLV... this >> describes the usage of the TLV very well. >> > >> > Henning Rogge >> > ******************************************************************** >> > This email and any attachments are confidential to the intended >> > recipient and may also be privileged. If you are not the intended >> > recipient please delete it from your system and notify the sender. >> > You should not copy it or use it for any purpose nor disclose or >> > distribute its contents to any other person. >> > ******************************************************************** >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > --089e011776a3ff4eeb05170cccda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Jiazi, and thanks for your comments,

This is part of an ongoing discussion. The current draft implies that beca= use there are two addresses in a RREQ, then if one is marked as OrigAddr by= having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other address m= ust be TargAddr. i.e in a RREQ, we can interpret an address without an asso= ciated TLV as TargAddr. By doing it this way, we save the length of the TLV= we might have associated with TargAddr. Further, this applied to other mes= sages - the meaning of an unmarked address is deduced from the message type= .=C2=A0For RREP, an address without an associated TLV is OrigAddr. For RERR= , all unmarked addresses are unreachable destinations. In RERR, we mark the= PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiate= from the unreachable addresses.

If in future, we = decided to add an new type of address into a message for some reason, that = address MUST have a TLV associated with it to differentiate. That makes sen= se anyway, we would want to indicate what the new address means.
=
The question is, is this acceptable? If not, maybe we have t= o accept adding a TLV to each of these messages so that there are no addres= ses without associated any Address Block TLVs.

Als= o, the order of addresses in the Address Block doesn't matter in either= case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section = 8, page 46):
"The addresses in an Address Block may app= ear in any order, and values
=C2=A0 =C2=A0in an Address Block TLV= must be associated with the correct address
=C2=A0 =C2=A0in the = Address Block.=C2=A0 To indicate which address each value is
=C2= =A0 =C2=A0associated with, the AODVv2 message representation uses lists whe= re
=C2=A0 =C2=A0the order of the addresses in the AddressList mat= ches the order of
=C2=A0 =C2=A0values in the other lists, e.g., S= eqNumList in a RERR."
Is this unclear?
<= br>
Kind regards,
Victoria.

<= div class=3D"gmail_extra">
On Tue, May 26, 20= 15 at 12:19 AM, Jiazi YI <ietf@jiaziyi.com> wrote:
If I understand well, we still nee= d the existence and the order in the address block, to identify the usage o= f addresses?=C2=A0

For example, section 8.1:=C2=A0
= 

8.1.3.  Address Block


   A RREQ contains two Addresses, OrigAddr and TargAddr, and each
   address has an associated prefix length.

        +-------------------------+------------------------------+
        | Data Elements           | Address Block                |
        +-------------------------+------------------------------+
        | OrigAddr/OrigPrefixLen  | <address> + <prefix-length>=
  |
        | TargAddr/TargPrefixLen  | <address> + <prefix-length>=
  |
        +-------------------------+------------------------------+

We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM=
. However, the only address block TLV for TargAddr (TargSeqNum) is optional=
. It means if we don't have the TargSeqNum TLV, according to RFC5444, w=
e won't be able to know what's the TargAddr. 

best

=

Jiazi<=
/font>



On Wed, Ma= y 13, 2015 at 7:13 PM, Lotte Steenbrink <lotte.steenbrink@fu-b= erlin.de> wrote:
Hi all,<= br> FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses al= l comments made in this thread. Any feedback is very welcome!

Regards,
Lotte

Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesys= tems.com>:

> I don't have time to look at this today, but Henning's suggest= ion looks good.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> ______________________________________________________________________= ____
>
> T:=C2=A0 +44 (0)1245 242194=C2=A0 |=C2=A0 E: chris.dearlove@= baesystems.com
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN.
> www.baesyst= ems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >
>
>
> -----Original Message-----
> From: Henning Rogge [mailto:hrogge@gmail.com]
> Sent: 13 May 2015 15:11
> To: Lotte Steenbrink
> Cc: Dearlove, Christopher (UK); manet@ietf.org
> Subject: Re: [manet] RFC 5444 translation tables
>
> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external partner o= r from the internet.
> Consider carefully whether you should click on any links, open any att= achments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for i= nstructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <lotte.steenbrink@fu-berl= in.de> wrote:
>> Hi Christopher,
>> thanks for your feedback.
>>
>> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
>> <chris.dearlove@baesystems.com>:
>>
>> There is a style question that all existing TLVs have names like >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2= =80=99t think
>> IANA enforce such issues, and different people will have different=
>> opinions on the importance of consistent style. (Naming can matter= ,
>> we=E2=80=99re spending cycles on an ID just about TLV names.)
>>
>>
>>
>> Absolutely. In your opinion, would it suffice to adjust the curren= t
>> names stylistically (see attached file), or do some names need ext= ra
>> work in terms of clarification or consistency? (I was just wonderi= ng
>> if METRIC should be edited to make clear that it is not directly >> related to LINK_METRIC...)
>
> Maybe the name "PATH_METRIC" would make sense for the new TL= V... this describes the usage of the TLV very well.
>
> Henning Rogge
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet


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


--089e011776a3ff4eeb05170cccda-- From nobody Wed May 27 03:51:30 2015 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 4C36C1ACD3F; Wed, 27 May 2015 03:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 Om6Af_usUEfu; Wed, 27 May 2015 03:51:26 -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 D73C91ACD2F; Wed, 27 May 2015 03:51:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208";a="469039411" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 27 May 2015 11:51:23 +0100 X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208";a="103426955" Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasodc005.greenlnk.net with ESMTP; 27 May 2015 11:51:23 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0224.002; Wed, 27 May 2015 11:51:23 +0100 From: "Dearlove, Christopher (UK)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) Thread-Index: AQHQl9lRRJ5prP9FWkWLg5d6Ru4fcp2PpRzQ Date: Wed, 27 May 2015 10:51:23 +0000 Message-ID: References: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> In-Reply-To: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) 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, 27 May 2015 10:51:29 -0000 SXQncyBhIHBoaWxvc29waHkgcXVlc3Rpb24sIHdoYXQgZG9lcyB1cGRhdGVzIG1lYW4/IElzIHRo ZXJlIGEgZm9ybWFsIFJGQyBFZGl0b3IgZGVmaW5pdGlvbj8gVGhpcyBkb2VzLCBhdCB0aGUgbGVh c3QsIHVwZGF0ZSBJQU5BIHJlZ2lzdHJpZXMgZXN0YWJsaXNoZWQgYnkgNzE4MSBhbmQgSSB0aGlu ayA3MTg4IGFuZCBYWFhYIChkcmFmdC1pZXRmLW1hbmV0LXRsdi1uYW1pbmcgdGhhdCB3ZSBleHBl Y3QgdG8gYmUgYW4gUkZDIGJlZm9yZSBvciB3aXRoIHRoaXMpLg0KDQpCdXQgaG9uZXN0bHksIEkg YW5kIGNvLWF1dGhvciBkb24ndCBjYXJlIG9uZSB3YXkgb3IgdGhlIG90aGVyLCBpZiB0aGUgSUVT RyBwaWNrcyBhbiBhbnN3ZXIsIHdlJ2xsIGltcGxlbWVudCBpdC4gSSB3aWxsIHByb2JhYmx5IGhh dmUgdG8gbGV0IG15IGNvLWF1dGhvciBoYW5kbGUgdGhlIG1lY2hhbmljcyBvZiB0aGlzLCBJIG1h eSBiZSB1bmF2YWlsYWJsZSBzaG9ydGx5IGZvciBhdCBsZWFzdCBhIHdlZWsuDQoNCi0tIA0KQ2hy aXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJBRSBTeXN0ZW1z IEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiDCoCs0NCAoMCkx MjQ1IDI0MjE5NCDCoHwgwqBFOiBjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbQ0KDQpCQUUg U3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmss IEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1z LmNvbS9haQ0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0 ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTog U3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJhcnJ5IExlaWJhIFttYWlsdG86YmFycnls ZWliYUBjb21wdXRlci5vcmddIA0KU2VudDogMjYgTWF5IDIwMTUgMTg6MjgNClRvOiBUaGUgSUVT Rw0KQ2M6IG1hbmV0LWNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVs dGl0b3BvbG9neUBpZXRmLm9yZzsgbWFuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IEJhcnJ5IExlaWJh J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRpdG9wb2xvZ3kt MDU6ICh3aXRoIENPTU1FTlQpDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcgISAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lk ZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIGZy b20gdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBj bGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9sbG93 IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBsaW5rIG9uIElUIG1hdHRlcnMgZm9yIGlu c3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91cyBlbWFpbCBtZXNzYWdlcy4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCkJh cnJ5IExlaWJhIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0K ZHJhZnQtaWV0Zi1tYW5ldC1vbHNydjItbXVsdGl0b3BvbG9neS0wNTogTm8gT2JqZWN0aW9uDQoN CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0 ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJ RVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVudCwgYWxv bmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbWFuZXQtb2xzcnYyLW11bHRp dG9wb2xvZ3kvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpMZXQncyBwbGVhc2UgaGF2ZSBhIGJyaWVmLCBub24tYmxvY2tpbmcgZGlzY3Vzc2lvbiBvZiB0 aGUgInVwZGF0ZXMiDQpzdGF0dXMgaGVyZS4gIEFzIEkgcmVhZCB0aGlzLCBJIGRvbid0IHNlZSBo b3cgdGhpcyB1cGRhdGVzIGVpdGhlciA3MTgxIG9yIDcxODguICBJdCBjbGVhcmx5IGRvZXNuJ3Qg dXBkYXRlIDcxODg6IGl0J3MganVzdCB1c2luZyBhbiBleHRlbnNpb24gbWVjaGFuaXNtIHRoYXQg d2FzIHNwZWNpZmllZCBpbiA3MTg4LiAgSSBhbHNvIGRvbid0IHRoaW5rIGl0IHVwZGF0ZXMgNzE4 MSwgYmVjYXVzZSBpdCdzIHNwZWNpZnlpbmcgYW4gb3B0aW9uYWwgKGluZGVlZCwgZXhwZXJpbWVu dGFsKSBleHRlbnNpb24uICBIZXJlOiBkb2VzIHNvbWVvbmUgcmVhZGluZyA3MTgxLCB3aXRoIG5v IGludGVyZXN0IGluIGltcGxlbWVudGluZyB0aGlzIGV4cGVyaW1lbnRhbCBleHRlbnNpb24sIG5l ZWQgdG8gcmVhZCAob3IgZXZlbiBrbm93DQphYm91dCkgdGhpcyBkb2N1bWVudD8gIEkgdGhpbmsg dGhlIGFuc3dlciBpcyBuby4NCg0KKFRoZXJlJ3MgYWxzbyB0aGUgc3B1cmlvdXMgIlhYWFgiIGlu IHRoZSB1cGRhdGVzIGxpc3QsIHdoaWNoIHNob3VsZCBiZQ0KcmVtb3ZlZC4pDQoNCg0KKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgdG8g dGhlIGludGVuZGVkCnJlY2lwaWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91 ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyLgpZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9y IHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9yIGRpc2Nsb3NlIG9yCmRpc3RyaWJ1dGUgaXRzIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== From nobody Wed May 27 04:00:59 2015 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 024C41ACDB4 for ; Wed, 27 May 2015 04:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 K-oKy79Qykwp for ; Wed, 27 May 2015 04:00:54 -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 7CDF01ACDA9 for ; Wed, 27 May 2015 04:00:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208,217";a="469043922" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 27 May 2015 12:00:52 +0100 X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208,217";a="103429312" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 27 May 2015 12:00:51 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Wed, 27 May 2015 12:00:51 +0100 From: "Dearlove, Christopher (UK)" To: Victoria Mercieca , Jiazi YI Thread-Topic: [manet] RFC 5444 translation tables Thread-Index: AQHQiBo0ZM63Aqka3kqbkDjZ519xRZ1wR18QgAmgdwCAAARxAIAAFrJggAAcbwCAE0I5gIACOxSAgAApwiA= Date: Wed, 27 May 2015 11:00:50 +0000 Message-ID: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC628GLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 11:00:58 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC628GLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIHlvdSBzYXZlIEkgdGhpbmsgdHdvIGJ5dGVzIG5vdCBoYXZpbmcgYSB0YXJnZXQg YWRkcmVzcy4gRm9yIHNpZ25pZmljYW50IGxvc3Mgb2YgZXh0ZW5zaWJpbGl0eS4NCg0KVHdvIGJ5 dGVzPw0KDQpDdXJyZW50bHkgeW91IGNhbiBoYXZlIGEgdmFsdWVsZXNzIFRMVi4gSXQgbmVlZHMg YSBzaW5nbGUgYWRkcmVzcyBpbmRleCwgbm8gbGVuZ3RoIG9yIHZhbHVlLg0KSW5zdGVhZCB5b3Ug Y2FuIGhhdmUgYSBUTFYgd2l0aCB0d28gdmFsdWVzIGZvciB0aGUgdHdvIGFkZHJlc3MgdHlwZXMu IFVzaW5nIGEgbXVsdGl2YWx1ZSBUTFYgaXQgbmVlZHMgbm8gaW5kaWNlcywgYSBzaW5nbGUgYnl0 ZSBsZW5ndGggKDIpIGFuZCB0d28gdmFsdWUgYnl0ZXMuDQoNCkV4dGVuc2liaWxpdHk/IFlvdSBj YW4gYWRkIGFkZGl0aW9uYWwgYWRkcmVzc2VzIHdpdGggb3RoZXIgbWVhbmluZ3MgaW4gZnV0dXJl IGV4dGVuc2lvbnMuIFlvdSBjYW4gdXNlIHRoZSAyNTQgdW5hbGxvY2F0ZWQgKG9yIDI1MywgaGF2 aW5nIGFuIFVOU1BFQ0lGSUVEIHZhbHVlIG9mIDI1NSBhcyBpbiBSRkMgNzE4OCBpcyBhbHNvIGEg Z29vZCBpZGVhKSB2YWx1ZXMgZm9yIHRoaXMgaW4gc29tZSBjYXNlcy4NCg0KSXQgaXMgYWxzbyBj b21wYXRpYmxlIHdpdGggZXhpc3RpbmcgZ2VuZXJpYyA1NDQ0IHBhcnNlcnMgYXBwcm9hY2hlcy4N Cg0KLS0NCkNocmlzdG9waGVyIERlYXJsb3ZlDQpTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyDQpC QUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVDog ICs0NCAoMCkxMjQ1IDI0MjE5NCAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208 bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRv dywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRw Oi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpS ZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5 LCBHVTIgN1lQDQoNCg0KRnJvbTogbWFuZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVmljdG9yaWEgTWVyY2llY2ENClNlbnQ6IDI3IE1heSAyMDE1IDEwOjI0 DQpUbzogSmlhemkgWUkNCkNjOiBtYW5ldA0KU3ViamVjdDogUmU6IFttYW5ldF0gUkZDIDU0NDQg dHJhbnNsYXRpb24gdGFibGVzDQoNCg0KKioqIFdBUk5JTkcgKioqDQpUaGlzIG1lc3NhZ2Ugb3Jp Z2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0 ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuDQpDb25zaWRlciBjYXJlZnVsbHkgd2hldGhl ciB5b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3Ig cmVwbHkuDQpGb3IgaW5mb3JtYXRpb24gcmVnYXJkaW5nIFJlZCBGbGFncyB0aGF0IHlvdSBjYW4g bG9vayBvdXQgZm9yIGluIGVtYWlscyB5b3UgcmVjZWl2ZSwgY2xpY2sgaGVyZTxodHRwOi8vaW50 cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0Rv Y3VtZW50cy9SZWQlMjBGbGFncy5wZGY+Lg0KSWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1c3Bp Y2lvdXMsIHBsZWFzZSBmb2xsb3cgdGhpcyBwcm9jZXNzPGh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxp bmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGY+Lg0KSGkgSmlhemksIGFuZCB0aGFu a3MgZm9yIHlvdXIgY29tbWVudHMsDQoNClRoaXMgaXMgcGFydCBvZiBhbiBvbmdvaW5nIGRpc2N1 c3Npb24uIFRoZSBjdXJyZW50IGRyYWZ0IGltcGxpZXMgdGhhdCBiZWNhdXNlIHRoZXJlIGFyZSB0 d28gYWRkcmVzc2VzIGluIGEgUlJFUSwgdGhlbiBpZiBvbmUgaXMgbWFya2VkIGFzIE9yaWdBZGRy IGJ5IGhhdmluZyBhbiBhc3NvY2lhdGVkIE9yaWdTZXFOdW0gKG9yIE9SSUdfU0VRX05VTSkgVExW LCB0aGUgb3RoZXIgYWRkcmVzcyBtdXN0IGJlIFRhcmdBZGRyLiBpLmUgaW4gYSBSUkVRLCB3ZSBj YW4gaW50ZXJwcmV0IGFuIGFkZHJlc3Mgd2l0aG91dCBhbiBhc3NvY2lhdGVkIFRMViBhcyBUYXJn QWRkci4gQnkgZG9pbmcgaXQgdGhpcyB3YXksIHdlIHNhdmUgdGhlIGxlbmd0aCBvZiB0aGUgVExW IHdlIG1pZ2h0IGhhdmUgYXNzb2NpYXRlZCB3aXRoIFRhcmdBZGRyLiBGdXJ0aGVyLCB0aGlzIGFw cGxpZWQgdG8gb3RoZXIgbWVzc2FnZXMgLSB0aGUgbWVhbmluZyBvZiBhbiB1bm1hcmtlZCBhZGRy ZXNzIGlzIGRlZHVjZWQgZnJvbSB0aGUgbWVzc2FnZSB0eXBlLiBGb3IgUlJFUCwgYW4gYWRkcmVz cyB3aXRob3V0IGFuIGFzc29jaWF0ZWQgVExWIGlzIE9yaWdBZGRyLiBGb3IgUkVSUiwgYWxsIHVu bWFya2VkIGFkZHJlc3NlcyBhcmUgdW5yZWFjaGFibGUgZGVzdGluYXRpb25zLiBJbiBSRVJSLCB3 ZSBtYXJrIHRoZSBQa3RTb3VyY2UgYWRkcmVzcyB3aXRoIGl0cyBvd24gUGt0U291cmNlIChQS1Rf U09VUkNFKSBUTFYgdG8gZGlmZmVyZW50aWF0ZSBmcm9tIHRoZSB1bnJlYWNoYWJsZSBhZGRyZXNz ZXMuDQoNCklmIGluIGZ1dHVyZSwgd2UgZGVjaWRlZCB0byBhZGQgYW4gbmV3IHR5cGUgb2YgYWRk cmVzcyBpbnRvIGEgbWVzc2FnZSBmb3Igc29tZSByZWFzb24sIHRoYXQgYWRkcmVzcyBNVVNUIGhh dmUgYSBUTFYgYXNzb2NpYXRlZCB3aXRoIGl0IHRvIGRpZmZlcmVudGlhdGUuIFRoYXQgbWFrZXMg c2Vuc2UgYW55d2F5LCB3ZSB3b3VsZCB3YW50IHRvIGluZGljYXRlIHdoYXQgdGhlIG5ldyBhZGRy ZXNzIG1lYW5zLg0KDQpUaGUgcXVlc3Rpb24gaXMsIGlzIHRoaXMgYWNjZXB0YWJsZT8gSWYgbm90 LCBtYXliZSB3ZSBoYXZlIHRvIGFjY2VwdCBhZGRpbmcgYSBUTFYgdG8gZWFjaCBvZiB0aGVzZSBt ZXNzYWdlcyBzbyB0aGF0IHRoZXJlIGFyZSBubyBhZGRyZXNzZXMgd2l0aG91dCBhc3NvY2lhdGVk IGFueSBBZGRyZXNzIEJsb2NrIFRMVnMuDQoNCkFsc28sIHRoZSBvcmRlciBvZiBhZGRyZXNzZXMg aW4gdGhlIEFkZHJlc3MgQmxvY2sgZG9lc24ndCBtYXR0ZXIgaW4gZWl0aGVyIGNhc2UuIEFPRFZ2 MiBkcmFmdCA5IHNheXMsIGluIHRoZSBSRkM1NDQ0IFJlcHJlc2VudGF0aW9uIFNlY3Rpb24gKFNl Y3Rpb24gOCwgcGFnZSA0Nik6DQoiVGhlIGFkZHJlc3NlcyBpbiBhbiBBZGRyZXNzIEJsb2NrIG1h eSBhcHBlYXIgaW4gYW55IG9yZGVyLCBhbmQgdmFsdWVzDQogICBpbiBhbiBBZGRyZXNzIEJsb2Nr IFRMViBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgY29ycmVjdCBhZGRyZXNzDQogICBpbiB0 aGUgQWRkcmVzcyBCbG9jay4gIFRvIGluZGljYXRlIHdoaWNoIGFkZHJlc3MgZWFjaCB2YWx1ZSBp cw0KICAgYXNzb2NpYXRlZCB3aXRoLCB0aGUgQU9EVnYyIG1lc3NhZ2UgcmVwcmVzZW50YXRpb24g dXNlcyBsaXN0cyB3aGVyZQ0KICAgdGhlIG9yZGVyIG9mIHRoZSBhZGRyZXNzZXMgaW4gdGhlIEFk ZHJlc3NMaXN0IG1hdGNoZXMgdGhlIG9yZGVyIG9mDQogICB2YWx1ZXMgaW4gdGhlIG90aGVyIGxp c3RzLCBlLmcuLCBTZXFOdW1MaXN0IGluIGEgUkVSUi4iDQpJcyB0aGlzIHVuY2xlYXI/DQoNCktp bmQgcmVnYXJkcywNClZpY3RvcmlhLg0KDQoNCk9uIFR1ZSwgTWF5IDI2LCAyMDE1IGF0IDEyOjE5 IEFNLCBKaWF6aSBZSSA8aWV0ZkBqaWF6aXlpLmNvbTxtYWlsdG86aWV0ZkBqaWF6aXlpLmNvbT4+ IHdyb3RlOg0KSWYgSSB1bmRlcnN0YW5kIHdlbGwsIHdlIHN0aWxsIG5lZWQgdGhlIGV4aXN0ZW5j ZSBhbmQgdGhlIG9yZGVyIGluIHRoZSBhZGRyZXNzIGJsb2NrLCB0byBpZGVudGlmeSB0aGUgdXNh Z2Ugb2YgYWRkcmVzc2VzPw0KDQpGb3IgZXhhbXBsZSwgc2VjdGlvbiA4LjE6DQoNCjguMS4zPGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hbmV0LWFvZHZ2Mi0wOSNzZWN0 aW9uLTguMS4zPi4gIEFkZHJlc3MgQmxvY2sNCg0KDQoNCg0KDQogICBBIFJSRVEgY29udGFpbnMg dHdvIEFkZHJlc3NlcywgT3JpZ0FkZHIgYW5kIFRhcmdBZGRyLCBhbmQgZWFjaA0KDQogICBhZGRy ZXNzIGhhcyBhbiBhc3NvY2lhdGVkIHByZWZpeCBsZW5ndGguDQoNCg0KDQogICAgICAgICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0K ICAgICAgICB8IERhdGEgRWxlbWVudHMgICAgICAgICAgIHwgQWRkcmVzcyBCbG9jayAgICAgICAg ICAgICAgICB8DQoNCiAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgIHwgT3JpZ0FkZHIvT3JpZ1ByZWZpeExl biAgfCA8YWRkcmVzcz4gKyA8cHJlZml4LWxlbmd0aD4gIHwNCg0KICAgICAgICB8IFRhcmdBZGRy L1RhcmdQcmVmaXhMZW4gIHwgPGFkZHJlc3M+ICsgPHByZWZpeC1sZW5ndGg+ICB8DQoNCiAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KDQoNCg0KV2UgY2FuIGluZmVyIHRoZSBPcmlnQWRkciBieSB0aGUgVExWIHR5cGUgT1JJ R19TRVFfTlVNLiBIb3dldmVyLCB0aGUgb25seSBhZGRyZXNzIGJsb2NrIFRMViBmb3IgVGFyZ0Fk ZHIgKFRhcmdTZXFOdW0pIGlzIG9wdGlvbmFsLiBJdCBtZWFucyBpZiB3ZSBkb24ndCBoYXZlIHRo ZSBUYXJnU2VxTnVtIFRMViwgYWNjb3JkaW5nIHRvIFJGQzU0NDQsIHdlIHdvbid0IGJlIGFibGUg dG8ga25vdyB3aGF0J3MgdGhlIFRhcmdBZGRyLg0KDQoNCg0KYmVzdA0KDQoNCg0KSmlhemkNCg0K DQoNCg0KDQpPbiBXZWQsIE1heSAxMywgMjAxNSBhdCA3OjEzIFBNLCBMb3R0ZSBTdGVlbmJyaW5r IDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWlsdG86bG90dGUuc3RlZW5icmlua0Bm dS1iZXJsaW4uZGU+PiB3cm90ZToNCkhpIGFsbCwNCkZZSSwgZHJhZnQtaWV0Zi1tYW5ldC1hb2R2 djItMDksIHdoaWNoIGNoYXJsaWUganVzdCBwdWJsaXNoZWQsIGFkZHJlc3NlcyBhbGwgY29tbWVu dHMgbWFkZSBpbiB0aGlzIHRocmVhZC4gQW55IGZlZWRiYWNrIGlzIHZlcnkgd2VsY29tZSENCg0K UmVnYXJkcywNCkxvdHRlDQoNCkFtIDEzLjA1LjIwMTUgdW0gMTY6MzMgc2NocmllYiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKSA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj46DQoNCj4gSSBkb24ndCBoYXZlIHRpbWUg dG8gbG9vayBhdCB0aGlzIHRvZGF5LCBidXQgSGVubmluZydzIHN1Z2dlc3Rpb24gbG9va3MgZ29v ZC4NCj4NCj4gLS0NCj4gQ2hyaXN0b3BoZXIgRGVhcmxvdmUNCj4gU2VuaW9yIFByaW5jaXBhbCBF bmdpbmVlcg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZQ0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPg0KPiBUOiAgKzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkx MjQ1JTIwMjQyMTk0PiAgfCAgRTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPg0KPg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVk IEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywg Q2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi4NCj4gd3d3LmJhZXN5c3RlbXMuY29tL2FpPGh0dHA6 Ly93d3cuYmFlc3lzdGVtcy5jb20vYWk+DQo+IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlIExpbWl0ZWQNCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUx DQo+IFJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBT dXJyZXksIEdVMiA3WVANCj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRvOmhyb2dnZUBnbWFpbC5jb208bWFpbHRvOmhyb2dn ZUBnbWFpbC5jb20+XQ0KPiBTZW50OiAxMyBNYXkgMjAxNSAxNToxMQ0KPiBUbzogTG90dGUgU3Rl ZW5icmluaw0KPiBDYzogRGVhcmxvdmUsIENocmlzdG9waGVyIChVSyk7IG1hbmV0QGlldGYub3Jn PG1haWx0bzptYW5ldEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFttYW5ldF0gUkZDIDU0NDQg dHJhbnNsYXRpb24gdGFibGVzDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5JTkcg ISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0 c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9y IGZyb20gdGhlIGludGVybmV0Lg0KPiBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5b3Ugc2hv dWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVwbHkuDQo+ IEZvbGxvdyB0aGUgJ1JlcG9ydCBTdXNwaWNpb3VzIEVtYWlscycgbGluayBvbiBJVCBtYXR0ZXJz IGZvciBpbnN0cnVjdGlvbnMgb24gcmVwb3J0aW5nIHN1c3BpY2lvdXMgZW1haWwgbWVzc2FnZXMu DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+DQo+IE9uIFdlZCwgTWF5IDEzLCAyMDE1IGF0IDM6NTUgUE0sIExvdHRlIFN0ZWVuYnJp bmsgPGxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlPG1haWx0bzpsb3R0ZS5zdGVlbmJyaW5r QGZ1LWJlcmxpbi5kZT4+IHdyb3RlOg0KPj4gSGkgQ2hyaXN0b3BoZXIsDQo+PiB0aGFua3MgZm9y IHlvdXIgZmVlZGJhY2suDQo+Pg0KPj4gQW0gMDcuMDUuMjAxNSB1bSAxMjowMCBzY2hyaWViIERl YXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQo+PiA8Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPj46DQo+Pg0KPj4gVGhlcmUg aXMgYSBzdHlsZSBxdWVzdGlvbiB0aGF0IGFsbCBleGlzdGluZyBUTFZzIGhhdmUgbmFtZXMgbGlr ZQ0KPj4gTElOS19TVEFUVVMsIHdoaWxlIGhlcmUgVExWcyBoYXZlIG5hbWVzIGxpa2UgT3JpZ1Nl cU51bS4gSSBkb27igJl0IHRoaW5rDQo+PiBJQU5BIGVuZm9yY2Ugc3VjaCBpc3N1ZXMsIGFuZCBk aWZmZXJlbnQgcGVvcGxlIHdpbGwgaGF2ZSBkaWZmZXJlbnQNCj4+IG9waW5pb25zIG9uIHRoZSBp bXBvcnRhbmNlIG9mIGNvbnNpc3RlbnQgc3R5bGUuIChOYW1pbmcgY2FuIG1hdHRlciwNCj4+IHdl 4oCZcmUgc3BlbmRpbmcgY3ljbGVzIG9uIGFuIElEIGp1c3QgYWJvdXQgVExWIG5hbWVzLikNCj4+ DQo+Pg0KPj4NCj4+IEFic29sdXRlbHkuIEluIHlvdXIgb3Bpbmlvbiwgd291bGQgaXQgc3VmZmlj ZSB0byBhZGp1c3QgdGhlIGN1cnJlbnQNCj4+IG5hbWVzIHN0eWxpc3RpY2FsbHkgKHNlZSBhdHRh Y2hlZCBmaWxlKSwgb3IgZG8gc29tZSBuYW1lcyBuZWVkIGV4dHJhDQo+PiB3b3JrIGluIHRlcm1z IG9mIGNsYXJpZmljYXRpb24gb3IgY29uc2lzdGVuY3k/IChJIHdhcyBqdXN0IHdvbmRlcmluZw0K Pj4gaWYgTUVUUklDIHNob3VsZCBiZSBlZGl0ZWQgdG8gbWFrZSBjbGVhciB0aGF0IGl0IGlzIG5v dCBkaXJlY3RseQ0KPj4gcmVsYXRlZCB0byBMSU5LX01FVFJJQy4uLikNCj4NCj4gTWF5YmUgdGhl IG5hbWUgIlBBVEhfTUVUUklDIiB3b3VsZCBtYWtlIHNlbnNlIGZvciB0aGUgbmV3IFRMVi4uLiB0 aGlzIGRlc2NyaWJlcyB0aGUgdXNhZ2Ugb2YgdGhlIFRMViB2ZXJ5IHdlbGwuDQo+DQo+IEhlbm5p bmcgUm9nZ2UNCj4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioNCj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgdG8gdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVu dCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVy Lg0KPiBZb3Ugc2hvdWxkIG5vdCBjb3B5IGl0IG9yIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Ugbm9y IGRpc2Nsb3NlIG9yDQo+IGRpc3RyaWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24uDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQptYW5ldCBtYWlsaW5nIGxpc3QNCm1hbmV0QGlldGYub3JnPG1haWx0bzpt YW5ldEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFu ZXQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K bWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0DQoNCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC628GLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi SGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hh cg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9u dC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0Kc3Bhbi5I ZWFkaW5nNENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgNCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyA0IjsNCglmb250LWZhbWls eToiQ2FtYnJpYSIsInNlcmlmIjsNCgljb2xvcjojNEY4MUJEOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7DQoJZm9udC1zdHlsZTppdGFsaWM7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjdHVhbGx5LCB5b3Ug c2F2ZSBJIHRoaW5rIHR3byBieXRlcyBub3QgaGF2aW5nIGEgdGFyZ2V0IGFkZHJlc3MuIEZvciBz aWduaWZpY2FudCBsb3NzIG9mIGV4dGVuc2liaWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Ud28gYnl0ZXM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DdXJyZW50bHkgeW91IGNhbiBoYXZlIGEgdmFsdWVsZXNzIFRMVi4gSXQgbmVlZHMg YSBzaW5nbGUgYWRkcmVzcyBpbmRleCwgbm8gbGVuZ3RoIG9yIHZhbHVlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JbnN0ZWFkIHlvdSBjYW4gaGF2ZSBhIFRMViB3aXRoIHR3byB2YWx1 ZXMgZm9yIHRoZSB0d28gYWRkcmVzcyB0eXBlcy4gVXNpbmcgYSBtdWx0aXZhbHVlIFRMViBpdCBu ZWVkcyBubyBpbmRpY2VzLCBhIHNpbmdsZSBieXRlIGxlbmd0aCAoMikgYW5kIHR3byB2YWx1ZSBi eXRlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkV4dGVuc2liaWxpdHk/IFlvdSBjYW4gYWRkIGFkZGl0aW9uYWwgYWRk cmVzc2VzIHdpdGggb3RoZXIgbWVhbmluZ3MgaW4gZnV0dXJlIGV4dGVuc2lvbnMuIFlvdSBjYW4g dXNlIHRoZSAyNTQgdW5hbGxvY2F0ZWQgKG9yIDI1MywgaGF2aW5nIGFuIFVOU1BFQ0lGSUVEIHZh bHVlDQogb2YgMjU1IGFzIGluIFJGQyA3MTg4IGlzIGFsc28gYSBnb29kIGlkZWEpIHZhbHVlcyBm b3IgdGhpcyBpbiBzb21lIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXQgaXMgYWxzbyBjb21wYXRpYmxlIHdp dGggZXhpc3RpbmcgZ2VuZXJpYyA1NDQ0IHBhcnNlcnMgYXBwcm9hY2hlcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJs b3ZlPGJyPg0KU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxp ZWQgSW50ZWxsaWdlbmNlPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiNCRUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDsmIzQzOzQ0ICgwKTEyNDUgMjQy MTk0ICZuYnNwO3wgJm5ic3A7PGI+RToNCjwvYj48YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxv dmVAYmFlc3lzdGVtcy5jb20iPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJh ZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhITi48YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3 LmJhZXN5c3RlbXMuY29tL2FpIj48c3BhbiBzdHlsZT0iY29sb3I6IzNBOEI5Mjt0ZXh0LWRlY29y YXRpb246bm9uZSI+d3d3LmJhZXN5c3RlbXMuY29tL2FpPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzNBOEI5MiI+QkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZDxi cj4NClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5SZWdpc3Rl cmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIg N1lQPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0IFttYWlsdG86bWFuZXQtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmljdG9yaWEgTWVyY2llY2E8YnI+DQo8Yj5TZW50 OjwvYj4gMjcgTWF5IDIwMTUgMTA6MjQ8YnI+DQo8Yj5Ubzo8L2I+IEppYXppIFlJPGJyPg0KPGI+ Q2M6PC9iPiBtYW5ldDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW21hbmV0XSBSRkMgNTQ0NCB0 cmFuc2xhdGlvbiB0YWJsZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCBibGFj ayAxLjBwdDtwYWRkaW5nOjIuMHB0IDIuMHB0IDIuMHB0IDIuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0 LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMzMzM5NzIiPioqKiBXQVJOSU5HICoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7dGV4dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3 aGl0ZSI+DQo8ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj5UaGlz IG1lc3NhZ2Ugb3JpZ2luYXRlcyBmcm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVy IGZyb20gYW4gZXh0ZXJuYWwgcGFydG5lciBvciB0aGUgaW50ZXJuZXQuPC9zcGFuPjwvZW0+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48YnI+DQo8ZW0+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIHlvdSBzaG91bGQgY2xpY2sgb24gYW55IGxp bmtzLCBvcGVuIGFueSBhdHRhY2htZW50cyBvciByZXBseS48L3NwYW4+PC9lbT48YnI+DQo8ZW0+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZvciBpbmZvcm1hdGlvbiByZWdhcmRpbmcgPC9zcGFuPg0KPC9lbT48L3NwYW4+ PC9pPjxzdHJvbmc+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZCBG bGFnczwvc3Bhbj48L2k+PC9zdHJvbmc+PGVtPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzMzMzk3MiI+IHRoYXQgeW91IGNhbiBsb29rIG91dCBmb3IgaW4gZW1haWxzIHlvdSByZWNl aXZlLA0KIGNsaWNrIDxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFlc3lzdGVtcy5jb20v aG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL1JlZCUyMEZsYWdzLnBkZiI+ DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWlsIGlzIHN1 c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5lbnQuYmFl c3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRzL0RlYWxp bmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiPg0KdGhpcyBwcm9jZXNzPC9hPi48 L3NwYW4+PC9lbT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMz Mzk3MiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBKaWF6aSwgYW5kIHRoYW5rcyBmb3IgeW91ciBjb21tZW50cyw8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgcGFy dCBvZiBhbiBvbmdvaW5nIGRpc2N1c3Npb24uIFRoZSBjdXJyZW50IGRyYWZ0IGltcGxpZXMgdGhh dCBiZWNhdXNlIHRoZXJlIGFyZSB0d28gYWRkcmVzc2VzIGluIGEgUlJFUSwgdGhlbiBpZiBvbmUg aXMgbWFya2VkIGFzIE9yaWdBZGRyIGJ5IGhhdmluZyBhbiBhc3NvY2lhdGVkIE9yaWdTZXFOdW0g KG9yIE9SSUdfU0VRX05VTSkgVExWLCB0aGUgb3RoZXIgYWRkcmVzcyBtdXN0IGJlIFRhcmdBZGRy Lg0KIGkuZSBpbiBhIFJSRVEsIHdlIGNhbiBpbnRlcnByZXQgYW4gYWRkcmVzcyB3aXRob3V0IGFu IGFzc29jaWF0ZWQgVExWIGFzIFRhcmdBZGRyLiBCeSBkb2luZyBpdCB0aGlzIHdheSwgd2Ugc2F2 ZSB0aGUgbGVuZ3RoIG9mIHRoZSBUTFYgd2UgbWlnaHQgaGF2ZSBhc3NvY2lhdGVkIHdpdGggVGFy Z0FkZHIuIEZ1cnRoZXIsIHRoaXMgYXBwbGllZCB0byBvdGhlciBtZXNzYWdlcyAtIHRoZSBtZWFu aW5nIG9mIGFuIHVubWFya2VkIGFkZHJlc3MgaXMgZGVkdWNlZA0KIGZyb20gdGhlIG1lc3NhZ2Ug dHlwZS4mbmJzcDtGb3IgUlJFUCwgYW4gYWRkcmVzcyB3aXRob3V0IGFuIGFzc29jaWF0ZWQgVExW IGlzIE9yaWdBZGRyLiBGb3IgUkVSUiwgYWxsIHVubWFya2VkIGFkZHJlc3NlcyBhcmUgdW5yZWFj aGFibGUgZGVzdGluYXRpb25zLiBJbiBSRVJSLCB3ZSBtYXJrIHRoZSBQa3RTb3VyY2UgYWRkcmVz cyB3aXRoIGl0cyBvd24gUGt0U291cmNlIChQS1RfU09VUkNFKSBUTFYgdG8gZGlmZmVyZW50aWF0 ZSBmcm9tIHRoZSB1bnJlYWNoYWJsZQ0KIGFkZHJlc3Nlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgaW4gZnV0dXJlLCB3ZSBkZWNpZGVk IHRvIGFkZCBhbiBuZXcgdHlwZSBvZiBhZGRyZXNzIGludG8gYSBtZXNzYWdlIGZvciBzb21lIHJl YXNvbiwgdGhhdCBhZGRyZXNzIE1VU1QgaGF2ZSBhIFRMViBhc3NvY2lhdGVkIHdpdGggaXQgdG8g ZGlmZmVyZW50aWF0ZS4gVGhhdCBtYWtlcyBzZW5zZSBhbnl3YXksIHdlIHdvdWxkIHdhbnQgdG8g aW5kaWNhdGUgd2hhdCB0aGUgbmV3IGFkZHJlc3MgbWVhbnMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbiBpcywgaXMgdGhp cyBhY2NlcHRhYmxlPyBJZiBub3QsIG1heWJlIHdlIGhhdmUgdG8gYWNjZXB0IGFkZGluZyBhIFRM ViB0byBlYWNoIG9mIHRoZXNlIG1lc3NhZ2VzIHNvIHRoYXQgdGhlcmUgYXJlIG5vIGFkZHJlc3Nl cyB3aXRob3V0IGFzc29jaWF0ZWQgYW55IEFkZHJlc3MgQmxvY2sgVExWcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxzbywgdGhlIG9yZGVy IG9mIGFkZHJlc3NlcyBpbiB0aGUgQWRkcmVzcyBCbG9jayBkb2Vzbid0IG1hdHRlciBpbiBlaXRo ZXIgY2FzZS4gQU9EVnYyIGRyYWZ0IDkgc2F5cywgaW4gdGhlIFJGQzU0NDQgUmVwcmVzZW50YXRp b24gU2VjdGlvbiAoU2VjdGlvbiA4LCBwYWdlIDQ2KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDtUaGUgYWRkcmVzc2VzIGlu IGFuIEFkZHJlc3MgQmxvY2sgbWF5IGFwcGVhciBpbiBhbnkgb3JkZXIsIGFuZCB2YWx1ZXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtpbiBhbiBBZGRyZXNzIEJsb2NrIFRMViBtdXN0IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUg Y29ycmVjdCBhZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7aW4gdGhlIEFkZHJlc3MgQmxvY2suJm5ic3A7IFRvIGlu ZGljYXRlIHdoaWNoIGFkZHJlc3MgZWFjaCB2YWx1ZSBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO2Fzc29jaWF0ZWQgd2l0 aCwgdGhlIEFPRFZ2MiBtZXNzYWdlIHJlcHJlc2VudGF0aW9uIHVzZXMgbGlzdHMgd2hlcmU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDt0aGUgb3JkZXIgb2YgdGhlIGFkZHJlc3NlcyBpbiB0aGUgQWRkcmVzc0xpc3QgbWF0Y2hl cyB0aGUgb3JkZXIgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt2YWx1ZXMgaW4gdGhlIG90aGVyIGxpc3RzLCBlLmcuLCBT ZXFOdW1MaXN0IGluIGEgUkVSUi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhpcyB1bmNsZWFyPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIHJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5WaWN0 b3JpYS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIE1heSAyNiwgMjAxNSBhdCAxMjoxOSBBTSwgSmlhemkgWUkgJmx0OzxhIGhy ZWY9Im1haWx0bzppZXRmQGppYXppeWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBqaWF6aXlp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklmIEkgdW5kZXJzdGFuZCB3ZWxsLCB3ZSBzdGlsbCBuZWVkIHRoZSBleGlzdGVuY2Ug YW5kIHRoZSBvcmRlciBpbiB0aGUgYWRkcmVzcyBibG9jaywgdG8gaWRlbnRpZnkgdGhlIHVzYWdl IG9mIGFkZHJlc3Nlcz8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkZvciBleGFtcGxlLCBzZWN0aW9uIDguMTombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGg0IHN0eWxlPSJtc28tbGluZS1oZWlnaHQtYWx0OjBwdCI+PGEg bmFtZT0iMTRkOGQ2MDNmNmZkNTNiNl9zZWN0aW9uLTguMS4zIj48L2E+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTA5I3NlY3Rpb24t OC4xLjMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjguMS4zPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2siPi4mbmJzcDsNCiBBZGRyZXNzIEJsb2NrPG86cD48L286cD48L3NwYW4+PC9o ND4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQSBSUkVR IGNvbnRhaW5zIHR3byBBZGRyZXNzZXMsIE9yaWdBZGRyIGFuZCBUYXJnQWRkciwgYW5kIGVhY2g8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgaGFzIGFuIGFzc29jaWF0ZWQgcHJl Zml4IGxlbmd0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IERhdGEg RWxlbWVudHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBBZGRyZXNzIEJsb2NrJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgT3JpZ0FkZHIvT3JpZ1ByZWZpeExlbiZuYnNwOyB8ICZs dDthZGRyZXNzJmd0OyAmIzQzOyAmbHQ7cHJlZml4LWxlbmd0aCZndDsgJm5ic3A7fDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBUYXJn QWRkci9UYXJnUHJlZml4TGVuJm5ic3A7IHwgJmx0O2FkZHJlc3MmZ3Q7ICYjNDM7ICZsdDtwcmVm aXgtbGVuZ3RoJmd0OyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQz Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5XZSBjYW4gaW5mZXIgdGhlIE9yaWdBZGRyIGJ5IHRoZSBUTFYgdHlwZSBP UklHX1NFUV9OVU0uIEhvd2V2ZXIsIHRoZSBvbmx5IGFkZHJlc3MgYmxvY2sgVExWIGZvciBUYXJn QWRkciAoVGFyZ1NlcU51bSkgaXMgb3B0aW9uYWwuIEl0IG1lYW5zIGlmIHdlIGRvbid0IGhhdmUg dGhlIFRhcmdTZXFOdW0gVExWLCBhY2NvcmRpbmcgdG8gUkZDNTQ0NCwgd2Ugd29uJ3QgYmUgYWJs ZSB0byBrbm93IHdoYXQncyB0aGUgVGFyZ0FkZHIuIDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+YmVzdDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Smlhemk8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBN YXkgMTMsIDIwMTUgYXQgNzoxMyBQTSwgTG90dGUgU3RlZW5icmluayAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlIiB0YXJnZXQ9Il9ibGFuayI+bG90dGUu c3RlZW5icmlua0BmdS1iZXJsaW4uZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIGFsbCw8YnI+DQpGWUksIGRyYWZ0LWlldGYtbWFuZXQtYW9k dnYyLTA5LCB3aGljaCBjaGFybGllIGp1c3QgcHVibGlzaGVkLCBhZGRyZXNzZXMgYWxsIGNvbW1l bnRzIG1hZGUgaW4gdGhpcyB0aHJlYWQuIEFueSBmZWVkYmFjayBpcyB2ZXJ5IHdlbGNvbWUhPGJy Pg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpMb3R0ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBbSAxMy4wNS4yMDE1IHVtIDE2OjMzIHNjaHJp ZWIgRGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpcy5k ZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPC9hPiZndDs6PGJyPg0KPGJyPg0KJmd0OyBJIGRvbid0IGhhdmUgdGltZSB0 byBsb29rIGF0IHRoaXMgdG9kYXksIGJ1dCBIZW5uaW5nJ3Mgc3VnZ2VzdGlvbiBsb29rcyBnb29k Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBDaHJpc3RvcGhlciBEZWFybG92ZTxi cj4NCiZndDsgU2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCiZndDsgQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2U8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 Ozxicj4NCiZndDsgVDombmJzcDsgPGEgaHJlZj0idGVsOiUyQjQ0JTIwJTI4MCUyOTEyNDUlMjAy NDIxOTQiIHRhcmdldD0iX2JsYW5rIj4mIzQzOzQ0ICgwKTEyNDUgMjQyMTk0PC9hPiZuYnNwOyB8 Jm5ic3A7IEU6DQo8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20i IHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT48YnI+DQom Z3Q7PGJyPg0KJmd0OyBCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1zZm9y ZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00yIDhI Ti48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdl dD0iX2JsYW5rIj53d3cuYmFlc3lzdGVtcy5jb20vYWk8L2E+PGJyPg0KJmd0OyBCQUUgU3lzdGVt cyBBcHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KJmd0OyBSZWdpc3RlcmVkIGluIEVu Z2xhbmQgJmFtcDsgV2FsZXMgTm86IDAxMzM3NDUxPGJyPg0KJmd0OyBSZWdpc3RlcmVkIE9mZmlj ZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsgRnJvbTogSGVubmluZyBSb2dnZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpocm9nZ2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHJvZ2dlQGdtYWlsLmNvbTwvYT5d PGJyPg0KJmd0OyBTZW50OiAxMyBNYXkgMjAxNSAxNToxMTxicj4NCiZndDsgVG86IExvdHRlIFN0 ZWVuYnJpbms8YnI+DQomZ3Q7IENjOiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKTsgPGEgaHJl Zj0ibWFpbHRvOm1hbmV0QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQptYW5ldEBpZXRmLm9y ZzwvYT48YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHRyYW5zbGF0aW9u IHRhYmxlczxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0hIFdBUk5J TkcgISAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20g b3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVy IG9yIGZyb20gdGhlIGludGVybmV0Ljxicj4NCiZndDsgQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRo ZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9y IHJlcGx5Ljxicj4NCiZndDsgRm9sbG93IHRoZSAnUmVwb3J0IFN1c3BpY2lvdXMgRW1haWxzJyBs aW5rIG9uIElUIG1hdHRlcnMgZm9yIGluc3RydWN0aW9ucyBvbiByZXBvcnRpbmcgc3VzcGljaW91 cyBlbWFpbCBtZXNzYWdlcy48YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBN YXkgMTMsIDIwMTUgYXQgMzo1NSBQTSwgTG90dGUgU3RlZW5icmluayAmbHQ7PGEgaHJlZj0ibWFp bHRvOmxvdHRlLnN0ZWVuYnJpbmtAZnUtYmVybGluLmRlIiB0YXJnZXQ9Il9ibGFuayI+bG90dGUu c3RlZW5icmlua0BmdS1iZXJsaW4uZGU8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyBIaSBD aHJpc3RvcGhlciw8YnI+DQomZ3Q7Jmd0OyB0aGFua3MgZm9yIHlvdXIgZmVlZGJhY2suPGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbSAwNy4wNS4yMDE1IHVtIDEyOjAwIHNjaHJpZWIgRGVh cmxvdmUsIENocmlzdG9waGVyIChVSyk8YnI+DQomZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb208L2E+Jmd0Ozo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IFRoZXJlIGlzIGEgc3R5bGUgcXVlc3Rpb24gdGhhdCBhbGwgZXhpc3RpbmcgVExWcyBoYXZlIG5h bWVzIGxpa2U8YnI+DQomZ3Q7Jmd0OyBMSU5LX1NUQVRVUywgd2hpbGUgaGVyZSBUTFZzIGhhdmUg bmFtZXMgbGlrZSBPcmlnU2VxTnVtLiBJIGRvbuKAmXQgdGhpbms8YnI+DQomZ3Q7Jmd0OyBJQU5B IGVuZm9yY2Ugc3VjaCBpc3N1ZXMsIGFuZCBkaWZmZXJlbnQgcGVvcGxlIHdpbGwgaGF2ZSBkaWZm ZXJlbnQ8YnI+DQomZ3Q7Jmd0OyBvcGluaW9ucyBvbiB0aGUgaW1wb3J0YW5jZSBvZiBjb25zaXN0 ZW50IHN0eWxlLiAoTmFtaW5nIGNhbiBtYXR0ZXIsPGJyPg0KJmd0OyZndDsgd2XigJlyZSBzcGVu ZGluZyBjeWNsZXMgb24gYW4gSUQganVzdCBhYm91dCBUTFYgbmFtZXMuKTxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEFic29sdXRlbHkuIElu IHlvdXIgb3Bpbmlvbiwgd291bGQgaXQgc3VmZmljZSB0byBhZGp1c3QgdGhlIGN1cnJlbnQ8YnI+ DQomZ3Q7Jmd0OyBuYW1lcyBzdHlsaXN0aWNhbGx5IChzZWUgYXR0YWNoZWQgZmlsZSksIG9yIGRv IHNvbWUgbmFtZXMgbmVlZCBleHRyYTxicj4NCiZndDsmZ3Q7IHdvcmsgaW4gdGVybXMgb2YgY2xh cmlmaWNhdGlvbiBvciBjb25zaXN0ZW5jeT8gKEkgd2FzIGp1c3Qgd29uZGVyaW5nPGJyPg0KJmd0 OyZndDsgaWYgTUVUUklDIHNob3VsZCBiZSBlZGl0ZWQgdG8gbWFrZSBjbGVhciB0aGF0IGl0IGlz IG5vdCBkaXJlY3RseTxicj4NCiZndDsmZ3Q7IHJlbGF0ZWQgdG8gTElOS19NRVRSSUMuLi4pPGJy Pg0KJmd0Ozxicj4NCiZndDsgTWF5YmUgdGhlIG5hbWUgJnF1b3Q7UEFUSF9NRVRSSUMmcXVvdDsg d291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIG5ldyBUTFYuLi4gdGhpcyBkZXNjcmliZXMgdGhlIHVz YWdlIG9mIHRoZSBUTFYgdmVyeSB3ZWxsLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhlbm5pbmcgUm9n Z2U8YnI+DQomZ3Q7ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCB0byB0aGUgaW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lw aWVudCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkPGJyPg0KJmd0OyByZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVt IGFuZCBub3RpZnkgdGhlIHNlbmRlci48YnI+DQomZ3Q7IFlvdSBzaG91bGQgbm90IGNvcHkgaXQg b3IgdXNlIGl0IGZvciBhbnkgcHVycG9zZSBub3IgZGlzY2xvc2Ugb3I8YnI+DQomZ3Q7IGRpc3Ry aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uPGJyPg0KJmd0OyAqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbWFuZXQgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm1hbmV0 QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1hbmV0IG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzptYW5ldEBpZXRmLm9yZyI+bWFuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWFuZXQ8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC628GLKXM0002VGREEN_-- From nobody Wed May 27 04:28:49 2015 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 48CA71ACDF9; Wed, 27 May 2015 04:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4HSxzDB7fBsj; Wed, 27 May 2015 04:28:45 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696A51ACDD4; Wed, 27 May 2015 04:28:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 06F13240443; Wed, 27 May 2015 04:28:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from [192.168.147.66] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 70E592402EA; Wed, 27 May 2015 04:28:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Heide Clausen X-Mailer: iPhone Mail (12F70) In-Reply-To: Date: Wed, 27 May 2015 13:28:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <088EB6F6-14D4-44F9-A34B-4A743C2C048A@thomasclausen.org> References: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> To: "Dearlove, Christopher (UK)" Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "manet@ietf.org" , Barry Leiba , The IESG , "manet-chairs@ietf.org" Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) 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, 27 May 2015 11:28:47 -0000 Confirm that we just want to "do the right thing" and are taking advice from= the IESG on what that is. And will implement it.=20 I am officially on vacation this week - but, as you can see, can't keep away= from mails. I am fully back in the salt mines come Monday.=20 Thomas --=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 27 mai 2015, at 12:51, Dearlove, Christopher (UK) wrote: >=20 > It's a philosophy question, what does updates mean? Is there a formal RFC E= ditor definition? This does, at the least, update IANA registries establishe= d by 7181 and I think 7188 and XXXX (draft-ietf-manet-tlv-naming that we exp= ect to be an RFC before or with this). >=20 > But honestly, I and co-author don't care one way or the other, if the IESG= picks an answer, we'll implement it. I will probably have to let my co-auth= or handle the mechanics of this, I may be unavailable shortly for at least a= week. >=20 > --=20 > Christopher Dearlove > Senior Principal Engineer > BAE Systems Applied Intelligence > __________________________________________________________________________= >=20 > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >=20 > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow= , Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >=20 >=20 > -----Original Message----- > From: Barry Leiba [mailto:barryleiba@computer.org]=20 > Sent: 26 May 2015 18:28 > To: The IESG > Cc: manet-chairs@ietf.org; draft-ietf-manet-olsrv2-multitopology@ietf.org;= manet@ietf.org > Subject: Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopolo= gy-05: (with COMMENT) >=20 > ----------------------! WARNING ! ---------------------- This message orig= inates 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 attachm= ents or reply. > Follow the 'Report Suspicious Emails' link on IT matters for instructions o= n reporting suspicious email messages. > -------------------------------------------------------- >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-manet-olsrv2-multitopology-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all emai= l addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Let's please have a brief, non-blocking discussion of the "updates" > status here. As I read this, I don't see how this updates either 7181 or 7= 188. It clearly doesn't update 7188: it's just using an extension mechanism= that was specified in 7188. I also don't think it updates 7181, because it= 's specifying an optional (indeed, experimental) extension. Here: does some= one reading 7181, with no interest in implementing this experimental extensi= on, need to read (or even know > about) this document? I think the answer is no. >=20 > (There's also the spurious "XXXX" in the updates list, which should be > removed.) >=20 >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** From nobody Wed May 27 04:35:29 2015 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 A60971ACE24 for ; Wed, 27 May 2015 04:35:28 -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 iPmLHPbm8FwV for ; Wed, 27 May 2015 04:35:26 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B82311ACE1B for ; Wed, 27 May 2015 04:35:25 -0700 (PDT) Received: by wizo1 with SMTP id o1so18477585wiz.1 for ; Wed, 27 May 2015 04:35: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:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=lEP3Pjjw7e9rGC30TWwoUPS4aN9cWtzx/PbqS/T1Wnc=; b=j95n4vNa3dQ+YY+e+7F0aO4jQcOyGqb9mTgiaw8u9wrAYMyvCC5ujni6/+zkS8FybU MVbiTNdn60IWDtat/Maqupb+xpyXMaIDmhN5Q41+RFgDi7DBRk/cOB/Rh5MXcg7Uc1xj kZX/Gd75e+Lr78pgiEt1TZHfBhpHNsdimUPxSFQuaPkRJQmwZs9jGOhDiwT/ae2ax3yc lwLcxmF5DDdl0mOQHm48+pMSc0+HPzLow5NrImqKZD0/iBT8wwZfZwqee5BD3KHDAuFW M3Kmua6I5HT/rGDnkCUU2+weBkJ4y+E6BIchhCZZxd3rnCgmbJbnwE/hQH5aNY+JhAHR otHg== X-Received: by 10.180.88.99 with SMTP id bf3mr49988377wib.75.1432726523496; Wed, 27 May 2015 04:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Wed, 27 May 2015 04:35:02 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> From: Henning Rogge Date: Wed, 27 May 2015 13:35:02 +0200 Message-ID: To: Victoria Mercieca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 11:35:28 -0000 Hi, there is one major and one minor problem with "no TLVs attached to address"= . The minor problem is that it forces the AODV2 parser to be aware of ALL possible TLVs. Normally each protocol does only need to care about the TLVs it uses itself, but in this case you need to make sure there is no other unknown TLV. The major problem is that the "no TLV" mechanism blocks any extension related to the address. What if we want a cryptographic signature attached to RERR unreachable addresses in the future? Or some other additional data? This would force a break of compatibility with the current draft. Because of these two reasons the protocol should always have a TLV that gives an address a meaning, this way it can ignore any unknown TLVs attached to the address AND ignore addresses which have no known TLVs, which makes extensions much easier. Henning Rogge On Wed, May 27, 2015 at 11:23 AM, Victoria Mercieca wrote: > Hi Jiazi, and thanks for your comments, > > This is part of an ongoing discussion. The current draft implies that > because there are two addresses in a RREQ, then if one is marked as OrigA= ddr > by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the other addre= ss > must be TargAddr. i.e in a RREQ, we can interpret an address without an > associated TLV as TargAddr. By doing it this way, we save the length of t= he > TLV we might have associated with TargAddr. Further, this applied to othe= r > messages - the meaning of an unmarked address is deduced from the message > type. For RREP, an address without an associated TLV is OrigAddr. For RER= R, > all unmarked addresses are unreachable destinations. In RERR, we mark the > PktSource address with its own PktSource (PKT_SOURCE) TLV to differentiat= e > from the unreachable addresses. > > If in future, we decided to add an new type of address into a message for > some reason, that address MUST have a TLV associated with it to > differentiate. That makes sense anyway, we would want to indicate what th= e > new address means. > > The question is, is this acceptable? If not, maybe we have to accept addi= ng > a TLV to each of these messages so that there are no addresses without > associated any Address Block TLVs. > > Also, the order of addresses in the Address Block doesn't matter in eithe= r > case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section= 8, > page 46): > "The addresses in an Address Block may appear in any order, and values > in an Address Block TLV must be associated with the correct address > in the Address Block. To indicate which address each value is > associated with, the AODVv2 message representation uses lists where > the order of the addresses in the AddressList matches the order of > values in the other lists, e.g., SeqNumList in a RERR." > Is this unclear? > > Kind regards, > Victoria. > > > On Tue, May 26, 2015 at 12:19 AM, Jiazi YI wrote: >> >> If I understand well, we still need the existence and the order in the >> address block, to identify the usage of addresses? >> >> For example, section 8.1: >> >> 8.1.3. Address Block >> >> A RREQ contains two Addresses, OrigAddr and TargAddr, and each >> address has an associated prefix length. >> >> +-------------------------+------------------------------+ >> | Data Elements | Address Block | >> +-------------------------+------------------------------+ >> | OrigAddr/OrigPrefixLen |
+ | >> | TargAddr/TargPrefixLen |
+ | >> +-------------------------+------------------------------+ >> >> >> We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the onl= y >> address block TLV for TargAddr (TargSeqNum) is optional. It means if we >> don't have the TargSeqNum TLV, according to RFC5444, we won't be able to >> know what's the TargAddr. >> >> >> best >> >> >> Jiazi >> >> >> >> >> On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink >> wrote: >>> >>> Hi all, >>> FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresse= s >>> all comments made in this thread. Any feedback is very welcome! >>> >>> Regards, >>> Lotte >>> >>> Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) >>> : >>> >>> > I don't have time to look at this today, but Henning's suggestion loo= ks >>> > good. >>> > >>> > -- >>> > Christopher Dearlove >>> > Senior Principal Engineer >>> > BAE Systems Applied Intelligence >>> > >>> > _____________________________________________________________________= _____ >>> > >>> > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com >>> > >>> > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great >>> > Baddow, Chelmsford, Essex CM2 8HN. >>> > www.baesystems.com/ai >>> > BAE Systems Applied Intelligence Limited >>> > Registered in England & Wales No: 01337451 >>> > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: Henning Rogge [mailto:hrogge@gmail.com] >>> > Sent: 13 May 2015 15:11 >>> > To: Lotte Steenbrink >>> > Cc: Dearlove, Christopher (UK); manet@ietf.org >>> > Subject: Re: [manet] RFC 5444 translation tables >>> > >>> > ----------------------! WARNING ! ---------------------- This message >>> > originates from outside our organisation, either from an external par= tner 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. >>> > -------------------------------------------------------- >>> > >>> > On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink >>> > wrote: >>> >> Hi Christopher, >>> >> thanks for your feedback. >>> >> >>> >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) >>> >> : >>> >> >>> >> There is a style question that all existing TLVs have names like >>> >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2=80= =99t think >>> >> IANA enforce such issues, and different people will have different >>> >> opinions on the importance of consistent style. (Naming can matter, >>> >> we=E2=80=99re spending cycles on an ID just about TLV names.) >>> >> >>> >> >>> >> >>> >> Absolutely. In your opinion, would it suffice to adjust the current >>> >> names stylistically (see attached file), or do some names need extra >>> >> work in terms of clarification or consistency? (I was just wondering >>> >> if METRIC should be edited to make clear that it is not directly >>> >> related to LINK_METRIC...) >>> > >>> > Maybe the name "PATH_METRIC" would make sense for the new TLV... this >>> > describes the usage of the TLV very well. >>> > >>> > Henning Rogge >>> > ******************************************************************** >>> > This email and any attachments are confidential to the intended >>> > recipient and may also be privileged. If you are not the intended >>> > recipient please delete it from your system and notify the sender. >>> > You should not copy it or use it for any purpose nor disclose or >>> > distribute its contents to any other person. >>> > ******************************************************************** >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www.ietf.org/mailman/listinfo/manet >> >> >> >> _______________________________________________ >> 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 27 04:55:40 2015 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 EBF0B1ACE48; Wed, 27 May 2015 04:55:34 -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 ZG68D109psfp; Wed, 27 May 2015 04:55:32 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD6381ACE1E; Wed, 27 May 2015 04:55:31 -0700 (PDT) Received: by iebgx4 with SMTP id gx4so11343413ieb.0; Wed, 27 May 2015 04:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kXRNjHx2jk/VnBA9cKlMhruVzZMMX/2z/ggkPEYDciM=; b=cCGdz69nW3i5ymAFsuHFtoOVH00QCp6HRAlhfQRYFRaweiRq69wvk58ziSBlECkHhH 7K7pwsefO+uLV7K+CY1a1YGgUi4MyRqlFxzC4ySU926CkNZyPpnN4xIlLVogVueVE7a3 MtmNLFCAvUdIRkdkedd548q5zwszfHN8F9jARbeDfgwnuxgpgKPqeXDsAbcKPVUQnl8S Gy9sq3yjY6IfrZCNtfKHgjWouLOop/JpDovlguOU57jDhsJ3SnG2Prej4wXDGpsg9moq 71TAoOyY60BT9apJcMBhQVH1XdeVK9gAtV6XYQcQ1XnjrOOZOBC9nejJQXO4BVfUNEPG 2A5A== MIME-Version: 1.0 X-Received: by 10.42.146.202 with SMTP id k10mr2908444icv.34.1432727731276; Wed, 27 May 2015 04:55:31 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Wed, 27 May 2015 04:55:31 -0700 (PDT) In-Reply-To: <088EB6F6-14D4-44F9-A34B-4A743C2C048A@thomasclausen.org> References: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> <088EB6F6-14D4-44F9-A34B-4A743C2C048A@thomasclausen.org> Date: Wed, 27 May 2015 07:55:31 -0400 X-Google-Sender-Auth: gXAQeCsSdrToza0xQLbeP_xZw8Y Message-ID: From: Barry Leiba To: Thomas Heide Clausen Content-Type: multipart/alternative; boundary=90e6ba6e8e9c7b93a505170eeb8d Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "Dearlove, Christopher \(UK\)" , "manet@ietf.org" , The IESG , "manet-chairs@ietf.org" Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) 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, 27 May 2015 11:55:35 -0000 --90e6ba6e8e9c7b93a505170eeb8d Content-Type: text/plain; charset=UTF-8 I know what you mean about "can't keep away". :-) Ok, thanks, both, for the responses. We'll figure this minor thing out in the IESG, and no need for you to waste more time thinking about it. Barry On Wednesday, May 27, 2015, Thomas Heide Clausen wrote: > Confirm that we just want to "do the right thing" and are taking advice > from the IESG on what that is. And will implement it. > > I am officially on vacation this week - but, as you can see, can't keep > away from mails. I am fully back in the salt mines come Monday. > > Thomas > > > -- > 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 27 mai 2015, at 12:51, Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com > wrote: > > > > It's a philosophy question, what does updates mean? Is there a formal > RFC Editor definition? This does, at the least, update IANA registries > established by 7181 and I think 7188 and XXXX (draft-ietf-manet-tlv-naming > that we expect to be an RFC before or with this). > > > > But honestly, I and co-author don't care one way or the other, if the > IESG picks an answer, we'll implement it. I will probably have to let my > co-author handle the mechanics of this, I may be unavailable shortly for at > least a week. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer > > BAE Systems Applied Intelligence > > > __________________________________________________________________________ > > > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > -----Original Message----- > > From: Barry Leiba [mailto:barryleiba@computer.org ] > > Sent: 26 May 2015 18:28 > > To: The IESG > > Cc: manet-chairs@ietf.org ; > draft-ietf-manet-olsrv2-multitopology@ietf.org ; > manet@ietf.org > > Subject: Barry Leiba's No Objection on > draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) > > > > ----------------------! 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. > > -------------------------------------------------------- > > > > Barry Leiba has entered the following ballot position for > > draft-ietf-manet-olsrv2-multitopology-05: No Objection > > > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Let's please have a brief, non-blocking discussion of the "updates" > > status here. As I read this, I don't see how this updates either 7181 > or 7188. It clearly doesn't update 7188: it's just using an extension > mechanism that was specified in 7188. I also don't think it updates 7181, > because it's specifying an optional (indeed, experimental) extension. > Here: does someone reading 7181, with no interest in implementing this > experimental extension, need to read (or even know > > about) this document? I think the answer is no. > > > > (There's also the spurious "XXXX" in the updates list, which should be > > removed.) > > > > > > ******************************************************************** > > 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. > > ******************************************************************** > > --90e6ba6e8e9c7b93a505170eeb8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I know what you mean about "can't keep away". =C2=A0:-)
O= k, thanks, both, for the responses.=C2=A0 We'll figure this minor thing= out in the IESG, and no need for you to waste more time thinking about it.=

Barry

On Wednesday, May 27, 2015, Thomas H= eide Clausen <thomas@thomasc= lausen.org> wrote:
Confirm that we= just want to "do the right thing" and are taking advice from the= IESG on what that is. And will implement it.

I am officially on vacation this week - but, as you can see, can't keep= away from mails. I am fully back in the salt mines come Monday.

Thomas


--
Thomas Heide Clausen
http://www.thoma= sclausen.org

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

> On 27 mai 2015, at 12:51, Dearlove, Christopher (UK) <chris.dearlove@baesystems.com> wrote:
>
> It's a philosophy question, what does updates mean? Is there a for= mal RFC Editor definition? This does, at the least, update IANA registries = established by 7181 and I think 7188 and XXXX (draft-ietf-manet-tlv-naming = that we expect to be an RFC before or with this).
>
> But honestly, I and co-author don't care one way or the other, if = the IESG picks an answer, we'll implement it. I will probably have to l= et my co-author handle the mechanics of this, I may be unavailable shortly = for at least a week.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> ______________________________________________________________________= ____
>
> T:=C2=A0 +44 (0)1245 242194=C2=A0 |=C2=A0 E: chris.dearlove@baesystems.com
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN.
> www.baesyst= ems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >
>
> -----Original Message-----
> From: Barry Leiba [mailto:barryleiba@computer.o= rg]
> Sent: 26 May 2015 18:28
> To: The IESG
> Cc: manet-chairs@ietf.org; draft-ietf-manet-olsrv2-multitopology@ietf.org<= /a>; manet@ietf.org
> Subject: Barry Leiba's No Objection on draft-ietf-manet-olsrv2-mul= titopology-05: (with COMMENT)
>
> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external partner o= r from the internet.
> Consider carefully whether you should click on any links, open any att= achments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for i= nstructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-manet-olsrv2-multitopology-05: No Objection
>
> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this int= roductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discu= ss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf= -manet-olsrv2-multitopology/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Let's please have a brief, non-blocking discussion of the "up= dates"
> status here.=C2=A0 As I read this, I don't see how this updates ei= ther 7181 or 7188.=C2=A0 It clearly doesn't update 7188: it's just = using an extension mechanism that was specified in 7188.=C2=A0 I also don&#= 39;t think it updates 7181, because it's specifying an optional (indeed= , experimental) extension.=C2=A0 Here: does someone reading 7181, with no i= nterest in implementing this experimental extension, need to read (or even = know
> about) this document?=C2=A0 I think the answer is no.
>
> (There's also the spurious "XXXX" in the updates list, w= hich should be
> removed.)
>
>
> ******************************************************************** > 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.
> ********************************************************************
--90e6ba6e8e9c7b93a505170eeb8d-- From nobody Wed May 27 05:51:24 2015 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 833D11A8869 for ; Wed, 27 May 2015 05:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 VPy3CMfM4SqN for ; Wed, 27 May 2015 05:51:14 -0700 (PDT) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515521A8868 for ; Wed, 27 May 2015 05:51:13 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so6446119lbc.1 for ; Wed, 27 May 2015 05:51:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ss2+xRpgrE3dkzzJE28gHVTrnMPvxRh69sgE8tEzdtk=; b=yA7fPZY7YP0fB9ax1UxhjDZGqli4kGM4F5iS1CWLHk4Ya3dotxMajBlU/2O0h9vyDU 9ahof0xudH7b90lQpNWLPjHOMKZBlV3C/KR6Q2Ib9G64QAST02OIbkgejItw4P+P/fHD R8VljOK65AJJANW6xz//AycaFw9xT/34eXGSD3m/ECrUMKOrSze/OfXmA8CpahydY1jS WTk8Znl+ndK+MTIvZoXt8V0mpH0RKHBtd3bbT2kooStPEtQrZFuymAWRBKdTlGWNL9EE 2Me55wzKNcJziNVoGmG/YZrwFihc4YWxwjOXrOPlgmWd3iN/cl4JSMcie+Rq4oqHOclP PIfQ== MIME-Version: 1.0 X-Received: by 10.152.8.6 with SMTP id n6mr27954752laa.116.1432731071797; Wed, 27 May 2015 05:51:11 -0700 (PDT) Received: by 10.112.252.4 with HTTP; Wed, 27 May 2015 05:51:11 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> Date: Wed, 27 May 2015 13:51:11 +0100 Message-ID: From: Victoria Mercieca To: "Dearlove, Christopher (UK)" Content-Type: multipart/alternative; boundary=001a11c3534a97df2d05170fb228 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 12:51:17 -0000 --001a11c3534a97df2d05170fb228 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for your comments also. On Wed, May 27, 2015 at 12:00 PM, Dearlove, Christopher (UK) < chris.dearlove@baesystems.com> wrote: > Actually, you save I think two bytes not having a target address. For > significant loss of extensibility. > > > > Two bytes? > > > > Currently you can have a valueless TLV. It needs a single address index, > no length or value. > Instead you can have a TLV with two values for the two address types. > Using a multivalue TLV it needs no indices, a single byte length (2) and > two value bytes. > > Like an "address meaning" TLV? And using just one of these TLVs in each message, mark each address in the address block? I've just found Section C2 in RFC5444 - Assume the definition of an Address Block TLV with type EXAMPLE1 (and no type extension) that has single octet values per address. There are a number of ways in which values a, a, b, and c may be associated with the four addresses in the preceding Address Block, where c is a default value that can be omitted. Examples: Using one multivalue TLV to cover all of the addresses: * has thasvalue and tismultivalue set (value 20); * and are omitted; * =3D 4 (single-length =3D 1). * The TLV is then EXAMPLE1 20 4 a a b c (7 octets). So we would define values a b c d, where "a" represents OrigAddr, "b" represents TargAddr, "c" represents an unreachable address in RERR, and "d" represents a PktSource address? Then separately add TLVs relating to metrics, sequence numbers, etc.? ...and we wouldnt need three kinds of SEQ_NUM TLV for this, we could just use SEQ_NUM, and have multi-values if necessary. Did I understand that correctly? Kind regards, Victoria. > > Extensibility? You can add additional addresses with other meanings in > future extensions. You can use the 254 unallocated (or 253, having an > UNSPECIFIED value of 255 as in RFC 7188 is also a good idea) values for > this in some cases. > > > > It is also compatible with existing generic 5444 parsers approaches. > > > > *-- * > > > > > *Christopher Dearlove Senior Principal Engineer BAE Systems Applied > Intelligence * > *________________________________________________________________________= __ > * > *T*: +44 (0)1245 242194 | *E: *chris.dearlove@baesystems.com > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > *From:* manet [mailto:manet-bounces@ietf.org] *On Behalf Of *Victoria > Mercieca > *Sent:* 27 May 2015 10:24 > *To:* Jiazi YI > *Cc:* manet > *Subject:* Re: [manet] RFC 5444 translation tables > > > > > > **** WARNING **** > > *This message originates from outside our organisation, either from an > external partner or the internet.* > > * Consider carefully whether you should click on any links, open any > attachments or reply. For information regarding **Red Flags** that you > can look out for in emails you receive, click here > .* > * If you feel the email is suspicious, please follow this process > .* > > Hi Jiazi, and thanks for your comments, > > > > This is part of an ongoing discussion. The current draft implies that > because there are two addresses in a RREQ, then if one is marked as > OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TLV, the > other address must be TargAddr. i.e in a RREQ, we can interpret an addres= s > without an associated TLV as TargAddr. By doing it this way, we save the > length of the TLV we might have associated with TargAddr. Further, this > applied to other messages - the meaning of an unmarked address is deduced > from the message type. For RREP, an address without an associated TLV is > OrigAddr. For RERR, all unmarked addresses are unreachable destinations. = In > RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE) T= LV > to differentiate from the unreachable addresses. > > > > If in future, we decided to add an new type of address into a message for > some reason, that address MUST have a TLV associated with it to > differentiate. That makes sense anyway, we would want to indicate what th= e > new address means. > > > > The question is, is this acceptable? If not, maybe we have to accept > adding a TLV to each of these messages so that there are no addresses > without associated any Address Block TLVs. > > > > Also, the order of addresses in the Address Block doesn't matter in eithe= r > case. AODVv2 draft 9 says, in the RFC5444 Representation Section (Section > 8, page 46): > > "The addresses in an Address Block may appear in any order, and values > > in an Address Block TLV must be associated with the correct address > > in the Address Block. To indicate which address each value is > > associated with, the AODVv2 message representation uses lists where > > the order of the addresses in the AddressList matches the order of > > values in the other lists, e.g., SeqNumList in a RERR." > > Is this unclear? > > > > Kind regards, > > Victoria. > > > > > > On Tue, May 26, 2015 at 12:19 AM, Jiazi YI wrote: > > If I understand well, we still need the existence and the order in the > address block, to identify the usage of addresses? > > > > For example, section 8.1: > > > 8.1.3 > . > Address Block > > > > > > A RREQ contains two Addresses, OrigAddr and TargAddr, and each > > address has an associated prefix length. > > > > +-------------------------+------------------------------+ > > | Data Elements | Address Block | > > +-------------------------+------------------------------+ > > | OrigAddr/OrigPrefixLen |
+ | > > | TargAddr/TargPrefixLen |
+ | > > +-------------------------+------------------------------+ > > > > We can infer the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only= address block TLV for TargAddr (TargSeqNum) is optional. It means if we do= n't have the TargSeqNum TLV, according to RFC5444, we won't be able to know= what's the TargAddr. > > > > best > > > > Jiazi > > > > > > > > On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink < > lotte.steenbrink@fu-berlin.de> wrote: > > Hi all, > FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses > all comments made in this thread. Any feedback is very welcome! > > Regards, > Lotte > > > Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) < > chris.dearlove@baesystems.com>: > > > I don't have time to look at this today, but Henning's suggestion looks > good. > > > > -- > > Christopher Dearlove > > Senior Principal Engineer > > BAE Systems Applied Intelligence > > > _________________________________________________________________________= _ > > > > T: +44 (0)1245 242194 | E: chris.dearlove@baesystems.com > > > > BAE Systems Applied Intelligence, Chelmsford Technology Park, Great > Baddow, Chelmsford, Essex CM2 8HN. > > www.baesystems.com/ai > > BAE Systems Applied Intelligence Limited > > Registered in England & Wales No: 01337451 > > Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP > > > > > > > > -----Original Message----- > > From: Henning Rogge [mailto:hrogge@gmail.com] > > Sent: 13 May 2015 15:11 > > To: Lotte Steenbrink > > Cc: Dearlove, Christopher (UK); manet@ietf.org > > Subject: Re: [manet] RFC 5444 translation tables > > > > ----------------------! 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. > > -------------------------------------------------------- > > > > On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink < > lotte.steenbrink@fu-berlin.de> wrote: > >> Hi Christopher, > >> thanks for your feedback. > >> > >> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK) > >> : > >> > >> There is a style question that all existing TLVs have names like > >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2=80= =99t think > >> IANA enforce such issues, and different people will have different > >> opinions on the importance of consistent style. (Naming can matter, > >> we=E2=80=99re spending cycles on an ID just about TLV names.) > >> > >> > >> > >> Absolutely. In your opinion, would it suffice to adjust the current > >> names stylistically (see attached file), or do some names need extra > >> work in terms of clarification or consistency? (I was just wondering > >> if METRIC should be edited to make clear that it is not directly > >> related to LINK_METRIC...) > > > > Maybe the name "PATH_METRIC" would make sense for the new TLV... this > describes the usage of the TLV very well. > > > > Henning Rogge > > ******************************************************************** > > This email and any attachments are confidential to the intended > > recipient and may also be privileged. If you are not the intended > > recipient please delete it from your system and notify the sender. > > You should not copy it or use it for any purpose nor disclose or > > distribute its contents to any other person. > > ******************************************************************** > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > > > --001a11c3534a97df2d05170fb228 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,

Thanks for your comments also= .=C2=A0

On Wed= , May 27, 2015 at 12:00 PM, Dearlove, Christopher (UK) &l= t;chris.= dearlove@baesystems.com> wrote:

Actually, you save I think two bytes not hav= ing a target address. For significant loss of extensibility.<= /span>

=C2=A0

Two bytes?

=C2=A0

Currently you can have a valueless TLV. It n= eeds a single address index, no length or value.


<= /p>

Instead you can have a TLV with two values f= or the two address types. Using a multivalue TLV it needs no indices, a sin= gle byte length (2) and two value bytes.

<= div>
Like an "address meaning" TLV? And using just = one of these TLVs in each message, mark each address in the address block? = I've just found Section C2 in RFC5444 -=C2=A0

= 
Assume the definition of an Address Block TLV with type EXAM=
PLE1 (and
   no type extension) that has single octet values per address.  There
   are a number of ways in which values a, a, b, and c may be associated
   with the four addresses in the preceding Address Block, where c is a
   default value that can be omitted.

   Examples:
   Using one multivalue TLV to =
cover all of the addresses:
      *  <tlv-flags> has thasvalue and tismultivalue set (value 20);
      *  <index-start> and <index-stop> are omitted;
      *  <length> =3D 4 (single-length =3D 1).
      *  The TLV is then EXAMPLE1 20 4 a a b c (7 octets).

So we would define values a b c d, where "a&qu=
ot; represents OrigAddr, "b" represents TargAddr, "c" r=
epresents an unreachable address in RERR, and "d" represents a Pk=
tSource address?
<=
br>
Then separatel=
y add TLVs relating to metrics, sequence numbers, etc.? ...and we wouldnt n=
eed three kinds of SEQ_NUM TLV for this, we could just use SEQ_NUM, and hav=
e multi-values if necessary.

Did I understand that correctly?

Kind regards,
Victoria.

=C2=A0=

Extensibility? You can add additional addres= ses with other meanings in future extensions. You can use the 254 unallocat= ed (or 253, having an UNSPECIFIED value of 255 as in RFC 7188 is also a good idea) values for this in some cases.<= u>

=C2=A0

It is also compatible with existing generic = 5444 parsers approaches.

=C2=A0

--

Christopher De= arlove
Senior Principal Engineer
BAE Systems Applied Intelligence
_____________________________________________________= _____________________

T: =C2=A0+44 (0)1245 242194<= /a> =C2=A0| =C2=A0E: chri= s.dearlove@baesystems.com

BAE Systems Applied Intelligence, Chelmsford Technology Park, = Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai=

BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451

Registered Office= : Surrey Research Park, Guildford, Surrey, GU2 7YP

=C2=A0

=C2=A0

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Victoria Mercieca
Sent: 27 May 2015 10:24
To: Jiazi YI
Cc: manet
Subject: Re: [manet] RFC 5444 translation tables

=C2=A0

= =C2=A0

*** WARNING ***

This message originates from outside our organisation, either f= rom an external partner or the internet.
Consider carefully whether= you should click on any links, open any attachments or reply.<= br> For information regarding = Red Flags that you = can look out for in emails you receive, click here.
If you feel the email is s= uspicious, please follow this process.

Hi Jiazi, and thanks for your comments,

=C2=A0

This is part of an ongoing discussion. The current d= raft implies that because there are two addresses in a RREQ, then if one is= marked as OrigAddr by having an associated OrigSeqNum (or ORIG_SEQ_NUM) TL= V, the other address must be TargAddr. i.e in a RREQ, we can interpret an address without an associated TLV as Ta= rgAddr. By doing it this way, we save the length of the TLV we might have a= ssociated with TargAddr. Further, this applied to other messages - the mean= ing of an unmarked address is deduced from the message type.=C2=A0For RREP, an address without an associated TLV= is OrigAddr. For RERR, all unmarked addresses are unreachable destinations= . In RERR, we mark the PktSource address with its own PktSource (PKT_SOURCE= ) TLV to differentiate from the unreachable addresses.

=C2=A0

If in future, we decided to add an new type of addre= ss into a message for some reason, that address MUST have a TLV associated = with it to differentiate. That makes sense anyway, we would want to indicat= e what the new address means.

=C2=A0

The question is, is this acceptable? If not, maybe w= e have to accept adding a TLV to each of these messages so that there are n= o addresses without associated any Address Block TLVs.

=C2=A0

Also, the order of addresses in the Address Block do= esn't matter in either case. AODVv2 draft 9 says, in the RFC5444 Repres= entation Section (Section 8, page 46):

"The addresses in an Address Block may appear i= n any order, and values

=C2=A0 =C2=A0in an Address Block TLV must be associa= ted with the correct address

=C2=A0 =C2=A0in the Address Block.=C2=A0 To indicate= which address each value is

=C2=A0 =C2=A0associated with, the AODVv2 message rep= resentation uses lists where

=C2=A0 =C2=A0the order of the addresses in the Addre= ssList matches the order of

=C2=A0 =C2=A0values in the other lists, e.g., SeqNum= List in a RERR."

Is this unclear?

=C2=A0

Kind regards,

Victoria.

=C2=A0

=C2=A0

On Tue, May 26, 2015 at 12:19 AM, Jiazi YI <ietf@jiaziyi.com> w= rote:

If I understand well, we still need the existence an= d the order in the address block, to identify the usage of addresses?=C2=A0=

=C2=A0

For example, section 8.1:=C2=A0

=C2=A0

8.1.3.=C2=A0 Address Block

=C2=A0
=C2=A0
=C2=A0=C2=A0 A RREQ contai=
ns two Addresses, OrigAddr and TargAddr, and each

=C2=A0=C2=A0 address has a=
n associated prefix length.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +-------------------------+-----------------------------=
-+


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 | Data Elements=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 | Address Block=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +-------------------------+-----------------------------=
-+


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 | OrigAddr/OrigPrefixLen=C2=A0 | <address> + <p=
refix-length> =C2=A0|


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 | TargAddr/TargPrefixLen=C2=A0 | <address> + <p=
refix-length>=C2=A0 |


=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +-------------------------+-----------------------------=
-+


=C2=A0


We can infer =
the OrigAddr by the TLV type ORIG_SEQ_NUM. However, the only address block =
TLV for TargAddr (TargSeqNum) is optional. It means if we don't have th=
e TargSeqNum TLV, according to RFC5444, we won't be able to know what&#=
39;s the TargAddr. =



=C2=A0


best


=C2=A0


Jiazi<=
span style=3D"color:black">


=C2=A0


=C2=A0

=C2=A0

On Wed, May 13, 2015 at 7:13 PM, Lotte Steenbrink &l= t;lotte.= steenbrink@fu-berlin.de> wrote:

Hi all,
FYI, draft-ietf-manet-aodvv2-09, which charlie just published, addresses al= l comments made in this thread. Any feedback is very welcome!

Regards,
Lotte


Am 13.05.2015 um 16:33 schrieb Dearlove, Christopher (UK) <chris.dearlove@baesys= tems.com>:

> I don't have time to look at this today, but Henning's suggest= ion looks good.
>
> --
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence
> ______________________________________________________________________= ____
>
> T:=C2=A0 +44 (0)1245 242194=C2=A0 |=C2=A0 E: chris.de= arlove@baesystems.com
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Ba= ddow, Chelmsford, Essex CM2 8HN.
> www.baesyst= ems.com/ai
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP >
>
>
> -----Original Message-----
> From: Henning Rogge [mailto:hrogge@gmail.com]
> Sent: 13 May 2015 15:11
> To: Lotte Steenbrink
> Cc: Dearlove, Christopher (UK); manet@ietf.org
> Subject: Re: [manet] RFC 5444 translation tables
>
> ----------------------! WARNING ! ---------------------- This message = originates from outside our organisation, either from an external partner o= r from the internet.
> Consider carefully whether you should click on any links, open any att= achments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters for i= nstructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> On Wed, May 13, 2015 at 3:55 PM, Lotte Steenbrink <lotte.steenbrink@fu-berl= in.de> wrote:
>> Hi Christopher,
>> thanks for your feedback.
>>
>> Am 07.05.2015 um 12:00 schrieb Dearlove, Christopher (UK)
>> <chris.dearlove@baesystems.com>:
>>
>> There is a style question that all existing TLVs have names like >> LINK_STATUS, while here TLVs have names like OrigSeqNum. I don=E2= =80=99t think
>> IANA enforce such issues, and different people will have different=
>> opinions on the importance of consistent style. (Naming can matter= ,
>> we=E2=80=99re spending cycles on an ID just about TLV names.)
>>
>>
>>
>> Absolutely. In your opinion, would it suffice to adjust the curren= t
>> names stylistically (see attached file), or do some names need ext= ra
>> work in terms of clarification or consistency? (I was just wonderi= ng
>> if METRIC should be edited to make clear that it is not directly >> related to LINK_METRIC...)
>
> Maybe the name "PATH_METRIC" would make sense for the new TL= V... this describes the usage of the TLV very well.
>
> Henning Rogge
> ******************************************************************** > This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
_______________________________________________
manet mailing list
manet@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/manet

=C2=A0


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

=C2=A0


--001a11c3534a97df2d05170fb228-- From nobody Wed May 27 06:08:50 2015 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 C753B1A88E9 for ; Wed, 27 May 2015 06:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 0jvWlRrmVeet for ; Wed, 27 May 2015 06:08:43 -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 168091A88CE for ; Wed, 27 May 2015 06:08:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208,217";a="469095119" Received: from unknown (HELO baemasodc005.greenlnk.net) ([10.108.52.29]) by ukmta3.baesystems.com with ESMTP; 27 May 2015 14:08:40 +0100 X-IronPort-AV: E=Sophos;i="5.13,505,1427756400"; d="scan'208,217";a="103454625" Received: from glkxh0004v.greenlnk.net ([10.109.2.35]) by baemasodc005.greenlnk.net with ESMTP; 27 May 2015 14:08:40 +0100 Received: from GLKXM0002V.GREENLNK.net ([169.254.5.193]) by GLKXH0004V.GREENLNK.net ([10.109.2.35]) with mapi id 14.03.0224.002; Wed, 27 May 2015 14:08:40 +0100 From: "Dearlove, Christopher (UK)" To: Victoria Mercieca Thread-Topic: [manet] RFC 5444 translation tables Thread-Index: AQHQiBo0ZM63Aqka3kqbkDjZ519xRZ1wR18QgAmgdwCAAARxAIAAFrJggAAcbwCAE0I5gIACOxSAgAApwiCAABAugIAAFMXQ Date: Wed, 27 May 2015 13:08:39 +0000 Message-ID: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.62.6] Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC6ADGLKXM0002VGREEN_" MIME-Version: 1.0 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 13:08:47 -0000 --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC6ADGLKXM0002VGREEN_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGJlbGlldmUgeW91IGRpZCB1bmRlcnN0YW5kLiBJIGJlbGlldmUgdGhhdCBzaG9ydGx5 IHlvdSAoZXZlcnlvbmUpIHdpbGwgaGF2ZSBzb21lIGFkZGl0aW9uYWwgbWF0ZXJpYWwgdGhhdCBJ IGhvcGUgd2lsbCBhbHNvIGJlIGhlbHBmdWwuDQoNCi0tDQpDaHJpc3RvcGhlciBEZWFybG92ZQ0K U2VuaW9yIFByaW5jaXBhbCBFbmdpbmVlcg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2Vu Y2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQoNClQ6ICArNDQgKDApMTI0NSAyNDIxOTQgIHwgIEU6IGNo cmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0 ZW1zLmNvbT4NCg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQg VGVjaG5vbG9neSBQYXJrLCBHcmVhdCBCYWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4u DQp3d3cuYmFlc3lzdGVtcy5jb20vYWk8aHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haT4NCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQNClJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmIFdhbGVzIE5vOiAwMTMzNzQ1MQ0KUmVnaXN0ZXJlZCBPZmZpY2U6IFN1cnJleSBSZXNl YXJjaCBQYXJrLCBHdWlsZGZvcmQsIFN1cnJleSwgR1UyIDdZUA0KDQoNCkZyb206IFZpY3Rvcmlh IE1lcmNpZWNhIFttYWlsdG86dm1lcmNpZWNhMEBnbWFpbC5jb21dDQpTZW50OiAyNyBNYXkgMjAx NSAxMzo1MQ0KVG86IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspDQpDYzogbWFuZXQNClN1Ympl Y3Q6IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHRyYW5zbGF0aW9uIHRhYmxlcw0KDQoNCioqKiBXQVJO SU5HICoqKg0KVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlz YXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0K Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3Ms IG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGlu ZyBSZWQgRmxhZ3MgdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2Vp dmUsIGNsaWNrIGhlcmU8aHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdv cmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlv dSBmZWVsIHRoZSBlbWFpbCBpcyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2Vz czxodHRwOi8vaW50cmFuZXQuZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9z cG90bGlnaHRzL0RvY3VtZW50cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMu cGRmPi4NCkhpIENocmlzLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMgYWxzby4NCg0KT24g V2VkLCBNYXkgMjcsIDIwMTUgYXQgMTI6MDAgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp IDxjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTxtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFl c3lzdGVtcy5jb20+PiB3cm90ZToNCkFjdHVhbGx5LCB5b3Ugc2F2ZSBJIHRoaW5rIHR3byBieXRl cyBub3QgaGF2aW5nIGEgdGFyZ2V0IGFkZHJlc3MuIEZvciBzaWduaWZpY2FudCBsb3NzIG9mIGV4 dGVuc2liaWxpdHkuDQoNClR3byBieXRlcz8NCg0KQ3VycmVudGx5IHlvdSBjYW4gaGF2ZSBhIHZh bHVlbGVzcyBUTFYuIEl0IG5lZWRzIGEgc2luZ2xlIGFkZHJlc3MgaW5kZXgsIG5vIGxlbmd0aCBv ciB2YWx1ZS4NCg0KSW5zdGVhZCB5b3UgY2FuIGhhdmUgYSBUTFYgd2l0aCB0d28gdmFsdWVzIGZv ciB0aGUgdHdvIGFkZHJlc3MgdHlwZXMuIFVzaW5nIGEgbXVsdGl2YWx1ZSBUTFYgaXQgbmVlZHMg bm8gaW5kaWNlcywgYSBzaW5nbGUgYnl0ZSBsZW5ndGggKDIpIGFuZCB0d28gdmFsdWUgYnl0ZXMu DQoNCkxpa2UgYW4gImFkZHJlc3MgbWVhbmluZyIgVExWPyBBbmQgdXNpbmcganVzdCBvbmUgb2Yg dGhlc2UgVExWcyBpbiBlYWNoIG1lc3NhZ2UsIG1hcmsgZWFjaCBhZGRyZXNzIGluIHRoZSBhZGRy ZXNzIGJsb2NrPyBJJ3ZlIGp1c3QgZm91bmQgU2VjdGlvbiBDMiBpbiBSRkM1NDQ0IC0NCg0KDQpB c3N1bWUgdGhlIGRlZmluaXRpb24gb2YgYW4gQWRkcmVzcyBCbG9jayBUTFYgd2l0aCB0eXBlIEVY QU1QTEUxIChhbmQNCg0KICAgbm8gdHlwZSBleHRlbnNpb24pIHRoYXQgaGFzIHNpbmdsZSBvY3Rl dCB2YWx1ZXMgcGVyIGFkZHJlc3MuICBUaGVyZQ0KDQogICBhcmUgYSBudW1iZXIgb2Ygd2F5cyBp biB3aGljaCB2YWx1ZXMgYSwgYSwgYiwgYW5kIGMgbWF5IGJlIGFzc29jaWF0ZWQNCg0KICAgd2l0 aCB0aGUgZm91ciBhZGRyZXNzZXMgaW4gdGhlIHByZWNlZGluZyBBZGRyZXNzIEJsb2NrLCB3aGVy ZSBjIGlzIGENCg0KICAgZGVmYXVsdCB2YWx1ZSB0aGF0IGNhbiBiZSBvbWl0dGVkLg0KDQoNCg0K ICAgRXhhbXBsZXM6DQoNCiAgIFVzaW5nIG9uZSBtdWx0aXZhbHVlIFRMViB0byBjb3ZlciBhbGwg b2YgdGhlIGFkZHJlc3NlczoNCg0KICAgICAgKiAgPHRsdi1mbGFncz4gaGFzIHRoYXN2YWx1ZSBh bmQgdGlzbXVsdGl2YWx1ZSBzZXQgKHZhbHVlIDIwKTsNCg0KICAgICAgKiAgPGluZGV4LXN0YXJ0 PiBhbmQgPGluZGV4LXN0b3A+IGFyZSBvbWl0dGVkOw0KDQogICAgICAqICA8bGVuZ3RoPiA9IDQg KHNpbmdsZS1sZW5ndGggPSAxKS4NCg0KICAgICAgKiAgVGhlIFRMViBpcyB0aGVuIEVYQU1QTEUx IDIwIDQgYSBhIGIgYyAoNyBvY3RldHMpLg0KDQoNCg0KU28gd2Ugd291bGQgZGVmaW5lIHZhbHVl cyBhIGIgYyBkLCB3aGVyZSAiYSIgcmVwcmVzZW50cyBPcmlnQWRkciwgImIiIHJlcHJlc2VudHMg VGFyZ0FkZHIsICJjIiByZXByZXNlbnRzIGFuIHVucmVhY2hhYmxlIGFkZHJlc3MgaW4gUkVSUiwg YW5kICJkIiByZXByZXNlbnRzIGEgUGt0U291cmNlIGFkZHJlc3M/DQoNCg0KDQpUaGVuIHNlcGFy YXRlbHkgYWRkIFRMVnMgcmVsYXRpbmcgdG8gbWV0cmljcywgc2VxdWVuY2UgbnVtYmVycywgZXRj Lj8gLi4uYW5kIHdlIHdvdWxkbnQgbmVlZCB0aHJlZSBraW5kcyBvZiBTRVFfTlVNIFRMViBmb3Ig dGhpcywgd2UgY291bGQganVzdCB1c2UgU0VRX05VTSwgYW5kIGhhdmUgbXVsdGktdmFsdWVzIGlm IG5lY2Vzc2FyeS4NCg0KDQoNCkRpZCBJIHVuZGVyc3RhbmQgdGhhdCBjb3JyZWN0bHk/DQoNCg0K DQpLaW5kIHJlZ2FyZHMsDQoNClZpY3RvcmlhLg0KDQoNCg0KRXh0ZW5zaWJpbGl0eT8gWW91IGNh biBhZGQgYWRkaXRpb25hbCBhZGRyZXNzZXMgd2l0aCBvdGhlciBtZWFuaW5ncyBpbiBmdXR1cmUg ZXh0ZW5zaW9ucy4gWW91IGNhbiB1c2UgdGhlIDI1NCB1bmFsbG9jYXRlZCAob3IgMjUzLCBoYXZp bmcgYW4gVU5TUEVDSUZJRUQgdmFsdWUgb2YgMjU1IGFzIGluIFJGQyA3MTg4IGlzIGFsc28gYSBn b29kIGlkZWEpIHZhbHVlcyBmb3IgdGhpcyBpbiBzb21lIGNhc2VzLg0KDQpJdCBpcyBhbHNvIGNv bXBhdGlibGUgd2l0aCBleGlzdGluZyBnZW5lcmljIDU0NDQgcGFyc2VycyBhcHByb2FjaGVzLg0K DQotLQ0KQ2hyaXN0b3BoZXIgRGVhcmxvdmUNClNlbmlvciBQcmluY2lwYWwgRW5naW5lZXINCkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpUOiAg KzQ0ICgwKTEyNDUgMjQyMTk0PHRlbDolMkI0NCUyMCUyODAlMjkxMjQ1JTIwMjQyMTk0PiAgfCAg RTogY2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb208bWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tPg0KDQpCQUUgU3lzdGVtcyBBcHBsaWVkIEludGVsbGlnZW5jZSwgQ2hlbG1z Zm9yZCBUZWNobm9sb2d5IFBhcmssIEdyZWF0IEJhZGRvdywgQ2hlbG1zZm9yZCwgRXNzZXggQ00y IDhITi4NCnd3dy5iYWVzeXN0ZW1zLmNvbS9haTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2Fp Pg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UgTGltaXRlZA0KUmVnaXN0ZXJlZCBp biBFbmdsYW5kICYgV2FsZXMgTm86IDAxMzM3NDUxDQpSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5 IFJlc2VhcmNoIFBhcmssIEd1aWxkZm9yZCwgU3VycmV5LCBHVTIgN1lQDQoNCg0KRnJvbTogbWFu ZXQgW21haWx0bzptYW5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzptYW5ldC1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIFZpY3RvcmlhIE1lcmNpZWNhDQpTZW50OiAyNyBNYXkgMjAx NSAxMDoyNA0KVG86IEppYXppIFlJDQpDYzogbWFuZXQNClN1YmplY3Q6IFJlOiBbbWFuZXRdIFJG QyA1NDQ0IHRyYW5zbGF0aW9uIHRhYmxlcw0KDQoNCioqKiBXQVJOSU5HICoqKg0KVGhpcyBtZXNz YWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRzaWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9t IGFuIGV4dGVybmFsIHBhcnRuZXIgb3IgdGhlIGludGVybmV0Lg0KQ29uc2lkZXIgY2FyZWZ1bGx5 IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1l bnRzIG9yIHJlcGx5Lg0KRm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyBSZWQgRmxhZ3MgdGhhdCB5 b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsIGNsaWNrIGhlcmU8aHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmPi4NCklmIHlvdSBmZWVsIHRoZSBlbWFpbCBp cyBzdXNwaWNpb3VzLCBwbGVhc2UgZm9sbG93IHRoaXMgcHJvY2VzczxodHRwOi8vaW50cmFuZXQu ZW50LmJhZXN5c3RlbXMuY29tL2hvd3dld29yay9zZWN1cml0eS9zcG90bGlnaHRzL0RvY3VtZW50 cy9EZWFsaW5nJTIwV2l0aCUyMFN1c3BpY2lvdXMlMjBFbWFpbHMucGRmPi4NCkhpIEppYXppLCBh bmQgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLA0KDQpUaGlzIGlzIHBhcnQgb2YgYW4gb25nb2lu ZyBkaXNjdXNzaW9uLiBUaGUgY3VycmVudCBkcmFmdCBpbXBsaWVzIHRoYXQgYmVjYXVzZSB0aGVy ZSBhcmUgdHdvIGFkZHJlc3NlcyBpbiBhIFJSRVEsIHRoZW4gaWYgb25lIGlzIG1hcmtlZCBhcyBP cmlnQWRkciBieSBoYXZpbmcgYW4gYXNzb2NpYXRlZCBPcmlnU2VxTnVtIChvciBPUklHX1NFUV9O VU0pIFRMViwgdGhlIG90aGVyIGFkZHJlc3MgbXVzdCBiZSBUYXJnQWRkci4gaS5lIGluIGEgUlJF USwgd2UgY2FuIGludGVycHJldCBhbiBhZGRyZXNzIHdpdGhvdXQgYW4gYXNzb2NpYXRlZCBUTFYg YXMgVGFyZ0FkZHIuIEJ5IGRvaW5nIGl0IHRoaXMgd2F5LCB3ZSBzYXZlIHRoZSBsZW5ndGggb2Yg dGhlIFRMViB3ZSBtaWdodCBoYXZlIGFzc29jaWF0ZWQgd2l0aCBUYXJnQWRkci4gRnVydGhlciwg dGhpcyBhcHBsaWVkIHRvIG90aGVyIG1lc3NhZ2VzIC0gdGhlIG1lYW5pbmcgb2YgYW4gdW5tYXJr ZWQgYWRkcmVzcyBpcyBkZWR1Y2VkIGZyb20gdGhlIG1lc3NhZ2UgdHlwZS4gRm9yIFJSRVAsIGFu IGFkZHJlc3Mgd2l0aG91dCBhbiBhc3NvY2lhdGVkIFRMViBpcyBPcmlnQWRkci4gRm9yIFJFUlIs IGFsbCB1bm1hcmtlZCBhZGRyZXNzZXMgYXJlIHVucmVhY2hhYmxlIGRlc3RpbmF0aW9ucy4gSW4g UkVSUiwgd2UgbWFyayB0aGUgUGt0U291cmNlIGFkZHJlc3Mgd2l0aCBpdHMgb3duIFBrdFNvdXJj ZSAoUEtUX1NPVVJDRSkgVExWIHRvIGRpZmZlcmVudGlhdGUgZnJvbSB0aGUgdW5yZWFjaGFibGUg YWRkcmVzc2VzLg0KDQpJZiBpbiBmdXR1cmUsIHdlIGRlY2lkZWQgdG8gYWRkIGFuIG5ldyB0eXBl IG9mIGFkZHJlc3MgaW50byBhIG1lc3NhZ2UgZm9yIHNvbWUgcmVhc29uLCB0aGF0IGFkZHJlc3Mg TVVTVCBoYXZlIGEgVExWIGFzc29jaWF0ZWQgd2l0aCBpdCB0byBkaWZmZXJlbnRpYXRlLiBUaGF0 IG1ha2VzIHNlbnNlIGFueXdheSwgd2Ugd291bGQgd2FudCB0byBpbmRpY2F0ZSB3aGF0IHRoZSBu ZXcgYWRkcmVzcyBtZWFucy4NCg0KVGhlIHF1ZXN0aW9uIGlzLCBpcyB0aGlzIGFjY2VwdGFibGU/ IElmIG5vdCwgbWF5YmUgd2UgaGF2ZSB0byBhY2NlcHQgYWRkaW5nIGEgVExWIHRvIGVhY2ggb2Yg dGhlc2UgbWVzc2FnZXMgc28gdGhhdCB0aGVyZSBhcmUgbm8gYWRkcmVzc2VzIHdpdGhvdXQgYXNz b2NpYXRlZCBhbnkgQWRkcmVzcyBCbG9jayBUTFZzLg0KDQpBbHNvLCB0aGUgb3JkZXIgb2YgYWRk cmVzc2VzIGluIHRoZSBBZGRyZXNzIEJsb2NrIGRvZXNuJ3QgbWF0dGVyIGluIGVpdGhlciBjYXNl LiBBT0RWdjIgZHJhZnQgOSBzYXlzLCBpbiB0aGUgUkZDNTQ0NCBSZXByZXNlbnRhdGlvbiBTZWN0 aW9uIChTZWN0aW9uIDgsIHBhZ2UgNDYpOg0KIlRoZSBhZGRyZXNzZXMgaW4gYW4gQWRkcmVzcyBC bG9jayBtYXkgYXBwZWFyIGluIGFueSBvcmRlciwgYW5kIHZhbHVlcw0KICAgaW4gYW4gQWRkcmVz cyBCbG9jayBUTFYgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNvcnJlY3QgYWRkcmVzcw0K ICAgaW4gdGhlIEFkZHJlc3MgQmxvY2suICBUbyBpbmRpY2F0ZSB3aGljaCBhZGRyZXNzIGVhY2gg dmFsdWUgaXMNCiAgIGFzc29jaWF0ZWQgd2l0aCwgdGhlIEFPRFZ2MiBtZXNzYWdlIHJlcHJlc2Vu dGF0aW9uIHVzZXMgbGlzdHMgd2hlcmUNCiAgIHRoZSBvcmRlciBvZiB0aGUgYWRkcmVzc2VzIGlu IHRoZSBBZGRyZXNzTGlzdCBtYXRjaGVzIHRoZSBvcmRlciBvZg0KICAgdmFsdWVzIGluIHRoZSBv dGhlciBsaXN0cywgZS5nLiwgU2VxTnVtTGlzdCBpbiBhIFJFUlIuIg0KSXMgdGhpcyB1bmNsZWFy Pw0KDQpLaW5kIHJlZ2FyZHMsDQpWaWN0b3JpYS4NCg0KDQpPbiBUdWUsIE1heSAyNiwgMjAxNSBh dCAxMjoxOSBBTSwgSmlhemkgWUkgPGlldGZAamlheml5aS5jb208bWFpbHRvOmlldGZAamlheml5 aS5jb20+PiB3cm90ZToNCklmIEkgdW5kZXJzdGFuZCB3ZWxsLCB3ZSBzdGlsbCBuZWVkIHRoZSBl eGlzdGVuY2UgYW5kIHRoZSBvcmRlciBpbiB0aGUgYWRkcmVzcyBibG9jaywgdG8gaWRlbnRpZnkg dGhlIHVzYWdlIG9mIGFkZHJlc3Nlcz8NCg0KRm9yIGV4YW1wbGUsIHNlY3Rpb24gOC4xOg0KDQo4 LjEuMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tYW5ldC1hb2R2djIt MDkjc2VjdGlvbi04LjEuMz4uICBBZGRyZXNzIEJsb2NrDQoNCg0KDQoNCg0KICAgQSBSUkVRIGNv bnRhaW5zIHR3byBBZGRyZXNzZXMsIE9yaWdBZGRyIGFuZCBUYXJnQWRkciwgYW5kIGVhY2gNCg0K ICAgYWRkcmVzcyBoYXMgYW4gYXNzb2NpYXRlZCBwcmVmaXggbGVuZ3RoLg0KDQoNCg0KICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQoNCiAgICAgICAgfCBEYXRhIEVsZW1lbnRzICAgICAgICAgICB8IEFkZHJlc3MgQmxvY2sg ICAgICAgICAgICAgICAgfA0KDQogICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICB8IE9yaWdBZGRyL09yaWdQ cmVmaXhMZW4gIHwgPGFkZHJlc3M+ICsgPHByZWZpeC1sZW5ndGg+ICB8DQoNCiAgICAgICAgfCBU YXJnQWRkci9UYXJnUHJlZml4TGVuICB8IDxhZGRyZXNzPiArIDxwcmVmaXgtbGVuZ3RoPiAgfA0K DQogICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCg0KDQoNCldlIGNhbiBpbmZlciB0aGUgT3JpZ0FkZHIgYnkgdGhlIFRMViB0 eXBlIE9SSUdfU0VRX05VTS4gSG93ZXZlciwgdGhlIG9ubHkgYWRkcmVzcyBibG9jayBUTFYgZm9y IFRhcmdBZGRyIChUYXJnU2VxTnVtKSBpcyBvcHRpb25hbC4gSXQgbWVhbnMgaWYgd2UgZG9uJ3Qg aGF2ZSB0aGUgVGFyZ1NlcU51bSBUTFYsIGFjY29yZGluZyB0byBSRkM1NDQ0LCB3ZSB3b24ndCBi ZSBhYmxlIHRvIGtub3cgd2hhdCdzIHRoZSBUYXJnQWRkci4NCg0KDQoNCmJlc3QNCg0KDQoNCkpp YXppDQoNCg0KDQoNCg0KT24gV2VkLCBNYXkgMTMsIDIwMTUgYXQgNzoxMyBQTSwgTG90dGUgU3Rl ZW5icmluayA8bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGU8bWFpbHRvOmxvdHRlLnN0ZWVu YnJpbmtAZnUtYmVybGluLmRlPj4gd3JvdGU6DQpIaSBhbGwsDQpGWUksIGRyYWZ0LWlldGYtbWFu ZXQtYW9kdnYyLTA5LCB3aGljaCBjaGFybGllIGp1c3QgcHVibGlzaGVkLCBhZGRyZXNzZXMgYWxs IGNvbW1lbnRzIG1hZGUgaW4gdGhpcyB0aHJlYWQuIEFueSBmZWVkYmFjayBpcyB2ZXJ5IHdlbGNv bWUhDQoNClJlZ2FyZHMsDQpMb3R0ZQ0KDQpBbSAxMy4wNS4yMDE1IHVtIDE2OjMzIHNjaHJpZWIg RGVhcmxvdmUsIENocmlzdG9waGVyIChVSykgPGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+Og0KDQo+IEkgZG9uJ3QgaGF2 ZSB0aW1lIHRvIGxvb2sgYXQgdGhpcyB0b2RheSwgYnV0IEhlbm5pbmcncyBzdWdnZXN0aW9uIGxv b2tzIGdvb2QuDQo+DQo+IC0tDQo+IENocmlzdG9waGVyIERlYXJsb3ZlDQo+IFNlbmlvciBQcmlu Y2lwYWwgRW5naW5lZXINCj4gQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2UNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4NCj4gVDogICs0NCAoMCkxMjQ1IDI0MjE5NDx0ZWw6JTJCNDQlMjAl MjgwJTI5MTI0NSUyMDI0MjE5ND4gIHwgIEU6IGNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29t PG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4NCj4NCj4gQkFFIFN5c3RlbXMg QXBwbGllZCBJbnRlbGxpZ2VuY2UsIENoZWxtc2ZvcmQgVGVjaG5vbG9neSBQYXJrLCBHcmVhdCBC YWRkb3csIENoZWxtc2ZvcmQsIEVzc2V4IENNMiA4SE4uDQo+IHd3dy5iYWVzeXN0ZW1zLmNvbS9h aTxodHRwOi8vd3d3LmJhZXN5c3RlbXMuY29tL2FpPg0KPiBCQUUgU3lzdGVtcyBBcHBsaWVkIElu dGVsbGlnZW5jZSBMaW1pdGVkDQo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCAmIFdhbGVzIE5vOiAw MTMzNzQ1MQ0KPiBSZWdpc3RlcmVkIE9mZmljZTogU3VycmV5IFJlc2VhcmNoIFBhcmssIEd1aWxk Zm9yZCwgU3VycmV5LCBHVTIgN1lQDQo+DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEhlbm5pbmcgUm9nZ2UgW21haWx0bzpocm9nZ2VAZ21haWwuY29tPG1haWx0 bzpocm9nZ2VAZ21haWwuY29tPl0NCj4gU2VudDogMTMgTWF5IDIwMTUgMTU6MTENCj4gVG86IExv dHRlIFN0ZWVuYnJpbmsNCj4gQ2M6IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyBtYW5ldEBp ZXRmLm9yZzxtYWlsdG86bWFuZXRAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbbWFuZXRdIFJG QyA1NDQ0IHRyYW5zbGF0aW9uIHRhYmxlcw0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tISBX QVJOSU5HICEgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBUaGlzIG1lc3NhZ2Ugb3JpZ2luYXRlcyBm cm9tIG91dHNpZGUgb3VyIG9yZ2FuaXNhdGlvbiwgZWl0aGVyIGZyb20gYW4gZXh0ZXJuYWwgcGFy dG5lciBvciBmcm9tIHRoZSBpbnRlcm5ldC4NCj4gQ29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIg eW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJl cGx5Lg0KPiBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsgb24gSVQg bWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVtYWlsIG1l c3NhZ2VzLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPg0KPiBPbiBXZWQsIE1heSAxMywgMjAxNSBhdCAzOjU1IFBNLCBMb3R0ZSBT dGVlbmJyaW5rIDxsb3R0ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZTxtYWlsdG86bG90dGUuc3Rl ZW5icmlua0BmdS1iZXJsaW4uZGU+PiB3cm90ZToNCj4+IEhpIENocmlzdG9waGVyLA0KPj4gdGhh bmtzIGZvciB5b3VyIGZlZWRiYWNrLg0KPj4NCj4+IEFtIDA3LjA1LjIwMTUgdW0gMTI6MDAgc2No cmllYiBEZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKQ0KPj4gPGNocmlzLmRlYXJsb3ZlQGJhZXN5 c3RlbXMuY29tPG1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbT4+Og0KPj4NCj4+ IFRoZXJlIGlzIGEgc3R5bGUgcXVlc3Rpb24gdGhhdCBhbGwgZXhpc3RpbmcgVExWcyBoYXZlIG5h bWVzIGxpa2UNCj4+IExJTktfU1RBVFVTLCB3aGlsZSBoZXJlIFRMVnMgaGF2ZSBuYW1lcyBsaWtl IE9yaWdTZXFOdW0uIEkgZG9u4oCZdCB0aGluaw0KPj4gSUFOQSBlbmZvcmNlIHN1Y2ggaXNzdWVz LCBhbmQgZGlmZmVyZW50IHBlb3BsZSB3aWxsIGhhdmUgZGlmZmVyZW50DQo+PiBvcGluaW9ucyBv biB0aGUgaW1wb3J0YW5jZSBvZiBjb25zaXN0ZW50IHN0eWxlLiAoTmFtaW5nIGNhbiBtYXR0ZXIs DQo+PiB3ZeKAmXJlIHNwZW5kaW5nIGN5Y2xlcyBvbiBhbiBJRCBqdXN0IGFib3V0IFRMViBuYW1l cy4pDQo+Pg0KPj4NCj4+DQo+PiBBYnNvbHV0ZWx5LiBJbiB5b3VyIG9waW5pb24sIHdvdWxkIGl0 IHN1ZmZpY2UgdG8gYWRqdXN0IHRoZSBjdXJyZW50DQo+PiBuYW1lcyBzdHlsaXN0aWNhbGx5IChz ZWUgYXR0YWNoZWQgZmlsZSksIG9yIGRvIHNvbWUgbmFtZXMgbmVlZCBleHRyYQ0KPj4gd29yayBp biB0ZXJtcyBvZiBjbGFyaWZpY2F0aW9uIG9yIGNvbnNpc3RlbmN5PyAoSSB3YXMganVzdCB3b25k ZXJpbmcNCj4+IGlmIE1FVFJJQyBzaG91bGQgYmUgZWRpdGVkIHRvIG1ha2UgY2xlYXIgdGhhdCBp dCBpcyBub3QgZGlyZWN0bHkNCj4+IHJlbGF0ZWQgdG8gTElOS19NRVRSSUMuLi4pDQo+DQo+IE1h eWJlIHRoZSBuYW1lICJQQVRIX01FVFJJQyIgd291bGQgbWFrZSBzZW5zZSBmb3IgdGhlIG5ldyBU TFYuLi4gdGhpcyBkZXNjcmliZXMgdGhlIHVzYWdlIG9mIHRoZSBUTFYgdmVyeSB3ZWxsLg0KPg0K PiBIZW5uaW5nIFJvZ2dlDQo+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZA0KPiByZWNpcGllbnQgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPiBy ZWNpcGllbnQgcGxlYXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtIGFuZCBub3RpZnkgdGhl IHNlbmRlci4NCj4gWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1c2UgaXQgZm9yIGFueSBwdXJw b3NlIG5vciBkaXNjbG9zZSBvcg0KPiBkaXN0cmlidXRlIGl0cyBjb250ZW50cyB0byBhbnkgb3Ro ZXIgcGVyc29uLg0KPiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbWFuZXQgbWFpbGluZyBsaXN0DQptYW5ldEBpZXRmLm9yZzxt YWlsdG86bWFuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL21hbmV0DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCm1hbmV0IG1haWxpbmcgbGlzdA0KbWFuZXRAaWV0Zi5vcmc8bWFpbHRvOm1hbmV0QGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldA0KDQoN Cg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC6ADGLKXM0002VGREEN_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQpoNA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTsNCgltc28tc3R5bGUtbGluazoi SGVhZGluZyA0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBz cGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN CgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsInNl cmlmIjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQjt9DQpzcGFuLkhlYWRpbmc0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiSGVhZGluZyA0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDQiOw0KCWZvbnQtZmFtaWx5OiJDYW1icmlhIiwi c2VyaWYiOw0KCWNvbG9yOiM0RjgxQkQ7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7DQoJ Zm9udC13ZWlnaHQ6Ym9sZDsNCglmb250LXN0eWxlOml0YWxpYzt9DQpzcGFuLkJhbGxvb25UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlllcywgSSBiZWxp ZXZlIHlvdSBkaWQgdW5kZXJzdGFuZC4gSSBiZWxpZXZlIHRoYXQgc2hvcnRseSB5b3UgKGV2ZXJ5 b25lKSB3aWxsIGhhdmUgc29tZSBhZGRpdGlvbmFsIG1hdGVyaWFsIHRoYXQgSSBob3BlIHdpbGwg YWxzbyBiZSBoZWxwZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwN0U3RSI+ LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzAwN0U3RSI+Q2hyaXN0b3BoZXIgRGVhcmxvdmU8YnI+DQpTZW5pb3IgUHJpbmNpcGFsIEVu Z2luZWVyPGJyPg0KQkFFIFN5c3RlbXMgQXBwbGllZCBJbnRlbGxpZ2VuY2U8YnI+DQo8L3NwYW4+ PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0JFQkVCRSI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDAwMDdFIj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3 RDdEN0QiPlQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojN0Q3RDdE Ij46ICZuYnNwOyYjNDM7NDQgKDApMTI0NSAyNDIxOTQgJm5ic3A7fCAmbmJzcDs8Yj5FOg0KPC9i PjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSI+Y2hyaXMuZGVh cmxvdmVAYmFlc3lzdGVtcy5jb208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMDAwMDdFIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzQThCOTIiPkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNm b3JkIFRlY2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIg OEhOLjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiPjxzcGFuIHN0 eWxlPSJjb2xvcjojM0E4QjkyO3RleHQtZGVjb3JhdGlvbjpub25lIj53d3cuYmFlc3lzdGVtcy5j b20vYWk8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZh bXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQgT2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2gg UGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gVmlj dG9yaWEgTWVyY2llY2EgW21haWx0bzp2bWVyY2llY2EwQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiAyNyBNYXkgMjAxNSAxMzo1MTxicj4NCjxiPlRvOjwvYj4gRGVhcmxvdmUsIENocmlz dG9waGVyIChVSyk8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbbWFuZXRdIFJGQyA1NDQ0IHRyYW5zbGF0aW9uIHRhYmxlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOnNvbGlkIGJsYWNrIDEuMHB0O3BhZGRpbmc6Mi4wcHQgMi4wcHQgMi4wcHQgMi4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyO2JhY2tncm91bmQ6d2hpdGUiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioqPG86 cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWdu OmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBvcmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIg b3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBleHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRl cm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5 NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNo b3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4gYW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwv c3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8 L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9uZz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFuPjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZv ciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xpY2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0 LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVu dHMvUmVkJTIwRmxhZ3MucGRmIj4NCmhlcmU8L2E+Ljwvc3Bhbj48L2VtPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+PGJyPg0KPGVtPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JZiB5b3Ug ZmVlbCB0aGUgZW1haWwgaXMgc3VzcGljaW91cywgcGxlYXNlIGZvbGxvdw0KPGEgaHJlZj0iaHR0 cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsvc2VjdXJpdHkvc3BvdGxp Z2h0cy9Eb2N1bWVudHMvRGVhbGluZyUyMFdpdGglMjBTdXNwaWNpb3VzJTIwRW1haWxzLnBkZiI+ DQp0aGlzIHByb2Nlc3M8L2E+Ljwvc3Bhbj48L2VtPjwvc3Bhbj48L2k+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMzMzOTcyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIENocmlzLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB5b3VyIGNvbW1l bnRzIGFsc28uJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBNYXkgMjcsIDIwMTUgYXQgMTI6MDAgUE0sIERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUsp ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdl dD0iX2JsYW5rIj5jaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BY3R1YWxseSwgeW91IHNhdmUg SSB0aGluayB0d28gYnl0ZXMgbm90IGhhdmluZyBhIHRhcmdldCBhZGRyZXNzLiBGb3Igc2lnbmlm aWNhbnQgbG9zcyBvZiBleHRlbnNpYmlsaXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlR3byBieXRlcz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5DdXJyZW50bHkgeW91IGNhbiBoYXZlIGEgdmFsdWVsZXNzIFRMVi4gSXQgbmVl ZHMgYSBzaW5nbGUgYWRkcmVzcyBpbmRleCwgbm8gbGVuZ3RoIG9yIHZhbHVlLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPkluc3RlYWQgeW91IGNhbiBoYXZlIGEgVExWIHdpdGggdHdvIHZhbHVlcyBmb3Ig dGhlIHR3byBhZGRyZXNzIHR5cGVzLiBVc2luZyBhIG11bHRpdmFsdWUgVExWIGl0IG5lZWRzDQog bm8gaW5kaWNlcywgYSBzaW5nbGUgYnl0ZSBsZW5ndGggKDIpIGFuZCB0d28gdmFsdWUgYnl0ZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpa2UgYW4gJnF1b3Q7YWRkcmVzcyBtZWFuaW5n JnF1b3Q7IFRMVj8gQW5kIHVzaW5nIGp1c3Qgb25lIG9mIHRoZXNlIFRMVnMgaW4gZWFjaCBtZXNz YWdlLCBtYXJrIGVhY2ggYWRkcmVzcyBpbiB0aGUgYWRkcmVzcyBibG9jaz8gSSd2ZSBqdXN0IGZv dW5kIFNlY3Rpb24gQzIgaW4gUkZDNTQ0NCAtJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkFzc3VtZSB0aGUgZGVmaW5pdGlvbiBvZiBhbiBBZGRyZXNzIEJsb2NrIFRMViB3aXRoIHR5cGUg RVhBTVBMRTEgKGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG5vIHR5cGUgZXh0ZW5z aW9uKSB0aGF0IGhhcyBzaW5nbGUgb2N0ZXQgdmFsdWVzIHBlciBhZGRyZXNzLiZuYnNwOyBUaGVy ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFyZSBhIG51bWJlciBvZiB3YXlzIGluIHdo aWNoIHZhbHVlcyBhLCBhLCBiLCBhbmQgYyBtYXkgYmUgYXNzb2NpYXRlZDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHdpdGggdGhlIGZvdXIgYWRkcmVzc2VzIGluIHRoZSBwcmVjZWRpbmcg QWRkcmVzcyBCbG9jaywgd2hlcmUgYyBpcyBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg ZGVmYXVsdCB2YWx1ZSB0aGF0IGNhbiBiZSBvbWl0dGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgRXhhbXBsZXM6PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVXNpbmcgb25lIG11bHRpdmFsdWUgVExWIHRvIGNv dmVyIGFsbCBvZiB0aGUgYWRkcmVzc2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgJmx0O3Rsdi1mbGFncyZndDsgaGFzIHRoYXN2YWx1ZSBh bmQgdGlzbXVsdGl2YWx1ZSBzZXQgKHZhbHVlIDIwKTs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7ICZsdDtpbmRleC1zdGFydCZndDsgYW5kICZs dDtpbmRleC1zdG9wJmd0OyBhcmUgb21pdHRlZDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7ICZsdDtsZW5ndGgmZ3Q7ID0gNCAoc2luZ2xlLWxl bmd0aCA9IDEpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICombmJzcDsgVGhlIFRMViBpcyB0aGVuIEVYQU1QTEUxIDIwIDQgYSBhIGIgYyAoNyBvY3RldHMp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+U28gd2Ugd291bGQgZGVmaW5lIHZhbHVlcyBhIGIgYyBkLCB3aGVyZSAmcXVvdDthJnF1b3Q7 IHJlcHJlc2VudHMgT3JpZ0FkZHIsICZxdW90O2ImcXVvdDsgcmVwcmVzZW50cyBUYXJnQWRkciwg JnF1b3Q7YyZxdW90OyByZXByZXNlbnRzIGFuIHVucmVhY2hhYmxlIGFkZHJlc3MgaW4gUkVSUiwg YW5kICZxdW90O2QmcXVvdDsgcmVwcmVzZW50cyBhIFBrdFNvdXJjZSBhZGRyZXNzPzwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlbiBzZXBhcmF0ZWx5IGFkZCBUTFZzIHJlbGF0 aW5nIHRvIG1ldHJpY3MsIHNlcXVlbmNlIG51bWJlcnMsIGV0Yy4/IC4uLmFuZCB3ZSB3b3VsZG50 IG5lZWQgdGhyZWUga2luZHMgb2YgU0VRX05VTSBUTFYgZm9yIHRoaXMsIHdlIGNvdWxkIGp1c3Qg dXNlIFNFUV9OVU0sIGFuZCBoYXZlIG11bHRpLXZhbHVlcyBpZiBuZWNlc3NhcnkuPC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5EaWQgSSB1bmRlcnN0YW5kIHRoYXQgY29ycmVjdGx5 Pzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+S2luZCByZWdhcmRzLDwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VmljdG9yaWEuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkV4dGVuc2liaWxpdHk/IFlvdSBjYW4gYWRkIGFkZGl0aW9uYWwgYWRkcmVzc2VzIHdp dGggb3RoZXIgbWVhbmluZ3MgaW4gZnV0dXJlIGV4dGVuc2lvbnMuIFlvdSBjYW4NCiB1c2UgdGhl IDI1NCB1bmFsbG9jYXRlZCAob3IgMjUzLCBoYXZpbmcgYW4gVU5TUEVDSUZJRUQgdmFsdWUgb2Yg MjU1IGFzIGluIFJGQyA3MTg4IGlzIGFsc28gYSBnb29kIGlkZWEpIHZhbHVlcyBmb3IgdGhpcyBp biBzb21lIGNhc2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkl0IGlzIGFsc28gY29tcGF0aWJsZSB3aXRoIGV4 aXN0aW5nIGdlbmVyaWMgNTQ0NCBwYXJzZXJzIGFwcHJvYWNoZXMuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIu MHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPi0tDQo8L3Nw YW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDdFN0UiPkNocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0KU2Vu aW9yIFByaW5jaXBhbCBFbmdpbmVlcjxicj4NCkJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdl bmNlPGJyPg0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiNC RUJFQkUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzAwMDA3RSI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojN0Q3RDdEIj5UPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzdEN0Q3RCI+OiAmbmJzcDs8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0 NSUyMDI0MjE5NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+DQog Jm5ic3A7fCAmbmJzcDs8Yj5FOiA8L2I+PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJsb3ZlQGJh ZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5j b208L2E+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDAwMDdF Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPkJB RSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRlY2hub2xvZ3kgUGFy aywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cuYmFlc3lzdGVtcy5jb20vYWkiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6IzNBOEI5Mjt0ZXh0LWRlY29yYXRpb246bm9uZSI+d3d3LmJhZXN5c3RlbXMuY29t L2FpPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojM0E4QjkyIj5CQUUgU3lzdGVtcyBB cHBsaWVkIEludGVsbGlnZW5jZSBMaW1pdGVkPGJyPg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kICZh bXA7IFdhbGVzIE5vOiAwMTMzNzQ1MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzQThCOTIiPlJlZ2lzdGVyZWQg T2ZmaWNlOiBTdXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IG1hbmV0DQog W21haWx0bzo8YSBocmVmPSJtYWlsdG86bWFuZXQtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPm1hbmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5W aWN0b3JpYSBNZXJjaWVjYTxicj4NCjxiPlNlbnQ6PC9iPiAyNyBNYXkgMjAxNSAxMDoyNDxicj4N CjxiPlRvOjwvYj4gSmlhemkgWUk8YnI+DQo8Yj5DYzo8L2I+IG1hbmV0PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbWFuZXRdIFJGQyA1NDQ0IHRyYW5zbGF0aW9uIHRhYmxlczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgYmxhY2sgMS4wcHQ7cGFkZGluZzoyLjBwdCAyLjBw dCAyLjBwdCAyLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4 dC1hbGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzMzMzk3MiI+KioqIFdBUk5JTkcgKioq PC9zcGFuPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJn aW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxl bT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPlRoaXMgbWVzc2FnZSBv cmlnaW5hdGVzIGZyb20gb3V0c2lkZSBvdXIgb3JnYW5pc2F0aW9uLCBlaXRoZXIgZnJvbSBhbiBl eHRlcm5hbCBwYXJ0bmVyIG9yIHRoZSBpbnRlcm5ldC48L3NwYW4+PC9lbT48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29uc2lk ZXIgY2FyZWZ1bGx5IHdoZXRoZXIgeW91IHNob3VsZCBjbGljayBvbiBhbnkgbGlua3MsIG9wZW4g YW55IGF0dGFjaG1lbnRzIG9yIHJlcGx5Ljwvc3Bhbj48L2VtPjxicj4NCjxlbT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Rm9yIGluZm9ybWF0aW9uIHJlZ2FyZGluZyA8L3NwYW4+DQo8L2VtPjwvc3Bhbj48L2k+PHN0cm9u Zz48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVkIEZsYWdzPC9zcGFu PjwvaT48L3N0cm9uZz48ZW0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMzMzOTcy Ij4gdGhhdCB5b3UgY2FuIGxvb2sgb3V0IGZvciBpbiBlbWFpbHMgeW91IHJlY2VpdmUsDQogY2xp Y2sgPGEgaHJlZj0iaHR0cDovL2ludHJhbmV0LmVudC5iYWVzeXN0ZW1zLmNvbS9ob3d3ZXdvcmsv c2VjdXJpdHkvc3BvdGxpZ2h0cy9Eb2N1bWVudHMvUmVkJTIwRmxhZ3MucGRmIiB0YXJnZXQ9Il9i bGFuayI+DQpoZXJlPC9hPi48L3NwYW4+PC9lbT48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMzMzM5NzIiPjxicj4NCjxlbT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWYgeW91IGZlZWwgdGhlIGVtYWls IGlzIHN1c3BpY2lvdXMsIHBsZWFzZSBmb2xsb3cNCjxhIGhyZWY9Imh0dHA6Ly9pbnRyYW5ldC5l bnQuYmFlc3lzdGVtcy5jb20vaG93d2V3b3JrL3NlY3VyaXR5L3Nwb3RsaWdodHMvRG9jdW1lbnRz L0RlYWxpbmclMjBXaXRoJTIwU3VzcGljaW91cyUyMEVtYWlscy5wZGYiIHRhcmdldD0iX2JsYW5r Ij4NCnRoaXMgcHJvY2VzczwvYT4uPC9zcGFuPjwvZW0+PC9zcGFuPjwvaT48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBKaWF6 aSwgYW5kIHRoYW5rcyBmb3IgeW91ciBjb21tZW50cyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIGlzIHBhcnQgb2YgYW4gb25nb2luZyBkaXNj dXNzaW9uLiBUaGUgY3VycmVudCBkcmFmdCBpbXBsaWVzIHRoYXQgYmVjYXVzZSB0aGVyZSBhcmUg dHdvIGFkZHJlc3NlcyBpbiBhIFJSRVEsIHRoZW4gaWYgb25lIGlzIG1hcmtlZCBhcyBPcmlnQWRk ciBieSBoYXZpbmcgYW4gYXNzb2NpYXRlZCBPcmlnU2VxTnVtDQogKG9yIE9SSUdfU0VRX05VTSkg VExWLCB0aGUgb3RoZXIgYWRkcmVzcyBtdXN0IGJlIFRhcmdBZGRyLiBpLmUgaW4gYSBSUkVRLCB3 ZSBjYW4gaW50ZXJwcmV0IGFuIGFkZHJlc3Mgd2l0aG91dCBhbiBhc3NvY2lhdGVkIFRMViBhcyBU YXJnQWRkci4gQnkgZG9pbmcgaXQgdGhpcyB3YXksIHdlIHNhdmUgdGhlIGxlbmd0aCBvZiB0aGUg VExWIHdlIG1pZ2h0IGhhdmUgYXNzb2NpYXRlZCB3aXRoIFRhcmdBZGRyLiBGdXJ0aGVyLCB0aGlz IGFwcGxpZWQgdG8NCiBvdGhlciBtZXNzYWdlcyAtIHRoZSBtZWFuaW5nIG9mIGFuIHVubWFya2Vk IGFkZHJlc3MgaXMgZGVkdWNlZCBmcm9tIHRoZSBtZXNzYWdlIHR5cGUuJm5ic3A7Rm9yIFJSRVAs IGFuIGFkZHJlc3Mgd2l0aG91dCBhbiBhc3NvY2lhdGVkIFRMViBpcyBPcmlnQWRkci4gRm9yIFJF UlIsIGFsbCB1bm1hcmtlZCBhZGRyZXNzZXMgYXJlIHVucmVhY2hhYmxlIGRlc3RpbmF0aW9ucy4g SW4gUkVSUiwgd2UgbWFyayB0aGUgUGt0U291cmNlIGFkZHJlc3Mgd2l0aCBpdHMNCiBvd24gUGt0 U291cmNlIChQS1RfU09VUkNFKSBUTFYgdG8gZGlmZmVyZW50aWF0ZSBmcm9tIHRoZSB1bnJlYWNo YWJsZSBhZGRyZXNzZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JZiBpbiBmdXR1cmUsIHdlIGRlY2lkZWQgdG8gYWRkIGFuIG5ldyB0 eXBlIG9mIGFkZHJlc3MgaW50byBhIG1lc3NhZ2UgZm9yIHNvbWUgcmVhc29uLCB0aGF0IGFkZHJl c3MgTVVTVCBoYXZlIGEgVExWIGFzc29jaWF0ZWQgd2l0aCBpdCB0byBkaWZmZXJlbnRpYXRlLiBU aGF0IG1ha2VzIHNlbnNlIGFueXdheSwNCiB3ZSB3b3VsZCB3YW50IHRvIGluZGljYXRlIHdoYXQg dGhlIG5ldyBhZGRyZXNzIG1lYW5zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHF1ZXN0aW9uIGlzLCBpcyB0aGlzIGFjY2VwdGFi bGU/IElmIG5vdCwgbWF5YmUgd2UgaGF2ZSB0byBhY2NlcHQgYWRkaW5nIGEgVExWIHRvIGVhY2gg b2YgdGhlc2UgbWVzc2FnZXMgc28gdGhhdCB0aGVyZSBhcmUgbm8gYWRkcmVzc2VzIHdpdGhvdXQg YXNzb2NpYXRlZCBhbnkgQWRkcmVzcyBCbG9jayBUTFZzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxzbywgdGhlIG9yZGVyIG9mIGFk ZHJlc3NlcyBpbiB0aGUgQWRkcmVzcyBCbG9jayBkb2Vzbid0IG1hdHRlciBpbiBlaXRoZXIgY2Fz ZS4gQU9EVnYyIGRyYWZ0IDkgc2F5cywgaW4gdGhlIFJGQzU0NDQgUmVwcmVzZW50YXRpb24gU2Vj dGlvbiAoU2VjdGlvbiA4LCBwYWdlIDQ2KTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZxdW90O1RoZSBhZGRyZXNzZXMgaW4gYW4g QWRkcmVzcyBCbG9jayBtYXkgYXBwZWFyIGluIGFueSBvcmRlciwgYW5kIHZhbHVlczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7aW4gYW4gQWRkcmVzcyBCbG9jayBUTFYgbXVzdCBiZSBhc3NvY2lhdGVkIHdpdGggdGhlIGNv cnJlY3QgYWRkcmVzczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7aW4gdGhlIEFkZHJlc3MgQmxvY2suJm5ic3A7IFRvIGlu ZGljYXRlIHdoaWNoIGFkZHJlc3MgZWFjaCB2YWx1ZSBpczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7YXNzb2NpYXRlZCB3 aXRoLCB0aGUgQU9EVnYyIG1lc3NhZ2UgcmVwcmVzZW50YXRpb24gdXNlcyBsaXN0cyB3aGVyZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7dGhlIG9yZGVyIG9mIHRoZSBhZGRyZXNzZXMgaW4gdGhlIEFkZHJlc3NMaXN0IG1h dGNoZXMgdGhlIG9yZGVyIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt2YWx1ZXMgaW4gdGhlIG90aGVyIGxpc3RzLCBl LmcuLCBTZXFOdW1MaXN0IGluIGEgUkVSUi4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyB0aGlzIHVuY2xlYXI/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5L aW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlZpY3RvcmlhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgTWF5IDI2LCAyMDE1IGF0IDEyOjE5IEFN LCBKaWF6aSBZSSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAamlheml5aS5jb20iIHRhcmdldD0i X2JsYW5rIj5pZXRmQGppYXppeWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiBJIHVuZGVyc3RhbmQgd2VsbCwgd2Ugc3Rp bGwgbmVlZCB0aGUgZXhpc3RlbmNlIGFuZCB0aGUgb3JkZXIgaW4gdGhlIGFkZHJlc3MgYmxvY2ss IHRvIGlkZW50aWZ5IHRoZSB1c2FnZSBvZiBhZGRyZXNzZXM/Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIGV4YW1wbGUsIHNlY3Rpb24g OC4xOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxoND48YSBuYW1l PSIxNGQ5NTA4MzQ5YTE2YTVlXzE0ZDhkNjAzZjZmZDUzYjZfc2VjdGlvIj48L2E+PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTA5I3Nl Y3Rpb24tOC4xLjMiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjgu MS4zPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPi4mbmJzcDsNCiBBZGRyZXNzIEJsb2NrPC9zcGFuPjxvOnA+PC9v OnA+PC9oND4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg QSBSUkVRIGNvbnRhaW5zIHR3byBBZGRyZXNzZXMsIE9yaWdBZGRyIGFuZCBUYXJnQWRkciwgYW5k IGVhY2g8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFkZHJlc3MgaGFzIGFuIGFzc29jaWF0 ZWQgcHJlZml4IGxlbmd0aC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 IERhdGEgRWxlbWVudHMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCBBZGRyZXNzIEJsb2NrJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgT3JpZ0FkZHIvT3JpZ1ByZWZpeExlbiZuYnNw OyB8ICZsdDthZGRyZXNzJmd0OyAmIzQzOyAmbHQ7cHJlZml4LWxlbmd0aCZndDsgJm5ic3A7fDwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0 O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCBUYXJnQWRkci9UYXJnUHJlZml4TGVuJm5ic3A7IHwgJmx0O2FkZHJlc3MmZ3Q7ICYjNDM7ICZs dDtwcmVmaXgtbGVuZ3RoJmd0OyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XZSBjYW4gaW5mZXIg dGhlIE9yaWdBZGRyIGJ5IHRoZSBUTFYgdHlwZSBPUklHX1NFUV9OVU0uIEhvd2V2ZXIsIHRoZSBv bmx5IGFkZHJlc3MgYmxvY2sgVExWIGZvciBUYXJnQWRkciAoVGFyZ1NlcU51bSkgaXMgb3B0aW9u YWwuIEl0IG1lYW5zIGlmIHdlIGRvbid0IGhhdmUgdGhlIFRhcmdTZXFOdW0gVExWLCBhY2NvcmRp bmcgdG8gUkZDNTQ0NCwgd2Ugd29uJ3QgYmUgYWJsZSB0byBrbm93IHdoYXQncyB0aGUgVGFyZ0Fk ZHIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+YmVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Smlhemk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgTWF5IDEzLCAy MDE1IGF0IDc6MTMgUE0sIExvdHRlIFN0ZWVuYnJpbmsgJmx0OzxhIGhyZWY9Im1haWx0bzpsb3R0 ZS5zdGVlbmJyaW5rQGZ1LWJlcmxpbi5kZSIgdGFyZ2V0PSJfYmxhbmsiPmxvdHRlLnN0ZWVuYnJp bmtAZnUtYmVybGluLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIGFsbCw8YnI+DQpGWUksIGRyYWZ0LWlldGYtbWFuZXQtYW9kdnYyLTA5 LCB3aGljaCBjaGFybGllIGp1c3QgcHVibGlzaGVkLCBhZGRyZXNzZXMgYWxsIGNvbW1lbnRzIG1h ZGUgaW4gdGhpcyB0aHJlYWQuIEFueSBmZWVkYmFjayBpcyB2ZXJ5IHdlbGNvbWUhPGJyPg0KPGJy Pg0KUmVnYXJkcyw8YnI+DQpMb3R0ZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCkFtIDEzLjA1LjIwMTUgdW0gMTY6MzMgc2NocmllYiBE ZWFybG92ZSwgQ2hyaXN0b3BoZXIgKFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzLmRlYXJs b3ZlQGJhZXN5c3RlbXMuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXMuZGVhcmxvdmVAYmFlc3lz dGVtcy5jb208L2E+Jmd0Ozo8YnI+DQo8YnI+DQomZ3Q7IEkgZG9uJ3QgaGF2ZSB0aW1lIHRvIGxv b2sgYXQgdGhpcyB0b2RheSwgYnV0IEhlbm5pbmcncyBzdWdnZXN0aW9uIGxvb2tzIGdvb2QuPGJy Pg0KJmd0Ozxicj4NCiZndDsgLS08YnI+DQomZ3Q7IENocmlzdG9waGVyIERlYXJsb3ZlPGJyPg0K Jmd0OyBTZW5pb3IgUHJpbmNpcGFsIEVuZ2luZWVyPGJyPg0KJmd0OyBCQUUgU3lzdGVtcyBBcHBs aWVkIEludGVsbGlnZW5jZTxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUOiZuYnNwOyA8YSBocmVmPSJ0ZWw6JTJCNDQlMjAlMjgwJTI5MTI0NSUyMDI0MjE5 NCIgdGFyZ2V0PSJfYmxhbmsiPiYjNDM7NDQgKDApMTI0NSAyNDIxOTQ8L2E+Jm5ic3A7IHwmbmJz cDsgRToNCjxhIGhyZWY9Im1haWx0bzpjaHJpcy5kZWFybG92ZUBiYWVzeXN0ZW1zLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmNocmlzLmRlYXJsb3ZlQGJhZXN5c3RlbXMuY29tPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7IEJBRSBTeXN0ZW1zIEFwcGxpZWQgSW50ZWxsaWdlbmNlLCBDaGVsbXNmb3JkIFRl Y2hub2xvZ3kgUGFyaywgR3JlYXQgQmFkZG93LCBDaGVsbXNmb3JkLCBFc3NleCBDTTIgOEhOLjxi cj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5iYWVzeXN0ZW1zLmNvbS9haSIgdGFyZ2V0PSJf YmxhbmsiPnd3dy5iYWVzeXN0ZW1zLmNvbS9haTwvYT48YnI+DQomZ3Q7IEJBRSBTeXN0ZW1zIEFw cGxpZWQgSW50ZWxsaWdlbmNlIExpbWl0ZWQ8YnI+DQomZ3Q7IFJlZ2lzdGVyZWQgaW4gRW5nbGFu ZCAmYW1wOyBXYWxlcyBObzogMDEzMzc0NTE8YnI+DQomZ3Q7IFJlZ2lzdGVyZWQgT2ZmaWNlOiBT dXJyZXkgUmVzZWFyY2ggUGFyaywgR3VpbGRmb3JkLCBTdXJyZXksIEdVMiA3WVA8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiBIZW5uaW5nIFJvZ2dlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmhy b2dnZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ocm9nZ2VAZ21haWwuY29tPC9hPl08YnI+ DQomZ3Q7IFNlbnQ6IDEzIE1heSAyMDE1IDE1OjExPGJyPg0KJmd0OyBUbzogTG90dGUgU3RlZW5i cmluazxicj4NCiZndDsgQ2M6IERlYXJsb3ZlLCBDaHJpc3RvcGhlciAoVUspOyA8YSBocmVmPSJt YWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm1hbmV0QGlldGYub3JnPC9h Pjxicj4NCiZndDsgU3ViamVjdDogUmU6IFttYW5ldF0gUkZDIDU0NDQgdHJhbnNsYXRpb24gdGFi bGVzPGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSEgV0FSTklORyAh IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gVGhpcyBtZXNzYWdlIG9yaWdpbmF0ZXMgZnJvbSBvdXRz aWRlIG91ciBvcmdhbmlzYXRpb24sIGVpdGhlciBmcm9tIGFuIGV4dGVybmFsIHBhcnRuZXIgb3Ig ZnJvbSB0aGUgaW50ZXJuZXQuPGJyPg0KJmd0OyBDb25zaWRlciBjYXJlZnVsbHkgd2hldGhlciB5 b3Ugc2hvdWxkIGNsaWNrIG9uIGFueSBsaW5rcywgb3BlbiBhbnkgYXR0YWNobWVudHMgb3IgcmVw bHkuPGJyPg0KJmd0OyBGb2xsb3cgdGhlICdSZXBvcnQgU3VzcGljaW91cyBFbWFpbHMnIGxpbmsg b24gSVQgbWF0dGVycyBmb3IgaW5zdHJ1Y3Rpb25zIG9uIHJlcG9ydGluZyBzdXNwaWNpb3VzIGVt YWlsIG1lc3NhZ2VzLjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBXZWQsIE1heSAx MywgMjAxNSBhdCAzOjU1IFBNLCBMb3R0ZSBTdGVlbmJyaW5rICZsdDs8YSBocmVmPSJtYWlsdG86 bG90dGUuc3RlZW5icmlua0BmdS1iZXJsaW4uZGUiIHRhcmdldD0iX2JsYW5rIj5sb3R0ZS5zdGVl bmJyaW5rQGZ1LWJlcmxpbi5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7IEhpIENocmlz dG9waGVyLDxicj4NCiZndDsmZ3Q7IHRoYW5rcyBmb3IgeW91ciBmZWVkYmFjay48YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IEFtIDA3LjA1LjIwMTUgdW0gMTI6MDAgc2NocmllYiBEZWFybG92 ZSwgQ2hyaXN0b3BoZXIgKFVLKTxicj4NCiZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Y2hy aXMuZGVhcmxvdmVAYmFlc3lzdGVtcy5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpcy5kZWFybG92 ZUBiYWVzeXN0ZW1zLmNvbTwvYT4mZ3Q7Ojxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhl cmUgaXMgYSBzdHlsZSBxdWVzdGlvbiB0aGF0IGFsbCBleGlzdGluZyBUTFZzIGhhdmUgbmFtZXMg bGlrZTxicj4NCiZndDsmZ3Q7IExJTktfU1RBVFVTLCB3aGlsZSBoZXJlIFRMVnMgaGF2ZSBuYW1l cyBsaWtlIE9yaWdTZXFOdW0uIEkgZG9u4oCZdCB0aGluazxicj4NCiZndDsmZ3Q7IElBTkEgZW5m b3JjZSBzdWNoIGlzc3VlcywgYW5kIGRpZmZlcmVudCBwZW9wbGUgd2lsbCBoYXZlIGRpZmZlcmVu dDxicj4NCiZndDsmZ3Q7IG9waW5pb25zIG9uIHRoZSBpbXBvcnRhbmNlIG9mIGNvbnNpc3RlbnQg c3R5bGUuIChOYW1pbmcgY2FuIG1hdHRlciw8YnI+DQomZ3Q7Jmd0OyB3ZeKAmXJlIHNwZW5kaW5n IGN5Y2xlcyBvbiBhbiBJRCBqdXN0IGFib3V0IFRMViBuYW1lcy4pPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQWJzb2x1dGVseS4gSW4geW91 ciBvcGluaW9uLCB3b3VsZCBpdCBzdWZmaWNlIHRvIGFkanVzdCB0aGUgY3VycmVudDxicj4NCiZn dDsmZ3Q7IG5hbWVzIHN0eWxpc3RpY2FsbHkgKHNlZSBhdHRhY2hlZCBmaWxlKSwgb3IgZG8gc29t ZSBuYW1lcyBuZWVkIGV4dHJhPGJyPg0KJmd0OyZndDsgd29yayBpbiB0ZXJtcyBvZiBjbGFyaWZp Y2F0aW9uIG9yIGNvbnNpc3RlbmN5PyAoSSB3YXMganVzdCB3b25kZXJpbmc8YnI+DQomZ3Q7Jmd0 OyBpZiBNRVRSSUMgc2hvdWxkIGJlIGVkaXRlZCB0byBtYWtlIGNsZWFyIHRoYXQgaXQgaXMgbm90 IGRpcmVjdGx5PGJyPg0KJmd0OyZndDsgcmVsYXRlZCB0byBMSU5LX01FVFJJQy4uLik8YnI+DQom Z3Q7PGJyPg0KJmd0OyBNYXliZSB0aGUgbmFtZSAmcXVvdDtQQVRIX01FVFJJQyZxdW90OyB3b3Vs ZCBtYWtlIHNlbnNlIGZvciB0aGUgbmV3IFRMVi4uLiB0aGlzIGRlc2NyaWJlcyB0aGUgdXNhZ2Ug b2YgdGhlIFRMViB2ZXJ5IHdlbGwuPGJyPg0KJmd0Ozxicj4NCiZndDsgSGVubmluZyBSb2dnZTxi cj4NCiZndDsgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKio8YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIHRvIHRoZSBpbnRlbmRlZDxicj4NCiZndDsgcmVjaXBpZW50 IGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQ8 YnI+DQomZ3Q7IHJlY2lwaWVudCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0gYW5k IG5vdGlmeSB0aGUgc2VuZGVyLjxicj4NCiZndDsgWW91IHNob3VsZCBub3QgY29weSBpdCBvciB1 c2UgaXQgZm9yIGFueSBwdXJwb3NlIG5vciBkaXNjbG9zZSBvcjxicj4NCiZndDsgZGlzdHJpYnV0 ZSBpdHMgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbi48YnI+DQomZ3Q7ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQptYW5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptYW5ldCBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bWFuZXRAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tYW5ldEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21hbmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tYW5ldDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D40EEC6ADGLKXM0002VGREEN_-- From nobody Wed May 27 08:11:17 2015 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 845D91B2CF7 for ; Wed, 27 May 2015 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 frDRD_AV_8jC for ; Wed, 27 May 2015 08:11:11 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD501A1A28 for ; Wed, 27 May 2015 08:11:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,506,1427752800"; d="scan'208";a="155532718" Received: from zmbs4.inria.fr ([128.93.142.17]) by mail2-relais-roc.national.inria.fr with ESMTP; 27 May 2015 17:11:08 +0200 Date: Wed, 27 May 2015 17:11:08 +0200 (CEST) From: Philippe Jacquet To: Jiazi YI Message-ID: <1697994246.8992635.1432739468584.JavaMail.zimbra@inria.fr> In-Reply-To: References: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.194.164.55] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - SAF8 (Mac)/8.0.9_GA_6191) Thread-Topic: I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt Thread-Index: 1w+45N9x+ET9Npz42iAmXfDVIFwC7g== Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.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: Wed, 27 May 2015 15:11:15 -0000 Hi Jiazi, I have looked at your multi path algorithm. It seems that you take as first= path the shortest (default) path. I believe this may not work properly in = some cases. For example in the scheme below D /| H | | C G |\ \| F B | | E |/ A The shortest path from A to D is the central path ABCD. If you remove it th= en your network is disconnected with A and D standing in different componen= ts, unreachable.=20 The good pair of paths in the example above is ABGHD and AEFCD. The problem= is finding the pair of disjoint paths with the shortest length sum and in = most case it does not take the shortest path. There is the classic algorith= m of Suurballe and Tarjan which is linear in the number of edges and it fin= ds the shortest cycle to all remote destinations. If we look for the k-tupl= e of pairwise disjoint path with shortest path sum there are classic soluti= ons based on easy linear programming.=20 Of course in order to have k disjoint paths we must have a network with a n= ode connectivity degree larger than k, or at least we must have the source = and destination in the same k-connected component. Another point, since OLS= R is based on reduced topology information, one must care that the MPR set = satisfies a k-coverage property (a two hope node which is covered by at lea= st k neighbor, must be covered by k MPRs).=20 I hope this helps. Philippe ----- Mail original ----- De: "Jiazi YI" =C0: "manet" Envoy=E9: Mardi 26 Mai 2015 00:32:27 Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt Dear all, As you might have seen, a new revision of olsrv2-multipath has been submitted. Sorry for the relatively delayed submission -- the birth of my new "boss" gave lots of extra work in the last two months. This revision mainly addresses previous comments from Justin (thanks very much!). Other than the editorial issues, the main changes include: - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the name change, this also releases the requirement of joining the source-route header from MP-OLSR supported router, to source routing supported router. - Making multi-path Dijkstra as a "default" algorithm for obtaining multiple paths. Other algorithms are allowed, as long as they fit the requirements defined in the document. It won't impact the interoperability. - Providing references to RFC 6554 and RFC 5095, which describes the vulnerabilities of source routing. There is one thing that I'm not sure about for the moment: currently, we defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO and TC messages separately, to identify the originators that supports source routing. I'm wondering, maybe it's better to define a *Message TLV* instead, as this feature (identifying source routing support) can be useful for other messages types also? regards Jiazi On Tue, May 26, 2015 at 12:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Mobile Ad-hoc Networks Working Group of > the IETF. > > Title : Multi-path Extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) > Authors : Jiazi Yi > Benoit Parrein > Filename : draft-ietf-manet-olsrv2-multipath-03.txt > Pages : 19 > Date : 2015-05-25 > > Abstract: > This document specifies a multi-path extension for the Optimized Link > State Routing Protocol version 2 (OLSRv2) to discover multiple > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > The interoperability with OLSRv2 is retained. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-03 > > > 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.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 27 09:15:41 2015 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 43A511A1BC8 for ; Wed, 27 May 2015 09:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 yItCUqRKly05 for ; Wed, 27 May 2015 09:15:34 -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 EC27B1A1BA3 for ; Wed, 27 May 2015 09:15:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FTOjlXYmh24kcoFMEIUNtj4qzwoIrYuRc2JUPY6xsrTMhAEfUJp3oNIbqq1zhjfW; 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.255.153]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1YxdzB-0007Jx-3G; Wed, 27 May 2015 12:15:17 -0400 Message-ID: <5565ED8E.6000201@earthlink.net> Date: Wed, 27 May 2015 09:15:10 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030405050303070808030706" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7fdbae9f0d6885afbf916d45416314eb3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 16:15:40 -0000 This is a multi-part message in MIME format. --------------030405050303070808030706 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hello Chris, On 5/27/2015 4:00 AM, Dearlove, Christopher (UK) wrote: > > Actually, you save I think two bytes not having a target address. For > significant loss of extensibility. > > I do not see the loss of extensibility. Could you provide an example where the existing design prevents extensibility? Regards, Charlie P. --------------030405050303070808030706 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hello Chris,

On 5/27/2015 4:00 AM, Dearlove, Christopher (UK) wrote:

Actually, you save I think two bytes not having a target address. For significant loss of extensibility.



I do not see the loss of extensibility. Could you provide an example where the existing design prevents extensibility?

Regards,
Charlie P.

--------------030405050303070808030706-- From nobody Wed May 27 09:20:22 2015 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 6F58B1A1BF2 for ; Wed, 27 May 2015 09:20: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 kFiH56zmC0Zu for ; Wed, 27 May 2015 09:20:20 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3301A1BD2 for ; Wed, 27 May 2015 09:20:20 -0700 (PDT) Received: by wgme6 with SMTP id e6so14229858wgm.2 for ; Wed, 27 May 2015 09:20: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=q950g3D8euytFDYJ4gQNUB5PVFnEh4nX+tCXIPk2MGM=; b=Jw/ulK6P5xlXyk8PqNlHA79yebD4GMJ5qJdieDStGXXilNkYsZ255peZwf8s1SOCz7 LgxkThoMrSV0hHqJlpTbgMHV+PNbQXhXPPp2xUs31y9hTaiZKie2WgaYGgK4cmdUIbYD N8pldEl0O3eGTIq9Nipmh4wigJD82253H6+SN/QWU7nMi3shk6MewZ4qfd0LDQYGPFn/ 6LWhbpc9xZKd+MzRFRlVFgCTBfHVMTkyGZtu795UkQ9azCW+wgaHEzLM4WX96oQPeCeH EwItaYVMMfJwD1d7xyJN45pV6TLrzV5h0COIXC1fYrO6aGI3aFZxbWYr9Idt7KxSFVYo JqQg== X-Received: by 10.180.187.170 with SMTP id ft10mr7502153wic.75.1432743618918; Wed, 27 May 2015 09:20:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Wed, 27 May 2015 09:19:58 -0700 (PDT) In-Reply-To: <5565ED8E.6000201@earthlink.net> References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> From: Henning Rogge Date: Wed, 27 May 2015 18:19:58 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "Dearlove, Christopher \(UK\)" , manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 16:20:21 -0000 On Wed, May 27, 2015 at 6:15 PM, Charlie Perkins wrote: > Hello Chris, > > On 5/27/2015 4:00 AM, Dearlove, Christopher (UK) wrote: > > Actually, you save I think two bytes not having a target address. For > significant loss of extensibility. Like I said in my earlier post, you would be (as an example) be unable to add a signature to this address. Because this would require to add a TLV. In fact you will be unable to add anything to this addresses. Henning Rogge From nobody Wed May 27 10:11:57 2015 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 9580D1A026E; Wed, 27 May 2015 10:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 wtbFqRSTsY9y; Wed, 27 May 2015 10:11:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E5791A00FE; Wed, 27 May 2015 10:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1193; q=dns/txt; s=iport; t=1432746711; x=1433956311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NmdD97yE7Z6UORBH6E6sdGeoZ5KIyLTk5HT9HBJMkpA=; b=VVSBRtPp+Ovljjd/gkAl//2Vgc8N16G9mS3qegC+LrVnB/s2kPa8ERI/ mobV7jchC5SFFxREFRAV6ZGLMbcZndsAkVHCJGM3dL2qs6OZKGbQx8pRO LLwiJ+qF/rl+gApBIHG/F2EZyFqJl2RIl7fyXo/Mv7nJ4Q4eVkXz+HRhp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBADM+WVV/4MNJK1cgxCBMgbBXgmHUAKBPjgUAQEBAQEBAYEKhCMBAQR5EAIBCEYyJQIEAQ0FiC3SAgEBAQEBAQEBAQEBAQEBAQEBAQEBGIs6hFIzB4QtAQSGa4UfhEKCPIsPgSmDcYJ/hzeHXyNhgVqBPW+BRoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="scan'208";a="153896363" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP; 27 May 2015 17:11:50 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t4RHBo9H008089 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 17:11:50 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.46]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 27 May 2015 12:11:50 -0500 From: "Alvaro Retana (aretana)" To: Barry Leiba , The IESG Thread-Topic: Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) Thread-Index: AQHQl9lHbxr34WTb9kaml4RTS8sgMZ2QIX2A Date: Wed, 27 May 2015 17:11:49 +0000 Message-ID: References: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> In-Reply-To: <20150526172732.24100.29704.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.15] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8586323D32A04A468805A88F907AFD7C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-manet-olsrv2-multitopology@ietf.org" , "manet@ietf.org" , "manet-chairs@ietf.org" Subject: Re: [manet] Barry Leiba's No Objection on draft-ietf-manet-olsrv2-multitopology-05: (with COMMENT) 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, 27 May 2015 17:11:52 -0000 On 5/26/15, 1:27 PM, "Barry Leiba" wrote: Barry: Hi! >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >Let's please have a brief, non-blocking discussion of the "updates" >status here. As I read this, I don't see how this updates either 7181 or >7188. It clearly doesn't update 7188: it's just using an extension >mechanism that was specified in 7188. Some of the registries defined in 7188 are updated in this document to fit the MT operation. The same applies to the spurious =B3XXXX=B2 reference, which really is tryi= ng to point to draft-ietf-manet-tlv-naming. >I also don't think it updates >7181, because it's specifying an optional (indeed, experimental) >extension. Here: does someone reading 7181, with no interest in >implementing this experimental extension, need to read (or even know >about) this document? I think the answer is no. Right, the answer to that is no..so I can see taking that away. Thanks! Alvaro. >(There's also the spurious "XXXX" in the updates list, which should be >removed.) From nobody Wed May 27 10:30:25 2015 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 1F67F1A8872 for ; Wed, 27 May 2015 10:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 6GKBf5FIlUUR for ; Wed, 27 May 2015 10:30:21 -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 94BF11A8888 for ; Wed, 27 May 2015 10:30:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=d+gA5OxnMSUrt5+1JyZHmtx9Vroqul324DYYXqAN+GrujFNcI5pceB3N6+U3+HG2; 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 [107.1.141.74] (helo=[192.168.255.153]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Yxf9k-0001FI-Je; Wed, 27 May 2015 13:30:18 -0400 Message-ID: <5565FEFE.304@earthlink.net> Date: Wed, 27 May 2015 10:29:34 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Henning Rogge References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac799415e1fb7a86fdeb3eb8a12f5b398b5350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 17:30:24 -0000 Hello Henning, Do you mean it is not extensible because one could not add any additional information to (in this example) the target address? I don't think that is true. Do you mean it is not extensible because one could not add more addresses? I also do not think that is true. Before going into greater detail, I wanted to find out more about the problem you have in mind. Regards, Charlie P. On 5/27/2015 9:19 AM, Henning Rogge wrote: > On Wed, May 27, 2015 at 6:15 PM, Charlie Perkins > wrote: >> Hello Chris, >> >> On 5/27/2015 4:00 AM, Dearlove, Christopher (UK) wrote: >> >> Actually, you save I think two bytes not having a target address. For >> significant loss of extensibility. > Like I said in my earlier post, you would be (as an example) be unable > to add a signature to this address. Because this would require to add > a TLV. In fact you will be unable to add anything to this addresses. > > Henning Rogge > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > From nobody Wed May 27 10:43:25 2015 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 7777B1A88A1 for ; Wed, 27 May 2015 10:43:24 -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 u50XMW7HG2Is for ; Wed, 27 May 2015 10:43:21 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B68A1A8849 for ; Wed, 27 May 2015 10:43:21 -0700 (PDT) Received: by wgez8 with SMTP id z8so16151923wge.0 for ; Wed, 27 May 2015 10:43: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:from:date:message-id:subject:to :cc:content-type; bh=qKiOTokBNXF3xLEJLBwQLxjxemHorYksXLxDOZ4l08E=; b=av8AVkXfb/tc3oXzZ3+SfHWdiUgt5qiyUTYwFpuzRI0I+k8jaOmzEARCiB24LMHkhE Gryst7K5Jfq8RKtbbZpvbuDE0ka8zx1BnaelXcbPRth92qNHvNRYiJsZbeTCjTHWU3mo srip6hPhy/3WSqrY6QQEdCjg4PL+6UjoD19cuPqUOXtAGOxAp+wtgrKWQzsNJUSyl+WR Fa4iAdHJD1Hl0cvF5iS0dy59sMAyLmJIXnZstxAsDnloCIyeDMm9y+bB9WJhSEibcYU2 NGZR5LOlB2x0ULN2v2jh1m44Nw3sCSpj/EhnNRQTlxlza/noEm25f3/kOPITmvNvx8GY x50A== X-Received: by 10.180.88.72 with SMTP id be8mr1535788wib.45.1432748599788; Wed, 27 May 2015 10:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Wed, 27 May 2015 10:42:59 -0700 (PDT) In-Reply-To: <5565FEFE.304@earthlink.net> References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> <5565FEFE.304@earthlink.net> From: Henning Rogge Date: Wed, 27 May 2015 19:42:59 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 17:43:24 -0000 On Wed, May 27, 2015 at 7:29 PM, Charlie Perkins wrote: > Hello Henning, > > Do you mean it is not extensible because one could not add any additional > information to (in this example) the target address? I don't think that is > true. If you define "address X triggers behavior Y because it has no TLVs attached" you cannot add TLVs to address X without breaking the protocol. Even if the TLVs have no meaning for AODV2. Henning From nobody Wed May 27 10:59:35 2015 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 181651A1EF3 for ; Wed, 27 May 2015 10:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_RP_MATCHES_RCVD=-0.01] 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 nQIPlCmVvM5t for ; Wed, 27 May 2015 10:59:32 -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 B79261A026A for ; Wed, 27 May 2015 10:59:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=N1tbl/PpzjZo2GupZVSEBnK5e1QzX6Pallbaho3VaXmAqo9SWeFAQgmuorFrFMN1; 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 [107.1.141.74] (helo=[192.168.255.153]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Yxfc4-0003H5-2d; Wed, 27 May 2015 13:59:32 -0400 Message-ID: <55660601.50107@earthlink.net> Date: Wed, 27 May 2015 10:59:29 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Henning Rogge References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> <5565FEFE.304@earthlink.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac781c1f1191ced4b104d4483964ccda2da350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 17:59:34 -0000 Hello Henning, The intention was, instead, to have "address X triggers behavior Y because it has no OrigSeqNum TLV attached". We do have TargSeqNum, and if in the future it is needed for extensibility, it can be used. If needed, we can include this sentence in the current specification to guide future authors of new extensions. Also I note that the basic address content of RREQ and RREP has not changed in 20 years, unless you count path accumulation, the specification of which still didn't at that time require both SeqNum TLVs to be included. If history is any guide, we may not see the need for additional addresses any time soon. But if we do, they can be added. Regards, Charlie P. On 5/27/2015 10:42 AM, Henning Rogge wrote: > On Wed, May 27, 2015 at 7:29 PM, Charlie Perkins > wrote: >> Hello Henning, >> >> Do you mean it is not extensible because one could not add any additional >> information to (in this example) the target address? I don't think that is >> true. > If you define "address X triggers behavior Y because it has no TLVs > attached" you cannot add TLVs to address X without breaking the > protocol. Even if the TLVs have no meaning for AODV2. > > Henning > From nobody Wed May 27 11:03:40 2015 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 742D81A0052 for ; Wed, 27 May 2015 11:03:40 -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 V9v337NehW4L for ; Wed, 27 May 2015 11:03:39 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B011A1B72 for ; Wed, 27 May 2015 11:03:39 -0700 (PDT) Received: by wizo1 with SMTP id o1so32440650wiz.1 for ; Wed, 27 May 2015 11:03:37 -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=6k2WzKh799xoU157QIUxoQbTAAf4ML8dplSI/f+XdW0=; b=BEbbTmTtQ71YNlUqZFTS0jIuA4AlT4lr2xoHQBsWyCP2NA0eo3QZ/H6AX96ZHnKP3F C0AKxfDXy6vChyR26OJlaDVVt5hEg2Tu5XG6IdRn/JB/5fxGhSCKhqY1LlfSrsDUrw/V Fs/dTmqcRy0qGdTlQ69uEtjUZJSMbo4/P6WVzbl4fesxZNW/itde3V6BDJkmV9WO/xMz 0fgcPc4Ss4FUZufI+G8O8WW5IFrZslsS8kwF1aq5I46y/998h9kz2pxFoq14isWJsC6c 6Hdt82s1fYDlP2xhF1EpNSw4a1E6TmIv5zMceLOI7y8Cnxfp3ykH9dI61sl6+wF+zSAN vkJA== X-Received: by 10.194.5.4 with SMTP id o4mr62415325wjo.51.1432749817886; Wed, 27 May 2015 11:03:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.27.179.86 with HTTP; Wed, 27 May 2015 11:03:17 -0700 (PDT) In-Reply-To: <55660601.50107@earthlink.net> References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> <5565FEFE.304@earthlink.net> <55660601.50107@earthlink.net> From: Henning Rogge Date: Wed, 27 May 2015 20:03:17 +0200 Message-ID: To: Charlie Perkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 18:03:40 -0000 On Wed, May 27, 2015 at 7:59 PM, Charlie Perkins wrote: > Hello Henning, > > The intention was, instead, to have > "address X triggers behavior Y because it has no OrigSeqNum TLV attached". This doesn't make sense either... how do you recognize an address added by an extension to the message? It will have no OrigSeqNum TLV attached either because it is not meant for your base protocol. Henning From nobody Wed May 27 14:05:08 2015 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 BCE0A1A6EE6 for ; Wed, 27 May 2015 14:05:06 -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 CGgkJe0WkTsI for ; Wed, 27 May 2015 14:05:03 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6573C1A1BCD for ; Wed, 27 May 2015 14:05:03 -0700 (PDT) Received: by wizk4 with SMTP id k4so125492042wiz.1 for ; Wed, 27 May 2015 14:05: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=C+pBvKoon1V/LgNAa1Oqoj69uT7SCaIff1RiX3N1iPI=; b=o4StTryrWLfDN+PDCc3FWTUK2OsyU0uzWNsBEoyXgD7qaVkJDkUfN+dyCqE+l1Huex YjBs2GmakJNqN3UD7R3gXU17g8AmHSn5bUgt10yGeL5yRrBdzbQlJcqwo6lBikRtBZiM kXMvQdzpgZtpZZLZ7FSMZl6F/I4qepj2MQvskC2UI6Vwxqhb5yz+cY754gaf6C7jNG51 h4wgibBicOsDpy2XmOB2OzLDvEiSJKKDal/kNKCi05WAIZxI244Orfo7hXeWWJMYSE5S bYO2JDzuUM9CqhxeWzR6XblWWTJcUru13DYW/U62E/ox5UaSTxp1DVA6zU4AhSPRDpO8 4AQA== MIME-Version: 1.0 X-Received: by 10.180.198.166 with SMTP id jd6mr53281566wic.48.1432760702147; Wed, 27 May 2015 14:05:02 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.220.134 with HTTP; Wed, 27 May 2015 14:05:02 -0700 (PDT) In-Reply-To: <1697994246.8992635.1432739468584.JavaMail.zimbra@inria.fr> References: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> <1697994246.8992635.1432739468584.JavaMail.zimbra@inria.fr> Date: Wed, 27 May 2015 23:05:02 +0200 X-Google-Sender-Auth: U4Qf6Op8MDiF02KzM-pHB_KGqfM Message-ID: From: Jiazi YI To: Philippe Jacquet Content-Type: multipart/alternative; boundary=047d7b66f2f1b31fd8051716989a Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.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: Wed, 27 May 2015 21:05:06 -0000 --047d7b66f2f1b31fd8051716989a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Philippe, Thanks very much for the comments. Please check inline: On Wed, May 27, 2015 at 5:11 PM, Philippe Jacquet wrote: > Hi Jiazi, > > I have looked at your multi path algorithm. It seems that you take as > first path the shortest (default) path. I believe this may not work > properly in some cases. For example in the scheme below > D > /| > H | > | C > G |\ > \| F > B | > | E > |/ > A > The shortest path from A to D is the central path ABCD. If you remove it > then your network is disconnected with A and D standing in different > components, unreachable. > Based on the default multipath algorithm in the draft, with the given topology, B and C won't not be "removed", but related links will be punished. So the obtained path set would be something like (depending on the cost function) A-B-C-D and A-E-F-C-D. Of course, this is still not exactly the ideal pair ABGHD and AEFCD. One of the reasons that we didn't require strict disjoint paths is (even they can provide the shortest cost in total), sometimes it is probably not a good choice. For example, with the topology below: ---50 hops------- / \ / \ S----B-------------D \ / \---C-----/ It's better to choose S-B-C-D and S-B-D, than S----50hops----D and S-B-D. The latter would cause large delay variance between the paths, and make the packet scheduling more complex. So the general idea of the default algorithm is: if you can get disjoint paths, do it. But if it's with too much cost, then you can make use of used vertex. An extreme case is, it goes back to single path routing (for example, if node C doesn't exist in the above example) --- but you didn't loose anything (except additional overhead due to the source routing header), compared to single path. > > The good pair of paths in the example above is ABGHD and AEFCD. The > problem is finding the pair of disjoint paths with the shortest length su= m > and in most case it does not take the shortest path. There is the classic > algorithm of Suurballe and Tarjan which is linear in the number of edges > and it finds the shortest cycle to all remote destinations. If we look fo= r > the k-tuple of pairwise disjoint path with shortest path sum there are > classic solutions based on easy linear programming. > Thanks for providing the pointer. As said in the draft, using different algorithms won't impact interoperability, and the protocol doesn't prohibit it. In fact, it's also an experimental point (illustrated in section 1.1, experiments to be conducted). I think we can provide a reference to the Suurballe's paper, as an example of alternatives. > > Of course in order to have k disjoint paths we must have a network with a > node connectivity degree larger than k, or at least we must have the sour= ce > and destination in the same k-connected component. Another point, since > OLSR is based on reduced topology information, one must care that the MPR > set satisfies a k-coverage property (a two hope node which is covered by = at > least k neighbor, must be covered by k MPRs). > Yes, we are aware of the fact the OLSR uses reduced topology. But as I said, the algorithm only tries its best to find the k *disjoint* paths. If unfortunately, we have a topology like A---B---C---D Then we have k same paths -- but we didn't loose anything, and it won't impact interoperability. > > I hope this helps. > Thanks again Philippe, it does help a lot ! best Jiazi > > Philippe > ----- Mail original ----- > De: "Jiazi YI" > =C3=80: "manet" > Envoy=C3=A9: Mardi 26 Mai 2015 00:32:27 > Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt > > Dear all, > > As you might have seen, a new revision of olsrv2-multipath has been > submitted. Sorry for the relatively delayed submission -- the birth of my > new "boss" gave lots of extra work in the last two months. > > This revision mainly addresses previous comments from Justin (thanks very > much!). Other than the editorial issues, the main changes include: > > - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the name > change, this also releases the requirement of joining the source-route > header from MP-OLSR supported router, to source routing supported router. > > - Making multi-path Dijkstra as a "default" algorithm for obtaining > multiple paths. Other algorithms are allowed, as long as they fit the > requirements defined in the document. It won't impact the interoperabilit= y. > > - Providing references to RFC 6554 and RFC 5095, which describes the > vulnerabilities of source routing. > > There is one thing that I'm not sure about for the moment: currently, we > defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO an= d > TC messages separately, to identify the originators that supports source > routing. > I'm wondering, maybe it's better to define a *Message TLV* instead, as th= is > feature (identifying source routing support) can be useful for other > messages types also? > > regards > > Jiazi > > > > On Tue, May 26, 2015 at 12:09 AM, wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Mobile Ad-hoc Networks Working Group = of > > the IETF. > > > > Title : Multi-path Extension for the Optimized Link > > State Routing Protocol version 2 (OLSRv2) > > Authors : Jiazi Yi > > Benoit Parrein > > Filename : draft-ietf-manet-olsrv2-multipath-03.txt > > Pages : 19 > > Date : 2015-05-25 > > > > Abstract: > > This document specifies a multi-path extension for the Optimized Lin= k > > State Routing Protocol version 2 (OLSRv2) to discover multiple > > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > > The interoperability with OLSRv2 is retained. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-0= 3 > > > > > > 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.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --047d7b66f2f1b31fd8051716989a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Philippe,=C2=A0

Thanks very much for= the comments. Please check inline:


On Wed, May 27, 2015 at 5:11 PM, Phi= lippe Jacquet <philippe.jacquet@inria.fr> wrote:
=
Hi Jiazi,

I have looked at your multi path algorithm. It seems that you take as first= path the shortest (default) path. I believe this may not work properly in = some cases. For example in the scheme below
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D
=C2=A0 =C2=A0 =C2=A0 =C2=A0 /|
=C2=A0 =C2=A0 =C2=A0 =C2=A0H |
=C2=A0 =C2=A0 =C2=A0 =C2=A0| C
=C2=A0 =C2=A0 =C2=A0 =C2=A0G |\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 \| F
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0B |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| E
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|/
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A
The shortest path from A to D is the central path ABCD. If you remove it th= en your network is disconnected with A and D standing in different componen= ts, unreachable.

Based on the default m= ultipath algorithm in the draft, with the given topology, B and C won't= not be "removed", but related links will be punished. So the obt= ained path set would be something like (depending on the cost function)=C2= =A0

A-B-C-D =C2=A0and A-E-F-C-D.=C2=A0
<= br>
Of course, this is still not exactly the ideal pair ABGHD and= AEFCD.=C2=A0
One of the reasons that we didn't require stric= t disjoint paths is (even they can provide the shortest cost in total), =C2= =A0sometimes it is probably not a good choice. For example, with the topolo= gy below:

=C2=A0 =C2=A0
=C2=A0 ---50 hops-------
=C2=A0 =C2=A0= / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 / = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
S----B-------------D
=C2=A0 =C2=A0 =C2=A0 \ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 /
=C2= =A0 =C2=A0 =C2=A0 =C2=A0\---C-----/

It'= s better to choose S-B-C-D and S-B-D, than S----50hops----D and S-B-D. The = latter would cause large delay variance between the paths, and make the pac= ket scheduling more complex.=C2=A0

So the general = idea of the default algorithm is: if you can get disjoint paths, do it. But= if it's with too much cost, then you can make use of used vertex. An e= xtreme case is, it goes back to single path routing (for example, if node C= doesn't exist in the above example) --- but you didn't loose anyth= ing (except additional overhead due to the source routing header), compared= to single path.=C2=A0

=C2=A0

The good pair of paths in the example above is ABGHD and AEFCD. The problem= is finding the pair of disjoint paths with the shortest length sum and in = most case it does not take the shortest path. There is the classic algorith= m of Suurballe and Tarjan which is linear in the number of edges and it fin= ds the shortest cycle to all remote destinations. If we look for the k-tupl= e of pairwise disjoint path with shortest path sum there are classic soluti= ons based on easy linear programming.

T= hanks for providing the pointer. As said in the draft, using different algo= rithms won't impact interoperability, and the protocol doesn't proh= ibit it. In fact, it's also an experimental point (illustrated in secti= on 1.1, experiments to be conducted).=C2=A0
I think we can provid= e a reference to the Suurballe's paper, as an example of alternatives.= =C2=A0
=C2=A0

Of course in order to have k disjoint paths we must have a network with a n= ode connectivity degree larger than k, or at least we must have the source = and destination in the same k-connected component. Another point, since OLS= R is based on reduced topology information, one must care that the MPR set = satisfies a k-coverage property (a two hope node which is covered by at lea= st k neighbor, must be covered by k MPRs).

<= div>Yes, we are aware of the fact the OLSR uses reduced topology. But as I = said, the algorithm only tries its best to find the k *disjoint* paths. If = unfortunately, we have a topology like=C2=A0

A---B= ---C---D

Then we have k same paths -- but we didn&= #39;t loose anything, and it won't impact interoperability.=C2=A0
=
=C2=A0

I hope this helps.

Thanks again Philipp= e, it does help a lot !

best

<= div>Jiazi
=C2=A0

Philippe
----- Mail original -----
De: "Jiazi YI" <ietf@jiaziyi.com>
=C3=80: "manet" <manet@ietf.org>
Envoy=C3=A9: Mardi 26 Mai 2015 00:32:27
Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt

Dear all,

As you might have seen, a new revision of olsrv2-multipath has been
submitted. Sorry for the relatively delayed submission -- the birth of my new "boss" gave lots of extra work in the last two months.

This revision mainly addresses previous comments from Justin (thanks very much!). Other than the editorial issues, the main changes include:

=C2=A0 =C2=A0- Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the = name
change, this also releases the requirement of joining the source-route
header from MP-OLSR supported router, to source routing supported router.
=C2=A0 - Making multi-path Dijkstra as a "default" algorithm for = obtaining
multiple paths. Other algorithms are allowed, as long as they fit the
requirements defined in the document. It won't impact the interoperabil= ity.

=C2=A0 - Providing references to RFC 6554 and RFC 5095, which describes the=
vulnerabilities of source routing.

There is one thing that I'm not sure about for the moment: currently, w= e
defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HEL= LO and
TC messages separately, to identify the originators that supports sou= rce
routing.
I'm wondering, maybe it's better to define a *Message TLV* i= nstead, as this
feature (identifying source routing support) can be useful for ot= her
messages types also?

regards

Jiazi



On Tue, May 26, 2015 at 12:09 AM, <internet-drafts@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=C2=A0 This draft is a work item of the Mobile Ad-hoc Networks Working = Group of
> the IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Multi-path Extension for the Optimized Link
> State Routing Protocol version 2 (OLSRv2)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: Jiazi Yi
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Benoit Parrein
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 := draft-ietf-manet-olsrv2-multipath-03.txt
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: 19
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : 2015-05-25
>
> Abstract:
>=C2=A0 =C2=A0 This document specifies a multi-path extension for the Op= timized Link
>=C2=A0 =C2=A0 State Routing Protocol version 2 (OLSRv2) to discover mul= tiple
>=C2=A0 =C2=A0 disjoint paths, so as to improve reliability of the OLSRv= 2 protocol.
>=C2=A0 =C2=A0 The interoperability with OLSRv2 is retained.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-man= et-olsrv2-multipath/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-manet-olsrv= 2-multipath-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-= ietf-manet-olsrv2-multipath-03
>
>
> 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.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 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

--047d7b66f2f1b31fd8051716989a-- From nobody Wed May 27 14:26:47 2015 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 2C0141AC3F3 for ; Wed, 27 May 2015 14:26:44 -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 58IaSrwhmD1h for ; Wed, 27 May 2015 14:26:42 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 749291AC3ED for ; Wed, 27 May 2015 14:26:42 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so106162476wic.1 for ; Wed, 27 May 2015 14:26:41 -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=EILMJ0PAoNgVcnS9L8QSXvPNrkd/1FKsiN8RypNiSUk=; b=BdRGAW8rgZhU7PyR3lMQ6Paln99sppYBheRo/BYKcGPMUl84qLryvovZRO60UXjE75 ys9iPQfRM4Xw0mqjV29d9As3EziHPbmvv6Lsa0F1KSyw2wOOvHuF9Z3WyGbttGNVMJnS cdorcujTyPgFgHYwP85O5POMdeLkuN1RhtGTYKMdXXsYGEm+e2+6ho1R0wYl2V/6RpSt zX3iUOSCEBrzJbIbJc4uemRhKiwaW4lf7stZGzCWte5a+Uunyk3wyYd5mT96v0XnD3KL AebUZHraokaspwmbf33mREobsT1f2QQDROprf5uExCwtk/BgojOattc1pH7PzjYUhSnv eVeA== MIME-Version: 1.0 X-Received: by 10.181.11.137 with SMTP id ei9mr9526790wid.48.1432762001207; Wed, 27 May 2015 14:26:41 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.220.134 with HTTP; Wed, 27 May 2015 14:26:41 -0700 (PDT) In-Reply-To: References: <13684050-0304-4A59-9220-3E7B1178B648@fu-berlin.de> <5565ED8E.6000201@earthlink.net> <5565FEFE.304@earthlink.net> <55660601.50107@earthlink.net> Date: Wed, 27 May 2015 23:26:41 +0200 X-Google-Sender-Auth: RAac6YVMCvOICgriwzCxKKZvf-c Message-ID: From: Jiazi YI To: Henning Rogge Content-Type: multipart/alternative; boundary=f46d043892d72139d2051716e6d6 Archived-At: Cc: Charlie Perkins , manet Subject: Re: [manet] RFC 5444 translation tables 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, 27 May 2015 21:26:44 -0000 --f46d043892d72139d2051716e6d6 Content-Type: text/plain; charset=UTF-8 Hi all, On Wed, May 27, 2015 at 8:03 PM, Henning Rogge wrote: > On Wed, May 27, 2015 at 7:59 PM, Charlie Perkins > wrote: > > Hello Henning, > > > > The intention was, instead, to have > > "address X triggers behavior Y because it has no OrigSeqNum TLV > attached". > > This doesn't make sense either... > > how do you recognize an address added by an extension to the message? > It will have no OrigSeqNum TLV attached either because it is not meant > for your base protocol. > I agree with Henning. Also I note that the basic address content of RREQ and RREP has not > changed in 20 years, unless you count path accumulation, the specification > of which still didn't at that time require both SeqNum TLVs to be included. > If history is any guide, we may not see the need for additional addresses > any time soon. But if we do, they can be added. In different papers citing/extending AODV, I'm very sure that the authors throw all kinds of weird stuff in the RREQ/RREP messages for different reasons: security, backup routes, route repair, etc., etc., etc. I don't agree with all of them, but people do that :) best Jiazi > > Henning > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www.ietf.org/mailman/listinfo/manet > --f46d043892d72139d2051716e6d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

On Wed, May 27, 2015 at 8:03 PM, Henning Rogge <hrogge@g= mail.com> wrote:
On Wed, May 27, 2015 a= t 7:59 PM, Charlie Perkins
<char= les.perkins@earthlink.net> wrote:
> Hello Henning,
>
> The intention was, instead, to have
> "address X triggers behavior Y because it has no OrigSeqNum TLV a= ttached".

This doesn't make sense either...

how do you recognize an address added by an extension to the message?
It will have no OrigSeqNum TLV attached either because it is not meant
for your base protocol.

I agree with He= nning.=C2=A0

Also I note that the basic address content of RREQ and = RREP has not
changed= in 20 years, unless you count path accumulation, the specification
of which still didn't a= t that time require both SeqNum TLVs to be included.
If history is any guide, we may not see t= he need for additional addresses
any time soon.=C2=A0 But if we do, they can be added.

In different papers ci= ting/extending AODV, I'm very sure that the authors throw all kinds of= =C2=A0weird=C2=A0stuff in the RREQ/RREP messages for different reasons: sec= urity, backup routes, route repair, etc., etc., etc. I don't agree with= all of them, but people do that :)

best

J= iazi
=C2=A0

Henning

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

--f46d043892d72139d2051716e6d6-- From nobody Thu May 28 05:57:50 2015 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 429961AC3A6 for ; Thu, 28 May 2015 05:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 7xuFoYj5k0RS for ; Thu, 28 May 2015 05:57:45 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FE91A92FB for ; Thu, 28 May 2015 05:57:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,513,1427752800"; d="scan'208";a="128295177" Received: from zmbs4.inria.fr ([128.93.142.17]) by mail3-relais-sop.national.inria.fr with ESMTP; 28 May 2015 14:57:43 +0200 Date: Thu, 28 May 2015 14:57:43 +0200 (CEST) From: Philippe Jacquet To: Jiazi YI Message-ID: <1319233296.9256787.1432817863292.JavaMail.zimbra@inria.fr> In-Reply-To: References: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> <1697994246.8992635.1432739468584.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [135.245.248.73] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - GC43 (Win)/8.0.9_GA_6191) Thread-Topic: I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt Thread-Index: bCQuOtOrRE3p3v1tVJN6xPgD6323rA== Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.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: Thu, 28 May 2015 12:57:49 -0000 Thanks Jiazi, But it is one point that the existing pairs of disjoints paths do not fit s= omeone expectations, and it is another point that the algorithm you propose= does not fully achieve what it is claimed to do. I guess you should correc= t your default algorithm. =20 Best, Philippe ----- Mail original ----- De: "Jiazi YI" =C0: "Philippe Jacquet" Cc: "manet" Envoy=E9: Mercredi 27 Mai 2015 23:05:02 Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt Hi Philippe, Thanks very much for the comments. Please check inline: On Wed, May 27, 2015 at 5:11 PM, Philippe Jacquet wrote: > Hi Jiazi, > > I have looked at your multi path algorithm. It seems that you take as > first path the shortest (default) path. I believe this may not work > properly in some cases. For example in the scheme below > D > /| > H | > | C > G |\ > \| F > B | > | E > |/ > A > The shortest path from A to D is the central path ABCD. If you remove it > then your network is disconnected with A and D standing in different > components, unreachable. > Based on the default multipath algorithm in the draft, with the given topology, B and C won't not be "removed", but related links will be punished. So the obtained path set would be something like (depending on the cost function) A-B-C-D and A-E-F-C-D. Of course, this is still not exactly the ideal pair ABGHD and AEFCD. One of the reasons that we didn't require strict disjoint paths is (even they can provide the shortest cost in total), sometimes it is probably not a good choice. For example, with the topology below: ---50 hops------- / \ / \ S----B-------------D \ / \---C-----/ It's better to choose S-B-C-D and S-B-D, than S----50hops----D and S-B-D. The latter would cause large delay variance between the paths, and make the packet scheduling more complex. So the general idea of the default algorithm is: if you can get disjoint paths, do it. But if it's with too much cost, then you can make use of used vertex. An extreme case is, it goes back to single path routing (for example, if node C doesn't exist in the above example) --- but you didn't loose anything (except additional overhead due to the source routing header), compared to single path. > > The good pair of paths in the example above is ABGHD and AEFCD. The > problem is finding the pair of disjoint paths with the shortest length su= m > and in most case it does not take the shortest path. There is the classic > algorithm of Suurballe and Tarjan which is linear in the number of edges > and it finds the shortest cycle to all remote destinations. If we look fo= r > the k-tuple of pairwise disjoint path with shortest path sum there are > classic solutions based on easy linear programming. > Thanks for providing the pointer. As said in the draft, using different algorithms won't impact interoperability, and the protocol doesn't prohibit it. In fact, it's also an experimental point (illustrated in section 1.1, experiments to be conducted). I think we can provide a reference to the Suurballe's paper, as an example of alternatives. > > Of course in order to have k disjoint paths we must have a network with a > node connectivity degree larger than k, or at least we must have the sour= ce > and destination in the same k-connected component. Another point, since > OLSR is based on reduced topology information, one must care that the MPR > set satisfies a k-coverage property (a two hope node which is covered by = at > least k neighbor, must be covered by k MPRs). > Yes, we are aware of the fact the OLSR uses reduced topology. But as I said, the algorithm only tries its best to find the k *disjoint* paths. If unfortunately, we have a topology like A---B---C---D Then we have k same paths -- but we didn't loose anything, and it won't impact interoperability. > > I hope this helps. > Thanks again Philippe, it does help a lot ! best Jiazi > > Philippe > ----- Mail original ----- > De: "Jiazi YI" > =C0: "manet" > Envoy=E9: Mardi 26 Mai 2015 00:32:27 > Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt > > Dear all, > > As you might have seen, a new revision of olsrv2-multipath has been > submitted. Sorry for the relatively delayed submission -- the birth of my > new "boss" gave lots of extra work in the last two months. > > This revision mainly addresses previous comments from Justin (thanks very > much!). Other than the editorial issues, the main changes include: > > - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the name > change, this also releases the requirement of joining the source-route > header from MP-OLSR supported router, to source routing supported router. > > - Making multi-path Dijkstra as a "default" algorithm for obtaining > multiple paths. Other algorithms are allowed, as long as they fit the > requirements defined in the document. It won't impact the interoperabilit= y. > > - Providing references to RFC 6554 and RFC 5095, which describes the > vulnerabilities of source routing. > > There is one thing that I'm not sure about for the moment: currently, we > defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO an= d > TC messages separately, to identify the originators that supports source > routing. > I'm wondering, maybe it's better to define a *Message TLV* instead, as th= is > feature (identifying source routing support) can be useful for other > messages types also? > > regards > > Jiazi > > > > On Tue, May 26, 2015 at 12:09 AM, wrote: > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Mobile Ad-hoc Networks Working Group = of > > the IETF. > > > > Title : Multi-path Extension for the Optimized Link > > State Routing Protocol version 2 (OLSRv2) > > Authors : Jiazi Yi > > Benoit Parrein > > Filename : draft-ietf-manet-olsrv2-multipath-03.txt > > Pages : 19 > > Date : 2015-05-25 > > > > Abstract: > > This document specifies a multi-path extension for the Optimized Lin= k > > State Routing Protocol version 2 (OLSRv2) to discover multiple > > disjoint paths, so as to improve reliability of the OLSRv2 protocol. > > The interoperability with OLSRv2 is retained. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath-0= 3 > > > > > > 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.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 Thu May 28 06:26:35 2015 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 68EB51AC3BE; Thu, 28 May 2015 06:26:33 -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] 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 X5nYxnQqqtm6; Thu, 28 May 2015 06:26:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3614A1A87E7; Thu, 28 May 2015 06:26:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528132630.13861.80616.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 06:26:30 -0700 Archived-At: Cc: draft-ietf-manet-olsrv2-multitopology@ietf.org, manet@ietf.org, manet-chairs@ietf.org Subject: [manet] Benoit Claise's Discuss on draft-ietf-manet-olsrv2-multitopology-05: (with DISCUSS) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 13:26:33 -0000 Benoit Claise has entered the following ballot position for draft-ietf-manet-olsrv2-multitopology-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multitopology/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The multiple points, brought up by Sue part of her OPS-DIR review, deserve a DISCUSS. Let's engage in the discussion. Status of the draft: Not ready (publication wise), Almost ready (technical basis) Overall comment: First of all, as a long-term supporter of the OLSR work I am very happy to see this experimental draft that seeks to provide clear proof points of the MT-OLSR-v2 work. I believe the MT-OLSR-v2 can provide substantial benefit in the industry. My comments should be taken as a way to help the experiment provide real data points to IETF and to the industry on the successful. Real data will help the long term debate over the ADOV-v2 and OLSR-v2 work. Almost 10 years ago Don Fedyk show me some very limited theoretical analysis on where early version of these protocol fit within 802.11s work. Experimental work is critical to expansion of this work as new 802.11 and new mobile radios continue to make MANET’s work relevant for future networks. Summary of Comments: My comments have 6 major issues, and a set of editorial changes. Five of my major points have to do with adding more details to the draft to judge the experiment valuable. One way to resolve these comments is to create document providing details on the test that will be run. A second way to resolve these comments on experiment is to provide additional high-level guidance in this document. The 6th major technical point is that you have not done the IANA Section to match previous RFCs (7181, 7188). I believe Barry Lieba and IANA have already noted this issue as well. The format of the IANA section should be changed to include all the IANA registration issues. I have other editorial comments but since I have indicated a substantial section re-write due to major comments, I will be glad to review the document for final editorial comments in a second pass. Technical summary: Basically – it is a good extension of existing work. It is useful for Wireless and MANET for mobile. The authors did a good job of focusing on just the revisions. However, I am recommending more detail on the experiments will help the protocol and help to create knobs for configuration and management of the protocol. Here are the main points of the review: Status: Almost ready, but has 5 major points that will help define the experiment as a success. 1 Major point about the IANA Section. Major 1 issues are the exact definition of the tests that make it a successful experiment. (p. 7, section 4, section 5, parameters This draft needs to have the clarity of setting expectations for if the experiments succeeds. The recommended tests in major concern 1-4 could be created in a separate draft. If so, this draft should reference that draft. A few things that should be in the tests are: 1) Topologies that prove the OLSR-v2 and MT-OLSR “doesn’t break” either protocol. As previous tests of link-state protocols have shown, it is the topologies and the changes between the topologies that cause failures. Changes to topologies include migrating between topologies due to link failures or link flapping. In the OLSR-v2 and MT-OLSR world this is extremely important as mobile nodes may have radios or Wifi that fades in and out. 2) Scaling tests – what happens if the arrays round out of space? Does the route calculation for each metric type cause problems? Are there efficiencies that some implementations use to improve scaling? 3) Interoperability tests with the previous versions OSLR-v2 (can you crash an older OLSR-V2 version)? These tests should be not just two boxes but topologies of nodes connected by Wifi (802.11n, 802.11ac, 802.11k (if ready)) and other mobile radios (software defined radios, military, and others). 4) Failure tests/Error conditions (section 5) – E.g. what happens parameter arrays have repetitions in the IFACE_METRIC_TYPES. What happens if the ordering of the LINK_METRIC_TYPE.metric type does not include the ROUTER_METRIC_TYPE First? Other tests should be described. All these tests should have topologies, parameters, and results. OSLR-2 tests should pick up the theory from the benchmarking WG for testing OSPF and ISIS depends on the types of topologies that are given. For other authors, I would give more precise details. However, due to the expertise of the two authors – I gave just this high level guidance. I will be glad to work through scenarios with the authors. Major 2: Should the be a negotiation of resources sizing or just an overload bit flag when it fails? We know that overload bits have problems. So, does this experiment try to fix this in the MT-OLSR2? If not, as it goes to from scalar to arrays – how will peers know when it fails in one MT-Topology versus another? Is this experiment restricted to fate-sharing among the MT-OLSR-v2 topologies due to resources on a single? Should the negotiation of the types in the Hello have a resource constraint in the MPR-WILLING TLV? This negotiation for MT-OLSRv2 is different than the simple upgrade from OLSR to OLSRv2. It is important to know how the overload works in MT-OLSR-v2 only, and combined MT-OLSRv2 and OLSR-v2. This overload should be tested in a variety of topologies with parameters, topologies, and routing flow carefully detailed. Again, see the benchmarking drafts on OSPF and ISIS. Again, what I pose is questions that I feel the authors should consider in an experiment for this type of work. These expert authors have the capability to place additional high-level in this document (or more detail in a different document). Again, I will gladly provide the authors with feedback and review Major 3: It is not clear that the experiment is consider whether the MPR calculation per TE-metric will consume significant resources. A good benchmarking (see Major 1) would be useful. The theoretical assurance that: “Each router may make its own decision as to whether or not to use a link metric, or link metrics, for flooding MPR calculation, and if so which and how. This decision MUST be made in a manner that ensures that flooded messages will reach the same symmetric 2-hop neighbors as would be the case for a router not supporting MT-OLSRv2 (section 10, paragraph) Is not really strongly there. If this is experimental, it is important to test this point in the benchmarking. I do not really see it in the experiment. This applies to the 1-hop neighbors (both those not considered (symmetric links)) and those considered in the 2-hop consideration. The experiment should again set benchmarks for success on the MPR calculation for MT-OLSR-v2, and combined MT-OLSR-v2 and OLSR-v2 which contain several topologies, careful parameter setting, and methods to record convergence time. Major comment 4: The link between NHDP and this standard’s experiment with MPR is not clear. I expected some comment on how NHDP interacts with the MPR Tests above. This may simply be a revision of the text for the use case for MPR calculation. I expected some comment because RFC 7466 states in its abstract: Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop neighbors if the measured link quality from that 1-hop neighbor is below an acceptable threshold while still retaining the corresponding link information as acquired from the HELLO message exchange. This allows immediate reinstatement of the 1-hop neighbor if the link quality later improves sufficiently. NHDP also collects information about symmetric 2-hop neighbors. However, it specifies that if a link from a symmetric 1-hop neighbor ceases being symmetric, including while "ignored" (as described above), then corresponding symmetric 2-hop neighbors are removed. This may lead to symmetric 2-hop neighborhood information being permanently removed (until further HELLO message received) if the link quality of a symmetric 1-hop neighbor drops below the acceptable threshold, even if only for a moment. Major concern 5: Experiments should drive to create operational guidelines for deployment, configuration knobs, and use cases (ADOV-2, OLSR-v2, MT-OLSR-v2) While all these major issues are not directly operations, early experiments will help the operations people to set the management variables in section 10: 1) Reasonable TE metrics, 2) Detecting that MANET is sufficiently connected, 3) Providing guidance to deployments on performance of route sets for diff-serv in different environments (Wifi and other mobile radio nodes), 4) Determine how the mixture of OLSR-v2 and MT-OLSR-v2 work in different environments. 5) Determine how to design for OLSR-v2 and MT-OLSR-v2 networks for better MPR assignment with NHDP Major 6: The IANA section does not answer all the IANA questions. It has most of the information, but I think it is not up to the latest IANA format and information. Barry Leiba and others have noted that the RFC 7181 and RFC7188 do not match this IANA section. Rather than repeat these comments, I will simple state the data needs to be consistent and the format match IANA’s comments. From nobody Thu May 28 07:37:32 2015 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 23D8A1ACE93 for ; Thu, 28 May 2015 07:37:31 -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 e3vIfToyI5h8 for ; Thu, 28 May 2015 07:37:27 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC1A1ACDD5 for ; Thu, 28 May 2015 07:35:56 -0700 (PDT) Received: by wgbgq6 with SMTP id gq6so38337530wgb.3 for ; Thu, 28 May 2015 07:35:55 -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=V93+340L+tVOSIz1rzYPiV2NClakW7K5rVRfT7eqPuQ=; b=vf54aWZnVsqhQFWDsq1rb4Rmz8PQ1U0+gDW+jwod4KZ+Suf/6gLs+qvIM/Uy7NZZ17 gcLz0diewImleby/C58yLTOn/jsSWfV3aE6StFkL/BJv8cdaKD6FEX0SDvypwQlsXCTb CFH1IXVzKQBQpEUCvz5Ug1P+BSPiSJVnZqw1Y3D5XJ8KFgM4zYFPWLKlZTsz91f1ZgJJ YSVvDlFSvFf4egOjOHaVk4tMFEz49KpOLGihqzPPMR2mZRsmvPGIcrq85y+QMV35ZOIH B0hRYPGIvabXa/W6ypLFEBJC2qOtoQdCJ6Wl2uCXTdTP8XxwlvenSkJeTPaDBqj19FZQ 3Rtg== MIME-Version: 1.0 X-Received: by 10.181.11.137 with SMTP id ei9mr16380523wid.48.1432823755355; Thu, 28 May 2015 07:35:55 -0700 (PDT) Sender: yi.jiazi@gmail.com Received: by 10.28.220.134 with HTTP; Thu, 28 May 2015 07:35:55 -0700 (PDT) In-Reply-To: <1319233296.9256787.1432817863292.JavaMail.zimbra@inria.fr> References: <20150525220900.6623.32594.idtracker@ietfa.amsl.com> <1697994246.8992635.1432739468584.JavaMail.zimbra@inria.fr> <1319233296.9256787.1432817863292.JavaMail.zimbra@inria.fr> Date: Thu, 28 May 2015 16:35:55 +0200 X-Google-Sender-Auth: P3L1pHWtTku1W1T693QdeP8g7e4 Message-ID: From: Jiazi YI To: Philippe Jacquet Content-Type: multipart/alternative; boundary=f46d043892d7f6c1d7051725469b Archived-At: Cc: manet Subject: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.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: Thu, 28 May 2015 14:37:31 -0000 --f46d043892d7f6c1d7051725469b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Philippe, I'm not sure what "expectations" you meant here. In the assumption of the default algorithm, the expectations are: - Get disjoint paths with reasonable costs - Less variance between different paths are expected. For example, if we have topology like ---50 hops------- / \ / \ S----B-------------D Then we would rather having one path than two paths. In fact, sometimes a *best* path is desired if we want to send the most important information through the best path. For example, if we transfer SVC (scalable video coding) streams, in which the video is encoded into a set of bitstreams with different priorities. The bitstream with highest priority is sent through the best path (for basic quality), and the ones with low priority are sent through inferior paths (for enhanced quality). Meanwhile, we don't want to see too much cost difference in the paths. In fact, the default algorithm doesn't claim to explore strict disjoint paths. Maybe we didn't say it clear enough in the draft -- will clarify it in the next revision. It's normal that different scenarios have different expectations in the paths obtained, that's why we didn't prohibit the use of other algorithms. best Jiazi On Thu, May 28, 2015 at 2:57 PM, Philippe Jacquet wrote: > Thanks Jiazi, > > But it is one point that the existing pairs of disjoints paths do not fit > someone expectations, and it is another point that the algorithm you > propose does not fully achieve what it is claimed to do. I guess you shou= ld > correct your default algorithm. > > Best, > Philippe > ----- Mail original ----- > De: "Jiazi YI" > =C3=80: "Philippe Jacquet" > Cc: "manet" > Envoy=C3=A9: Mercredi 27 Mai 2015 23:05:02 > Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt > > Hi Philippe, > > Thanks very much for the comments. Please check inline: > > > On Wed, May 27, 2015 at 5:11 PM, Philippe Jacquet < > philippe.jacquet@inria.fr > > wrote: > > > Hi Jiazi, > > > > I have looked at your multi path algorithm. It seems that you take as > > first path the shortest (default) path. I believe this may not work > > properly in some cases. For example in the scheme below > > D > > /| > > H | > > | C > > G |\ > > \| F > > B | > > | E > > |/ > > A > > The shortest path from A to D is the central path ABCD. If you remove i= t > > then your network is disconnected with A and D standing in different > > components, unreachable. > > > > Based on the default multipath algorithm in the draft, with the given > topology, B and C won't not be "removed", but related links will be > punished. So the obtained path set would be something like (depending on > the cost function) > > A-B-C-D and A-E-F-C-D. > > Of course, this is still not exactly the ideal pair ABGHD and AEFCD. > One of the reasons that we didn't require strict disjoint paths is (even > they can provide the shortest cost in total), sometimes it is probably n= ot > a good choice. For example, with the topology below: > > > ---50 hops------- > / \ > / \ > S----B-------------D > \ / > \---C-----/ > > It's better to choose S-B-C-D and S-B-D, than S----50hops----D and S-B-D. > The latter would cause large delay variance between the paths, and make t= he > packet scheduling more complex. > > So the general idea of the default algorithm is: if you can get disjoint > paths, do it. But if it's with too much cost, then you can make use of us= ed > vertex. An extreme case is, it goes back to single path routing (for > example, if node C doesn't exist in the above example) --- but you didn't > loose anything (except additional overhead due to the source routing > header), compared to single path. > > > > > > > The good pair of paths in the example above is ABGHD and AEFCD. The > > problem is finding the pair of disjoint paths with the shortest length > sum > > and in most case it does not take the shortest path. There is the class= ic > > algorithm of Suurballe and Tarjan which is linear in the number of edge= s > > and it finds the shortest cycle to all remote destinations. If we look > for > > the k-tuple of pairwise disjoint path with shortest path sum there are > > classic solutions based on easy linear programming. > > > > Thanks for providing the pointer. As said in the draft, using different > algorithms won't impact interoperability, and the protocol doesn't prohib= it > it. In fact, it's also an experimental point (illustrated in section 1.1, > experiments to be conducted). > I think we can provide a reference to the Suurballe's paper, as an exampl= e > of alternatives. > > > > > > Of course in order to have k disjoint paths we must have a network with= a > > node connectivity degree larger than k, or at least we must have the > source > > and destination in the same k-connected component. Another point, since > > OLSR is based on reduced topology information, one must care that the M= PR > > set satisfies a k-coverage property (a two hope node which is covered b= y > at > > least k neighbor, must be covered by k MPRs). > > > > Yes, we are aware of the fact the OLSR uses reduced topology. But as I > said, the algorithm only tries its best to find the k *disjoint* paths. I= f > unfortunately, we have a topology like > > A---B---C---D > > Then we have k same paths -- but we didn't loose anything, and it won't > impact interoperability. > > > > > > I hope this helps. > > > > Thanks again Philippe, it does help a lot ! > > best > > Jiazi > > > > > > Philippe > > ----- Mail original ----- > > De: "Jiazi YI" > > =C3=80: "manet" > > Envoy=C3=A9: Mardi 26 Mai 2015 00:32:27 > > Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.txt > > > > Dear all, > > > > As you might have seen, a new revision of olsrv2-multipath has been > > submitted. Sorry for the relatively delayed submission -- the birth of = my > > new "boss" gave lots of extra work in the last two months. > > > > This revision mainly addresses previous comments from Justin (thanks ve= ry > > much!). Other than the editorial issues, the main changes include: > > > > - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than the name > > change, this also releases the requirement of joining the source-route > > header from MP-OLSR supported router, to source routing supported route= r. > > > > - Making multi-path Dijkstra as a "default" algorithm for obtaining > > multiple paths. Other algorithms are allowed, as long as they fit the > > requirements defined in the document. It won't impact the > interoperability. > > > > - Providing references to RFC 6554 and RFC 5095, which describes the > > vulnerabilities of source routing. > > > > There is one thing that I'm not sure about for the moment: currently, w= e > > defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO > and > > TC messages separately, to identify the originators that supports sourc= e > > routing. > > I'm wondering, maybe it's better to define a *Message TLV* instead, as > this > > feature (identifying source routing support) can be useful for other > > messages types also? > > > > regards > > > > Jiazi > > > > > > > > On Tue, May 26, 2015 at 12:09 AM, wrote: > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > This draft is a work item of the Mobile Ad-hoc Networks Working Grou= p > of > > > the IETF. > > > > > > Title : Multi-path Extension for the Optimized Link > > > State Routing Protocol version 2 (OLSRv2) > > > Authors : Jiazi Yi > > > Benoit Parrein > > > Filename : draft-ietf-manet-olsrv2-multipath-03.txt > > > Pages : 19 > > > Date : 2015-05-25 > > > > > > Abstract: > > > This document specifies a multi-path extension for the Optimized > Link > > > State Routing Protocol version 2 (OLSRv2) to discover multiple > > > disjoint paths, so as to improve reliability of the OLSRv2 protoco= l. > > > The interoperability with OLSRv2 is retained. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-multipath/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ietf-manet-olsrv2-multipath-03 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-manet-olsrv2-multipath= -03 > > > > > > > > > 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.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > 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 > > > --f46d043892d7f6c1d7051725469b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Philippe,=C2=A0

I'm n= ot sure what "expectations" you meant here. In the assumption of = the default algorithm, the expectations are:
=C2=A0 =C2=A0- Get d= isjoint paths with reasonable costs
=C2=A0 =C2=A0- Less variance = between different paths are expected. For example, if we have topology like= =C2=A0

=C2=A0 ---50 hops-------
<= div style=3D"font-size:12.8000001907349px">=C2=A0 =C2=A0/ =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
=C2=A0 / =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 \
S----B-------------D

Then we would rather having one path than two paths.=C2=A0=

In fa= ct, sometimes a *best* path is desired if we want to send the most importan= t information through the best path. For example, if we transfer SVC (scala= ble video coding) streams, in which the video is encoded into a set of bits= treams with different priorities. The bitstream with highest priority is se= nt through the best path (for basic quality), and the ones with low priorit= y are sent through inferior paths (for enhanced quality). Meanwhile, we don= 't want to see too much cost difference in the paths.=C2=A0

In fact, the defa= ult algorithm doesn't claim to explore strict disjoint paths. Maybe we = didn't say it clear enough in the draft -- will clarify it in the next = revision.=C2=A0

It's normal that different scenarios have different expectati= ons in the paths obtained, that's why we didn't prohibit the use of= other algorithms.=C2=A0

best

Jiazi


On Thu, May 28, 2015 at 2:= 57 PM, Philippe Jacquet <philippe.jacquet@inria.fr> = wrote:
Thanks Jiazi,

But it is one point that the existing pairs of disjoints paths do not fit s= omeone expectations, and it is another point that the algorithm you propose= does not fully achieve what it is claimed to do. I guess you should correc= t your default algorithm.

Best,
Philippe
----- Mail original -----
De: "Jiazi YI" <ietf@jiaziyi.com>
=C3=80: "Philippe Jacquet" <philippe.jacquet@inria.fr>
Cc: "manet" <manet@ietf.org>
Envoy=C3=A9: Mercredi 27 Mai 2015 23:05:02
Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-= 03.txt

Hi Philippe,

Thanks very much for the comments. Please check inline:


On Wed, May 27, 2015 at 5:11 PM, Philippe Jacquet <philippe.jacquet@inria.fr
> wrote:

> Hi Jiazi,
>
> I have looked at your multi path algorithm. It seems that you take as<= br> > first path the shortest (default) path. I believe this may not work > properly in some cases. For example in the scheme below
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/|
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 H |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 | C
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 G |\
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\| F
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B |
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | E
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |/
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A
> The shortest path from A to D is the central path ABCD. If you remove = it
> then your network is disconnected with A and D standing in different > components, unreachable.
>

Based on the default multipath algorithm in the draft, with the given
topology, B and C won't not be "removed", but related links w= ill be
punished. So the obtained path set would be something like (depending on the cost function)

A-B-C-D=C2=A0 and A-E-F-C-D.

Of course, this is still not exactly the ideal pair ABGHD and AEFCD.
One of the reasons that we didn't require strict disjoint paths is (eve= n
they can provide the shortest cost in total),=C2=A0 sometimes it is probabl= y not
a good choice. For example, with the topology below:


=C2=A0 ---50 hops-------
=C2=A0 =C2=A0/=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<= br> =C2=A0 /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<= br> S----B-------------D
=C2=A0 =C2=A0 =C2=A0 \=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/
=C2=A0 =C2=A0 =C2=A0 =C2=A0\---C-----/

It's better to choose S-B-C-D and S-B-D, than S----50hops----D and S-B-= D.
The latter would cause large delay variance between the paths, and make the=
packet scheduling more complex.

So the general idea of the default algorithm is: if you can get disjoint paths, do it. But if it's with too much cost, then you can make use of = used
vertex. An extreme case is, it goes back to single path routing (for
example, if node C doesn't exist in the above example) --- but you didn= 't
loose anything (except additional overhead due to the source routing
header), compared to single path.



>
> The good pair of paths in the example above is ABGHD and AEFCD. The > problem is finding the pair of disjoint paths with the shortest length= sum
> and in most case it does not take the shortest path. There is the clas= sic
> algorithm of Suurballe and Tarjan which is linear in the number of edg= es
> and it finds the shortest cycle to all remote destinations. If we look= for
> the k-tuple of pairwise disjoint path with shortest path sum there are=
> classic solutions based on easy linear programming.
>

Thanks for providing the pointer. As said in the draft, using different
algorithms won't impact interoperability, and the protocol doesn't = prohibit
it. In fact, it's also an experimental point (illustrated in section 1.= 1,
experiments to be conducted).
I think we can provide a reference to the Suurballe's paper, as an exam= ple
of alternatives.


>
> Of course in order to have k disjoint paths we must have a network wit= h a
> node connectivity degree larger than k, or at least we must have the s= ource
> and destination in the same k-connected component. Another point, sinc= e
> OLSR is based on reduced topology information, one must care that the = MPR
> set satisfies a k-coverage property (a two hope node which is covered = by at
> least k neighbor, must be covered by k MPRs).
>

Yes, we are aware of the fact the OLSR uses reduced topology. But as I
said, the algorithm only tries its best to find the k *disjoint* paths. If<= br> unfortunately, we have a topology like

A---B---C---D

Then we have k same paths -- but we didn't loose anything, and it won&#= 39;t
impact interoperability.


>
> I hope this helps.
>

Thanks again Philippe, it does help a lot !

best

Jiazi


>
> Philippe
> ----- Mail original -----
> De: "Jiazi YI" <ietf@jiaziyi.com>
> =C3=80: "manet" <manet@ietf.org>
> Envoy=C3=A9: Mardi 26 Mai 2015 00:32:27
> Objet: Re: [manet] I-D Action: draft-ietf-manet-olsrv2-multipath-03.tx= t
>
> Dear all,
>
> As you might have seen, a new revision of olsrv2-multipath has been > submitted. Sorry for the relatively delayed submission -- the birth of= my
> new "boss" gave lots of extra work in the last two months. >
> This revision mainly addresses previous comments from Justin (thanks v= ery
> much!). Other than the editorial issues, the main changes include:
>
>=C2=A0 =C2=A0 - Changing the MP_OLSRv2 TLV to SR_OLSRv2 TLV. Other than= the name
> change, this also releases the requirement of joining the source-route=
> header from MP-OLSR supported router, to source routing supported rout= er.
>
>=C2=A0 =C2=A0- Making multi-path Dijkstra as a "default" algo= rithm for obtaining
> multiple paths. Other algorithms are allowed, as long as they fit the<= br> > requirements defined in the document. It won't impact the interope= rability.
>
>=C2=A0 =C2=A0- Providing references to RFC 6554 and RFC 5095, which des= cribes the
> vulnerabilities of source routing.
>
> There is one thing that I'm not sure about for the moment: current= ly, we
> defined SR_OLSRv2 TLV as *Message-Type-specific Message TLV* for HELLO= and
> TC messages separately, to identify the originators that supports sour= ce
> routing.
> I'm wondering, maybe it's better to define a *Message TLV* ins= tead, as this
> feature (identifying source routing support) can be useful for other > messages types also?
>
> regards
>
> Jiazi
>
>
>
> On Tue, May 26, 2015 at 12:09 AM, <internet-drafts@ietf.org> wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Draft= s
> > directories.
> >=C2=A0 This draft is a work item of the Mobile Ad-hoc Networks Wor= king Group of
> > the IETF.
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: Multi-path Extension for the Optimized Link
> > State Routing Protocol version 2 (OLSRv2)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Authors=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: Jiazi Yi
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Benoit Parrein
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2=A0 =C2=A0 =C2=A0 =C2= =A0 : draft-ietf-manet-olsrv2-multipath-03.txt
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0: 19
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : 2015-05-25
> >
> > Abstract:
> >=C2=A0 =C2=A0 This document specifies a multi-path extension for t= he Optimized Link
> >=C2=A0 =C2=A0 State Routing Protocol version 2 (OLSRv2) to discove= r multiple
> >=C2=A0 =C2=A0 disjoint paths, so as to improve reliability of the = OLSRv2 protocol.
> >=C2=A0 =C2=A0 The interoperability with OLSRv2 is retained.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-iet= f-manet-olsrv2-multipath/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-manet-= olsrv2-multipath-03
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-manet-olsrv2-multipath-03
> >
> >
> > 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.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.or= g
> > https://www.ietf.org/mailman/listinfo/manet
> >
>
> _______________________________________________
> manet mailing list
> manet@ietf.org=
> https://www.ietf.org/mailman/listinfo/manet
>

--f46d043892d7f6c1d7051725469b-- From nobody Fri May 29 10:20:27 2015 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 C83441ACE5C; Fri, 29 May 2015 10:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 gCoj6HGYbz6y; Fri, 29 May 2015 10:20:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B9B1ACEA9; Fri, 29 May 2015 10:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14003; q=dns/txt; s=iport; t=1432919914; x=1434129514; h=from:to:cc:subject:date:message-id:mime-version; bh=DUeqrV08jXplGMmDxyooH9lzxUXfsrwz1Mb+jV1r79U=; b=jR8bYWqb2IArwoCBDEopZmgh3xZLXsG4OUxbRH5KCpJy13mxA3T6PD02 AS/mxohNFNecfViWTA6SX270yC28BTKT5LF9q9Y/4E25ozPw5+Gjdm3gR rkt0tpDb3tXnNY6030Jjftisk+Atmk0wU6lXhjKb2sX/hCoAojcO5EFlm w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D6AwAsnmhV/5FdJa1cgkVLVGS+IAmBXIV1gUk4FAEBAQEBAQGBCoQlBHkSAYEAJwQOiDIN1SUBAQEBAQEBAwEBAQEBAQEBFgSNEoMzBIQ0BYtVhHmCPIQ1hl2BKYNxijiHYCODeII1gQEBAQE X-IronPort-AV: E=Sophos;i="5.13,518,1427760000"; d="scan'208,217";a="154614293" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 May 2015 17:18:33 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4THIX4e000486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 17:18:33 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.46]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 29 May 2015 12:18:33 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-manet-olsrv2-management-snapshot@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-olsrv2-management-snapshot Thread-Index: AQHQmjN9xuUWupS1Uk2vmrED/50a4g== Date: Fri, 29 May 2015 17:18:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D18E1798B4444aretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "chris.dearlove@baesystems.com" , "manet@ietf.org" , "manet-chairs@ietf.org" Subject: [manet] AD Review of draft-ietf-manet-olsrv2-management-snapshot 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, 29 May 2015 17:20:25 -0000 --_000_D18E1798B4444aretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished reading this document. To start, I have a couple of high-level questions, maybe related to the his= tory: 1. The name is somewhat tentative ("snapshot=94), so I=92m wondering if = there was a specific reason the WG wanted to make emphasis on a point in ti= me. [By the fact of publishing something it is already a snapshot at that = time.] 2. The methodology presented is very open (almost sounding as =93you can= do this, but that and the other thing are also seen sometimes more or less= often=94). I=92m wondering (thinking out loud) what is the value of publi= shing this document if it represents more a narrative of potential options = than a coherent look at how OLSRv2 networks are in fact managed (at least i= n the majority case, if that exists). I know that the mobile nature of the= networks contribute to the above, but the fact that the WG (according to t= he Shepherd=92s writeup [https://datatracker.ietf.org/doc/draft-ietf-manet-= olsrv2-management-snapshot/shepherdwriteup/]) didn=92t show a lot of enthus= iasm after adoption contributes to me wondering. Other than that, my other comments are minor or nits (see below). Assuming that the WG is still in support of this document moving forward, I= am going to start the IETF Last Call and ask the Ops Directorate for an ea= rlier-than-ususal review. You can take my comments as part of the Last Cal= l comments and incorporate them before the IESG review/discussion. Thanks! Alvaro. Minor: 1. Introduction. "The MANET routing protocol OLSRv2 [RFC7181], as well a= s its constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444], [= RFC7182], [RFC7183], [RFC7187], [RFC7188] is designed to autonomously maint= ain routes across a dynamic network topology.=94 Are all these references = needed? Some of these references already update rfc7181 or rfc6130, which = I think make them superfluous at this point. [Note that I=92m not suggesti= ng not to use the specific RFCs as references elsewhere in the document if = needed, just that at this point it seems like overkill. For example, 5148,= 7188 and 7187 are only referenced here.] 2. Section 3.3 (Security Material) You made a couple of good points her= e about some networks not using any security and about the used of differen= t mechanisms for key distribution. It would be good to see some of this di= scussion in the Security Considerations section as well. 3. Section 3.4. (The Value of C). C needs to be configured; is there a = recommended initial value to be used? [If I=92m missing something obvious = about this, please point me in the right direction.] 4. Section 4.2. (External Management) * "In some deployments, the NMS communicates with individual routers= by way of SNMP - and, more commonly, by way of "proprietary" simpler, less= verbose and (often) less secure protocols, and over UDP.=94 Not issuing = a recommendation or judgement, but because this document is reflecting curr= ent practice, it would be a good idea to also mention the potential risk of= using =93less secure=94 protocols in the Security Considerations section. * =93Note that this does not constitute a recommendation, but rather= an observation..=94 While the rest of that paragraph is true, I don=92t t= hink it belongs in this document. In fact, it would be a good seed for dis= cussion around the rechartering of the WG. 5. Section 7 (This Document does not Constrain how to Manage and Monitor= MANETs) I think that this section would have a higher impact if made a su= b-section of the Introduction as it somewhat sets the tone for the rest of = the document. 6. References. I think that rfc7181 should be Normative as an understan= ding of OLSRv2 is needed to comprehend the document itself. Nits: 1. Abstract. It is not too long, but it rambles a bit. Something more = concise should do, with the rest moved to the Introduction: * NEW> * This document describes how Optimized Link State Routing protoc= ol version 2 (OLSRv2) * Routed Mobile Ad Hoc Networks (MANETs) are typically managed in= terms of * pre-deployment, as well as rationale and means of monitoring an= d management of * MANET routers, including the MANET Neighborhood Discovery Proto= col (NHDP). 2. Section 5 (What and Why do we Manage and Monitor?). * Please expand =93TC=94. * =93..by an NMS in each router=94 I think you mean here =93by inte= rnal management=94, to be consistent. --_000_D18E1798B4444aretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

I just finished reading this document.

To start, I have a couple of high-level questions, maybe related to the his= tory:
  1. The name is somewhat tentative ("snapshot=94), so I=92m wondering = if there was a specific reason the WG wanted to make emphasis on a point in= time.  [By the fact of publishing something it is already a snapshot = at that time.]
  2. The methodology presented is very open (almost sound= ing as =93you can do this, but that and the other thing are also seen somet= imes more or less often=94).  I=92m wondering (thinking out loud) what= is the value of publishing this document if it represents more a narrative of potential options than a coherent look at how OLSRv2 networ= ks are in fact managed (at least in the majority case, if that exists). &nb= sp;I know that the mobile nature of the networks contribute to the above, b= ut the fact that the WG (according to the Shepherd=92s writeup [https://datatracke= r.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/shepherdwriteup<= /a>/]) didn=92t show a lot of enthusiasm after adoption contributes to me wondering.
Other than that, my other comments are minor or nits (see below).

Assuming that the WG is still in support of this document moving forwa= rd, I am going to start the IETF Last Call and ask the Ops Directorate for = an earlier-than-ususal review.  You can take my comments as part of th= e Last Call comments and incorporate them before the IESG review/discussion.

Thanks!

Alvaro.



Minor:
  1. Introduction. "T= he MANET routing protocol OLSRv2 [RFC7181], as well as its constituent parts NHDP [RFC6130], [RFC5497], [RFC5148], [RFC5444],  [RFC7182], [RFC7183], [RFC7187]= , [RFC7188] is designed to au= tonomously maintain routes across a dynamic network topology.=94  Are all these references needed?  Some of these re= ferences already update rfc7181 or rfc6130, which I think make th= em superfluous at this point.  [Note that I=92m not suggesting no= t to use the specific RFCs as references elsewhere in the document if needed, just that at this point it seems like overkill.  For examp= le, 5148, 7188 and 7187 are only referenced here.]
  2. Section 3.3 (Security Mat= erial)  You made a couple of good points here about some networks not = using any security and about the used of different mechanisms for key distr= ibution.  It would be good to see some of this discussion in the Security Considerations section as well.<= /li>
  3. Section 3.4. (The Value of C).  C ne= eds to be configured; is there a recommended initial value to be used? &nbs= p;[If I=92m missing something obvious about this, please point me in t= he right direction.]
  4. Section 4.2.  (External Management)<= /font>
    1. "In some deployments, the NMS communicates with in= dividual routers by way of SNMP - and, more commonly, by way of "proprietary" simpler, less verbose and (often) less secure protocols, and= over UDP.=94   Not issuing a recommendation or judgement, but because= this document is reflecting current practice, it would be a good idea to also mention the potential risk of using =93less se= cure=94 protocols in the Security Considerations section.
    2. =93Note that this does not constitute a recommendation, but r= ather an observati= on..=94  While the rest of that paragraph is true, I don=92t think it belongs in this document.  In fact, = it would be a good seed for discussion around the rechartering of the = WG.
  5. Section 7 (This Document does not Constra= in how to Manage and Monitor MANETs)  I think that this section w= ould have a higher impact if made a sub-section of the Introduction as it s= omewhat sets the tone for the rest of the document.
  6. References.  I think that rfc7181 should be = Normative as an understanding of OLSRv2 is needed to comprehend the documen= t itself.

Nits:
  1. Abstract.  It is not too long, but it rambles a bit.  Something m= ore concise should do, with the rest moved to the Introduction:
    • NEW>
    •    This documen= t describes how Optimized Link State Routing protocol version 2 (OLSRv= 2)
    •    Routed Mob= ile Ad Hoc Networks (MANETs) are typically managed in terms of 
    •    pre-deployment, = as well as ra= tionale and means of monitoring and management of 
    •    MANET routers, i= ncluding the = MANET Neighborhood Discovery Protocol (NHDP).
  2. Section 5 (What and Why do we Manage and Monitor?).  
    1. Please expand =93TC=94.
    2. =93..by an NMS in each router=94  I thin= k you mean here =93by internal management=94, to be consistent.=
--_000_D18E1798B4444aretanaciscocom_-- From nobody Fri May 29 10:41:51 2015 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 1B2121B2AEB; Fri, 29 May 2015 10:41:50 -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, 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 hoJG8Xtkmho9; Fri, 29 May 2015 10:41:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A132E1AD255; Fri, 29 May 2015 10:34:08 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150529173408.21963.54698.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 10:34:08 -0700 Archived-At: Cc: manet@ietf.org Subject: [manet] Last Call: (Snapshot of OLSRv2-Routed MANET Management) to Informational RFC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 17:41:50 -0000 The IESG has received a request from the Mobile Ad-hoc Networks WG (manet) to consider the following document: - 'Snapshot of OLSRv2-Routed MANET Management' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-06-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET Neighborhood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single configuration parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-management-snapshot/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri May 29 14:42:22 2015 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 6AD461A8A9E; Fri, 29 May 2015 14:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ouG95PSB3Myc; Fri, 29 May 2015 14:42:18 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935711B2DB3; Fri, 29 May 2015 14:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1479; q=dns/txt; s=iport; t=1432935738; x=1434145338; h=from:to:cc:subject:date:message-id:mime-version; bh=fAF+VGMCyCHGFJhFKK3qsjT2kho/zsWFWzS3m6pF/EU=; b=Onn8mtoKsZPIsLVmsWC+rB0d+YhOTwgopj+VqITZ3XFOV8cTBwZ/EPVn FtH29TrOs1e05A1thwnRMKuDmFVqkj+yJ31+K+Q2098Ao+4m4oFTJftKu HNZbd4pBkIHybTfUTPvm+HDj0VWVotqYUILPVVx5a/6NPnH/YHQS4uwX8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AIBQCI3GhV/49dJa1cgkVLgTjFfoFLTAEBAQEBAYELhBkMBHkSAQsBdCcEDogy1SEBAQEBAQEBAwEBAQEBAQEBGpBJhDQFkE6CPIsSgSmDcZIYI4N4gjWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,519,1427760000"; d="scan'208,217";a="423742907" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP; 29 May 2015 21:42:18 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t4TLgHSx013726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 May 2015 21:42:17 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.46]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Fri, 29 May 2015 16:42:17 -0500 From: "Alvaro Retana (aretana)" To: "draft-ietf-manet-rfc6779bis@tools.ietf.org" Thread-Topic: AD Review of draft-ietf-manet-rfc6779bis Thread-Index: AQHQmlhUJcbxBZdnVk+WktuAudwUvw== Date: Fri, 29 May 2015 21:42:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.4] Content-Type: multipart/alternative; boundary="_000_D18E5567B451Faretanaciscocom_" MIME-Version: 1.0 Archived-At: Cc: "chris.dearlove@baesystems.com" , "manet@ietf.org" , "manet-chairs@ietf.org" Subject: [manet] AD Review of draft-ietf-manet-rfc6779bis 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, 29 May 2015 21:42:20 -0000 --_000_D18E5567B451Faretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi! I just finished looking at this document. Given that the changes wrt RFC67= 79 are minimum, I think it is ready to proceed. Before we move forward to an IETF Last Call, we need to get a MIB Doctor=92= s review, which I have requested separately. Please be on the lookout for = any comments. Thanks! Alvaro. --_000_D18E5567B451Faretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

I just finished looking at this document.  Given that the changes= wrt RFC6779 are minimum, I think it is ready to proceed.

Before we move forward to an IETF Last Call, we need to get a MIB Doct= or=92s review, which I have requested separately.  Please be on the lo= okout for any comments.

Thanks!

Alvaro.
--_000_D18E5567B451Faretanaciscocom_-- From nobody Sun May 31 04:33:24 2015 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 6B8981A89B8 for ; Sun, 31 May 2015 04:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 sJSXquN7ye2o for ; Sun, 31 May 2015 04:33:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC151A6F27 for ; Sun, 31 May 2015 04:33:21 -0700 (PDT) Received: by wgme6 with SMTP id e6so93656056wgm.2 for ; Sun, 31 May 2015 04:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:to; bh=8RsdaBd+hDWxConYhCaJY/8oC0q0EvSXz/V0+jIQ5Zg=; b=T046ywxh2eR9Crj6qyo3AoXBHIGvuUjnPh2ybts8aX16Oj+WHMhUKqDLjqDNuUvL5o 3/1FmhgoOQtZSDgz24NV+nvqo4BCoUqT62HJnvV2eLFmUClXCCwltGBNrVsnq2fXXhF1 2jjrDZh7wug6RjOo/JOPZgzo4qZwAhatz8F/U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:to; bh=8RsdaBd+hDWxConYhCaJY/8oC0q0EvSXz/V0+jIQ5Zg=; b=Sr033ElFGZc7l5jLX1K4SpRbnBqSE4Ra0rOO+1A+E8c3Hs+xkcPeRZOndKyGWU4Vp5 utny7NazNLGU03G4w7osRWNlxcRNx/bbnPkkshpt36/tTir2dN/RQWCkwQAB9oHITgvq Psz1iMZJ6/XsCPpTET1Prp0SJt23u5NCYPPKzI0dFJBfVSeb1S+4hEKUeUSVVRbDfkAr Ag7DQFbpElhWe+YvRugfoz6P0RxlppHRlxiIlfuvKfCWGo/wOZL0vgJe7pv4qajCx4YU NjK06IL6xouZATMsX4yUPJ51qoIM8CrznQPkwaT9u10zRwS/PvnGPBwzPmW9JhEVJhi7 6G3Q== X-Gm-Message-State: ALoCoQldSwFbjN7jqIjIgYmsYilTNaZ8slJ3eY+KX6gqHdQu1wp7u8Q9sVNUWiNH1AZgO9mLqI5u X-Received: by 10.180.86.168 with SMTP id q8mr11297804wiz.80.1433072000442; Sun, 31 May 2015 04:33:20 -0700 (PDT) Received: from [172.19.248.34] ([212.175.90.144]) by mx.google.com with ESMTPSA id fs9sm16818826wjc.34.2015.05.31.04.33.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 31 May 2015 04:33:17 -0700 (PDT) From: Ulrich Herberg Content-Type: multipart/alternative; boundary=Apple-Mail-8EE122DC-9736-4A4B-A673-A943A11BAAFA Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Message-Id: Date: Sun, 31 May 2015 14:33:02 +0300 References: <20150528081235.4501.97727.idtracker@ietfa.amsl.com> To: manet X-Mailer: iPad Mail (12F69) Archived-At: Subject: [manet] Fwd: New Version Notification for draft-clausen-manet-rfc5444-usage-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: Sun, 31 May 2015 11:33:24 -0000 --Apple-Mail-8EE122DC-9736-4A4B-A673-A943A11BAAFA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable As we announced previously, we have been working on a document specifying ru= les for how to use RFC5444 in MANET protocols. Well, here it is (at least in= a -00 version).=20 We'd appreciate reviews and will soon ask for WG adoption. Best regards Ulrich=20 Begin forwarded message: > From: internet-drafts@ietf.org > Date: May 28, 2015 at 11:12:35 GMT+3 > To: "Christopher Dearlove" , "Henning Rogge= " , "Thomas Clausen" , "Henning Rogge" , "Ulrich Herberg" , "Thomas H. Clausen" , "Christop= her Dearlove" , "Ulrich Herberg" > Subject: New Version Notification for draft-clausen-manet-rfc5444-usage-00= .txt >=20 >=20 > A new version of I-D, draft-clausen-manet-rfc5444-usage-00.txt > has been successfully submitted by Thomas Clausen and posted to the > IETF repository. >=20 > Name: draft-clausen-manet-rfc5444-usage > Revision: 00 > Title: Rules For Designing Protocols Using the RFC5444 Generalized P= acket/ Message Format > Document date: 2015-05-28 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-clausen-manet-r= fc5444-usage-00.txt > Status: https://datatracker.ietf.org/doc/draft-clausen-manet-rfc54= 44-usage/ > Htmlized: https://tools.ietf.org/html/draft-clausen-manet-rfc5444-us= age-00 >=20 >=20 > Abstract: > This document updates the generalized MANET packet/message format, > specified in RFC5444, by providing prescriptive guidelines for how > protocols can use that packet/message format. In particular, these > mandatory guidelines prohibit a number of uses of RFC5444 that have > been suggested in various proposals, and which would have lead to > interoperability problems, to impediment of protocol extension > development, and to inability to use generic RFC5444 parsers. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submissi= on > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail-8EE122DC-9736-4A4B-A673-A943A11BAAFA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
As we announced previously, we have be= en working on a document specifying rules for how to use RFC5444 in MANET pr= otocols. Well, here it is (at least in a -00 version). 
We'd a= ppreciate reviews and will soon ask for WG adoption.

Best regards
Ulrich 

Begin forwarded message:=

From: internet-drafts@ietf.org
Date: May 2= 8, 2015 at 11:12:35 GMT+3
To: "Christopher Dearlove" <chris.dearlove@baesystems.com>= , "Henning Rogge" <he= nning.rogge@fkie.fraunhofer.de>, "Thomas Clausen" <t.clausen@computer.org>, "Henning Rogge" &= lt;henning.rogge@fkie.fr= aunhofer.de>, "Ulrich Herberg" <ulrich@herberg.name>, "Thomas H. Clausen" <T.Clausen@computer.org>, "Christopher Dearlov= e" <chris.dearlove@baesy= stems.com>, "Ulrich Herberg" <ulrich@herberg.name>
Subject: New Version Notificatio= n for draft-clausen-manet-rfc5444-usage-00.txt


A new version of I-D,= draft-clausen-manet-rfc5444-usage-00.txt
has been successfu= lly submitted by Thomas Clausen and posted to the
IETF repos= itory.

Name:        dra= ft-clausen-manet-rfc5444-usage
Revision:    00
Title:        Rules For Designing Protocols= Using the RFC5444 Generalized Packet/ Message Format
Docume= nt date:    2015-05-28
Group:      =  Individual Submission
Pages:       &nb= sp;17
URL:         &= nbsp;  https://www.ietf.org/internet-drafts/draft-cl= ausen-manet-rfc5444-usage-00.txt
Status:   &nb= sp;     https://datatracker.ietf.org/doc/draft-= clausen-manet-rfc5444-usage/
Htmlized:    = ;   https://tools.ietf.org/html/draft-clausen-manet-rfc5444-= usage-00


Abstract:
  This document updates the generalized MANET packet= /message format,
  specified in RFC5444, by provi= ding prescriptive guidelines for how
  protocols c= an use that packet/message format.  In particular, these
  mandatory guidelines prohibit a number of uses of RFC5444 tha= t have
  been suggested in various proposals, and= which would have lead to
  interoperability prob= lems, to impediment of protocol extension
  devel= opment, and to inability to use generic RFC5444 parsers.




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.ietf.org.

The IE= TF Secretariat

= --Apple-Mail-8EE122DC-9736-4A4B-A673-A943A11BAAFA--