From nobody Sun Nov 1 03:59:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2BAF1B7D28 for ; Sun, 1 Nov 2015 03:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dmdYiVUIh70B for ; Sun, 1 Nov 2015 03:59:20 -0800 (PST) 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 BCA821B7D27 for ; Sun, 1 Nov 2015 03:59:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id AA5EB240CC0; Sun, 1 Nov 2015 03:59:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 38F662409DF; Sun, 1 Nov 2015 03:59:20 -0800 (PST) To: Michael Richardson References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5626755C.7020306@joelhalpern.com> <24811.1446214368@sandelman.ca> From: "Joel M. Halpern" Message-ID: <5635FE96.5080608@joelhalpern.com> Date: Sun, 1 Nov 2015 06:59:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <24811.1446214368@sandelman.ca> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 11:59:21 -0000 No, BGP was not a typo. I wish it were. For clarity, I was not objecting to ACP. I think we need to be clearer about the relationship between Bootstrap, GRASP, and ACP. But that is a relatively minor issue. My point was that including a good distribution design in GRASP gives us a good toolkit. In its absence, people do things like BGP-LS, using BGP as an information distribution technique. Yours, Joel On 10/30/15 10:12 AM, Michael Richardson wrote: > > Joel M. Halpern wrote: > > While i think we should be cautious about attepting to boil the ocean, > > I certainly prefer GRASP plus good distribution design as an > > information distribution mechanism rather than BGP. > > Is "BGP" a typo? Did you mean ACP? > > If so, are you suggesting that we shouldn't have an IP-based ACP, but > should rather run things on top of GRASP? > > If GRASP is going to do all these things, such as prioritzation of events, > then wouldn't we be better off to start some place like MMTQ or that other > protocol that starts with D, which I can't recall, sitting here on the > airplane. (But I'll reply once I look it up) > From nobody Sun Nov 1 04:44:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C85C1B8068 for ; Sun, 1 Nov 2015 04:44:09 -0800 (PST) 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 MGaAyPi39NkS for ; Sun, 1 Nov 2015 04:44:05 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0: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 54EDE1B8066 for ; Sun, 1 Nov 2015 04:44:05 -0800 (PST) Received: by vkgs66 with SMTP id s66so71380104vkg.1 for ; Sun, 01 Nov 2015 04:44:04 -0800 (PST) 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=bHU1Tb28x8+YrkDrjF4W4NDnieV7ND8YdmPeCheN5Dc=; b=rc9DrpEk96C7lLymXjZxr7xwV3VA5Kp0cfqRpOCKBja56WxQOKcBFHUrM/uZE3MM54 kE7Uoyy+q7BrK540q10EXHKVUdeegxXCPmgaaK0OSGQxgvvVKiymxcuulXpsTT3DlQCS 7oHdFGMGYwBGOIv3JH5dpavCCIuT/MI1R6tVL7FSSSVrYdmcz9K+KEqqSQZQfPzn7EUr IU1Iqu8JbxFUktcxoqVE+gUd2Hw/WBL3QIBiZcYCaWPPdmlQHeknYOuc5LKYT84abbtm nWTF46BDe+dwLtYwBYm5q7LbJvUCcaBD6GfFktzSJ6LM7ucUuM5CPc9VTNMMxBEm8uUS +AeA== MIME-Version: 1.0 X-Received: by 10.31.54.208 with SMTP id d199mr11192342vka.143.1446381844393; Sun, 01 Nov 2015 04:44:04 -0800 (PST) Received: by 10.103.40.132 with HTTP; Sun, 1 Nov 2015 04:44:04 -0800 (PST) In-Reply-To: <20151020161711.GB10666@cisco.com> References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> Date: Sun, 1 Nov 2015 04:44:04 -0800 Message-ID: From: John Strassner To: Toerless Eckert , John Strassner Content-Type: multipart/alternative; boundary=001a11437fe20b77a905237a040d Archived-At: Cc: Michael Richardson , "Joel M. Halpern" , reddy.pallavali@ulusofona.pt, Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 12:44:09 -0000 --001a11437fe20b77a905237a040d Content-Type: text/plain; charset=UTF-8 Hi Toerless, > Before anima, every distributed function we designed in the IETF > used its own reinvented communication paradigm. The only common > mechanism was use of IP packets, but not even that was the lowest > common denominator (IS-IS anybody). At the risk of rocking the boat, I'm less interested in using autonomics for "plumbing" issues, such as healing broken routes, as I am in correcting user- and business-oriented functions and services. We are engineers. We have a natural affinity for playing with bright, shiny knobs that provide new technologies with which to design. However, this rarely directly pays the bills. The business person typically does not care what technologies and features are used, as long as his or her service works. If it exceeds an SLA, then its scotch time as well. But there is no "gold service enable" CLI command that I've ever seen. This is why many of the autonomic projects have tried to reach above forwarding and routing and try and translate business concepts to drive network services and resources that the business needs. We've failed, rather spectacularly, so far. After 500+ conferences on Future Internet, Next Generation Networking, yada-yada-yada, we still do not have a replacement for SNMP. NFV was stillborn - it has the management capabilities of a walnut. SDN is a bit more like an apple (tastier and prettier, but still no management). I know the IETF loves to work bottom-up. But perhaps we need to have a top-down approach as well to fix this. Otherwise, the network that never fails but still doesn't provide business value is just another cool journal paper. regards, John On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert wrote: > The way i see it: > > Before anima, every distributed function we designed in the IETF > used its own reinvented communication paradigm. The only common > mechanism was use of IP packets, but not even that was the lowest common > denominator (IS-IS anybody). > > So the question really is what are the pragmatic common communication > mechanisms we can come up with to make future distributed functions > easier to implement, deploy and operate. With focus on "deploy" because > thats what we want to be autonomic. And start with what our own "anima" > distributed functions realized via "agents" need. > > We know p2p with common presentation layer and set of session transaction > types, and some limited discovery, eg: mp2mp transactions. > > The discussion now is what's logically next. Once we have an idea, then > we can figure whether it makes sense to call/put-into GRASP and/or if/how > to deal with it in ANIMA. > > > On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote: > > Hi all, > > > > Sorry, I'm a bit confused. > > > > To me, this thread is starting to discuss generic messaging system > > capabilities (e.g., at the minimum, a message broker, at the other > > end of the scale, a full-blown ESB). I didn't think that the purpose > > of the ACP included such capabilities. > > > > In other words, there is a huge difference between GRASP > > generating a notification and GRASP functioning as a full > > messaging system, complete with message transformation and > > routing, queuing, etc. > > > > I was assuming the former, not the latter. > > > > Please correct me if I am wrong. > > > > (Note that FOCALE used an ESB for inter-agent communication.) > > > > regards, > > John > > > > > > > > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter < > > brian.e.carpenter@gmail.com> wrote: > > > > > On 20/10/2015 08:04, Joel M. Halpern wrote: > > > > There are at least two different factors to consider in terms of what > > > events are communicated to the operator. > > > > > > > > First, for initial deployment of autonomic technologies, operators > will > > > want ways to observe all the events so they can gain > > > > confidence in the technology. (We received these requests with > existing > > > self-organizing network technologies.) > > > > > > > > Secondly, different operators have different degrees of information > > > harvesting and display relative to the state of the > > > > network. Even if the network is taking care of itself perfectly, > some > > > operators will want visibility to any internal state > > > > change. These operators currently monitor their routing protocol > state > > > for similar effects. > > > > > > What I get from this is a requirement that all ASAs are capable of > > > notifying events, > > > but whether and how those events are reported live to operators is a > > > separate issue. > > > > > > (However, I have never forgotten that at Three Mile Island, the system > was > > > so busy > > > reporting minor alarms that it took hours before the underlying alarm > > > message > > > saying what was really wrong got printed. TMI, indeed.) > > > > > > Brian > > > > > > > > > > > Yours, > > > > Joel > > > > > > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote: > > > >> Michael, > > > >> > > > >> Yes, for every small issue there is no need to contact operator > except, > > > >> if it is a complex one. > > > >> Even for self-healing we can use Swarm Intelligence or Artificial > > > >> Intelligence techniques, but for learning may take some time. > However, > > > >> these are scalable techniques. > > > >> Here, also there is a need of consensus, if the system is fully > > > >> distributed and asynchronous need to know which object is crashed, > how > > > >> to schedule the loads and coverage issues as well. > > > >> > > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson > > > >> > wrote: > > > >> > > > >> > > > >> John Strassner > > > > wrote: > > > >> > When an autonomic system self-heals, why would the > operator > > > >> need to > > > >> > know? This is comparable to routing doing its job and > > > >> changing the > > > >> > path. There is no reason that the operator has to be > alerted > > > >> on every > > > >> > change in the system - there are already WAY TOO MANY of > > > >> these for the > > > >> > operator to handle. > > > >> > > > >> Yes, but just the same, the healing activity needs to be an > audited > > > >> event. > > > >> The ACP should be involved in capturing these events. > > > >> > > > >> Sometimes things don't heal perfectly; often moving traffic from > > > >> one system to another causes a load spike, and while things > > > continue to > > > >> function, the performance is different. > > > >> > > > >> -- > > > >> Michael Richardson > > >> >, Sandelman Software Works > > > >> -= IPv6 IoT consulting =- > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >> Anima@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/anima > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> Thank you very much for your time and consideration. > > > >> > > > >> > > > >> Yours sincerely, > > > >> > > > >> P Radha Krishna Reddy, M.Sc, M.Tech, > > > >> > > > >> Junior Researcher/Ph.D Student, > > > >> > > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal. > > > >> > > > >> Author of: Security Issues of Cloud Computing over General & IT > Sector > > > >> Mobile: +351923095671 > > > >> www.prkreddy.webs.com > > > >> http://pt.linkedin.com/in/reddypallavali/ > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >> Anima@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/anima > > > >> > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > > Anima@ietf.org > > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > > Anima@ietf.org > > > https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > -- > > regards, > > John > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > -- > --- > Toerless Eckert, eckert@cisco.com > -- regards, John --001a11437fe20b77a905237a040d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Toerless,

> Before ani= ma, every distributed function we designed in the IETF
> used its ow= n reinvented communication paradigm. The only common
> mechanism was= use of IP packets, but not even that was the lowest
>=C2=A0co= mmon denominator (IS-IS anybody).

At the risk of r= ocking the boat, I'm less interested in using autonomics
for = "plumbing" issues, such as healing broken routes, as I am in
correcting user- and business-oriented functions and services.
<= div>
We are engineers. We have a natural affinity for playing= with bright,
shiny knobs that provide new technologies with whic= h to design.
However, this rarely directly pays the bills. The bu= siness person
typically does not care what technologies and featu= res are used, as
long as his or her service works. If it exceeds = an SLA, then its
scotch time as well.

Bu= t there is no "gold service enable" CLI command that I've eve= r seen.
This is why many of the autonomic projects have tried to = reach above
forwarding and routing and try and translate business= concepts to
drive network services and resources that the busine= ss needs.

We've failed, rather spectacularly, = so far. After 500+ conferences on
Future Internet, Next Generatio= n Networking, yada-yada-yada, we
still do not have a replacement = for SNMP.

NFV was stillborn - it has the managemen= t capabilities of a walnut.
SDN is a bit more like an apple (tast= ier and prettier, but still no
management).

<= div>I know the IETF loves to work bottom-up. But perhaps we need to
have a top-down approach as well to fix this. Otherwise, the network
that never fails but still doesn't provide business value is jus= t another
cool journal paper.

regards,
John


On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert <ec= kert@cisco.com> wrote:
The = way i see it:

Before anima, every distributed function we designed in the IETF
used its own reinvented communication paradigm. The only common
mechanism was use of IP packets, but not even that was the lowest common denominator (IS-IS anybody).

So the question really is what are the pragmatic common communication
mechanisms we can come up with to make future distributed functions
easier to implement, deploy and operate. With focus on "deploy" b= ecause
thats what we want to be autonomic. And start with what our own "anima= "
distributed functions realized via "agents" need.

We know p2p with common presentation layer and set of session transaction types, and some limited discovery, eg: mp2mp transactions.

The discussion now is what's logically next. Once we have an idea, then=
we can figure whether it makes sense to call/put-into GRASP and/or if/how to deal with it in ANIMA.


On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote:
> Hi all,
>
> Sorry, I'm a bit confused.
>
> To me, this thread is starting to discuss generic messaging system
> capabilities (e.g., at the minimum, a message broker, at the other
> end of the scale, a full-blown ESB). I didn't think that the purpo= se
> of the ACP included such capabilities.
>
> In other words, there is a huge difference between GRASP
> generating a notification and GRASP functioning as a full
> messaging system, complete with message transformation and
> routing, queuing, etc.
>
> I was assuming the former, not the latter.
>
> Please correct me if I am wrong.
>
> (Note that FOCALE used an ESB for inter-agent communication.)
>
> regards,
> John
>
>
>
> On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter <
> brian.e.carpenter@gmail= .com> wrote:
>
> > On 20/10/2015 08:04, Joel M. Halpern wrote:
> > > There are at least two different factors to consider in term= s of what
> > events are communicated to the operator.
> > >
> > > First, for initial deployment of autonomic technologies, ope= rators will
> > want ways to observe all the events so they can gain
> > > confidence in the technology.=C2=A0 (We received these reque= sts with existing
> > self-organizing network technologies.)
> > >
> > > Secondly, different operators have different degrees of info= rmation
> > harvesting and display relative to the state of the
> > > network.=C2=A0 Even if the network is taking care of itself = perfectly, some
> > operators will want visibility to any internal state
> > > change.=C2=A0 These operators currently monitor their routin= g protocol state
> > for similar effects.
> >
> > What I get from this is a requirement that all ASAs are capable o= f
> > notifying events,
> > but whether and how those events are reported live to operators i= s a
> > separate issue.
> >
> > (However, I have never forgotten that at Three Mile Island, the s= ystem was
> > so busy
> > reporting minor alarms that it took hours before the underlying a= larm
> > message
> > saying what was really wrong got printed. TMI, indeed.)
> >
> >=C2=A0 =C2=A0 Brian
> >
> > >
> > > Yours,
> > > Joel
> > >
> > > On 10/19/15 2:58 PM, Reddy Pallavali wrote:
> > >> Michael,
> > >>
> > >> Yes, for every small issue there is no need to contact o= perator except,
> > >> if it is a complex one.
> > >> Even for self-healing we can use Swarm Intelligence or A= rtificial
> > >> Intelligence techniques, but for learning may take some = time. However,
> > >> these are scalable techniques.
> > >> Here, also there is a need of consensus, if the system i= s fully
> > >> distributed and asynchronous need to know which object i= s crashed, how
> > >> to schedule the loads and coverage issues as well.
> > >>
> > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson
> > >> <mcr+ietf@= sandelman.ca <mailto:mcr+= ietf@sandelman.ca>> wrote:
> > >>
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0John Strassner <strazpdj@gmail.com <mailto:strazpdj@gmail.com>>
> > wrote:
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > When an autonomic= system self-heals, why would the operator
> > >>=C2=A0 =C2=A0 =C2=A0need to
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > know? This is com= parable to routing doing its job and
> > >>=C2=A0 =C2=A0 =C2=A0changing the
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > path. There is no= reason that the operator has to be alerted
> > >>=C2=A0 =C2=A0 =C2=A0on every
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > change in the sys= tem - there are already WAY TOO MANY of
> > >>=C2=A0 =C2=A0 =C2=A0these for the
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > operator to handl= e.
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0Yes, but just the same, the healing a= ctivity needs to be an audited
> > >>=C2=A0 =C2=A0 =C2=A0event.
> > >>=C2=A0 =C2=A0 =C2=A0The ACP should be involved in capturi= ng these events.
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0Sometimes things don't heal perfe= ctly; often moving traffic from
> > >>=C2=A0 =C2=A0 =C2=A0one system to another causes a load s= pike, and while things
> > continue to
> > >>=C2=A0 =C2=A0 =C2=A0function, the performance is differen= t.
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0--
> > >>=C2=A0 =C2=A0 =C2=A0Michael Richardson <mcr+IETF@sandelman.ca
> > >>=C2=A0 =C2=A0 =C2=A0<mailto:mcr%2BIETF@sandelman.ca>>, Sandelman Software = Works
> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0-=3D IPv6 IoT consulting =3D-<= br> > > >>
> > >>
> > >>
> > >>
> > >>=C2=A0 =C2=A0 =C2=A0_____________________________________= __________
> > >>=C2=A0 =C2=A0 =C2=A0Anima mailing list
> > >>=C2=A0 =C2=A0 =C2=A0Ani= ma@ietf.org <mailto:Anima@ietf.org= >
> > >>=C2=A0 =C2=A0 =C2=A0https://www.ietf.or= g/mailman/listinfo/anima
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> Thank you very much for your time and consideration.
> > >>
> > >>
> > >> Yours sincerely,
> > >>
> > >> P Radha Krishna Reddy, M.Sc, M.Tech,
> > >>
> > >> Junior Researcher/Ph.D Student,
> > >>
> > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal.
> > >>
> > >> Author of: Security Issues of Cloud Computing over Gener= al & IT Sector
> > >> Mobile: +351923095671
> > >> www.prkreddy.webs.com
> > >> http://pt.linkedin.com/in/reddypallavali= /
> > >>
> > >>
> > >> _______________________________________________
> > >> Anima mailing list
> > >> Anima@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/= anima
> > >>
> > >
> > > _______________________________________________
> > > Anima mailing list
> > > Anima@ietf.org
> > > https://www.ietf.org/mailman/listinfo/anim= a
> > >
> >
> > _______________________________________________
> > Anima mailing list
> > Anima@ietf.org
> > https://www.ietf.org/mailman/listinfo/anima=
> >
>
>
>
> --
> regards,
> John

> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ietf.org/mailman/listinfo/anima


--
---
Toerless Eckert, eckert@cisco.com



--
regards,
John
--001a11437fe20b77a905237a040d-- From nobody Sun Nov 1 13:15:21 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0101A901F for ; Sun, 1 Nov 2015 13:15:19 -0800 (PST) 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 CmVjXDJMJlAA for ; Sun, 1 Nov 2015 13:15:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4374D1A901D for ; Sun, 1 Nov 2015 13:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45926; q=dns/txt; s=iport; t=1446412515; x=1447622115; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RGgmn5xLQ+FCAnOeiWecDfozFWeJLRlPAM+fsujAw/A=; b=GJCtjDLBYJMm051aj24bymP36VygQ8v/OaU4I20Er+xgP9Krdhp2OrTU P4gjODU5mbAWLrXKahvp/lmIwd74IoEbMHHnWHRbODQVzvHbOKJ403pQt weEv+fiEcx6hKzTeFZKrP4A7v5hc8W3Ia3qJc/sjZ4N9Hn+exs4hITGqa g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CNBQB6fzZW/49dJa1egm5NU28GvzuBVwMXAQmCPoM6AhyBATkTAQEBAQEBAYEKhDUBAQEDAQEBASAKHB8EAQEFAwMFCwIBCA4DBAEBASABBgMCAgIfBgsUCQgCBAENBQiIEwMKCA2wdowJDYRCAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIZ3hH6BUoEBgWQyCxcJCIJfgUUFh0KHCoQag10BhRyGEoFvgWCEP45Rg1+DcQEREgI+hARyAYQzQ4EHAQEB X-IronPort-AV: E=Sophos; i="5.20,230,1444694400"; d="scan'208,217"; a="40855372" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP; 01 Nov 2015 21:15:13 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tA1LFDlc017972 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 Nov 2015 21:15:13 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 Nov 2015 15:15:12 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Sun, 1 Nov 2015 15:15:12 -0600 From: "Michael Behringer (mbehring)" To: John Strassner , "Toerless Eckert (eckert)" Thread-Topic: [Anima] [ANIMA] Self-Managed Networks Thread-Index: AQHRCpUjXjIe5GlP3E2ynPCuDySifJ5zfv6AgAABsoCAAAiQAIABUtKAgAAIIYCAErEyAIAAKTJQ Date: Sun, 1 Nov 2015 21:15:12 +0000 Message-ID: References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.175] Content-Type: multipart/alternative; boundary="_000_e4e14ce7b38c49e3b925dffc07523635XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "Joel M. Halpern" , "reddy.pallavali@ulusofona.pt" , Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 21:15:20 -0000 --_000_e4e14ce7b38c49e3b925dffc07523635XCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sm9obiwgaW4gbXkgb3BpbmlvbiwgaWYgd2UgZ2V0IHRvIHRoZSBwb2ludCBvZiBhIHNvbGlkIGF1 dG9ub21pYyBpbmZyYXN0cnVjdHVyZSB3aXRoIHRoZSByaWdodCBiYXNlIHNlcnZpY2VzLCBzdWNo IGFzIGRpc2NvdmVyeSwgbWVzc2FnaW5nLCBidWlsdCBvbiBhIHNlbGYtbWFuYWdpbmcgQUNQLCBk ZXZlbG9wcGVycyB3aWxsIGhhdmUgYWxsIHRoZSB0b29scyB0byB3cml0ZSB0aGUgZnVuY3Rpb25z IHRoYXQgeW91IHdhbnQuDQoNClRoZSBBTiBpbmZyYXN0cnVjdHVyZSBpcyB0aGUgbmV3IElQOiBs aWtlIElQIGVuYWJsZWQgZm9sa3MgdG8gd3JpdGUgbmV0d29ya2luZyBhcHBsaWNhdGlvbnMgcmVh bGx5IGVhc2lseSwgdGhlIEFOSSBhbGxvd3MgdG8gd3JpdGUgc2VsZi1tYW5hZ2VtZW50IGZ1bmN0 aW9ucyByZWFsbHkgZWFzaWx5Lg0KDQpJZiB3ZSBnZXQgQU5JIHJpZ2h0LCB3ZSBlbmFibGUgYSB3 aG9sZSBuZXcgZWNvLXN5c3RlbSBvZiBuZXR3b3JrIHByb2dyYW1taW5nLg0KDQpNaWNoYWVsDQoN CkZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IEpvaG4gU3RyYXNzbmVyDQpTZW50OiAwMSBOb3ZlbWJlciAyMDE1IDIxOjQ0DQpUbzogVG9lcmxl c3MgRWNrZXJ0IChlY2tlcnQpIDxlY2tlcnRAY2lzY28uY29tPjsgSm9obiBTdHJhc3NuZXIgPHN0 cmF6cGRqQGdtYWlsLmNvbT4NCkNjOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRl bG1hbi5jYT47IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT47IHJlZGR5LnBh bGxhdmFsaUB1bHVzb2ZvbmEucHQ7IEFuaW1hIFdHIDxhbmltYUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbQW5pbWFdIFtBTklNQV0gU2VsZi1NYW5hZ2VkIE5ldHdvcmtzDQoNCkhpIFRvZXJsZXNz LA0KDQo+IEJlZm9yZSBhbmltYSwgZXZlcnkgZGlzdHJpYnV0ZWQgZnVuY3Rpb24gd2UgZGVzaWdu ZWQgaW4gdGhlIElFVEYNCj4gdXNlZCBpdHMgb3duIHJlaW52ZW50ZWQgY29tbXVuaWNhdGlvbiBw YXJhZGlnbS4gVGhlIG9ubHkgY29tbW9uDQo+IG1lY2hhbmlzbSB3YXMgdXNlIG9mIElQIHBhY2tl dHMsIGJ1dCBub3QgZXZlbiB0aGF0IHdhcyB0aGUgbG93ZXN0DQo+IGNvbW1vbiBkZW5vbWluYXRv ciAoSVMtSVMgYW55Ym9keSkuDQoNCkF0IHRoZSByaXNrIG9mIHJvY2tpbmcgdGhlIGJvYXQsIEkn bSBsZXNzIGludGVyZXN0ZWQgaW4gdXNpbmcgYXV0b25vbWljcw0KZm9yICJwbHVtYmluZyIgaXNz dWVzLCBzdWNoIGFzIGhlYWxpbmcgYnJva2VuIHJvdXRlcywgYXMgSSBhbSBpbg0KY29ycmVjdGlu ZyB1c2VyLSBhbmQgYnVzaW5lc3Mtb3JpZW50ZWQgZnVuY3Rpb25zIGFuZCBzZXJ2aWNlcy4NCg0K V2UgYXJlIGVuZ2luZWVycy4gV2UgaGF2ZSBhIG5hdHVyYWwgYWZmaW5pdHkgZm9yIHBsYXlpbmcg d2l0aCBicmlnaHQsDQpzaGlueSBrbm9icyB0aGF0IHByb3ZpZGUgbmV3IHRlY2hub2xvZ2llcyB3 aXRoIHdoaWNoIHRvIGRlc2lnbi4NCkhvd2V2ZXIsIHRoaXMgcmFyZWx5IGRpcmVjdGx5IHBheXMg dGhlIGJpbGxzLiBUaGUgYnVzaW5lc3MgcGVyc29uDQp0eXBpY2FsbHkgZG9lcyBub3QgY2FyZSB3 aGF0IHRlY2hub2xvZ2llcyBhbmQgZmVhdHVyZXMgYXJlIHVzZWQsIGFzDQpsb25nIGFzIGhpcyBv ciBoZXIgc2VydmljZSB3b3Jrcy4gSWYgaXQgZXhjZWVkcyBhbiBTTEEsIHRoZW4gaXRzDQpzY290 Y2ggdGltZSBhcyB3ZWxsLg0KDQpCdXQgdGhlcmUgaXMgbm8gImdvbGQgc2VydmljZSBlbmFibGUi IENMSSBjb21tYW5kIHRoYXQgSSd2ZSBldmVyIHNlZW4uDQpUaGlzIGlzIHdoeSBtYW55IG9mIHRo ZSBhdXRvbm9taWMgcHJvamVjdHMgaGF2ZSB0cmllZCB0byByZWFjaCBhYm92ZQ0KZm9yd2FyZGlu ZyBhbmQgcm91dGluZyBhbmQgdHJ5IGFuZCB0cmFuc2xhdGUgYnVzaW5lc3MgY29uY2VwdHMgdG8N CmRyaXZlIG5ldHdvcmsgc2VydmljZXMgYW5kIHJlc291cmNlcyB0aGF0IHRoZSBidXNpbmVzcyBu ZWVkcy4NCg0KV2UndmUgZmFpbGVkLCByYXRoZXIgc3BlY3RhY3VsYXJseSwgc28gZmFyLiBBZnRl ciA1MDArIGNvbmZlcmVuY2VzIG9uDQpGdXR1cmUgSW50ZXJuZXQsIE5leHQgR2VuZXJhdGlvbiBO ZXR3b3JraW5nLCB5YWRhLXlhZGEteWFkYSwgd2UNCnN0aWxsIGRvIG5vdCBoYXZlIGEgcmVwbGFj ZW1lbnQgZm9yIFNOTVAuDQoNCk5GViB3YXMgc3RpbGxib3JuIC0gaXQgaGFzIHRoZSBtYW5hZ2Vt ZW50IGNhcGFiaWxpdGllcyBvZiBhIHdhbG51dC4NClNETiBpcyBhIGJpdCBtb3JlIGxpa2UgYW4g YXBwbGUgKHRhc3RpZXIgYW5kIHByZXR0aWVyLCBidXQgc3RpbGwgbm8NCm1hbmFnZW1lbnQpLg0K DQpJIGtub3cgdGhlIElFVEYgbG92ZXMgdG8gd29yayBib3R0b20tdXAuIEJ1dCBwZXJoYXBzIHdl IG5lZWQgdG8NCmhhdmUgYSB0b3AtZG93biBhcHByb2FjaCBhcyB3ZWxsIHRvIGZpeCB0aGlzLiBP dGhlcndpc2UsIHRoZSBuZXR3b3JrDQp0aGF0IG5ldmVyIGZhaWxzIGJ1dCBzdGlsbCBkb2Vzbid0 IHByb3ZpZGUgYnVzaW5lc3MgdmFsdWUgaXMganVzdCBhbm90aGVyDQpjb29sIGpvdXJuYWwgcGFw ZXIuDQoNCnJlZ2FyZHMsDQpKb2huDQoNCg0KT24gVHVlLCBPY3QgMjAsIDIwMTUgYXQgOToxNyBB TSwgVG9lcmxlc3MgRWNrZXJ0IDxlY2tlcnRAY2lzY28uY29tPG1haWx0bzplY2tlcnRAY2lzY28u Y29tPj4gd3JvdGU6DQpUaGUgd2F5IGkgc2VlIGl0Og0KDQpCZWZvcmUgYW5pbWEsIGV2ZXJ5IGRp c3RyaWJ1dGVkIGZ1bmN0aW9uIHdlIGRlc2lnbmVkIGluIHRoZSBJRVRGDQp1c2VkIGl0cyBvd24g cmVpbnZlbnRlZCBjb21tdW5pY2F0aW9uIHBhcmFkaWdtLiBUaGUgb25seSBjb21tb24NCm1lY2hh bmlzbSB3YXMgdXNlIG9mIElQIHBhY2tldHMsIGJ1dCBub3QgZXZlbiB0aGF0IHdhcyB0aGUgbG93 ZXN0IGNvbW1vbg0KZGVub21pbmF0b3IgKElTLUlTIGFueWJvZHkpLg0KDQpTbyB0aGUgcXVlc3Rp b24gcmVhbGx5IGlzIHdoYXQgYXJlIHRoZSBwcmFnbWF0aWMgY29tbW9uIGNvbW11bmljYXRpb24N Cm1lY2hhbmlzbXMgd2UgY2FuIGNvbWUgdXAgd2l0aCB0byBtYWtlIGZ1dHVyZSBkaXN0cmlidXRl ZCBmdW5jdGlvbnMNCmVhc2llciB0byBpbXBsZW1lbnQsIGRlcGxveSBhbmQgb3BlcmF0ZS4gV2l0 aCBmb2N1cyBvbiAiZGVwbG95IiBiZWNhdXNlDQp0aGF0cyB3aGF0IHdlIHdhbnQgdG8gYmUgYXV0 b25vbWljLiBBbmQgc3RhcnQgd2l0aCB3aGF0IG91ciBvd24gImFuaW1hIg0KZGlzdHJpYnV0ZWQg ZnVuY3Rpb25zIHJlYWxpemVkIHZpYSAiYWdlbnRzIiBuZWVkLg0KDQpXZSBrbm93IHAycCB3aXRo IGNvbW1vbiBwcmVzZW50YXRpb24gbGF5ZXIgYW5kIHNldCBvZiBzZXNzaW9uIHRyYW5zYWN0aW9u DQp0eXBlcywgYW5kIHNvbWUgbGltaXRlZCBkaXNjb3ZlcnksIGVnOiBtcDJtcCB0cmFuc2FjdGlv bnMuDQoNClRoZSBkaXNjdXNzaW9uIG5vdyBpcyB3aGF0J3MgbG9naWNhbGx5IG5leHQuIE9uY2Ug d2UgaGF2ZSBhbiBpZGVhLCB0aGVuDQp3ZSBjYW4gZmlndXJlIHdoZXRoZXIgaXQgbWFrZXMgc2Vu c2UgdG8gY2FsbC9wdXQtaW50byBHUkFTUCBhbmQvb3IgaWYvaG93DQp0byBkZWFsIHdpdGggaXQg aW4gQU5JTUEuDQoNCg0KT24gVHVlLCBPY3QgMjAsIDIwMTUgYXQgMDg6NDg6MDVBTSAtMDcwMCwg Sm9obiBTdHJhc3NuZXIgd3JvdGU6DQo+IEhpIGFsbCwNCj4NCj4gU29ycnksIEknbSBhIGJpdCBj b25mdXNlZC4NCj4NCj4gVG8gbWUsIHRoaXMgdGhyZWFkIGlzIHN0YXJ0aW5nIHRvIGRpc2N1c3Mg Z2VuZXJpYyBtZXNzYWdpbmcgc3lzdGVtDQo+IGNhcGFiaWxpdGllcyAoZS5nLiwgYXQgdGhlIG1p bmltdW0sIGEgbWVzc2FnZSBicm9rZXIsIGF0IHRoZSBvdGhlcg0KPiBlbmQgb2YgdGhlIHNjYWxl LCBhIGZ1bGwtYmxvd24gRVNCKS4gSSBkaWRuJ3QgdGhpbmsgdGhhdCB0aGUgcHVycG9zZQ0KPiBv ZiB0aGUgQUNQIGluY2x1ZGVkIHN1Y2ggY2FwYWJpbGl0aWVzLg0KPg0KPiBJbiBvdGhlciB3b3Jk cywgdGhlcmUgaXMgYSBodWdlIGRpZmZlcmVuY2UgYmV0d2VlbiBHUkFTUA0KPiBnZW5lcmF0aW5n IGEgbm90aWZpY2F0aW9uIGFuZCBHUkFTUCBmdW5jdGlvbmluZyBhcyBhIGZ1bGwNCj4gbWVzc2Fn aW5nIHN5c3RlbSwgY29tcGxldGUgd2l0aCBtZXNzYWdlIHRyYW5zZm9ybWF0aW9uIGFuZA0KPiBy b3V0aW5nLCBxdWV1aW5nLCBldGMuDQo+DQo+IEkgd2FzIGFzc3VtaW5nIHRoZSBmb3JtZXIsIG5v dCB0aGUgbGF0dGVyLg0KPg0KPiBQbGVhc2UgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KPg0K PiAoTm90ZSB0aGF0IEZPQ0FMRSB1c2VkIGFuIEVTQiBmb3IgaW50ZXItYWdlbnQgY29tbXVuaWNh dGlvbi4pDQo+DQo+IHJlZ2FyZHMsDQo+IEpvaG4NCj4NCj4NCj4NCj4gT24gTW9uLCBPY3QgMTks IDIwMTUgYXQgMTI6MzUgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDwNCj4gYnJpYW4uZS5jYXJwZW50 ZXJAZ21haWwuY29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90ZToN Cj4NCj4gPiBPbiAyMC8xMC8yMDE1IDA4OjA0LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4g PiBUaGVyZSBhcmUgYXQgbGVhc3QgdHdvIGRpZmZlcmVudCBmYWN0b3JzIHRvIGNvbnNpZGVyIGlu IHRlcm1zIG9mIHdoYXQNCj4gPiBldmVudHMgYXJlIGNvbW11bmljYXRlZCB0byB0aGUgb3BlcmF0 b3IuDQo+ID4gPg0KPiA+ID4gRmlyc3QsIGZvciBpbml0aWFsIGRlcGxveW1lbnQgb2YgYXV0b25v bWljIHRlY2hub2xvZ2llcywgb3BlcmF0b3JzIHdpbGwNCj4gPiB3YW50IHdheXMgdG8gb2JzZXJ2 ZSBhbGwgdGhlIGV2ZW50cyBzbyB0aGV5IGNhbiBnYWluDQo+ID4gPiBjb25maWRlbmNlIGluIHRo ZSB0ZWNobm9sb2d5LiAgKFdlIHJlY2VpdmVkIHRoZXNlIHJlcXVlc3RzIHdpdGggZXhpc3RpbmcN Cj4gPiBzZWxmLW9yZ2FuaXppbmcgbmV0d29yayB0ZWNobm9sb2dpZXMuKQ0KPiA+ID4NCj4gPiA+ IFNlY29uZGx5LCBkaWZmZXJlbnQgb3BlcmF0b3JzIGhhdmUgZGlmZmVyZW50IGRlZ3JlZXMgb2Yg aW5mb3JtYXRpb24NCj4gPiBoYXJ2ZXN0aW5nIGFuZCBkaXNwbGF5IHJlbGF0aXZlIHRvIHRoZSBz dGF0ZSBvZiB0aGUNCj4gPiA+IG5ldHdvcmsuICBFdmVuIGlmIHRoZSBuZXR3b3JrIGlzIHRha2lu ZyBjYXJlIG9mIGl0c2VsZiBwZXJmZWN0bHksIHNvbWUNCj4gPiBvcGVyYXRvcnMgd2lsbCB3YW50 IHZpc2liaWxpdHkgdG8gYW55IGludGVybmFsIHN0YXRlDQo+ID4gPiBjaGFuZ2UuICBUaGVzZSBv cGVyYXRvcnMgY3VycmVudGx5IG1vbml0b3IgdGhlaXIgcm91dGluZyBwcm90b2NvbCBzdGF0ZQ0K PiA+IGZvciBzaW1pbGFyIGVmZmVjdHMuDQo+ID4NCj4gPiBXaGF0IEkgZ2V0IGZyb20gdGhpcyBp cyBhIHJlcXVpcmVtZW50IHRoYXQgYWxsIEFTQXMgYXJlIGNhcGFibGUgb2YNCj4gPiBub3RpZnlp bmcgZXZlbnRzLA0KPiA+IGJ1dCB3aGV0aGVyIGFuZCBob3cgdGhvc2UgZXZlbnRzIGFyZSByZXBv cnRlZCBsaXZlIHRvIG9wZXJhdG9ycyBpcyBhDQo+ID4gc2VwYXJhdGUgaXNzdWUuDQo+ID4NCj4g PiAoSG93ZXZlciwgSSBoYXZlIG5ldmVyIGZvcmdvdHRlbiB0aGF0IGF0IFRocmVlIE1pbGUgSXNs YW5kLCB0aGUgc3lzdGVtIHdhcw0KPiA+IHNvIGJ1c3kNCj4gPiByZXBvcnRpbmcgbWlub3IgYWxh cm1zIHRoYXQgaXQgdG9vayBob3VycyBiZWZvcmUgdGhlIHVuZGVybHlpbmcgYWxhcm0NCj4gPiBt ZXNzYWdlDQo+ID4gc2F5aW5nIHdoYXQgd2FzIHJlYWxseSB3cm9uZyBnb3QgcHJpbnRlZC4gVE1J LCBpbmRlZWQuKQ0KPiA+DQo+ID4gICAgQnJpYW4NCj4gPg0KPiA+ID4NCj4gPiA+IFlvdXJzLA0K PiA+ID4gSm9lbA0KPiA+ID4NCj4gPiA+IE9uIDEwLzE5LzE1IDI6NTggUE0sIFJlZGR5IFBhbGxh dmFsaSB3cm90ZToNCj4gPiA+PiBNaWNoYWVsLA0KPiA+ID4+DQo+ID4gPj4gWWVzLCBmb3IgZXZl cnkgc21hbGwgaXNzdWUgdGhlcmUgaXMgbm8gbmVlZCB0byBjb250YWN0IG9wZXJhdG9yIGV4Y2Vw dCwNCj4gPiA+PiBpZiBpdCBpcyBhIGNvbXBsZXggb25lLg0KPiA+ID4+IEV2ZW4gZm9yIHNlbGYt aGVhbGluZyB3ZSBjYW4gdXNlIFN3YXJtIEludGVsbGlnZW5jZSBvciBBcnRpZmljaWFsDQo+ID4g Pj4gSW50ZWxsaWdlbmNlIHRlY2huaXF1ZXMsIGJ1dCBmb3IgbGVhcm5pbmcgbWF5IHRha2Ugc29t ZSB0aW1lLiBIb3dldmVyLA0KPiA+ID4+IHRoZXNlIGFyZSBzY2FsYWJsZSB0ZWNobmlxdWVzLg0K PiA+ID4+IEhlcmUsIGFsc28gdGhlcmUgaXMgYSBuZWVkIG9mIGNvbnNlbnN1cywgaWYgdGhlIHN5 c3RlbSBpcyBmdWxseQ0KPiA+ID4+IGRpc3RyaWJ1dGVkIGFuZCBhc3luY2hyb25vdXMgbmVlZCB0 byBrbm93IHdoaWNoIG9iamVjdCBpcyBjcmFzaGVkLCBob3cNCj4gPiA+PiB0byBzY2hlZHVsZSB0 aGUgbG9hZHMgYW5kIGNvdmVyYWdlIGlzc3VlcyBhcyB3ZWxsLg0KPiA+ID4+DQo+ID4gPj4gT24g TW9uLCBPY3QgMTksIDIwMTUgYXQgNjozOSBQTSwgTWljaGFlbCBSaWNoYXJkc29uDQo+ID4gPj4g PG1jcitpZXRmQHNhbmRlbG1hbi5jYTxtYWlsdG86bWNyJTJCaWV0ZkBzYW5kZWxtYW4uY2E+IDxt YWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1haWx0bzptY3IlMkJpZXRmQHNhbmRlbG1hbi5j YT4+PiB3cm90ZToNCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gICAgIEpvaG4gU3RyYXNzbmVyIDxz dHJhenBkakBnbWFpbC5jb208bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbT4gPG1haWx0bzpzdHJh enBkakBnbWFpbC5jb208bWFpbHRvOnN0cmF6cGRqQGdtYWlsLmNvbT4+Pg0KPiA+IHdyb3RlOg0K PiA+ID4+ICAgICAgICAgID4gV2hlbiBhbiBhdXRvbm9taWMgc3lzdGVtIHNlbGYtaGVhbHMsIHdo eSB3b3VsZCB0aGUgb3BlcmF0b3INCj4gPiA+PiAgICAgbmVlZCB0bw0KPiA+ID4+ICAgICAgICAg ID4ga25vdz8gVGhpcyBpcyBjb21wYXJhYmxlIHRvIHJvdXRpbmcgZG9pbmcgaXRzIGpvYiBhbmQN Cj4gPiA+PiAgICAgY2hhbmdpbmcgdGhlDQo+ID4gPj4gICAgICAgICAgPiBwYXRoLiBUaGVyZSBp cyBubyByZWFzb24gdGhhdCB0aGUgb3BlcmF0b3IgaGFzIHRvIGJlIGFsZXJ0ZWQNCj4gPiA+PiAg ICAgb24gZXZlcnkNCj4gPiA+PiAgICAgICAgICA+IGNoYW5nZSBpbiB0aGUgc3lzdGVtIC0gdGhl cmUgYXJlIGFscmVhZHkgV0FZIFRPTyBNQU5ZIG9mDQo+ID4gPj4gICAgIHRoZXNlIGZvciB0aGUN Cj4gPiA+PiAgICAgICAgICA+IG9wZXJhdG9yIHRvIGhhbmRsZS4NCj4gPiA+Pg0KPiA+ID4+ICAg ICBZZXMsIGJ1dCBqdXN0IHRoZSBzYW1lLCB0aGUgaGVhbGluZyBhY3Rpdml0eSBuZWVkcyB0byBi ZSBhbiBhdWRpdGVkDQo+ID4gPj4gICAgIGV2ZW50Lg0KPiA+ID4+ICAgICBUaGUgQUNQIHNob3Vs ZCBiZSBpbnZvbHZlZCBpbiBjYXB0dXJpbmcgdGhlc2UgZXZlbnRzLg0KPiA+ID4+DQo+ID4gPj4g ICAgIFNvbWV0aW1lcyB0aGluZ3MgZG9uJ3QgaGVhbCBwZXJmZWN0bHk7IG9mdGVuIG1vdmluZyB0 cmFmZmljIGZyb20NCj4gPiA+PiAgICAgb25lIHN5c3RlbSB0byBhbm90aGVyIGNhdXNlcyBhIGxv YWQgc3Bpa2UsIGFuZCB3aGlsZSB0aGluZ3MNCj4gPiBjb250aW51ZSB0bw0KPiA+ID4+ICAgICBm dW5jdGlvbiwgdGhlIHBlcmZvcm1hbmNlIGlzIGRpZmZlcmVudC4NCj4gPiA+Pg0KPiA+ID4+ICAg ICAtLQ0KPiA+ID4+ICAgICBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YTxtYWlsdG86bWNyJTJCSUVURkBzYW5kZWxtYW4uY2E+DQo+ID4gPj4gICAgIDxtYWlsdG86bWNy JTJCSUVURkBzYW5kZWxtYW4uY2E8bWFpbHRvOm1jciUyNTJCSUVURkBzYW5kZWxtYW4uY2E+Pj4s IFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcw0KPiA+ID4+ICAgICAgIC09IElQdjYgSW9UIGNvbnN1 bHRpbmcgPS0NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+ICAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+ICAgICBB bmltYSBtYWlsaW5nIGxpc3QNCj4gPiA+PiAgICAgQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1h QGlldGYub3JnPiA8bWFpbHRvOkFuaW1hQGlldGYub3JnPG1haWx0bzpBbmltYUBpZXRmLm9yZz4+ DQo+ID4gPj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEN Cj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IC0tDQo+ID4gPj4gVGhhbmsg eW91IHZlcnkgbXVjaCBmb3IgeW91ciB0aW1lIGFuZCBjb25zaWRlcmF0aW9uLg0KPiA+ID4+DQo+ ID4gPj4NCj4gPiA+PiBZb3VycyBzaW5jZXJlbHksDQo+ID4gPj4NCj4gPiA+PiBQIFJhZGhhIEty aXNobmEgUmVkZHksIE0uU2MsIE0uVGVjaCwNCj4gPiA+Pg0KPiA+ID4+IEp1bmlvciBSZXNlYXJj aGVyL1BoLkQgU3R1ZGVudCwNCj4gPiA+Pg0KPiA+ID4+IENPUEUgTEFCUywgVW5pdmVyc2lkYWRl IEx1c29mb25hLCBMaXNib2EgLSBQb3J0dWdhbC4NCj4gPiA+Pg0KPiA+ID4+IEF1dGhvciBvZjog U2VjdXJpdHkgSXNzdWVzIG9mIENsb3VkIENvbXB1dGluZyBvdmVyIEdlbmVyYWwgJiBJVCBTZWN0 b3INCj4gPiA+PiBNb2JpbGU6ICszNTE5MjMwOTU2NzE8dGVsOiUyQjM1MTkyMzA5NTY3MT4NCj4g PiA+PiB3d3cucHJrcmVkZHkud2Vicy5jb208aHR0cDovL3d3dy5wcmtyZWRkeS53ZWJzLmNvbT4N Cj4gPiA+PiBodHRwOi8vcHQubGlua2VkaW4uY29tL2luL3JlZGR5cGFsbGF2YWxpLw0KPiA+ID4+ DQo+ID4gPj4NCj4gPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiA+ID4+IEFuaW1hQGlldGYub3Jn PG1haWx0bzpBbmltYUBpZXRmLm9yZz4NCj4gPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuaW1hDQo+ID4gPj4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gQW5pbWEgbWFpbGluZyBsaXN0 DQo+ID4gPiBBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+DQo+ID4gPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo+ID4gPg0KPiA+DQo+ID4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBBbmlt YSBtYWlsaW5nIGxpc3QNCj4gPiBBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+ DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0KPiA+DQo+ DQo+DQo+DQo+IC0tDQo+IHJlZ2FyZHMsDQo+IEpvaG4NCg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4gQW5p bWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQoNCg0KLS0NCi0tLQ0KVG9lcmxlc3MgRWNrZXJ0LCBl Y2tlcnRAY2lzY28uY29tPG1haWx0bzplY2tlcnRAY2lzY28uY29tPg0KDQoNCg0KLS0NCnJlZ2Fy ZHMsDQpKb2huDQo= --_000_e4e14ce7b38c49e3b925dffc07523635XCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkpvaG4sIGluIG15IG9waW5pb24sIGlmIHdlIGdldCB0byB0aGUgcG9pbnQgb2Yg YSBzb2xpZCBhdXRvbm9taWMgaW5mcmFzdHJ1Y3R1cmUgd2l0aA0KIHRoZSByaWdodCBiYXNlIHNl cnZpY2VzLCBzdWNoIGFzIGRpc2NvdmVyeSwgbWVzc2FnaW5nLCBidWlsdCBvbiBhIHNlbGYtbWFu YWdpbmcgQUNQLCBkZXZlbG9wcGVycyB3aWxsIGhhdmUgYWxsIHRoZSB0b29scyB0byB3cml0ZSB0 aGUgZnVuY3Rpb25zIHRoYXQgeW91IHdhbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGli cmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5UaGUgQU4gaW5mcmFzdHJ1Y3R1cmUgaXMgdGhlIG5ldyBJUDogbGlrZSBJUCBlbmFibGVk IGZvbGtzIHRvIHdyaXRlIG5ldHdvcmtpbmcgYXBwbGljYXRpb25zDQogcmVhbGx5IGVhc2lseSwg dGhlIEFOSSBhbGxvd3MgdG8gd3JpdGUgc2VsZi1tYW5hZ2VtZW50IGZ1bmN0aW9ucyByZWFsbHkg ZWFzaWx5LiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPklmIHdlIGdldCBBTkkg cmlnaHQsIHdlIGVuYWJsZSBhIHdob2xlIG5ldyBlY28tc3lzdGVtIG9mIG5ldHdvcmsgcHJvZ3Jh bW1pbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NaWNoYWVsPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtmb250LXdlaWdodDpib2xk Ij5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KIEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNl c0BpZXRmLm9yZ10gPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPk9uIEJlaGFsZiBP Zg0KPC9zcGFuPjwvYj5Kb2huIFN0cmFzc25lcjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IDAxIE5vdmVtYmVyIDIwMTUgMjE6NDQ8YnI+DQo8 Yj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gVG9lcmxlc3Mg RWNrZXJ0IChlY2tlcnQpICZsdDtlY2tlcnRAY2lzY28uY29tJmd0OzsgSm9obiBTdHJhc3NuZXIg Jmx0O3N0cmF6cGRqQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+Q2M6PC9zcGFuPjwvYj4gTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3ImIzQzO2ll dGZAc2FuZGVsbWFuLmNhJmd0OzsgSm9lbCBNLiBIYWxwZXJuICZsdDtqbWhAam9lbGhhbHBlcm4u Y29tJmd0OzsgcmVkZHkucGFsbGF2YWxpQHVsdXNvZm9uYS5wdDsgQW5pbWEgV0cgJmx0O2FuaW1h QGlldGYub3JnJmd0Ozxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJq ZWN0Ojwvc3Bhbj48L2I+IFJlOiBbQW5pbWFdIFtBTklNQV0gU2VsZi1NYW5hZ2VkIE5ldHdvcmtz PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IaSBUb2Vy bGVzcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZn dDsgQmVmb3JlIGFuaW1hLCBldmVyeSBkaXN0cmlidXRlZCBmdW5jdGlvbiB3ZSBkZXNpZ25lZCBp biB0aGUgSUVURjxicj4NCiZndDsgdXNlZCBpdHMgb3duIHJlaW52ZW50ZWQgY29tbXVuaWNhdGlv biBwYXJhZGlnbS4gVGhlIG9ubHkgY29tbW9uPGJyPg0KJmd0OyBtZWNoYW5pc20gd2FzIHVzZSBv ZiBJUCBwYWNrZXRzLCBidXQgbm90IGV2ZW4gdGhhdCB3YXMgdGhlIGxvd2VzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mZ3Q7Jm5ic3A7Y29tbW9uIGRlbm9taW5hdG9yIChJUy1JUyBhbnlib2R5KS48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkF0IHRoZSBy aXNrIG9mIHJvY2tpbmcgdGhlIGJvYXQsIEknbSBsZXNzIGludGVyZXN0ZWQgaW4gdXNpbmcgYXV0 b25vbWljczxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5mb3IgJnF1b3Q7cGx1bWJpbmcmcXVvdDsgaXNz dWVzLCBzdWNoIGFzIGhlYWxpbmcgYnJva2VuIHJvdXRlcywgYXMgSSBhbSBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5jb3JyZWN0aW5nIHVzZXItIGFuZCBidXNpbmVzcy1vcmllbnRlZCBmdW5jdGlv bnMgYW5kIHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+V2UgYXJlIGVuZ2luZWVycy4gV2UgaGF2ZSBhIG5hdHVyYWwgYWZmaW5pdHkgZm9y IHBsYXlpbmcgd2l0aCBicmlnaHQsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnNoaW55IGtub2JzIHRo YXQgcHJvdmlkZSBuZXcgdGVjaG5vbG9naWVzIHdpdGggd2hpY2ggdG8gZGVzaWduLjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5Ib3dldmVyLCB0aGlzIHJhcmVseSBkaXJlY3RseSBwYXlzIHRoZSBiaWxs cy4gVGhlIGJ1c2luZXNzIHBlcnNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50eXBpY2FsbHkgZG9l cyBub3QgY2FyZSB3aGF0IHRlY2hub2xvZ2llcyBhbmQgZmVhdHVyZXMgYXJlIHVzZWQsIGFzPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPmxvbmcgYXMgaGlzIG9yIGhlciBzZXJ2aWNlIHdvcmtzLiBJZiBp dCBleGNlZWRzIGFuIFNMQSwgdGhlbiBpdHM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+c2NvdGNoIHRp bWUgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkJ1dCB0aGVyZSBpcyBubyAmcXVvdDtnb2xkIHNlcnZpY2UgZW5hYmxlJnF1b3Q7IENMSSBj b21tYW5kIHRoYXQgSSd2ZSBldmVyIHNlZW4uPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoaXMgaXMg d2h5IG1hbnkgb2YgdGhlIGF1dG9ub21pYyBwcm9qZWN0cyBoYXZlIHRyaWVkIHRvIHJlYWNoIGFi b3ZlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmZvcndhcmRpbmcgYW5kIHJvdXRpbmcgYW5kIHRyeSBh bmQgdHJhbnNsYXRlIGJ1c2luZXNzIGNvbmNlcHRzIHRvPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPmRy aXZlIG5ldHdvcmsgc2VydmljZXMgYW5kIHJlc291cmNlcyB0aGF0IHRoZSBidXNpbmVzcyBuZWVk cy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldlJ3Zl IGZhaWxlZCwgcmF0aGVyIHNwZWN0YWN1bGFybHksIHNvIGZhci4gQWZ0ZXIgNTAwJiM0MzsgY29u ZmVyZW5jZXMgb248bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnV0dXJlIEludGVybmV0LCBOZXh0IEdl bmVyYXRpb24gTmV0d29ya2luZywgeWFkYS15YWRhLXlhZGEsIHdlPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPnN0aWxsIGRvIG5vdCBoYXZlIGEgcmVwbGFjZW1lbnQgZm9yIFNOTVAuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5ORlYgd2FzIHN0aWxsYm9ybiAt IGl0IGhhcyB0aGUgbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMgb2YgYSB3YWxudXQuPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPlNETiBpcyBhIGJpdCBtb3JlIGxpa2UgYW4gYXBwbGUgKHRhc3RpZXIgYW5k IHByZXR0aWVyLCBidXQgc3RpbGwgbm88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+bWFuYWdlbWVudCku PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JIGtub3cg dGhlIElFVEYgbG92ZXMgdG8gd29yayBib3R0b20tdXAuIEJ1dCBwZXJoYXBzIHdlIG5lZWQgdG88 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+aGF2ZSBhIHRvcC1kb3duIGFwcHJvYWNoIGFzIHdlbGwgdG8g Zml4IHRoaXMuIE90aGVyd2lzZSwgdGhlIG5ldHdvcms8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+dGhh dCBuZXZlciBmYWlscyBidXQgc3RpbGwgZG9lc24ndCBwcm92aWRlIGJ1c2luZXNzIHZhbHVlIGlz IGp1c3QgYW5vdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5jb29sIGpvdXJuYWwgcGFwZXIuPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5yZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij5Kb2huPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T24gVHVlLCBPY3Qg MjAsIDIwMTUgYXQgOToxNyBBTSwgVG9lcmxlc3MgRWNrZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86 ZWNrZXJ0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVja2VydEBjaXNjby5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSB3YXkgaSBzZWUgaXQ6PGJyPg0KPGJyPg0K QmVmb3JlIGFuaW1hLCBldmVyeSBkaXN0cmlidXRlZCBmdW5jdGlvbiB3ZSBkZXNpZ25lZCBpbiB0 aGUgSUVURjxicj4NCnVzZWQgaXRzIG93biByZWludmVudGVkIGNvbW11bmljYXRpb24gcGFyYWRp Z20uIFRoZSBvbmx5IGNvbW1vbjxicj4NCm1lY2hhbmlzbSB3YXMgdXNlIG9mIElQIHBhY2tldHMs IGJ1dCBub3QgZXZlbiB0aGF0IHdhcyB0aGUgbG93ZXN0IGNvbW1vbjxicj4NCmRlbm9taW5hdG9y IChJUy1JUyBhbnlib2R5KS48YnI+DQo8YnI+DQpTbyB0aGUgcXVlc3Rpb24gcmVhbGx5IGlzIHdo YXQgYXJlIHRoZSBwcmFnbWF0aWMgY29tbW9uIGNvbW11bmljYXRpb248YnI+DQptZWNoYW5pc21z IHdlIGNhbiBjb21lIHVwIHdpdGggdG8gbWFrZSBmdXR1cmUgZGlzdHJpYnV0ZWQgZnVuY3Rpb25z PGJyPg0KZWFzaWVyIHRvIGltcGxlbWVudCwgZGVwbG95IGFuZCBvcGVyYXRlLiBXaXRoIGZvY3Vz IG9uICZxdW90O2RlcGxveSZxdW90OyBiZWNhdXNlPGJyPg0KdGhhdHMgd2hhdCB3ZSB3YW50IHRv IGJlIGF1dG9ub21pYy4gQW5kIHN0YXJ0IHdpdGggd2hhdCBvdXIgb3duICZxdW90O2FuaW1hJnF1 b3Q7PGJyPg0KZGlzdHJpYnV0ZWQgZnVuY3Rpb25zIHJlYWxpemVkIHZpYSAmcXVvdDthZ2VudHMm cXVvdDsgbmVlZC48YnI+DQo8YnI+DQpXZSBrbm93IHAycCB3aXRoIGNvbW1vbiBwcmVzZW50YXRp b24gbGF5ZXIgYW5kIHNldCBvZiBzZXNzaW9uIHRyYW5zYWN0aW9uPGJyPg0KdHlwZXMsIGFuZCBz b21lIGxpbWl0ZWQgZGlzY292ZXJ5LCBlZzogbXAybXAgdHJhbnNhY3Rpb25zLjxicj4NCjxicj4N ClRoZSBkaXNjdXNzaW9uIG5vdyBpcyB3aGF0J3MgbG9naWNhbGx5IG5leHQuIE9uY2Ugd2UgaGF2 ZSBhbiBpZGVhLCB0aGVuPGJyPg0Kd2UgY2FuIGZpZ3VyZSB3aGV0aGVyIGl0IG1ha2VzIHNlbnNl IHRvIGNhbGwvcHV0LWludG8gR1JBU1AgYW5kL29yIGlmL2hvdzxicj4NCnRvIGRlYWwgd2l0aCBp dCBpbiBBTklNQS48YnI+DQo8YnI+DQo8YnI+DQpPbiBUdWUsIE9jdCAyMCwgMjAxNSBhdCAwODo0 ODowNUFNIC0wNzAwLCBKb2huIFN0cmFzc25lciB3cm90ZTo8YnI+DQomZ3Q7IEhpIGFsbCw8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBTb3JyeSwgSSdtIGEgYml0IGNvbmZ1c2VkLjxicj4NCiZndDs8YnI+ DQomZ3Q7IFRvIG1lLCB0aGlzIHRocmVhZCBpcyBzdGFydGluZyB0byBkaXNjdXNzIGdlbmVyaWMg bWVzc2FnaW5nIHN5c3RlbTxicj4NCiZndDsgY2FwYWJpbGl0aWVzIChlLmcuLCBhdCB0aGUgbWlu aW11bSwgYSBtZXNzYWdlIGJyb2tlciwgYXQgdGhlIG90aGVyPGJyPg0KJmd0OyBlbmQgb2YgdGhl IHNjYWxlLCBhIGZ1bGwtYmxvd24gRVNCKS4gSSBkaWRuJ3QgdGhpbmsgdGhhdCB0aGUgcHVycG9z ZTxicj4NCiZndDsgb2YgdGhlIEFDUCBpbmNsdWRlZCBzdWNoIGNhcGFiaWxpdGllcy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJbiBvdGhlciB3b3JkcywgdGhlcmUgaXMgYSBodWdlIGRpZmZlcmVuY2Ug YmV0d2VlbiBHUkFTUDxicj4NCiZndDsgZ2VuZXJhdGluZyBhIG5vdGlmaWNhdGlvbiBhbmQgR1JB U1AgZnVuY3Rpb25pbmcgYXMgYSBmdWxsPGJyPg0KJmd0OyBtZXNzYWdpbmcgc3lzdGVtLCBjb21w bGV0ZSB3aXRoIG1lc3NhZ2UgdHJhbnNmb3JtYXRpb24gYW5kPGJyPg0KJmd0OyByb3V0aW5nLCBx dWV1aW5nLCBldGMuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB3YXMgYXNzdW1pbmcgdGhlIGZvcm1l ciwgbm90IHRoZSBsYXR0ZXIuPGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIGNvcnJlY3QgbWUg aWYgSSBhbSB3cm9uZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAoTm90ZSB0aGF0IEZPQ0FMRSB1c2Vk IGFuIEVTQiBmb3IgaW50ZXItYWdlbnQgY29tbXVuaWNhdGlvbi4pPGJyPg0KJmd0Ozxicj4NCiZn dDsgcmVnYXJkcyw8YnI+DQomZ3Q7IEpvaG48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDE5LCAyMDE1IGF0IDEyOjM1IFBNLCBCcmlhbiBFIENhcnBl bnRlciAmbHQ7PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21h aWwuY29tIj5icmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIDIwLzEwLzIwMTUgMDg6MDQsIEpvZWwgTS4gSGFscGVybiB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGVyZSBhcmUgYXQgbGVhc3QgdHdvIGRpZmZlcmVu dCBmYWN0b3JzIHRvIGNvbnNpZGVyIGluIHRlcm1zIG9mIHdoYXQ8YnI+DQomZ3Q7ICZndDsgZXZl bnRzIGFyZSBjb21tdW5pY2F0ZWQgdG8gdGhlIG9wZXJhdG9yLjxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRmlyc3QsIGZvciBpbml0aWFsIGRlcGxveW1lbnQgb2YgYXV0 b25vbWljIHRlY2hub2xvZ2llcywgb3BlcmF0b3JzIHdpbGw8YnI+DQomZ3Q7ICZndDsgd2FudCB3 YXlzIHRvIG9ic2VydmUgYWxsIHRoZSBldmVudHMgc28gdGhleSBjYW4gZ2Fpbjxicj4NCiZndDsg Jmd0OyAmZ3Q7IGNvbmZpZGVuY2UgaW4gdGhlIHRlY2hub2xvZ3kuJm5ic3A7IChXZSByZWNlaXZl ZCB0aGVzZSByZXF1ZXN0cyB3aXRoIGV4aXN0aW5nPGJyPg0KJmd0OyAmZ3Q7IHNlbGYtb3JnYW5p emluZyBuZXR3b3JrIHRlY2hub2xvZ2llcy4pPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0OyBTZWNvbmRseSwgZGlmZmVyZW50IG9wZXJhdG9ycyBoYXZlIGRpZmZlcmVudCBk ZWdyZWVzIG9mIGluZm9ybWF0aW9uPGJyPg0KJmd0OyAmZ3Q7IGhhcnZlc3RpbmcgYW5kIGRpc3Bs YXkgcmVsYXRpdmUgdG8gdGhlIHN0YXRlIG9mIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG5ldHdv cmsuJm5ic3A7IEV2ZW4gaWYgdGhlIG5ldHdvcmsgaXMgdGFraW5nIGNhcmUgb2YgaXRzZWxmIHBl cmZlY3RseSwgc29tZTxicj4NCiZndDsgJmd0OyBvcGVyYXRvcnMgd2lsbCB3YW50IHZpc2liaWxp dHkgdG8gYW55IGludGVybmFsIHN0YXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY2hhbmdlLiZuYnNw OyBUaGVzZSBvcGVyYXRvcnMgY3VycmVudGx5IG1vbml0b3IgdGhlaXIgcm91dGluZyBwcm90b2Nv bCBzdGF0ZTxicj4NCiZndDsgJmd0OyBmb3Igc2ltaWxhciBlZmZlY3RzLjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBXaGF0IEkgZ2V0IGZyb20gdGhpcyBpcyBhIHJlcXVpcmVtZW50IHRo YXQgYWxsIEFTQXMgYXJlIGNhcGFibGUgb2Y8YnI+DQomZ3Q7ICZndDsgbm90aWZ5aW5nIGV2ZW50 cyw8YnI+DQomZ3Q7ICZndDsgYnV0IHdoZXRoZXIgYW5kIGhvdyB0aG9zZSBldmVudHMgYXJlIHJl cG9ydGVkIGxpdmUgdG8gb3BlcmF0b3JzIGlzIGE8YnI+DQomZ3Q7ICZndDsgc2VwYXJhdGUgaXNz dWUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IChIb3dldmVyLCBJIGhhdmUgbmV2ZXIg Zm9yZ290dGVuIHRoYXQgYXQgVGhyZWUgTWlsZSBJc2xhbmQsIHRoZSBzeXN0ZW0gd2FzPGJyPg0K Jmd0OyAmZ3Q7IHNvIGJ1c3k8YnI+DQomZ3Q7ICZndDsgcmVwb3J0aW5nIG1pbm9yIGFsYXJtcyB0 aGF0IGl0IHRvb2sgaG91cnMgYmVmb3JlIHRoZSB1bmRlcmx5aW5nIGFsYXJtPGJyPg0KJmd0OyAm Z3Q7IG1lc3NhZ2U8YnI+DQomZ3Q7ICZndDsgc2F5aW5nIHdoYXQgd2FzIHJlYWxseSB3cm9uZyBn b3QgcHJpbnRlZC4gVE1JLCBpbmRlZWQuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmbmJzcDsgQnJpYW48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7IFlvdXJzLDxicj4NCiZndDsgJmd0OyAmZ3Q7IEpvZWw8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDEwLzE5LzE1IDI6NTggUE0sIFJlZGR5 IFBhbGxhdmFsaSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgTWljaGFlbCw8YnI+DQom Z3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgWWVzLCBmb3IgZXZlcnkg c21hbGwgaXNzdWUgdGhlcmUgaXMgbm8gbmVlZCB0byBjb250YWN0IG9wZXJhdG9yIGV4Y2VwdCw8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgaWYgaXQgaXMgYSBjb21wbGV4IG9uZS48YnI+DQomZ3Q7 ICZndDsgJmd0OyZndDsgRXZlbiBmb3Igc2VsZi1oZWFsaW5nIHdlIGNhbiB1c2UgU3dhcm0gSW50 ZWxsaWdlbmNlIG9yIEFydGlmaWNpYWw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSW50ZWxsaWdl bmNlIHRlY2huaXF1ZXMsIGJ1dCBmb3IgbGVhcm5pbmcgbWF5IHRha2Ugc29tZSB0aW1lLiBIb3dl dmVyLDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyB0aGVzZSBhcmUgc2NhbGFibGUgdGVjaG5pcXVl cy48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgSGVyZSwgYWxzbyB0aGVyZSBpcyBhIG5lZWQgb2Yg Y29uc2Vuc3VzLCBpZiB0aGUgc3lzdGVtIGlzIGZ1bGx5PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 IGRpc3RyaWJ1dGVkIGFuZCBhc3luY2hyb25vdXMgbmVlZCB0byBrbm93IHdoaWNoIG9iamVjdCBp cyBjcmFzaGVkLCBob3c8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgdG8gc2NoZWR1bGUgdGhlIGxv YWRzIGFuZCBjb3ZlcmFnZSBpc3N1ZXMgYXMgd2VsbC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgT24gTW9uLCBPY3QgMTksIDIwMTUgYXQgNjozOSBQTSwg TWljaGFlbCBSaWNoYXJkc29uPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86bWNyJTJCaWV0ZkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2E8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1jciUyQmlldGZAc2FuZGVsbWFuLmNhIj5t Y3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7Sm9obiBTdHJhc3NuZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpz dHJhenBkakBnbWFpbC5jb20iPnN0cmF6cGRqQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86c3RyYXpwZGpAZ21haWwuY29tIj5zdHJhenBkakBnbWFpbC5jb208L2E+Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IFdoZW4gYW4gYXV0b25vbWljIHN5c3Rl bSBzZWxmLWhlYWxzLCB3aHkgd291bGQgdGhlIG9wZXJhdG9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtuZWVkIHRvPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IGtub3c/IFRoaXMgaXMgY29tcGFy YWJsZSB0byByb3V0aW5nIGRvaW5nIGl0cyBqb2IgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtjaGFuZ2luZyB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgcGF0aC4gVGhlcmUgaXMgbm8g cmVhc29uIHRoYXQgdGhlIG9wZXJhdG9yIGhhcyB0byBiZSBhbGVydGVkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvbiBldmVyeTxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBjaGFuZ2UgaW4gdGhl IHN5c3RlbSAtIHRoZXJlIGFyZSBhbHJlYWR5IFdBWSBUT08gTUFOWSBvZjxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlc2UgZm9yIHRoZTxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBvcGVyYXRv ciB0byBoYW5kbGUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtZZXMsIGJ1dCBqdXN0IHRoZSBzYW1lLCB0aGUgaGVhbGlu ZyBhY3Rpdml0eSBuZWVkcyB0byBiZSBhbiBhdWRpdGVkPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtldmVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwO1RoZSBBQ1Agc2hvdWxkIGJlIGludm9sdmVkIGluIGNhcHR1cmluZyB0aGVz ZSBldmVudHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDtTb21ldGltZXMgdGhpbmdzIGRvbid0IGhlYWwgcGVyZmVjdGx5 OyBvZnRlbiBtb3ZpbmcgdHJhZmZpYyBmcm9tPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDtvbmUgc3lzdGVtIHRvIGFub3RoZXIgY2F1c2VzIGEgbG9hZCBzcGlrZSwg YW5kIHdoaWxlIHRoaW5nczxicj4NCiZndDsgJmd0OyBjb250aW51ZSB0bzxicj4NCiZndDsgJmd0 OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ZnVuY3Rpb24sIHRoZSBwZXJmb3JtYW5jZSBp cyBkaWZmZXJlbnQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDstLTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7TWljaGFlbCBSaWNoYXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJTJC SUVURkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7SUVURkBzYW5kZWxtYW4uY2E8L2E+PGJyPg0KJmd0 OyAmZ3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzptY3IlMjUyQklFVEZAc2FuZGVsbWFuLmNhIj5tY3IlMkJJRVRGQHNhbmRlbG1hbi5jYTwv YT4mZ3Q7Jmd0OywgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzPGJyPg0KJmd0OyAmZ3Q7ICZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LTxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O0FuaW1hIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIj5BbmltYUBpZXRmLm9yZzwvYT4g Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hPC9hPjxi cj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 Jmd0OyAtLTxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5 b3VyIHRpbWUgYW5kIGNvbnNpZGVyYXRpb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IFlvdXJzIHNpbmNlcmVs eSw8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgUCBSYWRo YSBLcmlzaG5hIFJlZGR5LCBNLlNjLCBNLlRlY2gsPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEp1bmlvciBSZXNlYXJjaGVyL1BoLkQgU3R1ZGVudCw8YnI+ DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgQ09QRSBMQUJTLCBV bml2ZXJzaWRhZGUgTHVzb2ZvbmEsIExpc2JvYSAtIFBvcnR1Z2FsLjxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBBdXRob3Igb2Y6IFNlY3VyaXR5IElzc3Vl cyBvZiBDbG91ZCBDb21wdXRpbmcgb3ZlciBHZW5lcmFsICZhbXA7IElUIFNlY3Rvcjxicj4NCiZn dDsgJmd0OyAmZ3Q7Jmd0OyBNb2JpbGU6IDxhIGhyZWY9InRlbDolMkIzNTE5MjMwOTU2NzEiPiYj NDM7MzUxOTIzMDk1NjcxPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw Oi8vd3d3LnBya3JlZGR5LndlYnMuY29tIiB0YXJnZXQ9Il9ibGFuayI+d3d3LnBya3JlZGR5Lndl YnMuY29tPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vcHQubGlu a2VkaW4uY29tL2luL3JlZGR5cGFsbGF2YWxpLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9wdC5s aW5rZWRpbi5jb20vaW4vcmVkZHlwYWxsYXZhbGkvPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7Jmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAm Z3Q7Jmd0OyBBbmltYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDsgPGEgaHJl Zj0ibWFpbHRvOkFuaW1hQGlldGYub3JnIj5BbmltYUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZn dDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hbmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYW5pbWE8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IEFuaW1hIG1haWxpbmcgbGlzdDxicj4N CiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFAaWV0 Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9yZyI+QW5pbWFAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYW5pbWEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FuaW1hPC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4mZ3Q7PC9zcGFuPjwvZm9udD48L3NwYW4+PGZvbnQgY29sb3I9 IiM4ODg4ODgiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0i aG9lbnpiIj4mZ3Q7IC0tPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZndDsgcmVn YXJkcyw8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jmd0OyBKb2huPC9zcGFuPjxi cj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+Jmd0OyBBbmltYSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+Jmd0OyA8YSBocmVmPSJtYWlsdG86QW5pbWFAaWV0Zi5vcmciPkFuaW1hQGlldGYub3JnPC9h Pjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWEiIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PC9zcGFuPjxicj4N Cjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPi0tPC9zcGFuPjxicj4NCjxzcGFuIGNs YXNzPSJob2VuemIiPi0tLTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5Ub2VybGVz cyBFY2tlcnQsIDxhIGhyZWY9Im1haWx0bzplY2tlcnRAY2lzY28uY29tIj5lY2tlcnRAY2lzY28u Y29tPC9hPjwvc3Bhbj48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi Pjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkpvaG48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_e4e14ce7b38c49e3b925dffc07523635XCHRCD006ciscocom_-- From nobody Sun Nov 1 14:52:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A8D1B3127 for ; Sun, 1 Nov 2015 14:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, 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 0qNrDp5SSW97 for ; Sun, 1 Nov 2015 14:52:39 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796241B3124 for ; Sun, 1 Nov 2015 14:52:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZQ36322; Sun, 01 Nov 2015 22:52:36 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sun, 1 Nov 2015 22:52:33 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 06:52:26 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: IETF 94 Virtual Queue for Remote Attendees Thread-Index: AQHRFPf0tiO6A6/qikKQO9+9zvhiXw== Date: Sun, 1 Nov 2015 22:52:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BBC6BD6@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.194.185.38] Content-Type: multipart/mixed; boundary="_002_5D36713D8A4E7348A7E10DF7437A4B927BBC6BD6nkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Fwd: IETF 94 Virtual Queue for Remote Attendees X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 22:52:42 -0000 --_002_5D36713D8A4E7348A7E10DF7437A4B927BBC6BD6nkgeml512mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi ANIMA participants, Please note that there is a trial virtual queue option instead of using the= jabber room. https://www.ietf.org/meeting/94/remote-participation.html#Meetecho This is available for our second session on Tuesday afternoon, when we use = the room 303. For more detail, please see the below message Regards, Sheng > At IETF 92 and IETF 93, we experimented in several sessions with offering= remote participants the opportunity to use a virtual queue if they wanted = to ask questions or make comments via their own audio instead of using the = jabber room. Here at IETF 94 we are planning to expand this experiment and = have the Meetecho virtual queue available to all sessions taking place in r= ooms 301, 303, 501 and 502. These are the four largest rooms at the Pacific= o Yokohama, and therefore likely to have the most participants (and potenti= ally the most remote participants). > > If you are one of the working groups that will have the virtual queue ava= ilable, this is how it will work: > - There will be two queues for your working group session =97 a virtual > queue and an actual (in-room) queue > - Remote attendees will log into the Meetecho platform and will have a > virtual mic line that they can enter if they have a question or > comment > - A second projector and screen will show the virtual queue to all > in-room attendees > - In-room participants will continue to use normal mic lines > > Important: there will be an additional laptop sitting on the WG chair tab= le at the front of the room, facing the chairs. This laptop will show the v= irtual queue. If you as the chair want to recognize a remote attendee in th= e virtual queue so that they can speak directly to/with everyone in the act= ual meeting room, just indicate verbally that you want to do so. A Meetecho= team member will be remotely monitoring your session and will unmute the r= emote attendee in the queue when prompted by a chair. > > Below is the list of all sessions taking place in rooms that can offer th= e virtual queue. If you have any concerns about having the virtual queue av= ailable in your session, or if you prefer to withdraw your working group fr= om the experiment entirely, please let us know as soon as possible. Otherwi= se tomorrow (Sunday) we will inform all attendees about the availability of= the virtual queue in rooms 301, 303, 501 and 502. > > > ++ MONDAY, November 2, 2015 ++ > > 0900-1130 Morning Session I > Room 303 IRTF hopsrg Proposed How Ossified = is the Protocol Stack? Research Group > Room 502 IRTF sdnrg Software Defined Net= working > Room 501 OPS v6ops IPv6 Operations WG > Room 301 RTG detnet Deterministic Networki= ng WG > > 1130-1300 Break > > 1300-1500 Afternoon Session I > Room 501 ART httpbis Hypertext Transfer Pr= otocol WG > Room 301 ART stir Secure Telephone Identity Revisi= ted WG > Room 502 RTG idr Inter-Domain Routing WG > Room 303 TSV tsvwg Transport Area Workin= g Group WG > > 1500-1520 Beverage Break - 3F and 5F Foyers > > 1520-1650 Afternoon Session II > Room 303 IRTF cfrg Crypto Forum > Room 301 OPS lime Layer Independent O= AM Management in the Multi-Layer Environment WG > Room 502 RTG rtgwg Routing Area Working = Group WG > Room 501 TSV rmcat RTP Media Congestion = Avoidance Techniques WG > > 1710-1910 Afternoon Session III > Room 301 ART slim Selection of Langu= age for Internet Media WG > Room 303 OPS lmap Large-Scale Measurem= ent of Broadband Performance WG > Room 502 OPS v6ops IPv6 Operations WG > Room 501 RTG rtgarea Routing Area Open Meet= ing > > ++ TUESDAY, November 3, 2015 ++ > > 0900-1130 Morning Session I > Room 301 ART core Constrained RESTful= Environments WG > Room 501 ART rtcweb Real-Time Communicatio= n in WEB-browsers WG > Room 502 INT homenet Home Networking WG > Room 303 RTG bfd Bidirectional Forw= arding Detection WG - 1030 - 1130 > Room 303 RTG spring Source Packet Routin= g in Networking WG - 0900 - 1030 > > 1300-1500 Afternoon Session I > Room 303 OPS supa Simplified Use of Po= licy Abstractions WG > Room 502 RTG nvo3 Network Virtualizati= on Overlays WG > Room 501 SEC dots DDoS Open Threat S= ignaling WG > Room 301 TSV ippm IP Performance Metri= cs WG > > 1520-1650 Afternoon Session II > Room 502 ART iss Internet Storage Sync BOF > Room 501 ART netvc Internet Video Codec= WG > Room 303 OPS anima Autonomic Networking = Integrated Model and Approach WG > Room 301 RTG lisp Locator/ID Separation Protocol WG > > 1710-1840 Afternoon Session III > Room 303 ART dbound Domain Boundaries WG > Room 301 ART modern Managing, Ordering, Dist= ributing, Exposing, & Registering telephone Numbers WG > Room 502 IRTF irtfopen IRTF Open Meeting > Room 501 RTG pce Path Computation E= lement WG > > ++ WEDNESDAY, November 4, 2015 ++ > > 0900-1130 Morning Session I > Room 501 INT 6man IPv6 Maintenance WG > Room 502 IRTF nfvrg Network Function Vir= tualization > Room 301 OPS netmod NETCONF Data Modeling La= nguage WG > Room 303 SEC tls Transport Layer Security WG > > 1300-1500 Afternoon Session I > Room 502 ART dispatch Dispatch WG > Rooms 411/412 OPS netmod NETCONF Data M= odeling Language WG > Room 413 RTG ospf Open Shortest Path = First IGP WG > Room 501 TSV tcpinc TCP Increased Securi= ty WG > > ++ THURSDAY, November 5, 2015 ++ > > 0900-1130 Morning Session I > Room 303 ART ice Interactive Connectivity Establish= ment WG > Room 501 INT 6lo IPv6 over Networks of Resource-co= nstrained Nodes WG > Room 502 RTG sfc Service Function Chaining WG > Room 301 RTG teas Traffic Engineering= Architecture and Signaling WG > > 1300-1500 Afternoon Session I > Room 303 INT softwire Softwires WG > Room 501 OPS netconf Network Configuration W= G > Room 301 RTG isis IS-IS for IP Internets WG > Room 502 SEC saag Security Area Open= Meeting > > 1520-1720 Afternoon Session II > Room 502 ART rtcweb Real-Time Communicatio= n in WEB-browsers WG > Room 303 INT 6tisch IPv6 over the TSCH = mode of IEEE 802.15.4e WG > Room 501 OPS opsarea Operations & Management= Area Open Meeting - Combined with OPSAWG > Room 301 SEC oauth Web Authorization Pr= otocol WG > > 1720-1740 Beverage Break > > 1740-1840 Afternoon Session III > Room 301 ART lager Label Generation Ru= les WG > Room 502 RTG mpls Multiprotocol Label = Switching WG > Room 303 RTG trill Transparent Interconnection of = Lots of Links WG > Room 501 SEC tls Transport Layer Security WG > > ++ FRIDAY, November 6, 2015 ++ > > 0900-1130 Morning Session I > Room 502 ART perc Privacy Enhanced RT= P Conferencing WG > Room 303 OPS grow Global Routing Opera= tions WG - 1030 - 1130 > Room 301 OPS l3sm L3VPN Service Model= WG - 0900 - 1030 > Room 301 OPS opsec Operational Security = Capabilities for IP Network Infrastructure WG - 1030 - 1130 > Room 303 RTG sidr Secure Inter-Domain Routing WG - 0= 900 - 1030 > Room 501 TSV rmcat RTP Media Congestion = Avoidance Techniques WG > > Regards, > Alexa > > > ---------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) Forum Management, > Meeting and Event Planning www.amsl.com >= --_002_5D36713D8A4E7348A7E10DF7437A4B927BBC6BD6nkgeml512mbxchi_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=124; creation-date="Sun, 01 Nov 2015 20:40:11 GMT"; modification-date="Sun, 01 Nov 2015 20:40:11 GMT" Content-ID: <9337371F49245B43A14D977A78179EFC@huawei.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNkbiBtYWls aW5nIGxpc3QNCnNkbkBpcnRmLm9yZw0KaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZG4NCg== --_002_5D36713D8A4E7348A7E10DF7437A4B927BBC6BD6nkgeml512mbxchi_-- From nobody Sun Nov 1 15:55:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D92B1B3B60 for ; Sun, 1 Nov 2015 15:55:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 uzd-9pne-Dq2 for ; Sun, 1 Nov 2015 15:55:42 -0800 (PST) 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 7E8641B3B5F for ; Sun, 1 Nov 2015 15:55:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 60EE324E0C9; Sun, 1 Nov 2015 15:55:42 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from dhcp-40-55.meeting.ietf94.jp (dhcp-40-55.meeting.ietf94.jp [133.93.40.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 17BEC242624; Sun, 1 Nov 2015 15:55:40 -0800 (PST) To: "Michael Behringer (mbehring)" , John Strassner , "Toerless Eckert (eckert)" References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> From: "Joel M. Halpern" Message-ID: <5636A67B.5000901@joelhalpern.com> Date: Sun, 1 Nov 2015 18:55:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Michael Richardson , "reddy.pallavali@ulusofona.pt" , Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 23:55:45 -0000 If I understand you, I agree that a strong ACP layer is valuable for the work we want to do. But if we do not provide some (significant) interoperable value on top of that, I don't see folks implementing it. Yours, Joel On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote: > John, in my opinion, if we get to the point of a solid autonomic > infrastructure with the right base services, such as discovery, > messaging, built on a self-managing ACP, developpers will have all the > tools to write the functions that you want. > > The AN infrastructure is the new IP: like IP enabled folks to write > networking applications really easily, the ANI allows to write > self-management functions really easily. > > If we get ANI right, we enable a whole new eco-system of network > programming. > > Michael > > *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *John Strassner > *Sent:* 01 November 2015 21:44 > *To:* Toerless Eckert (eckert) ; John Strassner > > *Cc:* Michael Richardson ; Joel M. Halpern > ; reddy.pallavali@ulusofona.pt; Anima WG > > *Subject:* Re: [Anima] [ANIMA] Self-Managed Networks > > Hi Toerless, > >> Before anima, every distributed function we designed in the IETF >> used its own reinvented communication paradigm. The only common >> mechanism was use of IP packets, but not even that was the lowest > >> common denominator (IS-IS anybody). > > At the risk of rocking the boat, I'm less interested in using autonomics > > for "plumbing" issues, such as healing broken routes, as I am in > > correcting user- and business-oriented functions and services. > > We are engineers. We have a natural affinity for playing with bright, > > shiny knobs that provide new technologies with which to design. > > However, this rarely directly pays the bills. The business person > > typically does not care what technologies and features are used, as > > long as his or her service works. If it exceeds an SLA, then its > > scotch time as well. > > But there is no "gold service enable" CLI command that I've ever seen. > > This is why many of the autonomic projects have tried to reach above > > forwarding and routing and try and translate business concepts to > > drive network services and resources that the business needs. > > We've failed, rather spectacularly, so far. After 500+ conferences on > > Future Internet, Next Generation Networking, yada-yada-yada, we > > still do not have a replacement for SNMP. > > NFV was stillborn - it has the management capabilities of a walnut. > > SDN is a bit more like an apple (tastier and prettier, but still no > > management). > > I know the IETF loves to work bottom-up. But perhaps we need to > > have a top-down approach as well to fix this. Otherwise, the network > > that never fails but still doesn't provide business value is just another > > cool journal paper. > > regards, > > John > > On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert > wrote: > > The way i see it: > > Before anima, every distributed function we designed in the IETF > used its own reinvented communication paradigm. The only common > mechanism was use of IP packets, but not even that was the lowest common > denominator (IS-IS anybody). > > So the question really is what are the pragmatic common communication > mechanisms we can come up with to make future distributed functions > easier to implement, deploy and operate. With focus on "deploy" because > thats what we want to be autonomic. And start with what our own "anima" > distributed functions realized via "agents" need. > > We know p2p with common presentation layer and set of session > transaction > types, and some limited discovery, eg: mp2mp transactions. > > The discussion now is what's logically next. Once we have an idea, then > we can figure whether it makes sense to call/put-into GRASP and/or > if/how > to deal with it in ANIMA. > > > On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote: > > Hi all, > > > > Sorry, I'm a bit confused. > > > > To me, this thread is starting to discuss generic messaging system > > capabilities (e.g., at the minimum, a message broker, at the other > > end of the scale, a full-blown ESB). I didn't think that the purpose > > of the ACP included such capabilities. > > > > In other words, there is a huge difference between GRASP > > generating a notification and GRASP functioning as a full > > messaging system, complete with message transformation and > > routing, queuing, etc. > > > > I was assuming the former, not the latter. > > > > Please correct me if I am wrong. > > > > (Note that FOCALE used an ESB for inter-agent communication.) > > > > regards, > > John > > > > > > > > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter < > >brian.e.carpenter@gmail.com > wrote: > > > > > On 20/10/2015 08:04, Joel M. Halpern wrote: > > > > There are at least two different factors to consider in terms of what > > > events are communicated to the operator. > > > > > > > > First, for initial deployment of autonomic technologies, operators will > > > want ways to observe all the events so they can gain > > > > confidence in the technology. (We received these requests with existing > > > self-organizing network technologies.) > > > > > > > > Secondly, different operators have different degrees of information > > > harvesting and display relative to the state of the > > > > network. Even if the network is taking care of itself perfectly, some > > > operators will want visibility to any internal state > > > > change. These operators currently monitor their routing protocol state > > > for similar effects. > > > > > > What I get from this is a requirement that all ASAs are capable of > > > notifying events, > > > but whether and how those events are reported live to operators is a > > > separate issue. > > > > > > (However, I have never forgotten that at Three Mile Island, the system was > > > so busy > > > reporting minor alarms that it took hours before the underlying alarm > > > message > > > saying what was really wrong got printed. TMI, indeed.) > > > > > > Brian > > > > > > > > > > > Yours, > > > > Joel > > > > > > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote: > > > >> Michael, > > > >> > > > >> Yes, for every small issue there is no need to contact operator except, > > > >> if it is a complex one. > > > >> Even for self-healing we can use Swarm Intelligence or Artificial > > > >> Intelligence techniques, but for learning may take some time. However, > > > >> these are scalable techniques. > > > >> Here, also there is a need of consensus, if the system is fully > > > >> distributed and asynchronous need to know which object is crashed, how > > > >> to schedule the loads and coverage issues as well. > > > >> > > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson > > > >> > >> wrote: > > > >> > > > >> > > > >> John Strassner > >> > > > wrote: > > > >> > When an autonomic system self-heals, why would the operator > > > >> need to > > > >> > know? This is comparable to routing doing its job and > > > >> changing the > > > >> > path. There is no reason that the operator has to be alerted > > > >> on every > > > >> > change in the system - there are already WAY TOO MANY of > > > >> these for the > > > >> > operator to handle. > > > >> > > > >> Yes, but just the same, the healing activity needs to be an audited > > > >> event. > > > >> The ACP should be involved in capturing these events. > > > >> > > > >> Sometimes things don't heal perfectly; often moving traffic from > > > >> one system to another causes a load spike, and while things > > > continue to > > > >> function, the performance is different. > > > >> > > > >> -- > > > >> Michael Richardson > > > >> >>, > Sandelman Software Works > > > >> -= IPv6 IoT consulting =- > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >>Anima@ietf.org > > > > >>https://www.ietf.org/mailman/listinfo/anima > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> Thank you very much for your time and consideration. > > > >> > > > >> > > > >> Yours sincerely, > > > >> > > > >> P Radha Krishna Reddy, M.Sc, M.Tech, > > > >> > > > >> Junior Researcher/Ph.D Student, > > > >> > > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal. > > > >> > > > >> Author of: Security Issues of Cloud Computing over General & IT Sector > > > >> Mobile:+351923095671 > > > >>www.prkreddy.webs.com > > > >>http://pt.linkedin.com/in/reddypallavali/ > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >>Anima@ietf.org > > > >>https://www.ietf.org/mailman/listinfo/anima > > > >> > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > >Anima@ietf.org > > > >https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > >Anima@ietf.org > > >https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > -- > > regards, > > John > > > _______________________________________________ > > Anima mailing list > >Anima@ietf.org > >https://www.ietf.org/mailman/listinfo/anima > > > -- > --- > Toerless Eckert, eckert@cisco.com > > > > > -- > > regards, > > John > From nobody Sun Nov 1 16:29:03 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C38E1B3D64 for ; Sun, 1 Nov 2015 16:29:00 -0800 (PST) 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 lF-KSMRSEqjq for ; Sun, 1 Nov 2015 16:28:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219371B3D62 for ; Sun, 1 Nov 2015 16:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=936; q=dns/txt; s=iport; t=1446424136; x=1447633736; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g0nBfsKt++HowmZHa7dRDp57nShkLa8je1TYu8y6Wqg=; b=M4L84bBVT8waF35dfj+lE+KUXl3a1RIahyy1CZZfcjm023pbKBKYm2aq 7UPmk5WMxzKKrvKiR3UNN9IwuuOZE9gFfM0U9NXNrz6F0m2V8S5adWdP/ 0oD6X/QhlYbxfOYiOhfrVXqgS2L0fwtgmju4of+Aer1IUGiXpxYGPxIAA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1AQAyrTZW/5BdJa1egzuBQga7DYQhAQ2BWoYZAhyBBzgUAQEBAQEBAYEKhDUBAQEEIxFFDAQCAQgRBAEBAwIjAwICAh8RFAEICAIEAQ0FCIgTAxKweowADYRCAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEihVWEfoFSgQGFKIFFAQSWQwGLLoFvlHCHUAEfAQFChARyhHeBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,230,1444694400"; d="scan'208";a="46504185" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP; 02 Nov 2015 00:28:55 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tA20StvB014895 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 00:28:55 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 1 Nov 2015 18:28:54 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Sun, 1 Nov 2015 18:28:54 -0600 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , John Strassner , "Toerless Eckert (eckert)" Thread-Topic: [Anima] [ANIMA] Self-Managed Networks Thread-Index: AQHRCpUjXjIe5GlP3E2ynPCuDySifJ5zfv6AgAABsoCAAAiQAIABUtKAgAAIIYCAErEyAIAAKTJQgACScoD//6SJwA== Date: Mon, 2 Nov 2015 00:28:54 +0000 Message-ID: <99ebecc1af084f67be2e69ba6a67287c@XCH-RCD-006.cisco.com> References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5636A67B.5000901@joelhalpern.com> In-Reply-To: <5636A67B.5000901@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "reddy.pallavali@ulusofona.pt" , Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 00:29:00 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21h aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPiBTZW50OiAwMiBOb3ZlbWJlciAyMDE1IDA4OjU2 DQo+IFRvOiBNaWNoYWVsIEJlaHJpbmdlciAobWJlaHJpbmcpIDxtYmVocmluZ0BjaXNjby5jb20+ OyBKb2huIFN0cmFzc25lcg0KPiA8c3RyYXpwZGpAZ21haWwuY29tPjsgVG9lcmxlc3MgRWNrZXJ0 IChlY2tlcnQpIDxlY2tlcnRAY2lzY28uY29tPg0KPiBDYzogTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IraWV0ZkBzYW5kZWxtYW4uY2E+Ow0KPiByZWRkeS5wYWxsYXZhbGlAdWx1c29mb25hLnB0OyBB bmltYSBXRyA8YW5pbWFAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbQW5pbWFdIFtBTklNQV0g U2VsZi1NYW5hZ2VkIE5ldHdvcmtzDQo+IA0KPiBJZiBJIHVuZGVyc3RhbmQgeW91LCBJIGFncmVl IHRoYXQgYSBzdHJvbmcgQUNQIGxheWVyIGlzIHZhbHVhYmxlIGZvciB0aGUgd29yaw0KPiB3ZSB3 YW50IHRvIGRvLg0KPiANCj4gQnV0IGlmIHdlIGRvIG5vdCBwcm92aWRlIHNvbWUgKHNpZ25pZmlj YW50KSBpbnRlcm9wZXJhYmxlIHZhbHVlIG9uIHRvcCBvZg0KPiB0aGF0LCBJIGRvbid0IHNlZSBm b2xrcyBpbXBsZW1lbnRpbmcgaXQuDQoNCkNvbXBsZXRlbHkgYWdyZWUuIA0KDQpNaWNoYWVsDQo= From nobody Sun Nov 1 16:41:20 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB81B3E01 for ; Sun, 1 Nov 2015 16:41:18 -0800 (PST) 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 KTse9D7Cv2gF for ; Sun, 1 Nov 2015 16:41:14 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0: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 C57571B3E00 for ; Sun, 1 Nov 2015 16:41:13 -0800 (PST) Received: by vkgs66 with SMTP id s66so76467847vkg.1 for ; Sun, 01 Nov 2015 16:41:13 -0800 (PST) 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=zxW/+AhUjt32XkGTB01MOLRdQ/Vtd4m+XLakn2h1YHI=; b=B7yu/hU9oO2rpDEix/Wxx7ysKKjZGM0DJVMD69Jt6hRp1aiJ2BxR9DjcMCdY0r5CoY JsSlQDq/phRm9LiVd6IF07hsJ6NCA/iNtpBY5w2EtuHhMP4NkR3DINFhymg/VmsXULbZ lGMpa+jrXoEhwdc0Jq8W7D3eY78KW14PttCoTSvpvRppcCwF6puMOI72UMBBHFrvtlYx leGb6e6oyDycOWY7n/6rtLFYoNoIjDFw7C2nb7jsW9NWqi8Xam1eY34OlX61mBfFaQvU Vq17NzOb2sQzF9T1dz0ewZbI9Lv/0jYGG+r0UnNTmwLpFfTgVdozK7CnKOMlO8oxPB88 aolg== MIME-Version: 1.0 X-Received: by 10.31.162.14 with SMTP id l14mr11708444vke.110.1446424872901; Sun, 01 Nov 2015 16:41:12 -0800 (PST) Received: by 10.103.40.132 with HTTP; Sun, 1 Nov 2015 16:41:12 -0800 (PST) In-Reply-To: <5636A67B.5000901@joelhalpern.com> References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5636A67B.5000901@joelhalpern.com> Date: Sun, 1 Nov 2015 16:41:12 -0800 Message-ID: From: John Strassner To: "Joel M. Halpern" , John Strassner Content-Type: multipart/alternative; boundary=001a11440296be63b505238408a3 Archived-At: Cc: Michael Richardson , "Toerless Eckert \(eckert\)" , "reddy.pallavali@ulusofona.pt" , Anima WG , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 00:41:18 -0000 --001a11440296be63b505238408a3 Content-Type: text/plain; charset=UTF-8 Hi Michael and Joel, I completely agree that we need a solid autonomic infrastructure. Without a solid foundation, we don't have anything to build upon. My point is that AFTER we have such a foundation, we need to turn our focus northwards (towards the app developers and customers), instead of staying down in the weeds. So, as Joel opined, once we have that foundation, let's (for once) look at how to enable the business to use these functions. For example, in FOCALE, we used the concept of capabilities and requirements to self-organize NEs in different ANIs to "communities" that could support similar autonomic functions. This provided several benefits, both at the infrastructure as well as at higher layers. regards, John On Sun, Nov 1, 2015 at 3:55 PM, Joel M. Halpern wrote: > If I understand you, I agree that a strong ACP layer is valuable for the > work we want to do. > > But if we do not provide some (significant) interoperable value on top of > that, I don't see folks implementing it. > > Yours, > Joel > > On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote: > >> John, in my opinion, if we get to the point of a solid autonomic >> infrastructure with the right base services, such as discovery, >> messaging, built on a self-managing ACP, developpers will have all the >> tools to write the functions that you want. >> >> The AN infrastructure is the new IP: like IP enabled folks to write >> networking applications really easily, the ANI allows to write >> self-management functions really easily. >> >> If we get ANI right, we enable a whole new eco-system of network >> programming. >> >> Michael >> >> *From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *John >> Strassner >> *Sent:* 01 November 2015 21:44 >> *To:* Toerless Eckert (eckert) ; John Strassner >> >> *Cc:* Michael Richardson ; Joel M. Halpern >> ; reddy.pallavali@ulusofona.pt; Anima WG >> >> *Subject:* Re: [Anima] [ANIMA] Self-Managed Networks >> >> Hi Toerless, >> >> Before anima, every distributed function we designed in the IETF >>> used its own reinvented communication paradigm. The only common >>> mechanism was use of IP packets, but not even that was the lowest >>> >> >> common denominator (IS-IS anybody). >>> >> >> At the risk of rocking the boat, I'm less interested in using autonomics >> >> for "plumbing" issues, such as healing broken routes, as I am in >> >> correcting user- and business-oriented functions and services. >> >> We are engineers. We have a natural affinity for playing with bright, >> >> shiny knobs that provide new technologies with which to design. >> >> However, this rarely directly pays the bills. The business person >> >> typically does not care what technologies and features are used, as >> >> long as his or her service works. If it exceeds an SLA, then its >> >> scotch time as well. >> >> But there is no "gold service enable" CLI command that I've ever seen. >> >> This is why many of the autonomic projects have tried to reach above >> >> forwarding and routing and try and translate business concepts to >> >> drive network services and resources that the business needs. >> >> We've failed, rather spectacularly, so far. After 500+ conferences on >> >> Future Internet, Next Generation Networking, yada-yada-yada, we >> >> still do not have a replacement for SNMP. >> >> NFV was stillborn - it has the management capabilities of a walnut. >> >> SDN is a bit more like an apple (tastier and prettier, but still no >> >> management). >> >> I know the IETF loves to work bottom-up. But perhaps we need to >> >> have a top-down approach as well to fix this. Otherwise, the network >> >> that never fails but still doesn't provide business value is just another >> >> cool journal paper. >> >> regards, >> >> John >> >> On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert > > wrote: >> >> The way i see it: >> >> Before anima, every distributed function we designed in the IETF >> used its own reinvented communication paradigm. The only common >> mechanism was use of IP packets, but not even that was the lowest >> common >> denominator (IS-IS anybody). >> >> So the question really is what are the pragmatic common communication >> mechanisms we can come up with to make future distributed functions >> easier to implement, deploy and operate. With focus on "deploy" >> because >> thats what we want to be autonomic. And start with what our own >> "anima" >> distributed functions realized via "agents" need. >> >> We know p2p with common presentation layer and set of session >> transaction >> types, and some limited discovery, eg: mp2mp transactions. >> >> The discussion now is what's logically next. Once we have an idea, >> then >> we can figure whether it makes sense to call/put-into GRASP and/or >> if/how >> to deal with it in ANIMA. >> >> >> On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote: >> > Hi all, >> > >> > Sorry, I'm a bit confused. >> > >> > To me, this thread is starting to discuss generic messaging system >> > capabilities (e.g., at the minimum, a message broker, at the other >> > end of the scale, a full-blown ESB). I didn't think that the purpose >> > of the ACP included such capabilities. >> > >> > In other words, there is a huge difference between GRASP >> > generating a notification and GRASP functioning as a full >> > messaging system, complete with message transformation and >> > routing, queuing, etc. >> > >> > I was assuming the former, not the latter. >> > >> > Please correct me if I am wrong. >> > >> > (Note that FOCALE used an ESB for inter-agent communication.) >> > >> > regards, >> > John >> > >> > >> > >> > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter < >> >brian.e.carpenter@gmail.com > >> wrote: >> > >> > > On 20/10/2015 08:04, Joel M. Halpern wrote: >> > > > There are at least two different factors to consider in terms >> of what >> > > events are communicated to the operator. >> > > > >> > > > First, for initial deployment of autonomic technologies, >> operators will >> > > want ways to observe all the events so they can gain >> > > > confidence in the technology. (We received these requests with >> existing >> > > self-organizing network technologies.) >> > > > >> > > > Secondly, different operators have different degrees of >> information >> > > harvesting and display relative to the state of the >> > > > network. Even if the network is taking care of itself >> perfectly, some >> > > operators will want visibility to any internal state >> > > > change. These operators currently monitor their routing >> protocol state >> > > for similar effects. >> > > >> > > What I get from this is a requirement that all ASAs are capable of >> > > notifying events, >> > > but whether and how those events are reported live to operators >> is a >> > > separate issue. >> > > >> > > (However, I have never forgotten that at Three Mile Island, the >> system was >> > > so busy >> > > reporting minor alarms that it took hours before the underlying >> alarm >> > > message >> > > saying what was really wrong got printed. TMI, indeed.) >> > > >> > > Brian >> > > >> > > > >> > > > Yours, >> > > > Joel >> > > > >> > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote: >> > > >> Michael, >> > > >> >> > > >> Yes, for every small issue there is no need to contact >> operator except, >> > > >> if it is a complex one. >> > > >> Even for self-healing we can use Swarm Intelligence or >> Artificial >> > > >> Intelligence techniques, but for learning may take some time. >> However, >> > > >> these are scalable techniques. >> > > >> Here, also there is a need of consensus, if the system is fully >> > > >> distributed and asynchronous need to know which object is >> crashed, how >> > > >> to schedule the loads and coverage issues as well. >> > > >> >> > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson >> > > >> >> >> >> wrote: >> > > >> >> > > >> >> > > >> John Strassner > strazpdj@gmail.com> >> >> >> > > wrote: >> > > >> > When an autonomic system self-heals, why would the >> operator >> > > >> need to >> > > >> > know? This is comparable to routing doing its job >> and >> > > >> changing the >> > > >> > path. There is no reason that the operator has to >> be alerted >> > > >> on every >> > > >> > change in the system - there are already WAY TOO >> MANY of >> > > >> these for the >> > > >> > operator to handle. >> > > >> >> > > >> Yes, but just the same, the healing activity needs to be >> an audited >> > > >> event. >> > > >> The ACP should be involved in capturing these events. >> > > >> >> > > >> Sometimes things don't heal perfectly; often moving >> traffic from >> > > >> one system to another causes a load spike, and while things >> > > continue to >> > > >> function, the performance is different. >> > > >> >> > > >> -- >> > > >> Michael Richardson > mcr%2BIETF@sandelman.ca> >> > > >> > mcr%252BIETF@sandelman.ca>>>, >> Sandelman Software Works >> > > >> -= IPv6 IoT consulting =- >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> _______________________________________________ >> > > >> Anima mailing list >> > > >>Anima@ietf.org > > >> > > >>https://www.ietf.org/mailman/listinfo/anima >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Thank you very much for your time and consideration. >> > > >> >> > > >> >> > > >> Yours sincerely, >> > > >> >> > > >> P Radha Krishna Reddy, M.Sc, M.Tech, >> > > >> >> > > >> Junior Researcher/Ph.D Student, >> > > >> >> > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal. >> > > >> >> > > >> Author of: Security Issues of Cloud Computing over General & >> IT Sector >> > > >> Mobile:+351923095671 >> > > >>www.prkreddy.webs.com >> > > >>http://pt.linkedin.com/in/reddypallavali/ >> > > >> >> > > >> >> > > >> _______________________________________________ >> > > >> Anima mailing list >> > > >>Anima@ietf.org >> > > >>https://www.ietf.org/mailman/listinfo/anima >> > > >> >> > > > >> > > > _______________________________________________ >> > > > Anima mailing list >> > > >Anima@ietf.org >> > > >https://www.ietf.org/mailman/listinfo/anima >> > > > >> > > >> > > _______________________________________________ >> > > Anima mailing list >> > >Anima@ietf.org >> > >https://www.ietf.org/mailman/listinfo/anima >> > > >> > >> > >> > >> > -- >> > regards, >> > John >> >> > _______________________________________________ >> > Anima mailing list >> >Anima@ietf.org >> >https://www.ietf.org/mailman/listinfo/anima >> >> >> -- >> --- >> Toerless Eckert, eckert@cisco.com >> >> >> >> >> -- >> >> regards, >> >> John >> >> -- regards, John --001a11440296be63b505238408a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael and Joel,

I compl= etely agree that we need a solid autonomic infrastructure.
Withou= t a solid foundation, we don't have anything to build upon.
<= br>
My point is that AFTER we have such a foundation, we need to<= /div>
turn our focus northwards (towards the app developers and
customers), instead of staying down in the weeds.

So, as Joel opined, once we have that foundation, let's (for once)
look at how to enable the business to use these functions. For
example, in FOCALE, we used the concept of capabilities and
requirements to self-organize NEs in different ANIs to
"co= mmunities" that could support similar autonomic functions.
T= his provided several benefits, both at the infrastructure as well
as at higher layers.

regards,
John
<= /div>

On Sun= , Nov 1, 2015 at 3:55 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
If I understand you, I agree= that a strong ACP layer is valuable for the work we want to do.

But if we do not provide some (significant) interoperable value on top of t= hat, I don't see folks implementing it.

Yours,
Joel

On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote:
John, in my opinion, if we get to the point of a solid autonomic
infrastructure with the right base services, such as discovery,
messaging, built on a self-managing ACP, developpers will have all the
tools to write the functions that you want.

The AN infrastructure is the new IP: like IP enabled folks to write
networking applications really easily, the ANI allows to write
self-management functions really easily.

If we get ANI right, we enable a whole new eco-system of network
programming.

Michael

*From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *John Strassner
*Sent:* 01 November 2015 21:44
*To:* Toerless Eckert (eckert) <eckert@cisco.com>; John Strassner
<strazpdj@gmail.= com>
*Cc:* Michael Richardson <mcr+ietf@sandelman.ca>; Joel M. Halpern
<jmh@joelhalper= n.com>; reddy.pallavali@ulusofona.pt; Anima WG
<anima@ietf.org&= gt;
*Subject:* Re: [Anima] [ANIMA] Self-Managed Networks

Hi Toerless,

Before anima, every distributed function we designed in the IETF
used its own reinvented communication paradigm. The only common
mechanism was use of IP packets, but not even that was the lowest

common denominator (IS-IS anybody).

At the risk of rocking the boat, I'm less interested in using autonomic= s

for "plumbing" issues, such as healing broken routes, as I am in<= br>
correcting user- and business-oriented functions and services.

We are engineers. We have a natural affinity for playing with bright,

shiny knobs that provide new technologies with which to design.

However, this rarely directly pays the bills. The business person

typically does not care what technologies and features are used, as

long as his or her service works. If it exceeds an SLA, then its

scotch time as well.

But there is no "gold service enable" CLI command that I've e= ver seen.

This is why many of the autonomic projects have tried to reach above

forwarding and routing and try and translate business concepts to

drive network services and resources that the business needs.

We've failed, rather spectacularly, so far. After 500+ conferences on
Future Internet, Next Generation Networking, yada-yada-yada, we

still do not have a replacement for SNMP.

NFV was stillborn - it has the management capabilities of a walnut.

SDN is a bit more like an apple (tastier and prettier, but still no

management).

I know the IETF loves to work bottom-up. But perhaps we need to

have a top-down approach as well to fix this. Otherwise, the network

that never fails but still doesn't provide business value is just anoth= er

cool journal paper.

regards,

John

On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert <eckert@cisco.com
<mailto:eckert@cis= co.com>> wrote:

=C2=A0 =C2=A0 The way i see it:

=C2=A0 =C2=A0 Before anima, every distributed function we designed in the I= ETF
=C2=A0 =C2=A0 used its own reinvented communication paradigm. The only comm= on
=C2=A0 =C2=A0 mechanism was use of IP packets, but not even that was the lo= west common
=C2=A0 =C2=A0 denominator (IS-IS anybody).

=C2=A0 =C2=A0 So the question really is what are the pragmatic common commu= nication
=C2=A0 =C2=A0 mechanisms we can come up with to make future distributed fun= ctions
=C2=A0 =C2=A0 easier to implement, deploy and operate. With focus on "= deploy" because
=C2=A0 =C2=A0 thats what we want to be autonomic. And start with what our o= wn "anima"
=C2=A0 =C2=A0 distributed functions realized via "agents" need.
=C2=A0 =C2=A0 We know p2p with common presentation layer and set of session=
=C2=A0 =C2=A0 transaction
=C2=A0 =C2=A0 types, and some limited discovery, eg: mp2mp transactions.
=C2=A0 =C2=A0 The discussion now is what's logically next. Once we have= an idea, then
=C2=A0 =C2=A0 we can figure whether it makes sense to call/put-into GRASP a= nd/or
=C2=A0 =C2=A0 if/how
=C2=A0 =C2=A0 to deal with it in ANIMA.


=C2=A0 =C2=A0 On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrot= e:
=C2=A0 =C2=A0 > Hi all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Sorry, I'm a bit confused.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > To me, this thread is starting to discuss generic messag= ing system
=C2=A0 =C2=A0 > capabilities (e.g., at the minimum, a message broker, at= the other
=C2=A0 =C2=A0 > end of the scale, a full-blown ESB). I didn't think = that the purpose
=C2=A0 =C2=A0 > of the ACP included such capabilities.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > In other words, there is a huge difference between GRASP=
=C2=A0 =C2=A0 > generating a notification and GRASP functioning as a ful= l
=C2=A0 =C2=A0 > messaging system, complete with message transformation a= nd
=C2=A0 =C2=A0 > routing, queuing, etc.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I was assuming the former, not the latter.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please correct me if I am wrong.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > (Note that FOCALE used an ESB for inter-agent communicat= ion.)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > regards,
=C2=A0 =C2=A0 > John
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter <=
=C2=A0 =C2=A0 >brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>= ;> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > > On 20/10/2015 08:04, Joel M. Halpern wrote:
=C2=A0 =C2=A0 > > > There are at least two different factors to co= nsider in terms of what
=C2=A0 =C2=A0 > > events are communicated to the operator.
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > > > First, for initial deployment of autonomic tec= hnologies, operators will
=C2=A0 =C2=A0 > > want ways to observe all the events so they can gai= n
=C2=A0 =C2=A0 > > > confidence in the technology.=C2=A0 (We receiv= ed these requests with existing
=C2=A0 =C2=A0 > > self-organizing network technologies.)
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > > > Secondly, different operators have different d= egrees of information
=C2=A0 =C2=A0 > > harvesting and display relative to the state of the=
=C2=A0 =C2=A0 > > > network.=C2=A0 Even if the network is taking c= are of itself perfectly, some
=C2=A0 =C2=A0 > > operators will want visibility to any internal stat= e
=C2=A0 =C2=A0 > > > change.=C2=A0 These operators currently monito= r their routing protocol state
=C2=A0 =C2=A0 > > for similar effects.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > What I get from this is a requirement that all ASAs= are capable of
=C2=A0 =C2=A0 > > notifying events,
=C2=A0 =C2=A0 > > but whether and how those events are reported live = to operators is a
=C2=A0 =C2=A0 > > separate issue.
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > (However, I have never forgotten that at Three Mile= Island, the system was
=C2=A0 =C2=A0 > > so busy
=C2=A0 =C2=A0 > > reporting minor alarms that it took hours before th= e underlying alarm
=C2=A0 =C2=A0 > > message
=C2=A0 =C2=A0 > > saying what was really wrong got printed. TMI, inde= ed.)
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > >=C2=A0 =C2=A0 Brian
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > > > Yours,
=C2=A0 =C2=A0 > > > Joel
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote: =C2=A0 =C2=A0 > > >> Michael,
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> Yes, for every small issue there is no nee= d to contact operator except,
=C2=A0 =C2=A0 > > >> if it is a complex one.
=C2=A0 =C2=A0 > > >> Even for self-healing we can use Swarm Int= elligence or Artificial
=C2=A0 =C2=A0 > > >> Intelligence techniques, but for learning = may take some time. However,
=C2=A0 =C2=A0 > > >> these are scalable techniques.
=C2=A0 =C2=A0 > > >> Here, also there is a need of consensus, i= f the system is fully
=C2=A0 =C2=A0 > > >> distributed and asynchronous need to know = which object is crashed, how
=C2=A0 =C2=A0 > > >> to schedule the loads and coverage issues = as well.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael R= ichardson
=C2=A0 =C2=A0 > > >> <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca= >
=C2=A0 =C2=A0 <mailto:mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>>>= ; wrote:
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0John Strassner <strazpdj@gmail.com = <mailto:strazpdj= @gmail.com>
=C2=A0 =C2=A0 <mailto:strazpdj@gmail.com <mailto:strazpdj@gmail.com>>>
=C2=A0 =C2=A0 > > wrote:
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > Whe= n an autonomic system self-heals, why would the operator
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0need to
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > kno= w? This is comparable to routing doing its job and
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0changing the
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > pat= h. There is no reason that the operator has to be alerted
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0on every
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > cha= nge in the system - there are already WAY TOO MANY of
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0these for the
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > ope= rator to handle.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0Yes, but just the same,= the healing activity needs to be an audited
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0event.
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0The ACP should be invol= ved in capturing these events.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0Sometimes things don= 9;t heal perfectly; often moving traffic from
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0one system to another c= auses a load spike, and while things
=C2=A0 =C2=A0 > > continue to
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0function, the performan= ce is different.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0--
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0Michael Richardson <= mcr+IETF@sande= lman.ca <mailto:mcr%2BIETF@sandelman.ca>
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0<mailto:mcr%2BIETF@sandelman.ca<= /a> <mailto:mcr%252BIETF@sandelman.ca>>>,
=C2=A0 =C2=A0 Sandelman Software Works
=C2=A0 =C2=A0 > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0-=3D IPv6 IoT co= nsulting =3D-
=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=A0Anima mailing list
=C2=A0 =C2=A0 > > >>Anima@ietf.org <mailto:Anima@ietf.org> <mailto:Anima@ietf.org
=C2=A0 =C2=A0 <mailto:Anima@ietf.org>>
=C2=A0 =C2=A0 > > >>https://www.ietf.org/mail= man/listinfo/anima
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> --
=C2=A0 =C2=A0 > > >> Thank you very much for your time and cons= ideration.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> Yours sincerely,
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> P Radha Krishna Reddy, M.Sc, M.Tech,
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> Junior Researcher/Ph.D Student,
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> COPE LABS, Universidade Lusofona, Lisboa -= Portugal.
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> Author of: Security Issues of Cloud Comput= ing over General & IT Sector
=C2=A0 =C2=A0 > > >> Mobile:+351923095671 <tel:%2B3519230= 95671>
=C2=A0 =C2=A0 > > >>www.prkreddy.webs.com <http://= www.prkreddy.webs.com>
=C2=A0 =C2=A0 > > >>http://pt.linkedin.com/in/r= eddypallavali/
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >> __________________________________________= _____
=C2=A0 =C2=A0 > > >> Anima mailing list
=C2=A0 =C2=A0 > > >>Anima@ietf.org <mailto:Anima@ietf.org>
=C2=A0 =C2=A0 > > >>https://www.ietf.org/mail= man/listinfo/anima
=C2=A0 =C2=A0 > > >>
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > > > ______________________________________________= _
=C2=A0 =C2=A0 > > > Anima mailing list
=C2=A0 =C2=A0 > > >Anima@ietf.org <mailto:Anima@ietf.org>
=C2=A0 =C2=A0 > > >https://www.ietf.org/mailman/= listinfo/anima
=C2=A0 =C2=A0 > > >
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 > > _______________________________________________
=C2=A0 =C2=A0 > > Anima mailing list
=C2=A0 =C2=A0 > >= Anima@ietf.org <mailto:Anima@ietf.org>
=C2=A0 =C2=A0 > >https://www.ietf.org/mailman/listi= nfo/anima
=C2=A0 =C2=A0 > >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > regards,
=C2=A0 =C2=A0 > John

=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Anima mailing list
=C2=A0 =C2=A0 >Anima= @ietf.org <mailto:Anima@ietf.org>
=C2=A0 =C2=A0 >https://www.ietf.org/mailman/listinfo/a= nima


=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 ---
=C2=A0 =C2=A0 Toerless Eckert, eckert@cisco.com <mailto:eckert@cisco.com>




--

regards,

John




--
regards,
John
--001a11440296be63b505238408a3-- From nobody Sun Nov 1 16:56:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91E11B3E77 for ; Sun, 1 Nov 2015 16:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, 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 kpEqLwa7UFMt for ; Sun, 1 Nov 2015 16:56:30 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83FF1B3E6D for ; Sun, 1 Nov 2015 16:56:29 -0800 (PST) Received: from sandelman.ca (t20010c40000030325de57cdc9ff70c71.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:5de5:7cdc:9ff7:c71]) by relay.sandelman.ca (Postfix) with ESMTPS id 888A72208B for ; Sun, 1 Nov 2015 19:56:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C657A61E1C; Sun, 1 Nov 2015 19:56:24 -0500 (EST) From: Michael Richardson To: Anima WG In-reply-to: References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> Comments: In-reply-to John Strassner message dated "Sun, 01 Nov 2015 04:44:04 -0800." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Nov 2015 09:56:24 +0900 Message-ID: <13027.1446425784@dooku.sandelman.ca> Archived-At: Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 00:56:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable John Strassner wrote: > Hi Toerless, >> Before anima, every distributed function we designed in the IETF used >> its own reinvented communication paradigm. The only common mechanism >> was use of IP packets, but not even that was the lowest =C2=A0common >> denominator (IS-IS anybody). > At the risk of rocking the boat, I'm less interested in using > autonomics for "plumbing" issues, such as healing broken routes, as I > am in correcting user- and business-oriented functions and services. > We are engineers. We have a natural affinity for playing with bright, > shiny knobs that provide new technologies with which to design. > However, this rarely directly pays the bills. The business person > typically does not care what technologies and features are used, as > long as his or her service works. If it exceeds an SLA, then its scot= ch > time as well. okay, so I hear your point, and I generally tend to agree. But, I want to argue for the business value of the plumbing. I've built a few small ISPs, and worked with entities like root-name server deployments. In each case it was very very difficult to do the justificati= on for the needed out-of-band access (telco's called it "craft terminal") that is needed during initial deployment and disaster recovery. Serial console servers are ridiculously expensive for what they do, and when you need only one or two ports in a shared cabinet, but you have 40 to 70 of these spread around the world... (as anycase root server operators have), it's a real financial pain. The ACP as plumbing of last resort really deals with this problem. The fact that it can also be substrate for something new is good. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWNrSzAAoJEKD0KQ7Gj3P2ykcH/i9X4pN3i4H0OKvq8DN50NVv nRlgX2ita58EpxCsxOd+egl6iszGqamdBSoA1iNFHh0iwvIv0YpNM96KbK2dRKFM Y/0EC08yZ6uIPZlmezpWI591ObxMgW9pCpvqrrDNEq5/OcvaotmODEWAOGmNGeqK o9aJ/bGpqRqJ99F3M1D5mmWZNLOiPS9H8gOy80Y8vFL6Vk/zhvPtIDBpL91SrZwh VVCV4S5J/da9rn3jJ+hPdkxG9s6aW+Q/485kbb4GQtlBBS7buwEfazkLT3MEPaUr hyteeoHIMvcduL2oSoo4kkTFa1DIxKvc9XJZwckA4RzAFpxedXPO3oQDuIXQRbI= =CKlv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 1 16:57:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F05B1B3EF1 for ; Sun, 1 Nov 2015 16:57:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 dJg9ZeQPEUTD for ; Sun, 1 Nov 2015 16:57:01 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 93B2F1B3EA1 for ; Sun, 1 Nov 2015 16:57:00 -0800 (PST) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 29D802EDF1ED8; Mon, 2 Nov 2015 00:56:53 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id tA20us1s003753 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Nov 2015 00:56:54 GMT Received: from [135.224.22.4] (135.5.27.18) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 1 Nov 2015 19:56:47 -0500 To: John Strassner , "Joel M. Halpern" References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5636A67B.5000901@joelhalpern.com> From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France Message-ID: <5636B4B8.1020104@alcatel-lucent.com> Date: Mon, 2 Nov 2015 01:56:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000803020701060203010602" X-Originating-IP: [135.5.27.18] Archived-At: Cc: Michael Richardson , "Toerless Eckert \(eckert\)" , "reddy.pallavali@ulusofona.pt" , "Michael Behringer \(mbehring\)" , Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 00:57:06 -0000 --------------000803020701060203010602 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Dear all, I also agree that the infrastructure is an essential building block to enable autonomic networking. To assess the "quality" of such an infrastructure, we would need to analyze how well this infrastructure covers the needs and specificities of autonomic functions. Jumping on one point mentioned by John on capabilities and requirements: in draft-peloso-anima-autonomic-function-00, we use similar capabilities/requirements approach to see how to provide value to the operator when deploying autonomic functions. This is a first version, and we welcome your feedback/collaboration to progress on the topic. Best regards, Laurent. On 02/11/2015 01:41, John Strassner wrote: > Hi Michael and Joel, > > I completely agree that we need a solid autonomic infrastructure. > Without a solid foundation, we don't have anything to build upon. > > My point is that AFTER we have such a foundation, we need to > turn our focus northwards (towards the app developers and > customers), instead of staying down in the weeds. > > So, as Joel opined, once we have that foundation, let's (for once) > look at how to enable the business to use these functions. For > example, in FOCALE, we used the concept of capabilities and > requirements to self-organize NEs in different ANIs to > "communities" that could support similar autonomic functions. > This provided several benefits, both at the infrastructure as well > as at higher layers. > > regards, > John > > On Sun, Nov 1, 2015 at 3:55 PM, Joel M. Halpern > wrote: > > If I understand you, I agree that a strong ACP layer is valuable > for the work we want to do. > > But if we do not provide some (significant) interoperable value on > top of that, I don't see folks implementing it. > > Yours, > Joel > > On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote: > > John, in my opinion, if we get to the point of a solid autonomic > infrastructure with the right base services, such as discovery, > messaging, built on a self-managing ACP, developpers will have > all the > tools to write the functions that you want. > > The AN infrastructure is the new IP: like IP enabled folks to > write > networking applications really easily, the ANI allows to write > self-management functions really easily. > > If we get ANI right, we enable a whole new eco-system of network > programming. > > Michael > > *From:*Anima [mailto:anima-bounces@ietf.org > ] *On Behalf Of *John Strassner > *Sent:* 01 November 2015 21:44 > *To:* Toerless Eckert (eckert) >; John Strassner > > > *Cc:* Michael Richardson >; Joel M. Halpern > >; > reddy.pallavali@ulusofona.pt > ; Anima WG > > > *Subject:* Re: [Anima] [ANIMA] Self-Managed Networks > > Hi Toerless, > > Before anima, every distributed function we designed in > the IETF > used its own reinvented communication paradigm. The only > common > mechanism was use of IP packets, but not even that was the > lowest > > > common denominator (IS-IS anybody). > > > At the risk of rocking the boat, I'm less interested in using > autonomics > > for "plumbing" issues, such as healing broken routes, as I am in > > correcting user- and business-oriented functions and services. > > We are engineers. We have a natural affinity for playing with > bright, > > shiny knobs that provide new technologies with which to design. > > However, this rarely directly pays the bills. The business person > > typically does not care what technologies and features are > used, as > > long as his or her service works. If it exceeds an SLA, then its > > scotch time as well. > > But there is no "gold service enable" CLI command that I've > ever seen. > > This is why many of the autonomic projects have tried to reach > above > > forwarding and routing and try and translate business concepts to > > drive network services and resources that the business needs. > > We've failed, rather spectacularly, so far. After 500+ > conferences on > > Future Internet, Next Generation Networking, yada-yada-yada, we > > still do not have a replacement for SNMP. > > NFV was stillborn - it has the management capabilities of a > walnut. > > SDN is a bit more like an apple (tastier and prettier, but > still no > > management). > > I know the IETF loves to work bottom-up. But perhaps we need to > > have a top-down approach as well to fix this. Otherwise, the > network > > that never fails but still doesn't provide business value is > just another > > cool journal paper. > > regards, > > John > > On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert > > >> wrote: > > The way i see it: > > Before anima, every distributed function we designed in > the IETF > used its own reinvented communication paradigm. The only > common > mechanism was use of IP packets, but not even that was the > lowest common > denominator (IS-IS anybody). > > So the question really is what are the pragmatic common > communication > mechanisms we can come up with to make future distributed > functions > easier to implement, deploy and operate. With focus on > "deploy" because > thats what we want to be autonomic. And start with what > our own "anima" > distributed functions realized via "agents" need. > > We know p2p with common presentation layer and set of session > transaction > types, and some limited discovery, eg: mp2mp transactions. > > The discussion now is what's logically next. Once we have > an idea, then > we can figure whether it makes sense to call/put-into > GRASP and/or > if/how > to deal with it in ANIMA. > > > On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner > wrote: > > Hi all, > > > > Sorry, I'm a bit confused. > > > > To me, this thread is starting to discuss generic > messaging system > > capabilities (e.g., at the minimum, a message broker, at > the other > > end of the scale, a full-blown ESB). I didn't think that > the purpose > > of the ACP included such capabilities. > > > > In other words, there is a huge difference between GRASP > > generating a notification and GRASP functioning as a full > > messaging system, complete with message transformation and > > routing, queuing, etc. > > > > I was assuming the former, not the latter. > > > > Please correct me if I am wrong. > > > > (Note that FOCALE used an ESB for inter-agent > communication.) > > > > regards, > > John > > > > > > > > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter < > >brian.e.carpenter@gmail.com > > >> wrote: > > > > > On 20/10/2015 08:04, Joel M. Halpern wrote: > > > > There are at least two different factors to consider > in terms of what > > > events are communicated to the operator. > > > > > > > > First, for initial deployment of autonomic > technologies, operators will > > > want ways to observe all the events so they can gain > > > > confidence in the technology. (We received these > requests with existing > > > self-organizing network technologies.) > > > > > > > > Secondly, different operators have different degrees > of information > > > harvesting and display relative to the state of the > > > > network. Even if the network is taking care of > itself perfectly, some > > > operators will want visibility to any internal state > > > > change. These operators currently monitor their > routing protocol state > > > for similar effects. > > > > > > What I get from this is a requirement that all ASAs > are capable of > > > notifying events, > > > but whether and how those events are reported live to > operators is a > > > separate issue. > > > > > > (However, I have never forgotten that at Three Mile > Island, the system was > > > so busy > > > reporting minor alarms that it took hours before the > underlying alarm > > > message > > > saying what was really wrong got printed. TMI, indeed.) > > > > > > Brian > > > > > > > > > > > Yours, > > > > Joel > > > > > > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote: > > > >> Michael, > > > >> > > > >> Yes, for every small issue there is no need to > contact operator except, > > > >> if it is a complex one. > > > >> Even for self-healing we can use Swarm Intelligence > or Artificial > > > >> Intelligence techniques, but for learning may take > some time. However, > > > >> these are scalable techniques. > > > >> Here, also there is a need of consensus, if the > system is fully > > > >> distributed and asynchronous need to know which > object is crashed, how > > > >> to schedule the loads and coverage issues as well. > > > >> > > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson > > > >> > > > > >>> wrote: > > > >> > > > >> > > > >> John Strassner > > > >>> > > > wrote: > > > >> > When an autonomic system self-heals, why > would the operator > > > >> need to > > > >> > know? This is comparable to routing > doing its job and > > > >> changing the > > > >> > path. There is no reason that the > operator has to be alerted > > > >> on every > > > >> > change in the system - there are already > WAY TOO MANY of > > > >> these for the > > > >> > operator to handle. > > > >> > > > >> Yes, but just the same, the healing activity > needs to be an audited > > > >> event. > > > >> The ACP should be involved in capturing these > events. > > > >> > > > >> Sometimes things don't heal perfectly; often > moving traffic from > > > >> one system to another causes a load spike, and > while things > > > continue to > > > >> function, the performance is different. > > > >> > > > >> -- > > > >> Michael Richardson > > > > > >> > >>>, > Sandelman Software Works > > > >> -= IPv6 IoT consulting =- > > > >> > > > >> > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >>Anima@ietf.org > > > > >> > > > >>https://www.ietf.org/mailman/listinfo/anima > > > >> > > > >> > > > >> > > > >> > > > >> -- > > > >> Thank you very much for your time and consideration. > > > >> > > > >> > > > >> Yours sincerely, > > > >> > > > >> P Radha Krishna Reddy, M.Sc, M.Tech, > > > >> > > > >> Junior Researcher/Ph.D Student, > > > >> > > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal. > > > >> > > > >> Author of: Security Issues of Cloud Computing over > General & IT Sector > > > >> Mobile:+351923095671 > > > > >>www.prkreddy.webs.com > > > > >>http://pt.linkedin.com/in/reddypallavali/ > > > >> > > > >> > > > >> _______________________________________________ > > > >> Anima mailing list > > > >>Anima@ietf.org > > > > > >>https://www.ietf.org/mailman/listinfo/anima > > > >> > > > > > > > > _______________________________________________ > > > > Anima mailing list > > > >Anima@ietf.org > > > > > >https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > _______________________________________________ > > > Anima mailing list > > >Anima@ietf.org > > > > >https://www.ietf.org/mailman/listinfo/anima > > > > > > > > > > > -- > > regards, > > John > > > _______________________________________________ > > Anima mailing list > >Anima@ietf.org > > > >https://www.ietf.org/mailman/listinfo/anima > > > -- > --- > Toerless Eckert, eckert@cisco.com > > > > > > > -- > > regards, > > John > > > > > -- > regards, > John > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------000803020701060203010602 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Dear all,

I also agree that the infrastructure is an essential building block to enable autonomic networking.
To assess the "quality" of such an infrastructure, we would need to analyze how well this infrastructure covers the needs and specificities of autonomic functions.

Jumping on one point mentioned by John on capabilities and requirements: in draft-peloso-anima-autonomic-function-00, we use similar capabilities/requirements approach to see how to provide value to the operator when deploying autonomic functions. This is a first version, and we welcome your feedback/collaboration to progress on the topic.

Best regards, Laurent.

On 02/11/2015 01:41, John Strassner wrote:
Hi Michael and Joel,

I completely agree that we need a solid autonomic infrastructure.
Without a solid foundation, we don't have anything to build upon.

My point is that AFTER we have such a foundation, we need to
turn our focus northwards (towards the app developers and
customers), instead of staying down in the weeds.

So, as Joel opined, once we have that foundation, let's (for once)
look at how to enable the business to use these functions. For
example, in FOCALE, we used the concept of capabilities and
requirements to self-organize NEs in different ANIs to
"communities" that could support similar autonomic functions.
This provided several benefits, both at the infrastructure as well
as at higher layers.

regards,
John

On Sun, Nov 1, 2015 at 3:55 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
If I understand you, I agree that a strong ACP layer is valuable for the work we want to do.

But if we do not provide some (significant) interoperable value on top of that, I don't see folks implementing it.

Yours,
Joel

On 11/1/15 4:15 PM, Michael Behringer (mbehring) wrote:
John, in my opinion, if we get to the point of a solid autonomic
infrastructure with the right base services, such as discovery,
messaging, built on a self-managing ACP, developpers will have all the
tools to write the functions that you want.

The AN infrastructure is the new IP: like IP enabled folks to write
networking applications really easily, the ANI allows to write
self-management functions really easily.

If we get ANI right, we enable a whole new eco-system of network
programming.

Michael

*From:*Anima [mailto:anima-bounces@ietf.org] *On Behalf Of *John Strassner
*Sent:* 01 November 2015 21:44
*To:* Toerless Eckert (eckert) <eckert@cisco.com>; John Strassner
<strazpdj@gmail.com>
*Cc:* Michael Richardson <mcr+ietf@sandelman.ca>; Joel M. Halpern
<jmh@joelhalpern.com>; reddy.pallavali@ulusofona.pt; Anima WG
<anima@ietf.org>
*Subject:* Re: [Anima] [ANIMA] Self-Managed Networks

Hi Toerless,

Before anima, every distributed function we designed in the IETF
used its own reinvented communication paradigm. The only common
mechanism was use of IP packets, but not even that was the lowest

common denominator (IS-IS anybody).

At the risk of rocking the boat, I'm less interested in using autonomics

for "plumbing" issues, such as healing broken routes, as I am in

correcting user- and business-oriented functions and services.

We are engineers. We have a natural affinity for playing with bright,

shiny knobs that provide new technologies with which to design.

However, this rarely directly pays the bills. The business person

typically does not care what technologies and features are used, as

long as his or her service works. If it exceeds an SLA, then its

scotch time as well.

But there is no "gold service enable" CLI command that I've ever seen.

This is why many of the autonomic projects have tried to reach above

forwarding and routing and try and translate business concepts to

drive network services and resources that the business needs.

We've failed, rather spectacularly, so far. After 500+ conferences on

Future Internet, Next Generation Networking, yada-yada-yada, we

still do not have a replacement for SNMP.

NFV was stillborn - it has the management capabilities of a walnut.

SDN is a bit more like an apple (tastier and prettier, but still no

management).

I know the IETF loves to work bottom-up. But perhaps we need to

have a top-down approach as well to fix this. Otherwise, the network

that never fails but still doesn't provide business value is just another

cool journal paper.

regards,

John

On Tue, Oct 20, 2015 at 9:17 AM, Toerless Eckert <eckert@cisco.com
<mailto:eckert@cisco.com>> wrote:

    The way i see it:

    Before anima, every distributed function we designed in the IETF
    used its own reinvented communication paradigm. The only common
    mechanism was use of IP packets, but not even that was the lowest common
    denominator (IS-IS anybody).

    So the question really is what are the pragmatic common communication
    mechanisms we can come up with to make future distributed functions
    easier to implement, deploy and operate. With focus on "deploy" because
    thats what we want to be autonomic. And start with what our own "anima"
    distributed functions realized via "agents" need.

    We know p2p with common presentation layer and set of session
    transaction
    types, and some limited discovery, eg: mp2mp transactions.

    The discussion now is what's logically next. Once we have an idea, then
    we can figure whether it makes sense to call/put-into GRASP and/or
    if/how
    to deal with it in ANIMA.


    On Tue, Oct 20, 2015 at 08:48:05AM -0700, John Strassner wrote:
    > Hi all,
    >
    > Sorry, I'm a bit confused.
    >
    > To me, this thread is starting to discuss generic messaging system
    > capabilities (e.g., at the minimum, a message broker, at the other
    > end of the scale, a full-blown ESB). I didn't think that the purpose
    > of the ACP included such capabilities.
    >
    > In other words, there is a huge difference between GRASP
    > generating a notification and GRASP functioning as a full
    > messaging system, complete with message transformation and
    > routing, queuing, etc.
    >
    > I was assuming the former, not the latter.
    >
    > Please correct me if I am wrong.
    >
    > (Note that FOCALE used an ESB for inter-agent communication.)
    >
    > regards,
    > John
    >
    >
    >
    > On Mon, Oct 19, 2015 at 12:35 PM, Brian E Carpenter <
    >brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
    >
    > > On 20/10/2015 08:04, Joel M. Halpern wrote:
    > > > There are at least two different factors to consider in terms of what
    > > events are communicated to the operator.
    > > >
    > > > First, for initial deployment of autonomic technologies, operators will
    > > want ways to observe all the events so they can gain
    > > > confidence in the technology.  (We received these requests with existing
    > > self-organizing network technologies.)
    > > >
    > > > Secondly, different operators have different degrees of information
    > > harvesting and display relative to the state of the
    > > > network.  Even if the network is taking care of itself perfectly, some
    > > operators will want visibility to any internal state
    > > > change.  These operators currently monitor their routing protocol state
    > > for similar effects.
    > >
    > > What I get from this is a requirement that all ASAs are capable of
    > > notifying events,
    > > but whether and how those events are reported live to operators is a
    > > separate issue.
    > >
    > > (However, I have never forgotten that at Three Mile Island, the system was
    > > so busy
    > > reporting minor alarms that it took hours before the underlying alarm
    > > message
    > > saying what was really wrong got printed. TMI, indeed.)
    > >
    > >    Brian
    > >
    > > >
    > > > Yours,
    > > > Joel
    > > >
    > > > On 10/19/15 2:58 PM, Reddy Pallavali wrote:
    > > >> Michael,
    > > >>
    > > >> Yes, for every small issue there is no need to contact operator except,
    > > >> if it is a complex one.
    > > >> Even for self-healing we can use Swarm Intelligence or Artificial
    > > >> Intelligence techniques, but for learning may take some time. However,
    > > >> these are scalable techniques.
    > > >> Here, also there is a need of consensus, if the system is fully
    > > >> distributed and asynchronous need to know which object is crashed, how
    > > >> to schedule the loads and coverage issues as well.
    > > >>
    > > >> On Mon, Oct 19, 2015 at 6:39 PM, Michael Richardson
    > > >> <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>
    <mailto:mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca>>> wrote:
    > > >>
    > > >>
    > > >>     John Strassner <strazpdj@gmail.com <mailto:strazpdj@gmail.com>
    <mailto:strazpdj@gmail.com <mailto:strazpdj@gmail.com>>>
    > > wrote:
    > > >>          > When an autonomic system self-heals, why would the operator
    > > >>     need to
    > > >>          > know? This is comparable to routing doing its job and
    > > >>     changing the
    > > >>          > path. There is no reason that the operator has to be alerted
    > > >>     on every
    > > >>          > change in the system - there are already WAY TOO MANY of
    > > >>     these for the
    > > >>          > operator to handle.
    > > >>
    > > >>     Yes, but just the same, the healing activity needs to be an audited
    > > >>     event.
    > > >>     The ACP should be involved in capturing these events.
    > > >>
    > > >>     Sometimes things don't heal perfectly; often moving traffic from
    > > >>     one system to another causes a load spike, and while things
    > > continue to
    > > >>     function, the performance is different.
    > > >>
    > > >>     --
    > > >>     Michael Richardson <mcr+IETF@sandelman.ca <mailto:mcr%2BIETF@sandelman.ca>
    > > >>     <mailto:mcr%2BIETF@sandelman.ca <mailto:mcr%252BIETF@sandelman.ca>>>,
    Sandelman Software Works
    > > >>       -= IPv6 IoT consulting =-
    > > >>
    > > >>
    > > >>
    > > >>
    > > >>     _______________________________________________
    > > >>     Anima mailing list
    > > >>Anima@ietf.org <mailto:Anima@ietf.org> <mailto:Anima@ietf.org
    <mailto:Anima@ietf.org>>
    > > >>https://www.ietf.org/mailman/listinfo/anima
    > > >>
    > > >>
    > > >>
    > > >>
    > > >> --
    > > >> Thank you very much for your time and consideration.
    > > >>
    > > >>
    > > >> Yours sincerely,
    > > >>
    > > >> P Radha Krishna Reddy, M.Sc, M.Tech,
    > > >>
    > > >> Junior Researcher/Ph.D Student,
    > > >>
    > > >> COPE LABS, Universidade Lusofona, Lisboa - Portugal.
    > > >>
    > > >> Author of: Security Issues of Cloud Computing over General & IT Sector
    > > >> Mobile:+351923095671 <tel:%2B351923095671>
    > > >>www.prkreddy.webs.com <http://www.prkreddy.webs.com>
    > > >>http://pt.linkedin.com/in/reddypallavali/
    > > >>
    > > >>
    > > >> _______________________________________________
    > > >> Anima mailing list
    > > >>Anima@ietf.org <mailto:Anima@ietf.org>
    > > >>https://www.ietf.org/mailman/listinfo/anima
    > > >>
    > > >
    > > > _______________________________________________
    > > > Anima mailing list
    > > >Anima@ietf.org <mailto:Anima@ietf.org>
    > > >https://www.ietf.org/mailman/listinfo/anima
    > > >
    > >
    > > _______________________________________________
    > > Anima mailing list
    > >Anima@ietf.org <mailto:Anima@ietf.org>
    > >https://www.ietf.org/mailman/listinfo/anima
    > >
    >
    >
    >
    > --
    > regards,
    > John

    > _______________________________________________
    > Anima mailing list
    >Anima@ietf.org <mailto:Anima@ietf.org>
    >https://www.ietf.org/mailman/listinfo/anima


    --
    ---
    Toerless Eckert, eckert@cisco.com <mailto:eckert@cisco.com>




--

regards,

John




--
regards,
John


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

--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------000803020701060203010602-- From nobody Sun Nov 1 17:19:02 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C401B3F76 for ; Sun, 1 Nov 2015 17:19:00 -0800 (PST) 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 HlMfHhF0vccH for ; Sun, 1 Nov 2015 17:18:58 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0: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 1D8C91B3F73 for ; Sun, 1 Nov 2015 17:18:58 -0800 (PST) Received: by vkex70 with SMTP id x70so76317015vke.3 for ; Sun, 01 Nov 2015 17:18:57 -0800 (PST) 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=W6AL+CO16ATBhLp2lfCSxh70phkJzEVhwYBSa87sJkE=; b=lptdFuQHZD5j9XKK+wNhv0FgCSi16Ui4xDCu4yIRHibp7QHX3ZFn5nW19zNf76D1if FZGB40ATc4kbjUyhvHMApGuT3xB/2NGhirQlmPntmdbbYS1vBvbj5ZWJc6OQWppwT5dM B28rQzCFxjsRINaelWHTJu/nFkSZZhT5DH89FPhFCs17mK7xwI+w0pqNQ2mpgKNJA9N/ +rObuU+9OSH5nhnOs8gi0NqGlmQRIrVYsau2dRCd9Mmzwg+LDlegqUgNsenUZdZ9ZNua SEoYBtKsU09szO+MVi7BJm9XAOF4pbLkt1dBLueSg/w3qQxgP52i2ue0JbdWK2vUIvOe akfA== MIME-Version: 1.0 X-Received: by 10.31.54.206 with SMTP id d197mr13186235vka.108.1446427137309; Sun, 01 Nov 2015 17:18:57 -0800 (PST) Received: by 10.103.40.132 with HTTP; Sun, 1 Nov 2015 17:18:56 -0800 (PST) In-Reply-To: <13027.1446425784@dooku.sandelman.ca> References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <13027.1446425784@dooku.sandelman.ca> Date: Sun, 1 Nov 2015 17:18:56 -0800 Message-ID: From: John Strassner To: Michael Richardson , John Strassner Content-Type: multipart/alternative; boundary=001a114380ecb6841c0523848fcf Archived-At: Cc: Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:19:00 -0000 --001a114380ecb6841c0523848fcf Content-Type: text/plain; charset=UTF-8 Hi Michael, agreed. In my last note, my example of building "communities" of NEs that shared the ability to provide autonomic functions to other (authenticated and authorized) NEs, as well as similar "communities" of NEs that requested the use of such capabilities, is (I hope!) one simple example of the business value of the plumbing. More specifically, this enabled the different autonomic networks to self-organize according to changes in context. Building that capability was in reality a compromise between the bottom-up capabilities of the autonomic network elements and the top-down needs of what was currently important, and how those needs affected the services currently provided. regards, John On Sun, Nov 1, 2015 at 4:56 PM, Michael Richardson wrote: > > John Strassner wrote: > > Hi Toerless, > > >> Before anima, every distributed function we designed in the IETF > used > >> its own reinvented communication paradigm. The only common mechanism > >> was use of IP packets, but not even that was the lowest common > >> denominator (IS-IS anybody). > > > At the risk of rocking the boat, I'm less interested in using > > autonomics for "plumbing" issues, such as healing broken routes, as I > > am in correcting user- and business-oriented functions and services. > > > We are engineers. We have a natural affinity for playing with bright, > > shiny knobs that provide new technologies with which to design. > > However, this rarely directly pays the bills. The business person > > typically does not care what technologies and features are used, as > > long as his or her service works. If it exceeds an SLA, then its > scotch > > time as well. > > okay, so I hear your point, and I generally tend to agree. > But, I want to argue for the business value of the plumbing. > > I've built a few small ISPs, and worked with entities like root-name server > deployments. In each case it was very very difficult to do the > justification > for the needed out-of-band access (telco's called it "craft terminal") that > is needed during initial deployment and disaster recovery. > > Serial console servers are ridiculously expensive for what they do, and > when > you need only one or two ports in a shared cabinet, but you have 40 to 70 > of > these spread around the world... (as anycase root server operators have), > it's a real financial pain. > > The ACP as plumbing of last resort really deals with this problem. > > The fact that it can also be substrate for something new is good. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > > -- regards, John --001a114380ecb6841c0523848fcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael,

agreed. In my la= st note, my example of building "communities" of NEs that shared = the ability to provide autonomic functions to other (authenticated and auth= orized) NEs, as well as similar "communities" of NEs that request= ed the use of such capabilities, is (I hope!) one simple example of the bus= iness value of the plumbing. More specifically, this enabled the different = autonomic networks to self-organize according to changes in context.
<= div>
Building that capability was in reality a compromise bet= ween the bottom-up capabilities of the autonomic network elements and the t= op-down needs of what was currently important, and how those needs affected= the services currently provided.

regards,
John

On Sun, Nov 1, 2015 at 4:56 PM, Michael Richardson <= mcr+ietf@sandelm= an.ca> wrote:

John Strassner <strazpdj@gmail.com= > wrote:
=C2=A0 =C2=A0 > Hi Toerless,

=C2=A0 =C2=A0 >> Before anima, every distributed function we designed= in the IETF used
=C2=A0 =C2=A0 >> its own reinvented communication paradigm. The only = common mechanism
=C2=A0 =C2=A0 >> was use of IP packets, but not even that was the low= est =C2=A0common
=C2=A0 =C2=A0 >> denominator (IS-IS anybody).

=C2=A0 =C2=A0 > At the risk of rocking the boat, I'm less interested= in using
=C2=A0 =C2=A0 > autonomics for "plumbing" issues, such as heal= ing broken routes, as I
=C2=A0 =C2=A0 > am in correcting user- and business-oriented functions a= nd services.

=C2=A0 =C2=A0 > We are engineers. We have a natural affinity for playing= with bright,
=C2=A0 =C2=A0 > shiny knobs that provide new technologies with which to = design.
=C2=A0 =C2=A0 > However, this rarely directly pays the bills. The busine= ss person
=C2=A0 =C2=A0 > typically does not care what technologies and features a= re used, as
=C2=A0 =C2=A0 > long as his or her service works. If it exceeds an SLA, = then its scotch
=C2=A0 =C2=A0 > time as well.

okay, so I hear your point, and I generally tend to agree.
But, I want to argue for the business value of the plumbing.

I've built a few small ISPs, and worked with entities like root-name se= rver
deployments.=C2=A0 In each case it was very very difficult to do the justif= ication
for the needed out-of-band access (telco's called it "craft termin= al") that
is needed during initial deployment and disaster recovery.

Serial console servers are ridiculously expensive for what they do, and whe= n
you need only one or two ports in a shared cabinet, but you have 40 to 70 o= f
these spread around the world... (as anycase root server operators have), it's a real financial pain.

The ACP as plumbing of last resort really deals with this problem.

The fact that it can also be substrate for something new is good.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




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




--
regards,
John
--001a114380ecb6841c0523848fcf-- From nobody Sun Nov 1 17:21:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A41B3F82 for ; Sun, 1 Nov 2015 17:21:22 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 CO4qwEbqrOd3 for ; Sun, 1 Nov 2015 17:21:19 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (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 390691B3F98 for ; Sun, 1 Nov 2015 17:21:19 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 1C7A6F24E78F; Mon, 2 Nov 2015 01:21:15 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id tA21LEfo027581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Nov 2015 01:21:14 GMT Received: from [135.224.22.4] (135.5.27.18) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 1 Nov 2015 20:21:11 -0500 To: "Joel M. Halpern" , Michael Richardson References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5626755C.7020306@joelhalpern.com> <24811.1446214368@sandelman.ca> <5635FE96.5080608@joelhalpern.com> From: Laurent Ciavaglia Organization: Alcatel-Lucent Bell Labs France Message-ID: <5636BA7D.6010005@alcatel-lucent.com> Date: Mon, 2 Nov 2015 02:21:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5635FE96.5080608@joelhalpern.com> Content-Type: multipart/alternative; boundary="------------090201050609080305050801" X-Originating-IP: [135.5.27.18] Archived-At: Cc: Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:21:22 -0000 --------------090201050609080305050801 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Joel, all, I fully agree on the need for "good distribution design in GRASP" (or other mechanism). Access to and use of information play a vital role in autonomic networks, thus it is key to identify the different needs and then to conceive the right mechanisms. The issue I see for the moment is that there are different set of requirements (wrt. information exchange), so the question is whether a single mechanism (currently GRASP) is suitable to cover the requirements or if more than one mechanism is a better option. Just to illustrate the above, some of the "information" to need to be exchanged/accessed are (not exclusive): intent/policy, manifest/mandate/meta-data, sensed/monitored data/measurements, learned information/beliefs, alarms/notifications, operations reporting/feedback/call for governance... Entities involved, frequencies and volumes, topologies/peers involved are quite different and poses specific requirements/constraints... Separating the concerns / decomposing into smaller problems/areas is okay, however when need a comprehensive view/framework otherwise we expose to (major) gaps and inconsistencies... What would be a good way forward? Best regards, Laurent. On 01/11/2015 12:59, Joel M. Halpern wrote: > No, BGP was not a typo. I wish it were. > > For clarity, I was not objecting to ACP. I think we need to be > clearer about the relationship between Bootstrap, GRASP, and ACP. But > that is a relatively minor issue. > > My point was that including a good distribution design in GRASP gives > us a good toolkit. In its absence, people do things like BGP-LS, > using BGP as an information distribution technique. > > Yours, > Joel > > On 10/30/15 10:12 AM, Michael Richardson wrote: >> >> Joel M. Halpern wrote: >> > While i think we should be cautious about attepting to boil >> the ocean, >> > I certainly prefer GRASP plus good distribution design as an >> > information distribution mechanism rather than BGP. >> >> Is "BGP" a typo? Did you mean ACP? >> >> If so, are you suggesting that we shouldn't have an IP-based ACP, but >> should rather run things on top of GRASP? >> >> If GRASP is going to do all these things, such as prioritzation of >> events, >> then wouldn't we be better off to start some place like MMTQ or that >> other >> protocol that starts with D, which I can't recall, sitting here on the >> airplane. (But I'll reply once I look it up) >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Bien cordialement, Best regards, *Laurent Ciavaglia* Secure Cloud Networking Bell Labs | Alcatel Lucent phone: +33 160 402 636 email: laurent.ciavaglia@alcatel-lucent.com linkedin: laurentciavaglia address: Route de Villejust | 91620 Nozay | France --------------090201050609080305050801 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit Joel, all,

I fully agree on the need for "good distribution design in GRASP" (or other mechanism).
Access to and use of information play a vital role in autonomic networks, thus it is key to identify the different needs and then to conceive the right mechanisms.
The issue I see for the moment is that there are different set of requirements (wrt. information exchange), so the question is whether a single mechanism (currently GRASP) is suitable to cover the requirements or if more than one mechanism is a better option.

Just to illustrate the above, some of the "information" to need to be exchanged/accessed are (not exclusive): intent/policy, manifest/mandate/meta-data, sensed/monitored data/measurements, learned information/beliefs, alarms/notifications, operations reporting/feedback/call for governance...

Entities involved, frequencies and volumes, topologies/peers involved are quite different and poses specific requirements/constraints...

Separating the concerns / decomposing into smaller problems/areas is okay, however when need a comprehensive view/framework otherwise we expose to (major) gaps and inconsistencies...

What would be a good way forward?

Best regards, Laurent.


On 01/11/2015 12:59, Joel M. Halpern wrote:
No, BGP was not a typo.  I wish it were.

For clarity, I was not objecting to ACP.  I think we need to be clearer about the relationship between Bootstrap, GRASP, and ACP.  But that is a relatively minor issue.

My point was that including a good distribution design in GRASP gives us a good toolkit.  In its absence, people do things like BGP-LS, using BGP as an information distribution technique.

Yours,
Joel

On 10/30/15 10:12 AM, Michael Richardson wrote:

Joel M. Halpern <jmh@joelhalpern.com> wrote:
     > While i think we should be cautious about attepting to boil the ocean,
     > I certainly prefer GRASP plus good distribution design as an
     > information distribution mechanism rather than BGP.

Is "BGP" a typo? Did you mean ACP?

If so, are you suggesting that we shouldn't have an IP-based ACP, but
should rather run things on top of GRASP?

If GRASP is going to do all these things, such as prioritzation of events,
then wouldn't we be better off to start some place like MMTQ or that other
protocol that starts with D, which I can't recall, sitting here on the
airplane.  (But I'll reply once I look it up)


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


--

Bien cordialement, Best regards,

 

Laurent Ciavaglia

Secure Cloud Networking

Bell Labs | Alcatel Lucent

 

phone: +33 160 402 636

email: laurent.ciavaglia@alcatel-lucent.com

linkedin: laurentciavaglia

address: Route de Villejust | 91620 Nozay | France

--------------090201050609080305050801-- From nobody Sun Nov 1 17:25:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCC81B3F48 for ; Sun, 1 Nov 2015 17:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, 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 6YV3VicgI9w4 for ; Sun, 1 Nov 2015 17:25:25 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E6E1B3FD4 for ; Sun, 1 Nov 2015 17:25:25 -0800 (PST) Received: from sandelman.ca (dhcp-32-243.meeting.ietf94.jp [133.93.32.243]) by relay.sandelman.ca (Postfix) with ESMTPS id 759712208B; Sun, 1 Nov 2015 20:25:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5CE64627E0; Sun, 1 Nov 2015 20:25:22 -0500 (EST) From: Michael Richardson To: "Joel M. Halpern" In-reply-to: <5635FE96.5080608@joelhalpern.com> References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5626755C.7020306@joelhalpern.com> <24811.1446214368@sandelman.ca> <5635FE96.5080608@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Sun, 01 Nov 2015 06:59:18 -0500." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 02 Nov 2015 10:25:22 +0900 Message-ID: <15285.1446427522@dooku.sandelman.ca> Archived-At: Cc: Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 01:25:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joel M. Halpern wrote: > No, BGP was not a typo. I wish it were. okay. > For clarity, I was not objecting to ACP. I think we need to be clear= er > about the relationship between Bootstrap, GRASP, and ACP. But that is > a relatively minor issue. > My point was that including a good distribution design in GRASP gives > us a good toolkit. In its absence, people do things like BGP-LS, usi= ng > BGP as an information distribution technique. Ah, okay. I understand, and very much agree. Being able to reuse GRASP is important, but we should be clear what kinds of things it is good for. Homenet wound up with HNCP rather than overloading a routing protocol (OSPF= ). =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWNruBAAoJEKD0KQ7Gj3P2QIMH/3cSWEa/rOtQSpIElKRqn17E 5cDNktouE/6KP1NesKF6giqn1EoQsS5UN1T93t++g+B/nL+sxHa1wwrSSZqCKXo1 h3FxSz12gkdBB1VAoO6jMRlg1lLV5sjMMlliSRm8HkZ/s3kep+fvYUIAueN1d5Nv sFuyHhnyE2JXyPrQccdsNslEvz65/7bF9Hx5o0AosAhypCd19EiRrEpFYKJ7wK07 frjihPbc6L3TsicvB6VRNsxqUHKyFiIMPs9yO5XQ2HVW5+AlHJgjK5kS9aA+Vu5s FHsnA1Qso9oV4J4/6a439DhochqA3T/3gXaL/XLbl4Uano4B+5IGdCEVcBBDIC4= =H7YO -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 1 18:13:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9221B41FB for ; Sun, 1 Nov 2015 18:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 rJE2VBQhw-Oc for ; Sun, 1 Nov 2015 18:13:33 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 59BA91B41FA for ; Sun, 1 Nov 2015 18:13:33 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 1CE15D1CE4390; Mon, 2 Nov 2015 02:13:30 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tA22DUEB031411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Nov 2015 03:13:30 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.230]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 2 Nov 2015 03:13:31 +0100 From: "PELOSO, PIERRE (PIERRE)" To: Michael Richardson , "Joel M. Halpern" Thread-Topic: [Anima] [ANIMA] Self-Managed Networks Thread-Index: AQHRFQ1mvbu/cyWkCUmqoqcD8kMzSZ6H+aUQ Date: Mon, 2 Nov 2015 02:13:30 +0000 Message-ID: References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5626755C.7020306@joelhalpern.com> <24811.1446214368@sandelman.ca> <5635FE96.5080608@joelhalpern.com> <15285.1446427522@dooku.sandelman.ca> In-Reply-To: <15285.1446427522@dooku.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Anima WG Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 02:13:35 -0000 Hi all, I am also convinced we need to be clear on the roles and duties allotted to= GRASP with regards to the ones allotted to ACP and Bootstrap. This is building a big part of the ANI and certainly not all. As Mikael men= tioned earlier ANI is the toolbox allowing for the easy dev of autonomic di= stributed functions. But the ANI must have on top of that the ability to control these functions= otherwise those may well mess the whole network at the expense of the oper= ator. Hence there is little chance this one would go to an ANIMA solution i= f we do not give minimal guarantees that ANI can control these AF. I'm convinced this implies that these autonomic functions must have duties = back with regards to the ANI, as we've attempted depicting in the draft we'= ve just been submitted, these autonomic functions must comply to:=20 1. advertize what they do (ok with John and Laurent), 2. to be deployable at will/under command (as john mentioned), =20 Which brings back to the roles and duties allotted to the different ANI pro= tocols, which ones should take in charge these exchange. And which entities= of the ANI should be the one offering some control on the autonomic functi= ons? I'm sure the week will provide opportunities to discuss these matters (poss= ibly even round a block of paper/white board that would be great). Regards, Pierre > -----Message d'origine----- > De=A0: Anima [mailto:anima-bounces@ietf.org] De la part de Michael Richar= dson > Envoy=E9=A0: lundi 2 novembre 2015 10:25 > =C0=A0: Joel M. Halpern > Cc=A0: Anima WG > Objet=A0: Re: [Anima] [ANIMA] Self-Managed Networks >=20 >=20 > Joel M. Halpern wrote: > > No, BGP was not a typo. I wish it were. >=20 > okay. >=20 > > For clarity, I was not objecting to ACP. I think we need to be cle= arer > > about the relationship between Bootstrap, GRASP, and ACP. But that= is > > a relatively minor issue. >=20 > > My point was that including a good distribution design in GRASP giv= es > > us a good toolkit. In its absence, people do things like BGP-LS, u= sing > > BGP as an information distribution technique. >=20 > Ah, okay. I understand, and very much agree. > Being able to reuse GRASP is important, but we should be clear what kinds= of > things it is good for. >=20 > Homenet wound up with HNCP rather than overloading a routing protocol (OS= PF). >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D IPv6 > IoT consulting =3D- >=20 >=20 From nobody Sun Nov 1 23:24:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7E71B33C1 for ; Sun, 1 Nov 2015 23:24:51 -0800 (PST) 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 c6tMjp56HRv2 for ; Sun, 1 Nov 2015 23:24:49 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C702C1B33BC for ; Sun, 1 Nov 2015 23:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3646; q=dns/txt; s=iport; t=1446449089; x=1447658689; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=o0o3TBfqRYd9rDxsmg3uybpJRUn6Q6PZnktG5MUrs4g=; b=iuV6rzzwAqUe3S+GIMi24g55NA5hpPFH6lUSObB/+uBf+HnpJIh7THmw HFscbM5mozyvD/3uWrSKXWI3rjJNCAKxDIXF1yO0qfoc+1q3UV34gWP9N KNzDymE1GtE5Zfe7EKxPHVfiAXf65F2+uRRV5B/EZJ9PBycIcwFdExQt8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdAgDkDjdW/5NdJa1egzuBQga/NgENgVqGGQIcgQ04FAEBAQEBAQGBCoQ1AQEBAwEjEUoHBAIBCBEEAQEBAgIjAwICAjAUAQgIAQEEARIIiCAIsEWQWAEBAQEBAQEBAQEBAQEBAQEBAQEBARiBIoVVhH6EdIMHgUUFjRuJKAGNHZxAAR8BAUKEBHKEd4EHAQEB X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="scan'208";a="42990332" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 02 Nov 2015 07:24:49 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tA27OmCl004543 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2015 07:24:49 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 2 Nov 2015 01:24:48 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Mon, 2 Nov 2015 01:24:48 -0600 From: "Michael Behringer (mbehring)" To: Brian E Carpenter , "anima@ietf.org" Thread-Topic: [Anima] Adjacency table Thread-Index: AdEBF0lVI0ejcX5uRqKQPhnB4FLRpQRAktyAAMlF8oA= Date: Mon, 2 Nov 2015 07:24:48 +0000 Message-ID: <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> References: <1245fe092b154549a46b9a4f4b1d0c7a@XCH-RTP-006.cisco.com> <5631813D.2030402@gmail.com> In-Reply-To: <5631813D.2030402@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.231.175] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Adjacency table X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 07:24:51 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBFDQo+IENhcnBlbnRlcg0KPiBT ZW50OiAyOSBPY3RvYmVyIDIwMTUgMTE6MTUNCj4gVG86IGFuaW1hQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbQW5pbWFdIEFkamFjZW5jeSB0YWJsZQ0KPiANCj4gSGkgTWljaGFlbCwNCj4gDQo+ IFNvLCBJJ20gdGhpbmtpbmcgYWJvdXQgaG93IGEgR1JBU1AgaW1wbGVtZW50YXRpb24gbWlnaHQg dXNlIHRoZSBhZGphY2VuY3kNCj4gdGFibGUsIGFuZCBJIGhhdmUgc29tZSBxdWVzdGlvbnMgYW5k IGNvbW1lbnRzLg0KPiANCj4gMS4gV2hhdCBpcyB0aGUgZm9ybWF0IGFuZCBzY29wZSBvZiB0aGUg Tm9kZS1JRD8gSXMgaXQganVzdCBhbiBhcmJpdHJhcnkgdmFsdWUNCj4gdGhhdCBoYXMgbm8gZ2xv YmFsIG1lYW5pbmcsIG9yIGlzIGl0IG1vcmUgdGhhbiB0aGF0Pw0KDQpJdCBpcyB0aGUgaW5idWls dCBoL3cgaWRlbnRpZmllci4gV2UgaGF2ZSBhICJ1bmlxdWUgZGV2aWNlIGlkZW50aWZpZXIiLCB3 aGljaCBpcyBhIGNvbWJpbmF0aW9uIG9mIGRldmljZSB0eXBlIGFuZCBzZXJpYWwgbnVtYmVyLiBO b3cgdGhhdCBJJ20gd3JpdGluZyB0aGF0LCBJIHdvbmRlciB3aGV0aGVyIHdlIGNhbiBhc3N1bWUg dW5pcXVlbmVzcyBhY3Jvc3MgdmVuZG9ycy4uLiANCiANCj4gMi4gSSB3b3VsZCB2ZXJ5IG11Y2gg bGlrZSB0aGUgSW50ZXJmYWNlIElEIHRvIGJlIHRoZSBpbnRlcmZhY2UgaW5kZXggKGEgc21hbGwN Cj4gaW50ZWdlciwgdG8gYmUgZm91bmQgaW4gaXBpNl9pZmluZGV4IGluIHRoZSBBZHZhbmNlZCBT b2NrZXQgQVBJKS4NCj4gVGhlcmUncyBubyBiZW5lZml0IGFuZCBtb3JlIHdvcmsgaW4gaGF2aW5n IGEgbmFtZSB0aGVyZS4NCg0KWWVzLCBvZiBjb3Vyc2UgdGhlIGZpZWxkcyBhcmUgZXhhbXBsZXMu IGkvZiBpbmRleCBzb3VuZHMgb2suIA0KDQo+IDMuIFNpbWlsYXJseSwgSSB3b3VsZCB2ZXJ5IG11 Y2ggbGlrZSB0aGUgSVAgYWRkcmVzc2VzIHRvIGJlIGJpbmFyeS4gQWdhaW4sDQo+IHRoZXJlJ3Mg bm8gYmVuZWZpdCBhbmQgbW9yZSB3b3JrIGluIGhhdmluZyB0aGVtIGh1bWFuLXJlYWRhYmxlLg0K DQpJIHRoaW5rIGFjdHVhbGx5IHRoYXQncyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyAoYXMgaXMg dGhlIGludGVyZmFjZSBpZCksIGFuZCBkb2Vzbid0IG5lZWQgdG8gYmUgc3BlY2lmaWVkIGluIHRo ZSBkb2N1bWVudCwgYXMgbG9uZyBhcyB0aGUgcHJvdG9jb2xzIGRvIHRoZSByaWdodCB0aGluZy4g DQoNCk1pY2hhZWwNCiANCj4gUmVnYXJkcywNCj4gICAgQnJpYW4NCj4gDQo+IE9uIDA4LzEwLzIw MTUgMDQ6NTQsIE1pY2hhZWwgQmVocmluZ2VyIChtYmVocmluZykgd3JvdGU6DQo+ID4gQU5JTUEg V0csDQo+ID4NCj4gPiBJbiB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIEFDUCBkcmFmdCwgSSB3 YXMgdHJ5aW5nIHRvIGJlIGNsZWFyZXIgb24gd2hhdA0KPiB0cmlnZ2VycyBBQ1AgY3JlYXRpb24u IFdoaWxlIHRoaW5raW5nIGFib3V0IHRoaXMgSSBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQN Cj4gcHJhY3RpY2FsbHkgYWxsIG9wZXJhdGlvbnMgaW4gQU5JTUEgdG9kYXkgYXJlIHJlYWxseSBm b2N1c2VkIGFyb3VuZCBhbg0KPiBhZGphY2VuY3kgdGFibGUsIHdoaWNoIEkgbm93IGxpc3QgaW4g c2VjdGlvbiA1LjEgKHByZWNvbmRpdGlvbikuDQo+ID4NCj4gPiBBbHNvIGluIHRoZSBib290c3Ry YXAgZGVzaWduIHRlYW0gY2FsbCBqdXN0IG5vdywgc2FtZSB0aGluZzogV2hhdCB0cmlnZ2VycyBh DQo+IGJvb3RzdHJhcCBhY3Rpb24/IEFuZCBhZ2FpbiwgaXQncyByZWFsbHkgYW5jaG9yZWQgYXJv dW5kIHRoZSBhZGphY2VuY3kgdGFibGUuDQo+ID4NCj4gPiBTaW5jZSB0aGlzIHNlZW1zIGEgcHJl dHR5IGltcG9ydGFudCBjb25jZXB0IChhbHRob3VnaCBxdWl0ZSBzaW1wbGUsIHJlYWxseSksDQo+ IEkgd2FudGVkIHRvIGlsbHVzdHJhdGUgaG93IHRoaXMgYWxsIGZpdHMgdG9nZXRoZXIgaW4gbXkg bWluZDoNCj4gPg0KPiA+IFRoZXJlIGFyZSBwcm9jZXNzZXMgZmVlZGluZyB0aGUgYWRqYWNlbmN5 IHRhYmxlOyB0aGVyZSBhcmUgcHJvY2Vzc2VzDQo+IHRyaWdnZXJlZCBieSBpdC4gRGlzY292ZXJ5 IGZlZWRzIHRoZSB0YWJsZS4gQnV0IHRoZXJlIGFyZSBhbHNvIHBvdGVudGlhbCBvdGhlcg0KPiBp bnB1dCB2ZWN0b3JzLiBEZXBlbmRpbmcgb24gdGhlIHN0YXRlIG9mIHRoZSBkZXZpY2UsIGFuZCB3 aGF0IGl0IHNlZXMgaW4gdGhlDQo+IHRhYmxlLCBkaWZmZXJlbnQgdGhpbmdzIGhhcHBlbi4gQW5k IHRoZXJlIHdlIGdvIGludG8gdGhlIGJvb3RzdHJhcCBkcmFmdCwgdGhlDQo+IEFDUCBkcmFmdCwg b3IgcG90ZW50aWFsbHkgb3RoZXJzLg0KPiA+DQo+ID4gSSBndWVzcyB0aGUgcmVmZXJlbmNlIG1v ZGVsIHNob3VsZCBleHBsYWluIHRoaXMgdGFibGUsIGJlY2F1c2UgaXQNCj4gPiByZWFsbHkgbGlu a3MgYWxsIHRoZSBkb2N1bWVudHMgdG9nZXRoZXIsIGluIGEgd2F5LiB2DQo+ID4NCj4gPiBEb2Vz IHRoaXMgbWFrZSBzZW5zZSB0byBldmVyeW9uZT8gQW55IHRoaW5ncyB0aGF0IGRvbid0IHNlZW0g cmlnaHQ/DQo+IFRob3VnaHRzPw0KPiA+DQo+ID4gTWljaGFlbA0KDQo= From nobody Mon Nov 2 10:58:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9601ACDC6 for ; Mon, 2 Nov 2015 10:57:55 -0800 (PST) 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 rotnYRljnwbq for ; Mon, 2 Nov 2015 10:57:54 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 3441A1ACE27 for ; Mon, 2 Nov 2015 10:57:49 -0800 (PST) Received: by pabfh17 with SMTP id fh17so32276636pab.0 for ; Mon, 02 Nov 2015 10:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=91duMePaTm8+P/uebtU94yGCVXjtPJPT5AREpQmeed8=; b=gPSmgd/o3NAeXC+f7ja7ODKp2/qk7stPijCrazY9woc/L+BHR+PoRuLcBKbIlyMTmD JnIC4dbzs2OhmyUARukpgzPafkOJrwibWXJR4zbHXIuWH9VabjHe7itwofln3+MpkVKB vD8tckzJgRuJrLY8D45a+WCweID0uJozjYLioz/akf8JVYiBGeM+tbQRiZ0qLftvLjo1 btrIuoYoikKxlb4ZoWipUlpG2NN+Ua2kajhLI6ThwWXj6jGsD0Dk65duZBRo1sDhKfxR dCvLdZGM3cfEQzdmoOteCxP+jRSq2Leh7QMXKN3SyVQP3sco7j+vIVpDd4B4R/PH66st DzsA== X-Received: by 10.68.211.132 with SMTP id nc4mr29178754pbc.16.1446490668807; Mon, 02 Nov 2015 10:57:48 -0800 (PST) Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rz9sm25334443pbb.61.2015.11.02.10.57.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 10:57:47 -0800 (PST) To: "Michael Behringer (mbehring)" , "anima@ietf.org" References: <1245fe092b154549a46b9a4f4b1d0c7a@XCH-RTP-006.cisco.com> <5631813D.2030402@gmail.com> <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637B22B.4000701@gmail.com> Date: Tue, 3 Nov 2015 07:57:47 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] Adjacency table X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 18:57:55 -0000 On 02/11/2015 20:24, Michael Behringer (mbehring) wrote: >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Brian E >> Carpenter >> Sent: 29 October 2015 11:15 >> To: anima@ietf.org >> Subject: Re: [Anima] Adjacency table >> >> Hi Michael, >> >> So, I'm thinking about how a GRASP implementation might use the adjacency >> table, and I have some questions and comments. >> >> 1. What is the format and scope of the Node-ID? Is it just an arbitrary value >> that has no global meaning, or is it more than that? > > It is the inbuilt h/w identifier. We have a "unique device identifier", which is a combination of device type and serial number. Now that I'm writing that, I wonder whether we can assume uniqueness across vendors... Probably not, but presumably the security bootstrap can deliver some sort of answer to that? Anyway, if the answer is "unique string" that is what I wanted to know, thanks. > >> 2. I would very much like the Interface ID to be the interface index (a small >> integer, to be found in ipi6_ifindex in the Advanced Socket API). >> There's no benefit and more work in having a name there. > > Yes, of course the fields are examples. i/f index sounds ok. > >> 3. Similarly, I would very much like the IP addresses to be binary. Again, >> there's no benefit and more work in having them human-readable. > > I think actually that's implementation specific (as is the interface id), and doesn't need to be specified in the document, as long as the protocols do the right thing. Well, it needs to be specified in the API for accessing the adjacency table. If we want portability, I think it needs to be specified generally. Brian > > Michael > >> Regards, >> Brian >> >> On 08/10/2015 04:54, Michael Behringer (mbehring) wrote: >>> ANIMA WG, >>> >>> In the latest version of the ACP draft, I was trying to be clearer on what >> triggers ACP creation. While thinking about this I came to the conclusion that >> practically all operations in ANIMA today are really focused around an >> adjacency table, which I now list in section 5.1 (precondition). >>> >>> Also in the bootstrap design team call just now, same thing: What triggers a >> bootstrap action? And again, it's really anchored around the adjacency table. >>> >>> Since this seems a pretty important concept (although quite simple, really), >> I wanted to illustrate how this all fits together in my mind: >>> >>> There are processes feeding the adjacency table; there are processes >> triggered by it. Discovery feeds the table. But there are also potential other >> input vectors. Depending on the state of the device, and what it sees in the >> table, different things happen. And there we go into the bootstrap draft, the >> ACP draft, or potentially others. >>> >>> I guess the reference model should explain this table, because it >>> really links all the documents together, in a way. v >>> >>> Does this make sense to everyone? Any things that don't seem right? >> Thoughts? >>> >>> Michael > From nobody Mon Nov 2 11:16:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC0F1B2AA3 for ; Mon, 2 Nov 2015 11:16:54 -0800 (PST) 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 gytuVNBbWa2H for ; Mon, 2 Nov 2015 11:16:52 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 87C2B1B2AA2 for ; Mon, 2 Nov 2015 11:16:52 -0800 (PST) Received: by pabfh17 with SMTP id fh17so32697538pab.0 for ; Mon, 02 Nov 2015 11:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=yokv3aDX2XG9Wsy96K7Hyft5SnEdod4zpAcv7w2qZA4=; b=pxOFZgwdEnmURgw/malvy9sHTSOUQCFF7po9ouQsTZw1J5SEOmuQWRFrEwCYbKaZz0 M/wVonaGCUfHOai59AH1SsIUcqWmxVM1cLwa/JU1LN9fdnJSTOxGz4dvLVUxU6na0SZF TSTnQC5cLkYc6/m7s3bUFg57tm2cy21YBHuQIzbIvZGsDlUYhSNeGukMqYC48RdGgk3B Ee7J8VOfgyMSL1UaTP7vIT1Biw05ezKiKuJ/HuMWtFBSPoR2CL53PEzaEnlXK+5Zv5vH Eglb4hePCqF2N2xjKS8DAPZH7Fw5Qbxc0j1l12io3q9ALBbMFIF6behOf3CS2qog5kjC hbhQ== X-Received: by 10.68.136.10 with SMTP id pw10mr28698644pbb.89.1446491812210; Mon, 02 Nov 2015 11:16:52 -0800 (PST) Received: from ?IPv6:2406:e007:4394:1:28cc:dc4c:9703:6781? ([2406:e007:4394:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id bz1sm25485273pab.20.2015.11.02.11.16.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 11:16:50 -0800 (PST) To: anima@ietf.org References: <29518.1445276383@sandelman.ca> <56253ECD.9010701@joelhalpern.com> <562545FC.5060905@gmail.com> <20151020161711.GB10666@cisco.com> <5626755C.7020306@joelhalpern.com> <24811.1446214368@sandelman.ca> <5635FE96.5080608@joelhalpern.com> <15285.1446427522@dooku.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5637B6A2.7030904@gmail.com> Date: Tue, 3 Nov 2015 08:16:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] [ANIMA] Self-Managed Networks X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Nov 2015 19:16:54 -0000 On 02/11/2015 15:13, PELOSO, PIERRE (PIERRE) wrote: > Hi all, >=20 > I am also convinced we need to be clear on the roles and duties allotte= d to GRASP with regards to the ones allotted to ACP and Bootstrap. The discussion on the GRASP open issues yesterday was very helpful, I thi= nk. GRASP shouldn't be taking decisions that can only be taken by the ASA, be= cause the ASA "knows" the semantics of a particular use case. GRASP is a carrie= r that supports certain styles of interactions between ASAs. (This doesn't exclude that GRASP can take default decisions if the ASA designer fails to make a choice. A simple example is that GRASP has a default loop count for a negotiation, but of course an ASA can change it.= ) When we discover a style of interaction between ASAs that GRASP doesn't s= upport, we will have two choices: 1) extend GRASP 2) just use the ACP directly > This is building a big part of the ANI and certainly not all. As Mikael= mentioned earlier ANI is the toolbox allowing for the easy dev of autono= mic distributed functions. > But the ANI must have on top of that the ability to control these funct= ions otherwise those may well mess the whole network at the expense of th= e operator. Hence there is little chance this one would go to an ANIMA so= lution if we do not give minimal guarantees that ANI can control these AF= =2E > I'm convinced this implies that these autonomic functions must have dut= ies back with regards to the ANI, as we've attempted depicting in the dra= ft we've just been submitted, these autonomic functions must comply to:=20 > 1. advertize what they do (ok with John and Laurent), > 2. to be deployable at will/under command (as john mentioned), Sure. The features mentioned in draft-peloso-anima-autonomic-function are= important. > Which brings back to the roles and duties allotted to the different ANI= protocols, which ones should take in charge these exchange. And which en= tities of the ANI should be the one offering some control on the autonomi= c functions? > I'm sure the week will provide opportunities to discuss these matters (= possibly even round a block of paper/white board that would be great). A question I have (because of the "imperative" commands) is whether we sh= ould add a generic message feature to GRASP. It would be a carrier for any kin= d of direct message between two GRASP-using entities. The advantage compared t= o raw usage of the ACP would be that a message could refer to a specific object= ive, so that all the GRASP discovery and cache mechanisms would apply. Regards Brian >=20 > Regards, >=20 > Pierre >=20 >> -----Message d'origine----- >> De : Anima [mailto:anima-bounces@ietf.org] De la part de Michael Richa= rdson >> Envoy=C3=A9 : lundi 2 novembre 2015 10:25 >> =C3=80 : Joel M. Halpern >> Cc : Anima WG >> Objet : Re: [Anima] [ANIMA] Self-Managed Networks >> >> >> Joel M. Halpern wrote: >> > No, BGP was not a typo. I wish it were. >> >> okay. >> >> > For clarity, I was not objecting to ACP. I think we need to be = clearer >> > about the relationship between Bootstrap, GRASP, and ACP. But t= hat is >> > a relatively minor issue. >> >> > My point was that including a good distribution design in GRASP = gives >> > us a good toolkit. In its absence, people do things like BGP-LS= , using >> > BGP as an information distribution technique. >> >> Ah, okay. I understand, and very much agree. >> Being able to reuse GRASP is important, but we should be clear what ki= nds of >> things it is good for. >> >> Homenet wound up with HNCP rather than overloading a routing protocol = (OSPF). >> >> -- >> Michael Richardson , Sandelman Software Works = -=3D IPv6 >> IoT consulting =3D- >> >> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Mon Nov 2 20:09:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0116E1B2CE0 for ; Mon, 2 Nov 2015 20:09:22 -0800 (PST) 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 Twg4yHnPTxDp for ; Mon, 2 Nov 2015 20:09:20 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id C194B1B2CC1 for ; Mon, 2 Nov 2015 20:09:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B6EE41E59F6 for ; Mon, 2 Nov 2015 20:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ylri4m5x6955 for ; Mon, 2 Nov 2015 20:08:46 -0800 (PST) Received: from t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp (t20010c400000302418ef1e5e1effddeb.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:18ef:1e5e:1eff:ddeb]) by c8a.amsl.com (Postfix) with ESMTPA id 6E38C1E59F2 for ; Mon, 2 Nov 2015 20:08:46 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Nov 2015 20:09:19 -0800 Message-Id: <3C0C5548-B56C-49E1-B5C5-6C243F532BBF@amsl.com> To: anima@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Mon, 2 Nov 2015 20:09:19 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Anima] Queue for ANIMA Remote Attendees X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 04:09:22 -0000 If you are planning to participate in the ANIMA session here at IETF 94 = today =97 either locally in Yokohama or as a remote participant =97 we = want to make sure that you are aware that the IETF is providing a remote = participants with a fairly new way to ask questions or make comments. In = addition to using the Jabber room, for the ANIMA session there is also = the opportunity for remote participants to enter a virtual queue and ask = questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the ANIMA session =97 a virtual queue and an actual (in-room) queue. = Remote attendees will log into the Meetecho platform and will have a = virtual mic line that they can enter if they have a question or comment. = In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Tue Nov 3 01:50:25 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7881B3150 for ; Tue, 3 Nov 2015 01:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, 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 sh0rHmZ2Zf1G for ; Tue, 3 Nov 2015 01:50:22 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9380D1B30B8 for ; Tue, 3 Nov 2015 01:50:22 -0800 (PST) Received: from sandelman.ca (y125066.ppp.asahi-net.or.jp [118.243.125.66]) by relay.sandelman.ca (Postfix) with ESMTPS id 3B3D92208D; Tue, 3 Nov 2015 04:50:21 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 18C0761E0B; Tue, 3 Nov 2015 18:50:19 +0900 (JST) From: Michael Richardson To: Brian E Carpenter In-reply-to: <5637B22B.4000701@gmail.com> References: <1245fe092b154549a46b9a4f4b1d0c7a@XCH-RTP-006.cisco.com> <5631813D.2030402@gmail.com> <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> <5637B22B.4000701@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Tue, 03 Nov 2015 07:57:47 +1300." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5177.1446544219.1@dooku.sandelman.ca> Content-Transfer-Encoding: quoted-printable Date: Tue, 03 Nov 2015 18:50:19 +0900 Message-ID: <5178.1446544219@dooku.sandelman.ca> Archived-At: Cc: "anima@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Adjacency table X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 09:50:23 -0000 Brian E Carpenter wrote: > > It is the inbuilt h/w identifier. We have a "unique device identifier"= , > > which is a combination of device type and serial number. Now that I'm > > writing that, I wonder whether we can assume uniqueness across vendors= ... = > Probably not, but presumably the security bootstrap can deliver some sor= t > of answer to that? Anyway, if the answer is "unique string" that is what= I > wanted to know, thanks. Yes, the combination of will be uniq= ue before bootstrap. After bootstrap, we will have in a certificate that would be installed in each device. If you are reall= y lazy, you can just use the entire certificate bytes [on the order of 1Kbytes], but technically, a device might have many of those over it's lifetime. The serialNumber is mandated to be unique by pkix/x509. -- = ] Never tell me the odds! | ipv6 mesh networ= ks [ = ] Michael Richardson, Sandelman Software Works | network architec= t [ = ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ = = From nobody Tue Nov 3 13:02:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DA1A03A0 for ; Tue, 3 Nov 2015 13:02:57 -0800 (PST) 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 DpW2l4g4hkR1 for ; Tue, 3 Nov 2015 13:02:55 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCDDA1A036C for ; Tue, 3 Nov 2015 13:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1658; q=dns/txt; s=iport; t=1446584575; x=1447794175; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=clso1oknZrbrd2F+K8My/v1nOpFqncgZSlunb0TtVxQ=; b=GX4H5gJET4enKvN9X+WivxflMS7dQdxnZ36gpx3+21XwHc4/yJ3Y8pJs x49D4fFwO8tzlmA6AgD8wvvSjjEV7GvpkZd0x/pFTCMTCBkq4t/Fho30w kSlXtMBGUOsjwDUPIwn5p6UX9E1VEvEEN13BmjNvkQ4qpr8qoPjaRLyYT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D8AQBbIDlW/5tdJa1UCoM7gUIGvT0BDYFdhhMCgUI4FAEBAQEBAQGBCoQ1AQEBAwE6PwUHBAIBCA4DBAEBAR4JByERFAkIAQEEAQ0FCIgRAwoIvV4NhC4BAQEBAQEBAQEBAQEBAQEBAQEBAQEYhlWEfoJTgV2FCAEElkYBiAyDIYFtlHOHUQEfAQFCgg4CHoFWcgGELIEHAQEB X-IronPort-AV: E=Sophos;i="5.20,240,1444694400"; d="scan'208";a="41743623" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 03 Nov 2015 21:02:46 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA3L2kwX011782 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Nov 2015 21:02:46 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 3 Nov 2015 15:02:46 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Tue, 3 Nov 2015 15:02:46 -0600 From: "Michael Behringer (mbehring)" To: Michael Richardson , Brian E Carpenter Thread-Topic: [Anima] Adjacency table Thread-Index: AdEBF0lVI0ejcX5uRqKQPhnB4FLRpQRAktyAAMlF8oAAJP7EgAAfK9+AAArKUPA= Date: Tue, 3 Nov 2015 21:02:46 +0000 Message-ID: <368b49b722ab4ae5ad4fdfa2f016f73b@XCH-RCD-006.cisco.com> References: <1245fe092b154549a46b9a4f4b1d0c7a@XCH-RTP-006.cisco.com> <5631813D.2030402@gmail.com> <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> <5637B22B.4000701@gmail.com> <5178.1446544219@dooku.sandelman.ca> In-Reply-To: <5178.1446544219@dooku.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.230.206] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] Adjacency table X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Nov 2015 21:02:57 -0000 > -----Original Message----- > From: Michael Richardson [mailto:mcr@sandelman.ca] > Sent: 03 November 2015 18:50 > To: Brian E Carpenter > Cc: Michael Behringer (mbehring) ; anima@ietf.org > Subject: Re: [Anima] Adjacency table >=20 > Brian E Carpenter wrote: > > > It is the inbuilt h/w identifier. We have a "unique device > > > identifier", which is a combination of device type and serial > > > number. Now that I'm writing that, I wonder whether we can assume > uniqueness across vendors... >=20 > > Probably not, but presumably the security bootstrap can deliver some > > sort of answer to that? Anyway, if the answer is "unique string" that > > is what I wanted to know, thanks. >=20 > Yes, the combination of will be > unique before bootstrap. Are you suggesting to use that as a device-ID?=20 Strictly speaking isn't guaranteed to be unique eit= her...=20 =20 > After bootstrap, we will have i= n > a certificate that would be installed in each device. =20 I'd prefer to use the same device ID all the time, before and after bootstr= ap. Why change? It's just a string to identify the device... > If you are really lazy, you > can just use the entire certificate bytes [on the order of 1Kbytes], but > technically, a device might have many of those over it's lifetime. Right.=20 > The serialNumber is mandated to be unique by pkix/x509. Are you saying that the serial numbers in products ARE unique?=20 Michael =20 From nobody Tue Nov 3 22:01:22 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF701ACDF5 for ; Tue, 3 Nov 2015 22:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.41 X-Spam-Level: * X-Spam-Status: No, score=1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_12=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_19=0.6, J_CHICKENPOX_27=0.6, J_CHICKENPOX_29=0.6, 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 xDVBma_QvNXe for ; Tue, 3 Nov 2015 22:01:21 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D5E1ACDF3 for ; Tue, 3 Nov 2015 22:01:20 -0800 (PST) Received: from sandelman.ca (y125066.ppp.asahi-net.or.jp [118.243.125.66]) by relay.sandelman.ca (Postfix) with ESMTPS id 168732208B; Wed, 4 Nov 2015 01:01:19 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 09CBE61E12; Wed, 4 Nov 2015 15:01:17 +0900 (JST) From: Michael Richardson To: "anima\@ietf.org" In-reply-to: <368b49b722ab4ae5ad4fdfa2f016f73b@XCH-RCD-006.cisco.com> References: <1245fe092b154549a46b9a4f4b1d0c7a@XCH-RTP-006.cisco.com> <5631813D.2030402@gmail.com> <4f5ca63f14214eb9b326f9d83f74a8f6@XCH-RCD-006.cisco.com> <5637B22B.4000701@gmail.com> <5178.1446544219@dooku.sandelman.ca> <368b49b722ab4ae5ad4fdfa2f016f73b@XCH-RCD-006.cisco.com> Comments: In-reply-to "Michael Behringer (mbehring)" message dated "Tue, 03 Nov 2015 21:02:46 +0000." X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 04 Nov 2015 15:01:17 +0900 Message-ID: <3967.1446616877@dooku.sandelman.ca> Archived-At: Cc: "Michael Behringer \(mbehring\)" Subject: Re: [Anima] Adjacency table X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 06:01:22 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable First, I confused myself and mis-stated something, but fundamentally what I said was accurate. Let me clarify first: 1) every certificate issued by any CA is supposed to have a unique "Serial Number" attribute. dooku-[~] mcr 10008 %openssl x509 -in /etc/postfix/ssl/dooku.crt -noout -te= xt Certificate: Data: Version: 3 (0x2) Serial Number: 121 (0x79) ... Signature Algorithm: sha1WithRSAEncryption Issuer: C=3DCA, ST=3DOntario, L=3DOttawa, O=3DSandelman Software Wo= rks, OU=3DDebugging Department, CN=3Dsandelman.ca/emailAddress=3Dmcr@sandel= man.ca [yes, I need to remove SHA1 from my SOHO CA] 2) The 802.1AR specification says vendors will use a SubjectAltName to indicate a vendor-specific serial number. 802.1AR is rather silent about the form of that number, but in draft-richardson-6tisch-idevid-cert-01 now draft-richardson-anima-idevid-cert-00 I suggested that it would be an integer like SerialNumber. Michael Behringer (mbehring) wrote: >> > Probably not, but presumably the security bootstrap can deliver so= me >> > sort of answer to that? Anyway, if the answer is "unique string" >> > is what I wanted to know, thanks. >> Yes, the combination of will be >> unique before bootstrap. > Are you suggesting to use that as a device-ID? Strictly speaking of vendor CA-key> isn't guaranteed to be unique either... I never said was unique. I said that the pair was unique by construction (yes, bad things can happen, but that's against the spec). I was vague as to whether this was the SerialNumber in the certificate, of the device-serialnumber in the SubjectAltName. Let me clarify that it's the latter. >> After bootstrap, we will have > domain-specific-serialNumber> in a certificate that would be install= ed >> in each device. > I'd prefer to use the same device ID all the time, before and after > bootstrap. Why change? It's just a string to identify the device... Well, because vendorA can issue SN: 000011 and vendorB can issue SN: 00011, and we can't expect them to coordinate. The enrollment part of the bootstrap process will provide the node with a n= ew (locally significant) certificate, and can provide it with whatever stable deviceID you like. Unless you have a model where unenrolled nodes form prospective ACPs [that idea of mine was withdrawn after discussion], then no nodes communicate with each other in a secure way until after they are enrolled.=20 >> If you are really lazy, you can just use the entire certificate bytes >> [on the order of 1Kbytes], but technically, a device might have many >> of those over it's lifetime. > Right. >> The serialNumber is mandated to be unique by pkix/x509. > Are you saying that the serial numbers in products ARE unique? Yes. The pair is unique from the factory. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 =20 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJWOZ8rAAoJEKD0KQ7Gj3P2eusH/Ayb/rwqPyxIu8+KvWxWDrf/ na4NIVDLc4DGcvtHfKOvsrexnXBVBbNk3cah4lSJpM4ogxY51SbLqsNHcACLY7zs k+RGi+XI6TF06zLm/tYCzHSDJptK1aJthY1gH123TLP9ETwd68+32TqwipJk+va4 nlngn4JxJzvuxTtAbZcTjwoFIGrvACloJ6GfQk0gErMBq/B0okhbMYTlK0C4uhe9 QVPb7fy3DR7hY+g0shrOdJuh753L0Blm/qrZxUCIIABPLiEZxj5xLNpx9Egzr1sQ eAjioz15+2YsfVVz81buaG0ZkmclXdeLhFEGt55bNsop6C9pCkvk+TeF/rXlnao= =xO3b -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 10 00:29:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE761A8842 for ; Tue, 10 Nov 2015 00:29:55 -0800 (PST) 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 SyXoTU6iGbeM for ; Tue, 10 Nov 2015 00:29:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC091A8841 for ; Tue, 10 Nov 2015 00:29:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAD27826; Tue, 10 Nov 2015 08:29:49 +0000 (GMT) Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 10 Nov 2015 08:29:46 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0235.001; Tue, 10 Nov 2015 16:29:39 +0800 From: Sheng Jiang To: Anima WG Thread-Topic: Abstract summary of ANIMA IETF94 Thread-Index: AdEbkfCNqqwkeq9ZSK+58b5wlH8Sww== Date: Tue, 10 Nov 2015 08:29:39 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BBCC275@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5641AAFE.00C8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7d40251c1abafbd618ad68182b949f02 Archived-At: Cc: "anima-chairs@tools.ietf.org" Subject: [Anima] Abstract summary of ANIMA IETF94 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 08:29:55 -0000 SGksIGFsbCwNCg0KV2hpbGUgdGhlIFdHIG1pbnV0ZXMgaXMgc3RpbGwgaW4gdGhlIHdheSwgYW4g YWJzdHJhY3Qgc3VtbWFyeSBvZiBBTklNQSBXRyBtZWV0aW5nIGhhcyBtYWRlIGF2YWlsYWJsZSBh dCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVhL29wcy90cmFjL3dpa2kvSUVURjk0c3Vt bWFyeS4NCg0KSWYgeW91IGhhdmUgYW55IHN1Z2dlc3Rpb25zIGZvciBjaGFuZ2VzLCBsZXQgdXMg a25vdy4gQW5kLCB0aGVyZSBhcmUgb3RoZXIgT1BTJk1hbmFnZW1lbnQgQXJlYSBXRyBzdW1tYXJp ZXMgdGhlcmUgYXMgd2VsbC4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg== From nobody Tue Nov 10 19:05:30 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415F1B47B4 for ; Tue, 10 Nov 2015 19:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AoItWz_1Xww5 for ; Tue, 10 Nov 2015 19:05:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90521B47B0 for ; Tue, 10 Nov 2015 19:05:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AECA200A5 for ; Tue, 10 Nov 2015 22:09:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 9B8AF637F8; Tue, 10 Nov 2015 22:05:26 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 849AF637F3 for ; Tue, 10 Nov 2015 22:05:26 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 03:05:29 -0000 --=-=-= Content-Type: text/plain I spent most of my 11h trip home on Monday catching trying to empty my list of drafts to read... I have a series of comments on the documents which I'll post as seperate threads. I read through: - draft-ietf-anima-grasp-01 - draft-ietf-anima-autonomic-control-plane-01 - draft-behringer-anima-autonomic-addressing-02 - draft-liu-anima-grasp-distribution-00 - draft-ietf-anima-autonomic-control-plane-01 - draft-behringer-anima-reference-model-04 Reading the drafts I get a profound sense of dis-unity... It's about ACP vs GRASP, and how/where we do things. I think we need a virtual interim or something like that where we can talk for a longer period of time in a smaller group. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVkKwcoCLcPvd0N1lAQJElQf+LMd1ODszXJzutflEen7IwUuQG1rp4Kpu B37kbvwy1EtQkTuvcTIxEqpH307yrC6/ch8PqMPIiVcfQ1efS7Y/kn/zlOG7RnM5 DRU+ebtYxx7zwSfK3pAEJgRrapNm9uAIJ5vrTQeUbUlOZdXW9gVwW4Wc/w+zsYat /E2A5xPeYgVRjTda4IS4TkGxWneF2HkXlmO5+jX0vARcGa4U4qLVUcTbfvcofCr0 fsrIFrRm0zVjVS+67y8YVCySBfYrmrrqJ43Sbsrr+te2bdEjIhAji9aCpbw3N1VZ w4H6SwJVWF1Inf4FlCs07CNENjyDTcnkcCGw/rnxXjxzYpiaihjanA== =2FCy -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 10 20:11:05 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA4E1B43DF for ; Tue, 10 Nov 2015 20:11:03 -0800 (PST) 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 cDb21bpf4luh for ; Tue, 10 Nov 2015 20:11:02 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e: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 9FAFE1B42EF for ; Tue, 10 Nov 2015 20:11:02 -0800 (PST) Received: by padhx2 with SMTP id hx2so18817545pad.1 for ; Tue, 10 Nov 2015 20:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=/qWHx0QuhI5djGXOhsknXTPswpttdHleqjrBJF3myH8=; b=bFWjFcrVsAuNyAHj38zYls+DSdWYDDdAIP1Ngs+0zmtBN4hMosJa3aS5yR3Nk4BqSY VY6rpZ4rPEFfE/ukymcgxvO9q2k6rhlk2Bm1zZu1msfC9S4gfj/NoHtoTOXcOvf3tGeh Lps70u5umzmYCIvyoHIDTCbVzFZlU4S33FseOqrnZlmeolywuzer7nPtsstKfEMuYrmR AL0PkmoVmEF8XrqR2jL290kfzHMqsnDD83B0YFNKr5JsXnBL48plDdpdfOFYSH4/5xJF pUtsS19bUXZiMDehC6lq5b1r7xYhjMyGpFnSY1bTBA6OpmNu3Vi4ZaMiiT6bkT0pEg+h iWsg== X-Received: by 10.66.62.202 with SMTP id a10mr11037791pas.131.1447215062178; Tue, 10 Nov 2015 20:11:02 -0800 (PST) Received: from ?IPv6:2406:e007:64af:1:28cc:dc4c:9703:6781? ([2406:e007:64af:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id sx1sm6961296pbc.36.2015.11.10.20.10.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 10 Nov 2015 20:11:00 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <20901.1447211126@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5642BFD0.3000805@gmail.com> Date: Wed, 11 Nov 2015 17:10:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20901.1447211126@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 04:11:04 -0000 On 11/11/2015 16:05, Michael Richardson wrote: > > I spent most of my 11h trip home on Monday catching trying to empty my list > of drafts to read... I have a series of comments on the documents which I'll > post as seperate threads. > > I read through: > - draft-ietf-anima-grasp-01 > - draft-ietf-anima-autonomic-control-plane-01 > - draft-behringer-anima-autonomic-addressing-02 > - draft-liu-anima-grasp-distribution-00 > - draft-ietf-anima-autonomic-control-plane-01 > - draft-behringer-anima-reference-model-04 > > Reading the drafts I get a profound sense of dis-unity... > It's about ACP vs GRASP, and how/where we do things. Can you try to explain where you see a disconnect? Because I don't. The ACP provides a secure private Internet for ANs to use as they wisk, and GRASP runs over the ACP to offer higher level messaging functions to the ANs. Right now all that GRASP seems to need from the ACP is a status bit saying "ACP is up" and a socket API. It might need to peek into the adjacency table, but I'm not even sure about that. True, this chases its own tail a bit if GRASP is used for initial discovery, and that does need to be tied down. > I think we need a virtual interim or something like that where we can talk > for a longer period of time in a smaller group. We certainly need to understand what's not fitting together. Brian From nobody Wed Nov 11 00:37:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2152E1A6F7C for ; Wed, 11 Nov 2015 00:37:54 -0800 (PST) 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 ZRxHtsc9Egjy for ; Wed, 11 Nov 2015 00:37:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD26F1A6F67 for ; Wed, 11 Nov 2015 00:37:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDY25329; Wed, 11 Nov 2015 08:37:49 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 11 Nov 2015 08:37:48 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.203]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Wed, 11 Nov 2015 16:37:40 +0800 From: Sheng Jiang To: Michael Richardson , "anima@ietf.org" Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3b8zeewHBLvkOBHXdLivoFIp6WfcLQ Date: Wed, 11 Nov 2015 08:37:40 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BBCCB38@nkgeml512-mbx.china.huawei.com> References: <20901.1447211126@sandelman.ca> In-Reply-To: <20901.1447211126@sandelman.ca> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.5642FE5D.00B0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1e2a6b20679748fe12b0de1fb2da297 Archived-At: Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 08:37:54 -0000 SGksIE1pY2hhZWwgUiwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbnRyaWJ1dGlvbnMuIFdlIGNhbiBj ZXJ0YWlubHkgYXJyYW5nZSB2aXJ0dWFsIGludGVyaW0gbWVldGluZy4gSG93ZXZlciwgdGhlIGRp ZmZpY3VsdHksIGxldCdzIHNheSBvbmx5IEdSQVNQIGFuZCBBQ1Agb25seSwgaXMgcGVvcGxlIGJl bG9uZyB0byBkaWZmZXJlbnQgdGltZSB6b25lLiBZb3UgYXJlIGluIG5vcnRoZXJuIEFtZXJpY2Fu LiBCcmlhbiBpcyBpbiBOZXcgWmVhbGFuZC4gTWljaGFlbCBCIGlzIGluIEV1cm9wZS4gVGhpcyBo YXMgbm90IG1lbnRpb25lZCB0aGF0IEJpbmcgYW5kIEkgYXJlIGluIENoaW5lc2UgdGltZSB6b25l Lg0KDQpZb3UgY2FuIHN1Z2dlc3QgYSBtZWV0aW5nIHRpbWUuIEJ1dCBJIGd1ZXNzIG1vcmUgZmVh c2libGUgc29sdXRpb24gaXMgdG8gc3BsaXQgdGhlIG1lZXRpbmcgaW50byBldmVuIHNtYWxsZXI6 IHlvdSBjYW4gaGF2ZSBtZWV0aW5nIHdpdGggQnJpYW4sIHRoZW4gaGF2ZSBhbm90aGVyIG9uZSB3 aXRoIE1pY2hhZWwgQi4NCg0KTWVhbndoaWxlLCBkaXNjdXNzaW9uIHRocm91Z2ggZW1haWwgbWF5 IGFsc28gZWZmaWNpZW50LiBBbHRob3VnaCB3ZSBtYXkgaGF2ZSB0eXBlIGEgbG90LCBidXQgd2Ug Y291bGQgY2xlYXIgdXAgb3VyIGlkZWFzIGR1cmluZyB0aGUgdHlwaW5nLg0KDQpSZWdhcmRzLA0K DQpTaGVuZw0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBBbmltYSBbbWFp bHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWNoYWVsDQo+UmljaGFy ZHNvbg0KPlNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTEsIDIwMTUgMTE6MDUgQU0NCj5Ubzog YW5pbWFAaWV0Zi5vcmcNCj5TdWJqZWN0OiBbQW5pbWFdIGNvbW1lbnRzIG9uIGN1cnJlbnQgZHJh ZnRzDQo+DQo+DQo+SSBzcGVudCBtb3N0IG9mIG15IDExaCB0cmlwIGhvbWUgb24gTW9uZGF5IGNh dGNoaW5nIHRyeWluZyB0byBlbXB0eSBteSBsaXN0DQo+b2YgZHJhZnRzIHRvIHJlYWQuLi4gIEkg aGF2ZSBhIHNlcmllcyBvZiBjb21tZW50cyBvbiB0aGUgZG9jdW1lbnRzIHdoaWNoIEknbGwNCj5w b3N0IGFzIHNlcGVyYXRlIHRocmVhZHMuDQo+DQo+SSByZWFkIHRocm91Z2g6DQo+ICAtIGRyYWZ0 LWlldGYtYW5pbWEtZ3Jhc3AtMDENCj4gIC0gZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29u dHJvbC1wbGFuZS0wMQ0KPiAgLSBkcmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJl c3NpbmctMDINCj4gIC0gZHJhZnQtbGl1LWFuaW1hLWdyYXNwLWRpc3RyaWJ1dGlvbi0wMA0KPiAg LSBkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAxDQo+ICAtIGRyYWZ0 LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDQNCj4NCj5SZWFkaW5nIHRoZSBkcmFm dHMgSSBnZXQgYSBwcm9mb3VuZCBzZW5zZSBvZiBkaXMtdW5pdHkuLi4NCj5JdCdzIGFib3V0IEFD UCB2cyBHUkFTUCwgYW5kIGhvdy93aGVyZSB3ZSBkbyB0aGluZ3MuDQo+DQo+SSB0aGluayB3ZSBu ZWVkIGEgdmlydHVhbCBpbnRlcmltIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQgd2hlcmUgd2UgY2Fu IHRhbGsNCj5mb3IgYSBsb25nZXIgcGVyaW9kIG9mIHRpbWUgaW4gYSBzbWFsbGVyIGdyb3VwLg0K Pg0KPi0tDQo+TWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+LCBTYW5k ZWxtYW4gU29mdHdhcmUgV29ya3MNCj4gLT0gSVB2NiBJb1QgY29uc3VsdGluZyA9LQ0KPg0KPg0K DQo= From nobody Wed Nov 11 07:06:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52201AD0CE for ; Wed, 11 Nov 2015 07:06:43 -0800 (PST) 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 N_m1_qbxff2R for ; Wed, 11 Nov 2015 07:06:38 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB5C1AD0D0 for ; Wed, 11 Nov 2015 07:06:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2636; q=dns/txt; s=iport; t=1447254397; x=1448463997; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IEt2fE8wHDFhdxWC/H9JKDNP6aR8uBB+GgE0YiOzzxw=; b=k5r5C1ph9Cb3m7wCsS8pd7y9UCaJ6P0ve2fW6NDs43hif4J5XcyN70VS JCdtG0F7MMIQXfXgzT6od1OSzPdOHTEG6gPFbJ9Roip1b99hTvYpsVmoN 0vdIp+UvfFfJpf9efOi9f7ZINn6eGdG2Crfu8N0Z4nMP48fzkRgWl3mMw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAgB3WENW/51dJa1egztTbwa+GwENg?= =?us-ascii?q?WUXCoVvAhyBKTgUAQEBAQEBAYEKhDQBAQEDAQEBASAROgsFCwIBCBgCAiYCAgI?= =?us-ascii?q?fBgsVEAIEDgWIGQMKCA2zWIt/DYRbAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBA?= =?us-ascii?q?Ydjgm6CU4IegwQvgRUFlkgBizCBdYFbh2WLModSAR8BAUKEBHIBhE6BBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,276,1444694400"; d="scan'208";a="48698869" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 11 Nov 2015 15:06:37 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tABF6a2t004204 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 15:06:37 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 Nov 2015 09:06:36 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 11 Nov 2015 09:06:36 -0600 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WbFNlXfA390qGwfzbG5IpEJ6WmiYAgAC3MIA= Date: Wed, 11 Nov 2015 15:06:36 +0000 Message-ID: <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> In-Reply-To: <5642BFD0.3000805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.14] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 15:06:43 -0000 DQo+IE9uIE5vdiAxMCwgMjAxNSwgYXQgOToxMCBQTSwgQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBPbiAxMS8xMS8yMDE1IDE2OjA1 LCBNaWNoYWVsIFJpY2hhcmRzb24gd3JvdGU6DQo+PiANCj4+IEkgc3BlbnQgbW9zdCBvZiBteSAx MWggdHJpcCBob21lIG9uIE1vbmRheSBjYXRjaGluZyB0cnlpbmcgdG8gZW1wdHkgbXkgbGlzdA0K Pj4gb2YgZHJhZnRzIHRvIHJlYWQuLi4gIEkgaGF2ZSBhIHNlcmllcyBvZiBjb21tZW50cyBvbiB0 aGUgZG9jdW1lbnRzIHdoaWNoIEknbGwNCj4+IHBvc3QgYXMgc2VwZXJhdGUgdGhyZWFkcy4NCj4+ IA0KPj4gSSByZWFkIHRocm91Z2g6DQo+PiAgLSBkcmFmdC1pZXRmLWFuaW1hLWdyYXNwLTAxDQo+ PiAgLSBkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAxDQo+PiAgLSBk cmFmdC1iZWhyaW5nZXItYW5pbWEtYXV0b25vbWljLWFkZHJlc3NpbmctMDINCj4+ICAtIGRyYWZ0 LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMDANCj4+ICAtIGRyYWZ0LWlldGYtYW5pbWEt YXV0b25vbWljLWNvbnRyb2wtcGxhbmUtMDENCj4+ICAtIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1y ZWZlcmVuY2UtbW9kZWwtMDQNCj4+IA0KPj4gUmVhZGluZyB0aGUgZHJhZnRzIEkgZ2V0IGEgcHJv Zm91bmQgc2Vuc2Ugb2YgZGlzLXVuaXR5Li4uDQo+PiBJdCdzIGFib3V0IEFDUCB2cyBHUkFTUCwg YW5kIGhvdy93aGVyZSB3ZSBkbyB0aGluZ3MuDQo+IA0KPiBDYW4geW91IHRyeSB0byBleHBsYWlu IHdoZXJlIHlvdSBzZWUgYSBkaXNjb25uZWN0PyBCZWNhdXNlIEkgZG9u4oCZdC4NCg0KPiBUaGUg QUNQIHByb3ZpZGVzIGEgc2VjdXJlIHByaXZhdGUgSW50ZXJuZXQgZm9yIEFOcyB0byB1c2UgYXMg dGhleQ0KPiB3aXNrLCBhbmQgR1JBU1AgcnVucyBvdmVyIHRoZSBBQ1AgdG8gb2ZmZXIgaGlnaGVy IGxldmVsIG1lc3NhZ2luZw0KPiBmdW5jdGlvbnMgdG8gdGhlIEFOcy4NCj4gDQo+IFJpZ2h0IG5v dyBhbGwgdGhhdCBHUkFTUCBzZWVtcyB0byBuZWVkIGZyb20gdGhlIEFDUCBpcyBhIHN0YXR1cyBi aXQNCj4gc2F5aW5nICJBQ1AgaXMgdXAiIGFuZCBhIHNvY2tldCBBUEkuIEl0IG1pZ2h0IG5lZWQg dG8gcGVlayBpbnRvIHRoZQ0KPiBhZGphY2VuY3kgdGFibGUsIGJ1dCBJJ20gbm90IGV2ZW4gc3Vy ZSBhYm91dCB0aGF0Lg0KPiANCj4gVHJ1ZSwgdGhpcyBjaGFzZXMgaXRzIG93biB0YWlsIGEgYml0 IGlmIEdSQVNQIGlzIHVzZWQgZm9yIGluaXRpYWwgZGlzY292ZXJ5LA0KPiBhbmQgdGhhdCBkb2Vz IG5lZWQgdG8gYmUgdGllZCBkb3duLg0KDQpUaGlzIGlzIHdoYXQgSSBjYWxsZWQgb3V0IGR1cmlu ZyBZb2tvaGFtYSBhcyB3ZWxsLiBJcyBpdCAiQUNQIHRoZW4gR1JBU1DigJ0gb3Ig4oCcR1JBU1Ag dGhlbiBBQ1AgdGhlbiBHUkFTUCBhZ2FpbuKAnT8gQ2xlYXJseSBJIGhhdmUgYSBib290c3RyYXBw aW5nIHBlcnNwZWN0aXZlIGJ1dCBtYXliZSBNaWNoYWVsIGlzIHRoaW5raW5nIGFsb25nIHRoZSBz YW1lIGxpbmVzLiANCg0KLSBtYXgNCg0KPiANCj4+IEkgdGhpbmsgd2UgbmVlZCBhIHZpcnR1YWwg aW50ZXJpbSBvciBzb21ldGhpbmcgbGlrZSB0aGF0IHdoZXJlIHdlIGNhbiB0YWxrDQo+PiBmb3Ig YSBsb25nZXIgcGVyaW9kIG9mIHRpbWUgaW4gYSBzbWFsbGVyIGdyb3VwLg0KPiANCj4gV2UgY2Vy dGFpbmx5IG5lZWQgdG8gdW5kZXJzdGFuZCB3aGF0J3Mgbm90IGZpdHRpbmcgdG9nZXRoZXIuDQo+ IA0KPiAgICBCcmlhbg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gQW5pbWEgbWFpbGluZyBsaXN0DQo+IEFuaW1hQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCg0K From nobody Wed Nov 11 11:18:58 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6628E1B3897 for ; Wed, 11 Nov 2015 11:18:57 -0800 (PST) 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 moKXhrcaGZO0 for ; Wed, 11 Nov 2015 11:18:55 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 B6DAB1B3891 for ; Wed, 11 Nov 2015 11:18:55 -0800 (PST) Received: by pabfh17 with SMTP id fh17so39024518pab.0 for ; Wed, 11 Nov 2015 11:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=DrbOcpg8cH+kSseNAKn3C3qrhPe/wzbHMCdPYPV7zic=; b=EC7m7yh5Inh4n6KjO2BsvGD1LO9X22OgNkPPcNmem3OvGn7zinxrJoLQcgqsEqsYBZ 0l4FNuHSIHqoU+/QsjxB8XA/vcN3ejg0BA4/enruszJE6fF8jM5NHLCXGwAEGLMnae1p prnY6ZncNLs35bMJTiNSV/s6WixvJxyf2W5I7wTHhmmYyO3UrUMUej7HHy26BZvbt2PT bjtcoNh94BFgvZobRp6fEqNR3UN5VOQy6iOL4egUG84uFP+pcP+0VevCThVPQrhDE9ys CrTY5sPBHfSvQJ0o/eoBf7qhwCXnnSTuSlWHgZs/uyx1td5QYbCIitsA6hug3dhei6cV styw== X-Received: by 10.66.150.5 with SMTP id ue5mr2479481pab.42.1447269535312; Wed, 11 Nov 2015 11:18:55 -0800 (PST) Received: from ?IPv6:2406:e007:7e1b:1:28cc:dc4c:9703:6781? ([2406:e007:7e1b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id ol9sm3218082pbb.30.2015.11.11.11.18.51 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Nov 2015 11:18:53 -0800 (PST) To: "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5643949B.8050602@gmail.com> Date: Thu, 12 Nov 2015 08:18:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 19:18:57 -0000 Hi Max, On 12/11/2015 04:06, Max Pritikin (pritikin) wrote: >=20 >> On Nov 10, 2015, at 9:10 PM, Brian E Carpenter wrote: >> >> On 11/11/2015 16:05, Michael Richardson wrote: >>> >>> I spent most of my 11h trip home on Monday catching trying to empty m= y list >>> of drafts to read... I have a series of comments on the documents wh= ich I'll >>> post as seperate threads. >>> >>> I read through: >>> - draft-ietf-anima-grasp-01 >>> - draft-ietf-anima-autonomic-control-plane-01 >>> - draft-behringer-anima-autonomic-addressing-02 >>> - draft-liu-anima-grasp-distribution-00 >>> - draft-ietf-anima-autonomic-control-plane-01 >>> - draft-behringer-anima-reference-model-04 >>> >>> Reading the drafts I get a profound sense of dis-unity... >>> It's about ACP vs GRASP, and how/where we do things. >> >> Can you try to explain where you see a disconnect? Because I don=E2=80= =99t. >=20 >> The ACP provides a secure private Internet for ANs to use as they >> wisk, and GRASP runs over the ACP to offer higher level messaging >> functions to the ANs. >> >> Right now all that GRASP seems to need from the ACP is a status bit >> saying "ACP is up" and a socket API. It might need to peek into the >> adjacency table, but I'm not even sure about that. >> >> True, this chases its own tail a bit if GRASP is used for initial disc= overy, >> and that does need to be tied down. >=20 > This is what I called out during Yokohama as well. Is it "ACP then GRAS= P=E2=80=9D or =E2=80=9CGRASP then ACP then GRASP again=E2=80=9D? Clearly = I have a bootstrapping perspective but maybe Michael is thinking along th= e same lines.=20 So, the reason I haven't been rushing to update the GRASP document follow= ing the very helpful discussion in Yokohama (which I followed thanks to a perfect= performance by Meetecho) is that I am teaching myself Python by trying to= write a prototype GRASP implementation instead. It's an instructive process and= I hope it will find bugs in the GRASP design and make the resolution of the open= issues much easier. As far as I can see so far, when the GRASP protocol engine comes up, the= first thing it will do is ask the ACP "are you up?". Assuming the ACP says no, = GRASP knows that it is running insecurely. Apart from that its discovery mechan= ism will be available and if either the secure bootstrap mechanism or the ACP want= s to execute GRASP discovery it can do so. That would imply that the bootstrap= and the ACP each supports a notional GRASP objective to allow discovery; thes= e could be objectives with no value field. For example, assume every bootstrap re= lay supports an objective called "bootRelay" and every ACP engine supports an objectiv= e called "ACP". Then when each bootstrap relay agent comes up it tells its local GRASP en= gine that it's available to be discovered. In my prototype that would use a fu= nction called grasp.register_obj(). Any device that wanted to find a relay agent= would ask its local GRASP engine using a function called grasp.discover(). ACP engi= nes would discover each other similarly. What they do when they've found each other= is out of scope for GRASP. Clearly at that stage everybody is using non-ACP addresses (link-local ma= inly) until the bootstrap phase is over and the ACP is established. Does this make any sense? Of course there is a security issue during the non-ACP discovery phase, a= s noted in the GRASP draft: If GRASP is used temporarily without an external security mechanism, for example during system bootstrap (Section 3.3.1), the Session ID (Section 3.6) will act as a nonce to provide limited protection against third parties injecting responses. Brian From nobody Wed Nov 11 14:27:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2151B3AA3 for ; Wed, 11 Nov 2015 14:27:34 -0800 (PST) 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 rRKgRQVj1HKn for ; Wed, 11 Nov 2015 14:27:32 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 854261B3B35 for ; Wed, 11 Nov 2015 14:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7172; q=dns/txt; s=iport; t=1447280852; x=1448490452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UNWog1odOvbFJPNNNX0Y7JP1ebA2pnbGNAOrPXZOmA8=; b=ex2hkDcppzjI9oVqoI0zXJnYYtPqFxa0KPYQEUmRny2QXEcCoWz6SIAj CLwDqpz/Y09Bh3uyYpMcXl0KCUlaxJbXM3fVNq5AtLAm9+znfKBQppzOw Bfu9ukCP93/OhxvpyAkxu/N5BoSLFmUygGtSaHQpMWvArGmtE01Xbt+OE 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAgCuv0NW/4kNJK1egzuBQga+HwENg?= =?us-ascii?q?WWGEAIcgS44FAEBAQEBAQGBCoQ0AQEBAwEjEUAFBQsCAQgYAgImAgICHxEVEAI?= =?us-ascii?q?EDgWIGQMKCLN/jAQNhGMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYgQGHY4JuglOBY?= =?us-ascii?q?T2DBC+BFQEElkgBizCBdYFbh2WKMYEBh1IBHwEBQoQEcgGECyQfgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,278,1444694400"; d="scan'208";a="44006429" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2015 22:27:31 +0000 Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tABMRV8n013936 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2015 22:27:31 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 Nov 2015 16:27:31 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Wed, 11 Nov 2015 16:27:30 -0600 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WbFNlXfA390qGwfzbG5IpEJ6WmiYAgAC3MICAAEZ7gIAANLSA Date: Wed, 11 Nov 2015 22:27:30 +0000 Message-ID: <9CAF2294-4181-4AE3-AD43-7A7BB0FC9BD1@cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> In-Reply-To: <5643949B.8050602@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.99.106.14] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 22:27:34 -0000 DQo+IE9uIE5vdiAxMSwgMjAxNSwgYXQgMTI6MTggUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gSGkgTWF4LA0KPiANCj4gT24g MTIvMTEvMjAxNSAwNDowNiwgTWF4IFByaXRpa2luIChwcml0aWtpbikgd3JvdGU6DQo+PiANCj4+ PiBPbiBOb3YgMTAsIDIwMTUsIGF0IDk6MTAgUE0sIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5l LmNhcnBlbnRlckBnbWFpbC5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IE9uIDExLzExLzIwMTUgMTY6 MDUsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEkgc3BlbnQgbW9zdCBv ZiBteSAxMWggdHJpcCBob21lIG9uIE1vbmRheSBjYXRjaGluZyB0cnlpbmcgdG8gZW1wdHkgbXkg bGlzdA0KPj4+PiBvZiBkcmFmdHMgdG8gcmVhZC4uLiAgSSBoYXZlIGEgc2VyaWVzIG9mIGNvbW1l bnRzIG9uIHRoZSBkb2N1bWVudHMgd2hpY2ggSSdsbA0KPj4+PiBwb3N0IGFzIHNlcGVyYXRlIHRo cmVhZHMuDQo+Pj4+IA0KPj4+PiBJIHJlYWQgdGhyb3VnaDoNCj4+Pj4gLSBkcmFmdC1pZXRmLWFu aW1hLWdyYXNwLTAxDQo+Pj4+IC0gZHJhZnQtaWV0Zi1hbmltYS1hdXRvbm9taWMtY29udHJvbC1w bGFuZS0wMQ0KPj4+PiAtIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1hdXRvbm9taWMtYWRkcmVzc2lu Zy0wMg0KPj4+PiAtIGRyYWZ0LWxpdS1hbmltYS1ncmFzcC1kaXN0cmlidXRpb24tMDANCj4+Pj4g LSBkcmFmdC1pZXRmLWFuaW1hLWF1dG9ub21pYy1jb250cm9sLXBsYW5lLTAxDQo+Pj4+IC0gZHJh ZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wNA0KPj4+PiANCj4+Pj4gUmVhZGlu ZyB0aGUgZHJhZnRzIEkgZ2V0IGEgcHJvZm91bmQgc2Vuc2Ugb2YgZGlzLXVuaXR5Li4uDQo+Pj4+ IEl0J3MgYWJvdXQgQUNQIHZzIEdSQVNQLCBhbmQgaG93L3doZXJlIHdlIGRvIHRoaW5ncy4NCj4+ PiANCj4+PiBDYW4geW91IHRyeSB0byBleHBsYWluIHdoZXJlIHlvdSBzZWUgYSBkaXNjb25uZWN0 PyBCZWNhdXNlIEkgZG9u4oCZdC4NCj4+IA0KPj4+IFRoZSBBQ1AgcHJvdmlkZXMgYSBzZWN1cmUg cHJpdmF0ZSBJbnRlcm5ldCBmb3IgQU5zIHRvIHVzZSBhcyB0aGV5DQo+Pj4gd2lzaywgYW5kIEdS QVNQIHJ1bnMgb3ZlciB0aGUgQUNQIHRvIG9mZmVyIGhpZ2hlciBsZXZlbCBtZXNzYWdpbmcNCj4+ PiBmdW5jdGlvbnMgdG8gdGhlIEFOcy4NCj4+PiANCj4+PiBSaWdodCBub3cgYWxsIHRoYXQgR1JB U1Agc2VlbXMgdG8gbmVlZCBmcm9tIHRoZSBBQ1AgaXMgYSBzdGF0dXMgYml0DQo+Pj4gc2F5aW5n ICJBQ1AgaXMgdXAiIGFuZCBhIHNvY2tldCBBUEkuIEl0IG1pZ2h0IG5lZWQgdG8gcGVlayBpbnRv IHRoZQ0KPj4+IGFkamFjZW5jeSB0YWJsZSwgYnV0IEknbSBub3QgZXZlbiBzdXJlIGFib3V0IHRo YXQuDQo+Pj4gDQo+Pj4gVHJ1ZSwgdGhpcyBjaGFzZXMgaXRzIG93biB0YWlsIGEgYml0IGlmIEdS QVNQIGlzIHVzZWQgZm9yIGluaXRpYWwgZGlzY292ZXJ5LA0KPj4+IGFuZCB0aGF0IGRvZXMgbmVl ZCB0byBiZSB0aWVkIGRvd24uDQo+PiANCj4+IFRoaXMgaXMgd2hhdCBJIGNhbGxlZCBvdXQgZHVy aW5nIFlva29oYW1hIGFzIHdlbGwuIElzIGl0ICJBQ1AgdGhlbiBHUkFTUOKAnSBvciDigJxHUkFT UCB0aGVuIEFDUCB0aGVuIEdSQVNQIGFnYWlu4oCdPyBDbGVhcmx5IEkgaGF2ZSBhIGJvb3RzdHJh cHBpbmcgcGVyc3BlY3RpdmUgYnV0IG1heWJlIE1pY2hhZWwgaXMgdGhpbmtpbmcgYWxvbmcgdGhl IHNhbWUgbGluZXMuIA0KPiANCj4gU28sIHRoZSByZWFzb24gSSBoYXZlbid0IGJlZW4gcnVzaGlu ZyB0byB1cGRhdGUgdGhlIEdSQVNQIGRvY3VtZW50IGZvbGxvd2luZyB0aGUNCj4gdmVyeSBoZWxw ZnVsIGRpc2N1c3Npb24gaW4gWW9rb2hhbWEgKHdoaWNoIEkgZm9sbG93ZWQgdGhhbmtzIHRvIGEg cGVyZmVjdA0KPiBwZXJmb3JtYW5jZSBieSBNZWV0ZWNobykgaXMgdGhhdCBJIGFtIHRlYWNoaW5n IG15c2VsZiBQeXRob24gYnkgdHJ5aW5nIHRvIHdyaXRlDQo+IGEgcHJvdG90eXBlIEdSQVNQIGlt cGxlbWVudGF0aW9uIGluc3RlYWQuIEl0J3MgYW4gaW5zdHJ1Y3RpdmUgcHJvY2VzcyBhbmQgSSBo b3BlDQo+IGl0IHdpbGwgZmluZCBidWdzIGluIHRoZSBHUkFTUCBkZXNpZ24gYW5kIG1ha2UgdGhl IHJlc29sdXRpb24gb2YgdGhlIG9wZW4gaXNzdWVzDQo+IG11Y2ggZWFzaWVyLg0KDQpBbmQgaXMg b2YgY291cnNlICptdWNoIG1vcmUgZnVuKiB0aGFuIHdvcmtpbmcgb24gdGhlIGRvY3VtZW50IHRl eHQuIDopDQoNCj4gQXMgZmFyIGFzIEkgY2FuIHNlZSBzbyBmYXIsIHdoZW4gdGhlIEdSQVNQICBw cm90b2NvbCBlbmdpbmUgY29tZXMgdXAsIHRoZSBmaXJzdA0KPiB0aGluZyBpdCB3aWxsIGRvIGlz IGFzayB0aGUgQUNQICJhcmUgeW91IHVwPyIuIEFzc3VtaW5nIHRoZSBBQ1Agc2F5cyBubywgR1JB U1ANCj4ga25vd3MgdGhhdCBpdCBpcyBydW5uaW5nIGluc2VjdXJlbHkuDQoNCkFjY29yZGluZyB0 byBzMy4zLjI6DQoiICAgV2hlbiBydW5uaW5nIHdpdGhvdXQgYW4gQUNQLCBUTFMgTVVTVCBiZSBz dXBwb3J0ZWQgYW5kIHVzZWQgYnkNCiAgIGRlZmF1bHQsIGV4Y2VwdCBmb3IgbXVsdGljYXN0IGRp c2NvdmVyeSBtZXNzYWdlcy4gIERUTFMgTUFZIGJlDQogICBzdXBwb3J0ZWQgYXMgYW4gYWx0ZXJu YXRpdmUgYnV0IHRoZSBkZXRhaWxzIGFyZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMNCiAgIGRvY3Vt ZW50LuKAnQ0KQnV0IHRoaXMgY2Fu4oCZdCBoYXBwZW4gdW50aWwgYm9vdHN0cmFwcGluZyBpcyBj b21wbGV0ZS4NCg0KPiBBcGFydCBmcm9tIHRoYXQgaXRzIGRpc2NvdmVyeSBtZWNoYW5pc20gd2ls bA0KPiBiZSBhdmFpbGFibGUgYW5kIGlmIGVpdGhlciB0aGUgc2VjdXJlIGJvb3RzdHJhcCBtZWNo YW5pc20gb3IgdGhlIEFDUCB3YW50cyB0bw0KPiBleGVjdXRlIEdSQVNQIGRpc2NvdmVyeSBpdCBj YW4gZG8gc28uIFRoYXQgd291bGQgaW1wbHkgdGhhdCB0aGUgYm9vdHN0cmFwIGFuZA0KPiB0aGUg QUNQIGVhY2ggc3VwcG9ydHMgYSBub3Rpb25hbCBHUkFTUCBvYmplY3RpdmUgdG8gYWxsb3cgZGlz Y292ZXJ5OyB0aGVzZSBjb3VsZA0KPiBiZSBvYmplY3RpdmVzIHdpdGggbm8gdmFsdWUgZmllbGQu IEZvciBleGFtcGxlLCBhc3N1bWUgZXZlcnkgYm9vdHN0cmFwIHJlbGF5IHN1cHBvcnRzDQo+IGFu IG9iamVjdGl2ZSBjYWxsZWQgImJvb3RSZWxheSIgYW5kIGV2ZXJ5IEFDUCBlbmdpbmUgc3VwcG9y dHMgYW4gb2JqZWN0aXZlIGNhbGxlZA0KPiAiQUNQIi4NCj4gDQo+IFRoZW4gd2hlbiBlYWNoIGJv b3RzdHJhcCByZWxheSBhZ2VudCBjb21lcyB1cCBpdCB0ZWxscyBpdHMgbG9jYWwgR1JBU1AgZW5n aW5lDQo+IHRoYXQgaXQncyBhdmFpbGFibGUgdG8gYmUgZGlzY292ZXJlZC4gSW4gbXkgcHJvdG90 eXBlIHRoYXQgd291bGQgdXNlIGEgZnVuY3Rpb24NCj4gY2FsbGVkIGdyYXNwLnJlZ2lzdGVyX29i aigpLiBBbnkgZGV2aWNlIHRoYXQgd2FudGVkIHRvIGZpbmQgYSByZWxheSBhZ2VudCB3b3VsZCBh c2sNCj4gaXRzIGxvY2FsIEdSQVNQIGVuZ2luZSB1c2luZyBhIGZ1bmN0aW9uIGNhbGxlZCBncmFz cC5kaXNjb3ZlcigpLiBBQ1AgZW5naW5lcyB3b3VsZA0KPiBkaXNjb3ZlciBlYWNoIG90aGVyIHNp bWlsYXJseS4gV2hhdCB0aGV5IGRvIHdoZW4gdGhleSd2ZSBmb3VuZCBlYWNoIG90aGVyIGlzDQo+ IG91dCBvZiBzY29wZSBmb3IgR1JBU1AuDQo+IA0KPiBDbGVhcmx5IGF0IHRoYXQgc3RhZ2UgZXZl cnlib2R5IGlzIHVzaW5nIG5vbi1BQ1AgYWRkcmVzc2VzIChsaW5rLWxvY2FsIG1haW5seSkNCj4g dW50aWwgdGhlIGJvb3RzdHJhcCBwaGFzZSBpcyBvdmVyIGFuZCB0aGUgQUNQIGlzIGVzdGFibGlz aGVkLg0KPiANCj4gRG9lcyB0aGlzIG1ha2UgYW55IHNlbnNlPw0KDQpJIHRoaW5rIHNvLiBEb2Vz buKAmXQgbWVhbiBJIGRvbuKAmXQgaGF2ZSBxdWVzdGlvbnMgdGhvdWdoIDspDQoNCj4gDQo+IE9m IGNvdXJzZSB0aGVyZSBpcyBhIHNlY3VyaXR5IGlzc3VlIGR1cmluZyB0aGUgbm9uLUFDUCBkaXNj b3ZlcnkgcGhhc2UsIGFzDQo+IG5vdGVkIGluIHRoZSBHUkFTUCBkcmFmdDoNCj4gDQo+ICAgICAg SWYgR1JBU1AgaXMgdXNlZCB0ZW1wb3JhcmlseSB3aXRob3V0IGFuIGV4dGVybmFsIHNlY3VyaXR5 DQo+ICAgICAgbWVjaGFuaXNtLCBmb3IgZXhhbXBsZSBkdXJpbmcgc3lzdGVtIGJvb3RzdHJhcCAo U2VjdGlvbiAzLjMuMSksDQo+ICAgICAgdGhlIFNlc3Npb24gSUQgKFNlY3Rpb24gMy42KSB3aWxs IGFjdCBhcyBhIG5vbmNlIHRvIHByb3ZpZGUNCj4gICAgICBsaW1pdGVkIHByb3RlY3Rpb24gYWdh aW5zdCB0aGlyZCBwYXJ0aWVzIGluamVjdGluZyByZXNwb25zZXMuDQoNCkkgdW5kZXJzdGFuZCB0 aGUgaW50ZW50aW9uIG9mIHVzaW5nIHRoZSBTZXNzaW9uSUQgYXMgYSBub25jZS4gDQoNClRoZXJl IGFyZSB0aHJlZSBxdWVzdGlvbnMgSeKAmXZlIGdvdDogDQoxKSBXaGF0IGlzIEdSQVNQIHByb3Zp ZGluZyBib290c3RyYXBwaW5nIHRoYXQgaXNu4oCZdCBwcm92aWRlZCB2aWEgb3RoZXIgbWV0aG9k cz8gSXMgdGhlIGFyZ3VtZW50IHRoYXQgdGhlIGludGVybmFsIEFQSSBtZXRob2RzIHRvIGEgR1JB U1AgbGlicmFyeSBtYWtlcyBpdCBlYXNpZXIgdG8gY29kZSBhbiBhZ2VudCB0aGFuLCBmb3IgZXhh bXBsZSwgaGF2aW5nIGFuIGFnZW50IG9wZW4gdGhlIHNvY2tldCBkaXJlY3RseT8gDQoNCjIpIEhv dyBjb21wbGV4IGlzIGl0IHRvIHVzZSBHUkFTUCBhcyB0aGUgZGlzY292ZXJ5IG1ldGhvZD8gSWYg Y2xpZW50cyBwZXJmb3JtIEROUyBvciBESENQIG9yIG90aGVyIGRpc2NvdmVyeSBtZXRob2RzIGlu IGFkZGl0aW9uIHRvIEdSQVNQIGhvdyBtdWNoIGFkZGl0aW9uYWwgY29kZSBkbyB0aGV5IG5lZWQg dG8gcGVyZm9ybSBHUkFTUCBpdHNlbGY/IEkgYWRtaXQgSeKAmW0gdHJ5aW5nIHRvIHRoaW5rIGhl cmUgYWJvdXQgbmV0Y29uZiBhbmQgb3RoZXIgZ3JvdXBzIHRoYXQgbWlnaHQgd2FudCB0byBkbyBk aXNjb3ZlcnkgYnV0IG5vdCBiZSByZXF1aXJlZCB0byBkbyB0aGUgcmVzdCBvZiBhdXRvbm9taWMg KGUuZy4gR1JBU1AsIEFDUCBldGMpLiAgDQoNCjMpIERvZXMgdGhlIFNlc3Npb25JRCBtZXRob2Qg YWN0dWFsbHkgd29yaz8gKEFzc3VtaW5nIHRoZSBhYm92ZSBNVVNUIGFib3V0IFRMUyBpc27igJl0 IGFwcGxpZWQgb2YgY291cnNlKS4NCg0KLSBtYXgNCg0KDQoNCj4gDQo+ICAgQnJpYW4NCg0K From nobody Wed Nov 11 15:09:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789E1B3C02 for ; Wed, 11 Nov 2015 15:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_36=0.6, 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 GR9I-lrX1kWo for ; Wed, 11 Nov 2015 15:09:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 7E9951B3C01 for ; Wed, 11 Nov 2015 15:09:27 -0800 (PST) Received: by pasz6 with SMTP id z6so45475164pas.2 for ; Wed, 11 Nov 2015 15:09:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=eD0kc6Dx13EneIwt4vvymQs2DAmU1G9RN83C1IkJ0bU=; b=RJ+WUBU9pk62rpQwUOU+6aa3TueMLDrOyy7PKmYw2ViDiJp6B5gk6kgUDq2SQ18Aci XP2Oj/3w6n5DWWlsqwZHi19ukY2VU8ugFLOMVU1PD1Xy08aQu6JGm0Kb15UVKfsX2h8f O/Djt4lrUD6EJR/g/tCt+c9VAzO8c3Zn0nkoB3TUogq2agARyTTdltZfC4aKxwG5BNUv hUf81eUZohkZC2jEiIeeaehYincBUPbwdCDzc5NgdTcarOdlvf7tKIuQ143QfYthLGpf lbeXk9ixf5JDv/kea0qRg51f6flRrzaC3lp5rpY5Z+Agh28yLuX98+Ace9JxnfO7yuAr 1xog== X-Received: by 10.66.217.194 with SMTP id pa2mr18127361pac.98.1447283367063; Wed, 11 Nov 2015 15:09:27 -0800 (PST) Received: from ?IPv6:2406:e007:7e1b:1:28cc:dc4c:9703:6781? ([2406:e007:7e1b:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id at5sm4615743pbc.32.2015.11.11.15.09.23 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Nov 2015 15:09:25 -0800 (PST) To: "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> <9CAF2294-4181-4AE3-AD43-7A7BB0FC9BD1@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <5643CAA9.1050902@gmail.com> Date: Thu, 12 Nov 2015 12:09:29 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <9CAF2294-4181-4AE3-AD43-7A7BB0FC9BD1@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 23:09:29 -0000 Comments in line. This is good, we're getting to the real questions... On 12/11/2015 11:27, Max Pritikin (pritikin) wrote: >=20 >> On Nov 11, 2015, at 12:18 PM, Brian E Carpenter wrote: >> >> Hi Max, >> >> On 12/11/2015 04:06, Max Pritikin (pritikin) wrote: >>> >>>> On Nov 10, 2015, at 9:10 PM, Brian E Carpenter wrote: >>>> >>>> On 11/11/2015 16:05, Michael Richardson wrote: >>>>> >>>>> I spent most of my 11h trip home on Monday catching trying to empty= my list >>>>> of drafts to read... I have a series of comments on the documents = which I'll >>>>> post as seperate threads. >>>>> >>>>> I read through: >>>>> - draft-ietf-anima-grasp-01 >>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>> - draft-behringer-anima-autonomic-addressing-02 >>>>> - draft-liu-anima-grasp-distribution-00 >>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>> - draft-behringer-anima-reference-model-04 >>>>> >>>>> Reading the drafts I get a profound sense of dis-unity... >>>>> It's about ACP vs GRASP, and how/where we do things. >>>> >>>> Can you try to explain where you see a disconnect? Because I don=E2=80= =99t. >>> >>>> The ACP provides a secure private Internet for ANs to use as they >>>> wisk, and GRASP runs over the ACP to offer higher level messaging >>>> functions to the ANs. >>>> >>>> Right now all that GRASP seems to need from the ACP is a status bit >>>> saying "ACP is up" and a socket API. It might need to peek into the >>>> adjacency table, but I'm not even sure about that. >>>> >>>> True, this chases its own tail a bit if GRASP is used for initial di= scovery, >>>> and that does need to be tied down. >>> >>> This is what I called out during Yokohama as well. Is it "ACP then GR= ASP=E2=80=9D or =E2=80=9CGRASP then ACP then GRASP again=E2=80=9D? Clearl= y I have a bootstrapping perspective but maybe Michael is thinking along = the same lines.=20 >> >> So, the reason I haven't been rushing to update the GRASP document fol= lowing the >> very helpful discussion in Yokohama (which I followed thanks to a perf= ect >> performance by Meetecho) is that I am teaching myself Python by trying= to write >> a prototype GRASP implementation instead. It's an instructive process = and I hope >> it will find bugs in the GRASP design and make the resolution of the o= pen issues >> much easier. >=20 > And is of course *much more fun* than working on the document text. :) >=20 >> As far as I can see so far, when the GRASP protocol engine comes up, = the first >> thing it will do is ask the ACP "are you up?". Assuming the ACP says n= o, GRASP >> knows that it is running insecurely. >=20 > According to s3.3.2: > " When running without an ACP, TLS MUST be supported and used by > default, except for multicast discovery messages. DTLS MAY be > supported as an alternative but the details are out of scope for thi= s > document.=E2=80=9D > But this can=E2=80=99t happen until bootstrapping is complete. Yes (because nodes won't have certs yet). This is one of the reasons that= I think the non-ACP mode of GRASP is in general something we have to decl= are as TBD for now. So it means (I think) that all we have to work with is in= secure discovery. All other GRASP operations need to fail until acp.status =3D=3D= True or we can successfully start TLS. >> Apart from that its discovery mechanism will >> be available and if either the secure bootstrap mechanism or the ACP w= ants to >> execute GRASP discovery it can do so. That would imply that the bootst= rap and >> the ACP each supports a notional GRASP objective to allow discovery; t= hese could >> be objectives with no value field. For example, assume every bootstrap= relay supports >> an objective called "bootRelay" and every ACP engine supports an objec= tive called >> "ACP". >> >> Then when each bootstrap relay agent comes up it tells its local GRASP= engine >> that it's available to be discovered. In my prototype that would use a= function >> called grasp.register_obj(). Any device that wanted to find a relay ag= ent would ask >> its local GRASP engine using a function called grasp.discover(). ACP e= ngines would >> discover each other similarly. What they do when they've found each ot= her is >> out of scope for GRASP. >> >> Clearly at that stage everybody is using non-ACP addresses (link-local= mainly) >> until the bootstrap phase is over and the ACP is established. >> >> Does this make any sense? >=20 > I think so. Doesn=E2=80=99t mean I don=E2=80=99t have questions though = ;) >=20 >> >> Of course there is a security issue during the non-ACP discovery phase= , as >> noted in the GRASP draft: >> >> If GRASP is used temporarily without an external security >> mechanism, for example during system bootstrap (Section 3.3.1), >> the Session ID (Section 3.6) will act as a nonce to provide >> limited protection against third parties injecting responses. >=20 > I understand the intention of using the SessionID as a nonce.=20 >=20 > There are three questions I=E2=80=99ve got:=20 > 1) What is GRASP providing bootstrapping that isn=E2=80=99t provided vi= a other methods? Is the argument that the internal API methods to a GRASP= library makes it easier to code an agent than, for example, having an ag= ent open the socket directly?=20 If we are only talking about discovery, that is all you get. I have no religion here - if you have another discovery mechanism, that's fine by me. Of course we could add an explicitly insecure message mode to GRASP, so that you get whatever the GRASP API turns out to be instead of a basic socket. That wouldn't be hard; whether it's useful is another matter. > 2) How complex is it to use GRASP as the discovery method? If clients p= erform DNS or DHCP or other discovery methods in addition to GRASP how mu= ch additional code do they need to perform GRASP itself? I admit I=E2=80=99= m trying to think here about netconf and other groups that might want to = do discovery but not be required to do the rest of autonomic (e.g. GRASP,= ACP etc). Well, I'm hoping it will come down to a couple of calls. I really don't w= ant to go into details until I've made some code run, but what I'm thinking is ther= e would mainly be these calls: register_asa(asa_name) # register the calling ASA with GRASP # (bootstrap and ACP would pretend to be ASAs= ) register_obj(objective) # register an objective so that other nodes c= an discover you # "bootRelay" and "ACP" for example discover(objective, timeout)# discover other ASAs supporting the objectiv= e list_peers(objective) # get a list of locators of the discovered AS= As >=20 > 3) Does the SessionID method actually work? (Assuming the above MUST ab= out TLS isn=E2=80=99t applied of course). Well, Joel Halpern noticed a design error that we need to fix. I decided = to defer fixing it until I have tried to code it, but my co-authors may have= some ideas. (The error is that we didn't discuss the issue of two differe= nt nodes choosing the same SessionID value. That's low probability in a 24 b= it space but it's still a design flaw.) Brian From nobody Wed Nov 11 19:47:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42BF91A88DF for ; Wed, 11 Nov 2015 19:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, 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 sU9W2lVCN8UY for ; Wed, 11 Nov 2015 19:47:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFC9E1A874F for ; Wed, 11 Nov 2015 19:47:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAF47664; Thu, 12 Nov 2015 03:47:37 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 12 Nov 2015 03:47:36 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0235.001; Thu, 12 Nov 2015 11:47:28 +0800 From: "Liubing (Leo)" To: "Max Pritikin (pritikin)" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3b8xH4138F2EW7mUsJDdz/GZ6Vr3UAgAC3MACAAUSpsA== Date: Thu, 12 Nov 2015 03:47:27 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> In-Reply-To: <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56440BD9.007A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ccd1b2e7d70f86db74fa1c4ec8919865 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 03:47:42 -0000 SGkgYWxsLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuaW1hIFtt YWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1heCBQcml0aWtpbg0K PiAocHJpdGlraW4pDQouLi4NCj4gVGhpcyBpcyB3aGF0IEkgY2FsbGVkIG91dCBkdXJpbmcgWW9r b2hhbWEgYXMgd2VsbC4gSXMgaXQgIkFDUCB0aGVuIEdSQVNQ4oCdIG9yDQo+IOKAnEdSQVNQIHRo ZW4gQUNQIHRoZW4gR1JBU1AgYWdhaW7igJ0/IENsZWFybHkgSSBoYXZlIGEgYm9vdHN0cmFwcGlu Zw0KPiBwZXJzcGVjdGl2ZSBidXQgbWF5YmUgTWljaGFlbCBpcyB0aGlua2luZyBhbG9uZyB0aGUg c2FtZSBsaW5lcy4NCg0KQXBhcnQgZnJvbSBBU0FzLCB3ZSBhbHNvIG5lZWQgdGhlIGZvbGxvd2lu ZyBzaWduYWxsaW5nczoNCi0gYSBEaXNjb3ZlcnkgbWVjaGFuaXNtIGR1cmluZyBib290c3RyYXBw aW5nIChCb290LURpc2NvdmVyeSkNCi0gYSBEaXNjb3ZlcnkvTmVnb3RpYXRpb24gbWVjaGFuaXNt IGR1cmluZyBBQ1AgZXN0YWJsaXNoaW5nIChBQ1AtRGlzTmVnKQ0KDQpUaGUgR1JBU1AgbWlnaHQg aGF2ZSB0aGUgc2VjdXJpdHkgc3RhdGU6DQotIG5vIHNlY3VyaXR5IGF0IGFsbCAoR1JBU1AtTm9u U2VjKQ0KLSBUTFMvRFRMUyBzZWN1cmVkIChHUkFTUC0oRClUTFMpDQotIFJ1bm5pbmcgaW4gQUNQ LCBtb3N0bHkgZm9yIEFTQXMgY29tbXVuaWNhdGlvbiAoR1JBU1AtQUNQKQ0KDQpJZiB0aGUgQm9v dC1EaXNjb3ZlcnkgY2hvb3NlIEdSQVNQLCB0aGVuIEkgZ3Vlc3Mgd2UgbmVlZCB0byBtYWtlIHRo ZSBHUkFTUC1Ob25TZWMgdmFsaWQgYXMgd2VsbChpbiBjdXJyZW50IGRyYWZ0LCB0aGVyZSBpcyBu byBjaG9pY2UgZm9yIG5vbi1zZWN1cmVkIEdSQVNQKS4gQmVjYXVzZSBpdCB3b3VsZCBiZSBkaWZm aWN1bHQgZm9yIEdSQVNQIHRvIGdhaW4gKEQpVExTIHByb3RlY3Rpb24gd2l0aG91dCB0aGUgYm9v dHN0cmFwcGluZyByZWFkeS4NCkhvd2V2ZXIsIGFzIE1heCBzYWlkLCBpdCBzZWVtcyBib290c3Ry YXBwaW5nIHByZWZlciBvdGhlciBkaXNjb3ZlcnkgbWVjaGFuaXNtcyB0aGFuIEdSQVNQPyBJIG5l ZWQgdG8gZG8gYSBob21ld29yayB0byBmaWd1cmUgb3V0IHRoZSBzaWduYWxpbmcgcmVxdWlyZW1l bnRzIG9mIGJvb3RzdHJhcHBpbmcuIChNYXgsIGlmIHlvdSBjb3VsZCBnaXZlIG1lIHNvbWUgaGlu dCwgdGhhdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwuIE1hbnkgdGhhbmtzLikNCg0KSW4gQUNQIGRy YWZ0LCBpdCBzcGVjaWZpZXMgdGhhdCB0aGUgQUNQLURpc05lZyBNVVNUIGJlIHNlY3VyZWQuIFNv LCBpZiB0aGUgQUNQLURpc05lZyBpcyBHUkFTUCwgaXQganVzdCBhc3N1bWVzIEdSQVNQLShEKVRM UyBpbiB1c2UsIHdoaWNoIGlzIGFwcGxpY2FibGUgYWZ0ZXIgYm9vdHN0cmFwcGluZywgaXMgdGhl cmUgYW55IGdhcD8NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0K From nobody Wed Nov 11 21:00:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B231AC3F7 for ; Wed, 11 Nov 2015 21:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 ahhQholw8U_7 for ; Wed, 11 Nov 2015 21:00:15 -0800 (PST) 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 2D0001AC3F3 for ; Wed, 11 Nov 2015 21:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3814; q=dns/txt; s=iport; t=1447304415; x=1448514015; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=rFYdEf5Kw4B9KexZzD8HyFB2jRKo41HEhy4v9vShZW0=; b=RM4vBuwdcb6I6tbPafjxd2e22wb/EiraYKhqHwbts0GdGNVRbFj7jmeT R1BmlULclCyvyFBjLRuQUnKCtx4ITZo6/3JXcAMbzKTl79BEpXvA0joov 31wu4y+pFlnLvwvXCqWaRcBCPyor3Gg5tCb2jvWtt89BV3bF6Pxrqw3XS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D7AQB5HERW/4QNJK1egztTb743AQ2BZRcKhW8CgTI4FAEBAQEBAQGBCoQ1AQEEAQEBNzQLEAsYCSUPBRM2E4guDcQNAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASLUogkgRUFjhGIN40fCIFbh2WTBR8BAUKEJR00hT0BAQE X-IronPort-AV: E=Sophos;i="5.20,280,1444694400"; d="scan'208";a="206733476" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 12 Nov 2015 05:00:14 +0000 Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tAC50DJE013487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Nov 2015 05:00:14 GMT Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id tAC508WE018415; Wed, 11 Nov 2015 21:00:13 -0800 Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id tAC508pP018414; Wed, 11 Nov 2015 21:00:08 -0800 Date: Wed, 11 Nov 2015 21:00:08 -0800 From: Toerless Eckert To: Brian E Carpenter Message-ID: <20151112050008.GA16599@cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5642BFD0.3000805@gmail.com> User-Agent: Mutt/1.4.2.2i Archived-At: Cc: Michael Richardson , anima@ietf.org Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 05:00:16 -0000 My quick summary of how i could imagine the connection: A. Unenrolled node: 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nodes: instance of unsecure, unprotected L2-only GRASP. Enrolled node periodically sends L2 IP multicast objective discovery multicast "AN-node-who-wants-to-get-enrolled" AN nodes willing to enroll send unicast message back not sure if we want another unicast exchange round to prohibit some DoS attacks from other nodes on the same LAN. TBD: any attributes to include at "app-level", eg: SUDI or the like, might help, not sure. 2. Bootstrap continues with an EST/TLS connection where enrolled node acts as TLS proxy. Not sure if there further cases for GRASP in the bootstrap process or if everything we need would be within EST. We do know that we want specific details in the certificate assigned. Not sure enough about EST details yet. B. Enrolled Nodes creating ACP between each other. 1. GRASP (boring): same as A.1, except that the two nodes discovery that they are claming both to be enrolled into same domain. 2. TLS (or dTLS ?) connection built between the two nodes. GRASP inside TLS connection, also just single-hop negotiating ACP tunnel mode. MTI ACP encryption: dTLS or IPsec. IPsec is logical, but talking to IOT folks it seems dTLS will be in every IOT device that has any security, so maybe dTLS is better lowest common denominator. C. Primary GRASP instance inside ACP This instance will be protected by ACP and be network wide, eg: GRASP needs to forward hop-by-hop. 1. Main purpose for GRASP inside ACP for the ACP itself (everything else is for future autonomic agents): Service-discovery of registrar. Eg: the already enrolled AN node in A. acting as proxy for enrollment will learn IP-address of registrar via GRASP. There are some open questions i have here as well, but lets see if this is on the outset what we think it should be. Cheers Toerless On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: > On 11/11/2015 16:05, Michael Richardson wrote: > > > > I spent most of my 11h trip home on Monday catching trying to empty my list > > of drafts to read... I have a series of comments on the documents which I'll > > post as seperate threads. > > > > I read through: > > - draft-ietf-anima-grasp-01 > > - draft-ietf-anima-autonomic-control-plane-01 > > - draft-behringer-anima-autonomic-addressing-02 > > - draft-liu-anima-grasp-distribution-00 > > - draft-ietf-anima-autonomic-control-plane-01 > > - draft-behringer-anima-reference-model-04 > > > > Reading the drafts I get a profound sense of dis-unity... > > It's about ACP vs GRASP, and how/where we do things. > > Can you try to explain where you see a disconnect? Because I don't. > The ACP provides a secure private Internet for ANs to use as they > wisk, and GRASP runs over the ACP to offer higher level messaging > functions to the ANs. > > Right now all that GRASP seems to need from the ACP is a status bit > saying "ACP is up" and a socket API. It might need to peek into the > adjacency table, but I'm not even sure about that. > > True, this chases its own tail a bit if GRASP is used for initial discovery, > and that does need to be tied down. > > > I think we need a virtual interim or something like that where we can talk > > for a longer period of time in a smaller group. > > We certainly need to understand what's not fitting together. > > Brian > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- Toerless Eckert, eckert@cisco.com From nobody Thu Nov 12 08:34:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076101B3001 for ; Thu, 12 Nov 2015 08:34:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 UCHK1XvUbji9 for ; Thu, 12 Nov 2015 08:34:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEBF61B2FFD for ; Thu, 12 Nov 2015 08:34:49 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B6FF2015D; Thu, 12 Nov 2015 11:38:51 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 989B8637F8; Thu, 12 Nov 2015 11:34:48 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7F4AA637F3; Thu, 12 Nov 2015 11:34:48 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <5642BFD0.3000805@gmail.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: anima@ietf.org Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 16:34:51 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> I spent most of my 11h trip home on Monday catching trying to empty my >> list of drafts to read... I have a series of comments on the >> documents which I'll post as seperate threads. >> >> I read through: - draft-ietf-anima-grasp-01 - >> draft-ietf-anima-autonomic-control-plane-01 - >> draft-behringer-anima-autonomic-addressing-02 - >> draft-liu-anima-grasp-distribution-00 - >> draft-ietf-anima-autonomic-control-plane-01 - >> draft-behringer-anima-reference-model-04 >> >> Reading the drafts I get a profound sense of dis-unity... It's about >> ACP vs GRASP, and how/where we do things. > Can you try to explain where you see a disconnect? Because I don't. > The ACP provides a secure private Internet for ANs to use as they wisk, > and GRASP runs over the ACP to offer higher level messaging functions > to the ANs. I don't see this in the documents, and I have six half-written emails explaining where I think the disconnects are... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVkS/pYCLcPvd0N1lAQIc+AgAjH9on5Hu408ZE3IoM0k8GZ6P/nkQK9lg FJN1u2Md0qZsXl22vRwkTo9u6jHWuoLEdXyA6NODASlz16i25UM0Q972D++f/vO1 c4+0zvtyUAgtfUk7DOrtBgaDSDIRBL+zGRPyIJc4PrYnH7X6m1c8v8QYUTKAsfW1 IFoHMKzEgyk0J3Gcf2loVhsn/wfBRDQSQiRXPFIRBwOC9GwindazmXyetksXH1FB 2+RUvrWrL7rq/m2RIyWUI+eZUDCDPEbQJxRgIbVyeKeEzmPuU3Nh9G8Wt4SRJ1P/ 7812EU0rn2gX/ow19aDtIFe26x0U38DmSUliTJ1YNJDRHcxQo+1Lew== =sNWr -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 12 12:41:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08711B357F for ; Thu, 12 Nov 2015 12:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, HTML_MESSAGE=0.001, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 24agNts5A3Al for ; Thu, 12 Nov 2015 12:40:57 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E031B357C for ; Thu, 12 Nov 2015 12:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11750; q=dns/txt; s=iport; t=1447360857; x=1448570457; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=5KMsoofTBPDaUlrzoKojfWbrc9Ant3vRfNbmI4ExJ9g=; b=IcZ0WLRW1f+n5tFrchydpN6fkFexa8YY7YFzx7+nX4s5CmBmaaSv1Lqi 1L6sio1kWTJeyYA2C44apXds0m53KhgZCeOTHIxYyQ/xckFm0dd644VVt e/u4xsmyNNmFHftwWM4VHeOLdOKxwqt+k07/0X29KV+kfIFKQjvPFtCMw o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2AQAM+ERW/5JdJa1egm5NU2++PwENg?= =?us-ascii?q?WUXAQmFbwKBPzgUAQEBAQEBAYEKhDUBAQQBAQEqQQYFEAIBCBgJJQ8SBgsOFwI?= =?us-ascii?q?EDgWIGQMSDboehRYNhGIBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBItSglOCNYQxB?= =?us-ascii?q?YYLCZA0AYsxgXWBW4dlizKHUgEfAQFChARyAYU8AQEB?= X-IronPort-AV: E=Sophos;i="5.20,283,1444694400"; d="scan'208,217";a="207181207" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2015 20:40:56 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id tACKetan022135 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 20:40:56 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 14:40:55 -0600 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 14:40:55 -0600 From: "Toerless Eckert (eckert)" To: Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3W3mGPukqMfEuJ1fz8RZrCFJ6WmiYAgAGgFACAAPLugP//r1fO Date: Thu, 12 Nov 2015 20:40:55 +0000 Message-ID: References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com>,<5644E8A1.8090204@gmail.com> In-Reply-To: <5644E8A1.8090204@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_y990f9letlb0x30lg9j0rykk1447360642767emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Toerless Eckert \(eckert\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 20:40:59 -0000 --_000_y990f9letlb0x30lg9j0rykk1447360642767emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We thought that it would be better this way around because: Already enrolled device can be less attacked, because it will not react to = unsolicited messages. Client device sitting in a non-an environment will not generate messages un= necessary in this environment, but just rspond. Sent from my Samsung Captivate Glide on AT&T Brian E Carpenter wrote: Toerless, I think that's about right. I would probably invert the logic in stage 1 (an enrolled node responds to discovery multicast by an unenrolled node) but that's a detail. Brian On 12/11/2015 18:00, Toerless Eckert wrote: > My quick summary of how i could imagine the connection: > > A. Unenrolled node: > > 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nodes: > > instance of unsecure, unprotected L2-only GRASP. > Enrolled node periodically sends L2 IP multicast objective > discovery multicast "AN-node-who-wants-to-get-enrolled" > > AN nodes willing to enroll send unicast message back > > not sure if we want another unicast exchange round to prohibit > some DoS attacks from other nodes on the same LAN. > > TBD: any attributes to include at "app-level", eg: SUDI or the > like, might help, not sure. > > 2. Bootstrap continues with an EST/TLS connection where enrolled > node acts as TLS proxy. > > Not sure if there further cases for GRASP in the bootstrap process > or if everything we need would be within EST. We do know that > we want specific details in the certificate assigned. Not sure > enough about EST details yet. > > B. Enrolled Nodes creating ACP between each other. > > 1. GRASP (boring): same as A.1, except that the two nodes discovery > that they are claming both to be enrolled into same domain. > > 2. TLS (or dTLS ?) connection built between the two nodes. > GRASP inside TLS connection, also just single-hop negotiating > ACP tunnel mode. > > MTI ACP encryption: dTLS or IPsec. IPsec is logical, but > talking to IOT folks it seems dTLS will be in every IOT > device that has any security, so maybe dTLS is better lowest > common denominator. > > C. Primary GRASP instance inside ACP > > This instance will be protected by ACP and be network wide, > eg: GRASP needs to forward hop-by-hop. > > 1. Main purpose for GRASP inside ACP for the ACP itself (everything > else is for future autonomic agents): > > Service-discovery of registrar. Eg: the already enrolled AN node > in A. acting as proxy for enrollment will learn IP-address of > registrar via GRASP. > > There are some open questions i have here as well, but lets see > if this is on the outset what we think it should be. > > Cheers > Toerless > > On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: >> On 11/11/2015 16:05, Michael Richardson wrote: >>> >>> I spent most of my 11h trip home on Monday catching trying to empty my = list >>> of drafts to read... I have a series of comments on the documents whic= h I'll >>> post as seperate threads. >>> >>> I read through: >>> - draft-ietf-anima-grasp-01 >>> - draft-ietf-anima-autonomic-control-plane-01 >>> - draft-behringer-anima-autonomic-addressing-02 >>> - draft-liu-anima-grasp-distribution-00 >>> - draft-ietf-anima-autonomic-control-plane-01 >>> - draft-behringer-anima-reference-model-04 >>> >>> Reading the drafts I get a profound sense of dis-unity... >>> It's about ACP vs GRASP, and how/where we do things. >> >> Can you try to explain where you see a disconnect? Because I don't. >> The ACP provides a secure private Internet for ANs to use as they >> wisk, and GRASP runs over the ACP to offer higher level messaging >> functions to the ANs. >> >> Right now all that GRASP seems to need from the ACP is a status bit >> saying "ACP is up" and a socket API. It might need to peek into the >> adjacency table, but I'm not even sure about that. >> >> True, this chases its own tail a bit if GRASP is used for initial discov= ery, >> and that does need to be tied down. >> >>> I think we need a virtual interim or something like that where we can t= alk >>> for a longer period of time in a smaller group. >> >> We certainly need to understand what's not fitting together. >> >> Brian >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > --_000_y990f9letlb0x30lg9j0rykk1447360642767emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We thought that it would be better this way around because:

Already enrolled device can be less attacked, because it will not reac= t to unsolicited messages.

Client device sitting in a non-an environment will not generate messag= es unnecessary in this environment, but just rspond.




Sent from my Samsung Captivate = Glide on AT&T

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Toerless,

I think that's about right. I would probably invert the logic
in stage 1 (an enrolled node responds to discovery multicast by
an unenrolled node) but that's a detail.

   Brian


On 12/11/2015 18:00, Toerless Eckert wrote:
> My quick summary of how i could imagine the connection:
>
> A. Unenrolled node:
>
> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN node= s:
>
>    instance of unsecure, unprotected L2-only GRASP.
>    Enrolled node periodically sends L2 IP multicast obj= ective
>    discovery multicast "AN-node-who-wants-to-get-e= nrolled"
>
>    AN nodes willing to enroll send unicast message back=
>
>    not sure if we want another unicast exchange round t= o prohibit
>    some DoS attacks from other nodes on the same LAN. >
>    TBD: any attributes to include at "app-level&qu= ot;, eg: SUDI or the
>    like, might help, not sure.
>
> 2. Bootstrap continues with an EST/TLS connection where enrolled
>    node acts as TLS proxy.
>
>    Not sure if there further cases for GRASP in the boo= tstrap process
>    or if everything we need would be within EST. We do = know that
>    we want specific details in the certificate assigned= . Not sure
>    enough about EST details yet.
>
> B. Enrolled Nodes creating ACP between each other.
>
> 1. GRASP (boring): same as A.1, except that the two nodes discovery >    that they are claming both to be enrolled into same = domain.
>
> 2. TLS (or dTLS ?) connection built between the two nodes.
>    GRASP inside TLS connection, also just single-hop ne= gotiating
>    ACP tunnel mode.
>
>    MTI ACP encryption: dTLS or IPsec. IPsec is logical,= but
>    talking to IOT folks it seems dTLS will be in every = IOT
>    device that has any security, so maybe dTLS is bette= r lowest
>    common denominator.
>
> C. Primary GRASP instance inside ACP
>
>    This instance will be protected by ACP and be networ= k wide,
>    eg: GRASP needs to forward hop-by-hop.
>
> 1. Main purpose for GRASP inside ACP for the ACP itself (everything >    else is for future autonomic agents):
>
>    Service-discovery of registrar. Eg: the already enro= lled AN node
>    in A. acting as proxy for enrollment will learn IP-a= ddress of
>    registrar via GRASP.
>
> There are some open questions i have here as well, but lets see
> if this is on the outset what we think it should be.
>
> Cheers
>     Toerless
>
> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote:=
>> On 11/11/2015 16:05, Michael Richardson wrote:
>>>
>>> I spent most of my 11h trip home on Monday catching trying to = empty my list
>>> of drafts to read...  I have a series of comments on the = documents which I'll
>>> post as seperate threads.
>>>
>>> I read through:
>>>   - draft-ietf-anima-grasp-01
>>>   - draft-ietf-anima-autonomic-control-plane-01
>>>   - draft-behringer-anima-autonomic-addressing-02 >>>   - draft-liu-anima-grasp-distribution-00
>>>   - draft-ietf-anima-autonomic-control-plane-01
>>>   - draft-behringer-anima-reference-model-04
>>>
>>> Reading the drafts I get a profound sense of dis-unity...
>>> It's about ACP vs GRASP, and how/where we do things.
>>
>> Can you try to explain where you see a disconnect? Because I don't= .
>> The ACP provides a secure private Internet for ANs to use as they<= br> >> wisk, and GRASP runs over the ACP to offer higher level messaging<= br> >> functions to the ANs.
>>
>> Right now all that GRASP seems to need from the ACP is a status bi= t
>> saying "ACP is up" and a socket API. It might need to pe= ek into the
>> adjacency table, but I'm not even sure about that.
>>
>> True, this chases its own tail a bit if GRASP is used for initial = discovery,
>> and that does need to be tied down.
>>
>>> I think we need a virtual interim or something like that where= we can talk
>>> for a longer period of time in a smaller group.
>>
>> We certainly need to understand what's not fitting together.
>>
>>     Brian
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/anima
>
--_000_y990f9letlb0x30lg9j0rykk1447360642767emailandroidcom_-- From nobody Thu Nov 12 13:15:23 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8B1B3646 for ; Thu, 12 Nov 2015 13:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, HTML_MESSAGE=0.001, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 gu4UrR4YckRx for ; Thu, 12 Nov 2015 13:15:18 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252141B3648 for ; Thu, 12 Nov 2015 13:15:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14088; q=dns/txt; s=iport; t=1447362916; x=1448572516; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=w9zLmOYHdoUnSqBSstkryHRCX1uGL5ZRCeFWBGpKxVs=; b=NpRAYNCA+zpn/Jk1iGEQ2yLF/XMvBwCkElFXdaNG1gYZM7yZMLaptkEi whCWNlTqZWsc4ji4SJ973AD2E2AZlBHoksCicjg3V9wj+WsGNBfZGUY0/ zPfil+IX2E5ScpnfmHMQKIs8Tv9s9lhnXdvYpYuEqQixmHocaJP/AIPVs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D2AQCtAEVW/5pdJa1egm5NU2++PgENgWUXAQmFbwKBPzgUAQEBAQEBAYEKhDUBAQQBAQEqQQYFEAIBCBgJJQ8SBgsOFwIEAQ0FiBkDEg26CYUYDYRiAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASLUoJTgjWEMQWGCwmQNAGLMYF1gVuHZYsyh1IBHwEBQoQEcgGFPAEBAQ X-IronPort-AV: E=Sophos;i="5.20,283,1444694400"; d="scan'208,217";a="207624708" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 12 Nov 2015 21:15:14 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tACLFEjE011157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 21:15:14 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 15:15:13 -0600 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 15:15:14 -0600 From: "Toerless Eckert (eckert)" To: "Joel M. Halpern" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3W3mGPukqMfEuJ1fz8RZrCFJ6WmiYAgAGgFACAAPLugP//r1fOgABti4D//5wLEA== Date: Thu, 12 Nov 2015 21:15:14 +0000 Message-ID: References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com> <5644E8A1.8090204@gmail.com> , <564500DB.8090506@joelhalpern.com> In-Reply-To: <564500DB.8090506@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_ev49hcpr5ddchrnlxpiev6i91447362886124emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Toerless Eckert \(eckert\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 21:15:21 -0000 --_000_ev49hcpr5ddchrnlxpiev6i91447362886124emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A registrar is the seed node Sent from my Samsung Captivate Glide on AT&T "Joel M. Halpern" wrote: I am missing something in the description. Initially, I assume, all nodes are unenrolled. If the only way to get enrolled is to receive a message from an enrolled node, then it seems that we simply stay in the state with all nodes unenrolled. So in either case, don't we need some way for two unenrolled nodes to decide collectively taht they should declare themselves enrolled? Yours, Joel On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote: > We thought that it would be better this way around because: > > Already enrolled device can be less attacked, because it will not react > to unsolicited messages. > > Client device sitting in a non-an environment will not generate messages > unnecessary in this environment, but just rspond. > > > > > Sent from my Samsung Captivate Glide on AT&T > > Brian E Carpenter wrote: > Toerless, > > I think that's about right. I would probably invert the logic > in stage 1 (an enrolled node responds to discovery multicast by > an unenrolled node) but that's a detail. > > Brian > > > On 12/11/2015 18:00, Toerless Eckert wrote: >> My quick summary of how i could imagine the connection: >> >> A. Unenrolled node: >> >> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nodes: >> >> instance of unsecure, unprotected L2-only GRASP. >> Enrolled node periodically sends L2 IP multicast objective >> discovery multicast "AN-node-who-wants-to-get-enrolled" >> >> AN nodes willing to enroll send unicast message back >> >> not sure if we want another unicast exchange round to prohibit >> some DoS attacks from other nodes on the same LAN. >> >> TBD: any attributes to include at "app-level", eg: SUDI or the >> like, might help, not sure. >> >> 2. Bootstrap continues with an EST/TLS connection where enrolled >> node acts as TLS proxy. >> >> Not sure if there further cases for GRASP in the bootstrap process >> or if everything we need would be within EST. We do know that >> we want specific details in the certificate assigned. Not sure >> enough about EST details yet. >> >> B. Enrolled Nodes creating ACP between each other. >> >> 1. GRASP (boring): same as A.1, except that the two nodes discovery >> that they are claming both to be enrolled into same domain. >> >> 2. TLS (or dTLS ?) connection built between the two nodes. >> GRASP inside TLS connection, also just single-hop negotiating >> ACP tunnel mode. >> >> MTI ACP encryption: dTLS or IPsec. IPsec is logical, but >> talking to IOT folks it seems dTLS will be in every IOT >> device that has any security, so maybe dTLS is better lowest >> common denominator. >> >> C. Primary GRASP instance inside ACP >> >> This instance will be protected by ACP and be network wide, >> eg: GRASP needs to forward hop-by-hop. >> >> 1. Main purpose for GRASP inside ACP for the ACP itself (everything >> else is for future autonomic agents): >> >> Service-discovery of registrar. Eg: the already enrolled AN node >> in A. acting as proxy for enrollment will learn IP-address of >> registrar via GRASP. >> >> There are some open questions i have here as well, but lets see >> if this is on the outset what we think it should be. >> >> Cheers >> Toerless >> >> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: >>> On 11/11/2015 16:05, Michael Richardson wrote: >>>> >>>> I spent most of my 11h trip home on Monday catching trying to empty my= list >>>> of drafts to read... I have a series of comments on the documents whi= ch I'll >>>> post as seperate threads. >>>> >>>> I read through: >>>> - draft-ietf-anima-grasp-01 >>>> - draft-ietf-anima-autonomic-control-plane-01 >>>> - draft-behringer-anima-autonomic-addressing-02 >>>> - draft-liu-anima-grasp-distribution-00 >>>> - draft-ietf-anima-autonomic-control-plane-01 >>>> - draft-behringer-anima-reference-model-04 >>>> >>>> Reading the drafts I get a profound sense of dis-unity... >>>> It's about ACP vs GRASP, and how/where we do things. >>> >>> Can you try to explain where you see a disconnect? Because I don't. >>> The ACP provides a secure private Internet for ANs to use as they >>> wisk, and GRASP runs over the ACP to offer higher level messaging >>> functions to the ANs. >>> >>> Right now all that GRASP seems to need from the ACP is a status bit >>> saying "ACP is up" and a socket API. It might need to peek into the >>> adjacency table, but I'm not even sure about that. >>> >>> True, this chases its own tail a bit if GRASP is used for initial disco= very, >>> and that does need to be tied down. >>> >>>> I think we need a virtual interim or something like that where we can = talk >>>> for a longer period of time in a smaller group. >>> >>> We certainly need to understand what's not fitting together. >>> >>> Brian >>> >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>>https://www.ietf.org/mailman/listinfo/anima >> > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --_000_ev49hcpr5ddchrnlxpiev6i91447362886124emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
A registrar is the seed node




Sent from my Samsung Captivate = Glide on AT&T

"Joel M. Halpern" <jmh@joelhalpern.com> wrote:
I am missing something in the description.

Initially, I assume, all nodes are unenrolled.
If the only way to get enrolled is to receive a message from an enrolled node, then it seems that we simply stay in the state with all nodes
unenrolled.
So in either case, don't we need some way for two unenrolled nodes to
decide collectively taht they should declare themselves enrolled?

Yours,
Joel

On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote:
> We thought that it would be better this way around because:
>
> Already enrolled device can be less attacked, because it will not reac= t
> to unsolicited messages.
>
> Client device sitting in a non-an environment will not generate messag= es
> unnecessary in this environment, but just rspond.
>
>
>
>
> Sent from my Samsung Captivate Glide on AT&T
>
> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> Toerless,
>
> I think that's about right. I would probably invert the logic
> in stage 1 (an enrolled node responds to discovery multicast by
> an unenrolled node) but that's a detail.
>
>     Brian
>
>
> On 12/11/2015 18:00, Toerless Eckert wrote:
>> My quick summary of how i could imagine the connection:
>>
>> A. Unenrolled node:
>>
>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN = nodes:
>>
>>    instance of unsecure, unprotected L2-only GRASP.=
>>    Enrolled node periodically sends L2 IP multicast= objective
>>    discovery multicast "AN-node-who-wants-to-g= et-enrolled"
>>
>>    AN nodes willing to enroll send unicast message = back
>>
>>    not sure if we want another unicast exchange rou= nd to prohibit
>>    some DoS attacks from other nodes on the same LA= N.
>>
>>    TBD: any attributes to include at "app-leve= l", eg: SUDI or the
>>    like, might help, not sure.
>>
>> 2. Bootstrap continues with an EST/TLS connection where enrolled >>    node acts as TLS proxy.
>>
>>    Not sure if there further cases for GRASP in the= bootstrap process
>>    or if everything we need would be within EST. We= do know that
>>    we want specific details in the certificate assi= gned. Not sure
>>    enough about EST details yet.
>>
>> B. Enrolled Nodes creating ACP between each other.
>>
>> 1. GRASP (boring): same as A.1, except that the two nodes discover= y
>>    that they are claming both to be enrolled into s= ame domain.
>>
>> 2. TLS (or dTLS ?) connection built between the two nodes.
>>    GRASP inside TLS connection, also just single-ho= p negotiating
>>    ACP tunnel mode.
>>
>>    MTI ACP encryption: dTLS or IPsec. IPsec is logi= cal, but
>>    talking to IOT folks it seems dTLS will be in ev= ery IOT
>>    device that has any security, so maybe dTLS is b= etter lowest
>>    common denominator.
>>
>> C. Primary GRASP instance inside ACP
>>
>>    This instance will be protected by ACP and be ne= twork wide,
>>    eg: GRASP needs to forward hop-by-hop.
>>
>> 1. Main purpose for GRASP inside ACP for the ACP itself (everythin= g
>>    else is for future autonomic agents):
>>
>>    Service-discovery of registrar. Eg: the already = enrolled AN node
>>    in A. acting as proxy for enrollment will learn = IP-address of
>>    registrar via GRASP.
>>
>> There are some open questions i have here as well, but lets see >> if this is on the outset what we think it should be.
>>
>> Cheers
>>     Toerless
>>
>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wr= ote:
>>> On 11/11/2015 16:05, Michael Richardson wrote:
>>>>
>>>> I spent most of my 11h trip home on Monday catching trying= to empty my list
>>>> of drafts to read...  I have a series of comments on = the documents which I'll
>>>> post as seperate threads.
>>>>
>>>> I read through:
>>>>   - draft-ietf-anima-grasp-01
>>>>   - draft-ietf-anima-autonomic-control-plane-01<= br> >>>>   - draft-behringer-anima-autonomic-addressing-0= 2
>>>>   - draft-liu-anima-grasp-distribution-00
>>>>   - draft-ietf-anima-autonomic-control-plane-01<= br> >>>>   - draft-behringer-anima-reference-model-04
>>>>
>>>> Reading the drafts I get a profound sense of dis-unity...<= br> >>>> It's about ACP vs GRASP, and how/where we do things.
>>>
>>> Can you try to explain where you see a disconnect? Because I d= on't.
>>> The ACP provides a secure private Internet for ANs to use as t= hey
>>> wisk, and GRASP runs over the ACP to offer higher level messag= ing
>>> functions to the ANs.
>>>
>>> Right now all that GRASP seems to need from the ACP is a statu= s bit
>>> saying "ACP is up" and a socket API. It might need t= o peek into the
>>> adjacency table, but I'm not even sure about that.
>>>
>>> True, this chases its own tail a bit if GRASP is used for init= ial discovery,
>>> and that does need to be tied down.
>>>
>>>> I think we need a virtual interim or something like that w= here we can talk
>>>> for a longer period of time in a smaller group.
>>>
>>> We certainly need to understand what's not fitting together. >>>
>>>     Brian
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> Anima@ietf.org
>>>https:/= /www.ietf.org/mailman/listinfo/anima
>>
>
>
> _______________________________________________
> Anima mailing list
> Anima@ietf.org
> https://www.ie= tf.org/mailman/listinfo/anima
>
 --_000_ev49hcpr5ddchrnlxpiev6i91447362886124emailandroidcom_-- From nobody Thu Nov 12 13:33:15 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4D11B36DC for ; Thu, 12 Nov 2015 13:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.653 X-Spam-Level: X-Spam-Status: No, score=-1.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, HTML_MESSAGE=0.001, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 dgmDymhRyIcP for ; Thu, 12 Nov 2015 13:33:11 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53DED1B36CC for ; Thu, 12 Nov 2015 13:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16327; q=dns/txt; s=iport; t=1447363991; x=1448573591; h=from:to:cc:subject:date:message-id:references: in-reply-to:reply-to:mime-version; bh=8mdfd/kccuznTwtj1klPtcCh0JSTJiTOITdHQ6DfCY4=; b=FrLFYnHiqb8ytyb3sXxOOEqW/ze4AaBwb/eLRkogIZ66OnQvTmK9WFKR DYbvgCvhxFXPeR9R7Z/m0o9xDQOtQHPaoDGw7/53p270NMnzkO/oO4xV1 zPmNrorRjpm0IB0AYNnrchNBtTd39bsMA6Kd5LxHDPnM1d12+Q5cj8X11 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D3AQDxBEVW/5ldJa1egm5NU2+FOLkGAQ2BZRcBCYQYgVcCgT84FAEBAQEBAQGBCoQ1AQEEAQEBKkEGBRACAQgYCSUPEgYLDhcCBAENBYgZAxINuX2FFw2EYgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEi1KCU4I1hDEFhgsJkDQBizGBdYFbh2WLModSAR8BAUKBYDEdgVZyAYU8AQEB X-IronPort-AV: E=Sophos;i="5.20,283,1444694400"; d="scan'208,217";a="207772387" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 12 Nov 2015 21:33:10 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tACLX98g017014 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Nov 2015 21:33:10 GMT Received: from xch-rcd-003.cisco.com (173.37.102.13) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 12 Nov 2015 15:33:09 -0600 Received: from xch-rcd-003.cisco.com ([173.37.102.13]) by XCH-RCD-003.cisco.com ([173.37.102.13]) with mapi id 15.00.1104.000; Thu, 12 Nov 2015 15:33:09 -0600 From: "Toerless Eckert (eckert)" To: "Joel M. Halpern" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3W3mGPukqMfEuJ1fz8RZrCFJ6WmiYAgAGgFACAAPLugP//r1fOgABti4D//5wLEIAAZ3YA//+djcw= Date: Thu, 12 Nov 2015 21:33:09 +0000 Message-ID: References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com> <5644E8A1.8090204@gmail.com> <564500DB.8090506@joelhalpern.com> , <564503CC.8000705@joelhalpern.com> In-Reply-To: <564503CC.8000705@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_sv1xlbyc61wim6vot6ssk50q1447363923764emailandroidcom_" MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Toerless Eckert \(eckert\)" List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Nov 2015 21:33:14 -0000 --_000_sv1xlbyc61wim6vot6ssk50q1447363923764emailandroidcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the reference model is not enlightening enough about this, id recommend = we first fix that doc up to capture this. Sent from my Samsung Captivate Glide on AT&T "Joel M. Halpern" wrote: With the behaviors fragmented across the GRASP, ACP, and Bootstrap documents, this is veyr hard to determine. In particular, as far as I can tell the current bootstrap document does not have Proxies advertising. I missed where it said that a proxy must be enrolled before it starts forwarding. And the registrar is described as responding to requests. Yours, Joel On 11/12/15 4:15 PM, Toerless Eckert (eckert) wrote: > A registrar is the seed node > > > > > Sent from my Samsung Captivate Glide on AT&T > > "Joel M. Halpern" wrote: > I am missing something in the description. > > Initially, I assume, all nodes are unenrolled. > If the only way to get enrolled is to receive a message from an enrolled > node, then it seems that we simply stay in the state with all nodes > unenrolled. > So in either case, don't we need some way for two unenrolled nodes to > decide collectively taht they should declare themselves enrolled? > > Yours, > Joel > > On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote: >> We thought that it would be better this way around because: >> >> Already enrolled device can be less attacked, because it will not react >> to unsolicited messages. >> >> Client device sitting in a non-an environment will not generate messages >> unnecessary in this environment, but just rspond. >> >> >> >> >> Sent from my Samsung Captivate Glide on AT&T >> >> Brian E Carpenter wrote: >> Toerless, >> >> I think that's about right. I would probably invert the logic >> in stage 1 (an enrolled node responds to discovery multicast by >> an unenrolled node) but that's a detail. >> >> Brian >> >> >> On 12/11/2015 18:00, Toerless Eckert wrote: >>> My quick summary of how i could imagine the connection: >>> >>> A. Unenrolled node: >>> >>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nodes= : >>> >>> instance of unsecure, unprotected L2-only GRASP. >>> Enrolled node periodically sends L2 IP multicast objective >>> discovery multicast "AN-node-who-wants-to-get-enrolled" >>> >>> AN nodes willing to enroll send unicast message back >>> >>> not sure if we want another unicast exchange round to prohibit >>> some DoS attacks from other nodes on the same LAN. >>> >>> TBD: any attributes to include at "app-level", eg: SUDI or the >>> like, might help, not sure. >>> >>> 2. Bootstrap continues with an EST/TLS connection where enrolled >>> node acts as TLS proxy. >>> >>> Not sure if there further cases for GRASP in the bootstrap process >>> or if everything we need would be within EST. We do know that >>> we want specific details in the certificate assigned. Not sure >>> enough about EST details yet. >>> >>> B. Enrolled Nodes creating ACP between each other. >>> >>> 1. GRASP (boring): same as A.1, except that the two nodes discovery >>> that they are claming both to be enrolled into same domain. >>> >>> 2. TLS (or dTLS ?) connection built between the two nodes. >>> GRASP inside TLS connection, also just single-hop negotiating >>> ACP tunnel mode. >>> >>> MTI ACP encryption: dTLS or IPsec. IPsec is logical, but >>> talking to IOT folks it seems dTLS will be in every IOT >>> device that has any security, so maybe dTLS is better lowest >>> common denominator. >>> >>> C. Primary GRASP instance inside ACP >>> >>> This instance will be protected by ACP and be network wide, >>> eg: GRASP needs to forward hop-by-hop. >>> >>> 1. Main purpose for GRASP inside ACP for the ACP itself (everything >>> else is for future autonomic agents): >>> >>> Service-discovery of registrar. Eg: the already enrolled AN node >>> in A. acting as proxy for enrollment will learn IP-address of >>> registrar via GRASP. >>> >>> There are some open questions i have here as well, but lets see >>> if this is on the outset what we think it should be. >>> >>> Cheers >>> Toerless >>> >>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: >>>> On 11/11/2015 16:05, Michael Richardson wrote: >>>>> >>>>> I spent most of my 11h trip home on Monday catching trying to empty m= y list >>>>> of drafts to read... I have a series of comments on the documents wh= ich I'll >>>>> post as seperate threads. >>>>> >>>>> I read through: >>>>> - draft-ietf-anima-grasp-01 >>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>> - draft-behringer-anima-autonomic-addressing-02 >>>>> - draft-liu-anima-grasp-distribution-00 >>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>> - draft-behringer-anima-reference-model-04 >>>>> >>>>> Reading the drafts I get a profound sense of dis-unity... >>>>> It's about ACP vs GRASP, and how/where we do things. >>>> >>>> Can you try to explain where you see a disconnect? Because I don't. >>>> The ACP provides a secure private Internet for ANs to use as they >>>> wisk, and GRASP runs over the ACP to offer higher level messaging >>>> functions to the ANs. >>>> >>>> Right now all that GRASP seems to need from the ACP is a status bit >>>> saying "ACP is up" and a socket API. It might need to peek into the >>>> adjacency table, but I'm not even sure about that. >>>> >>>> True, this chases its own tail a bit if GRASP is used for initial disc= overy, >>>> and that does need to be tied down. >>>> >>>>> I think we need a virtual interim or something like that where we can= talk >>>>> for a longer period of time in a smaller group. >>>> >>>> We certainly need to understand what's not fitting together. >>>> >>>> Brian >>>> >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>>https://www.ietf.org/mailman/listinfo/anima >>> >> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >>https://www.ietf.org/mailman/listinfo/anima >> --_000_sv1xlbyc61wim6vot6ssk50q1447363923764emailandroidcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If the reference model is not enlightening enough about this, id recom= mend we first fix that doc up to capture this.




Sent from my Samsung Captivate = Glide on AT&T

"Joel M. Halpern" <jmh@joelhalpern.com> wrote:
With the behaviors fragmented across the GRASP, AC= P, and Bootstrap
documents, this is veyr hard to determine.
In particular, as far as I can tell the current bootstrap document does not have Proxies advertising.  I missed where it said that a proxy mus= t
be enrolled before it starts forwarding.  And the registrar is describ= ed
as responding to requests.

Yours,
Joel

On 11/12/15 4:15 PM, Toerless Eckert (eckert) wrote:
> A registrar is the seed node
>
>
>
>
> Sent from my Samsung Captivate Glide on AT&T
>
> "Joel M. Halpern" <jmh@joelhalpern.com> wrote:
> I am missing something in the description.
>
> Initially, I assume, all nodes are unenrolled.
> If the only way to get enrolled is to receive a message from an enroll= ed
> node, then it seems that we simply stay in the state with all nodes > unenrolled.
> So in either case, don't we need some way for two unenrolled nodes to<= br> > decide collectively taht they should declare themselves enrolled?
>
> Yours,
> Joel
>
> On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote:
>> We thought that it would be better this way around because:
>>
>> Already enrolled device can be less attacked, because it will not = react
>> to unsolicited messages.
>>
>> Client device sitting in a non-an environment will not generate me= ssages
>> unnecessary in this environment, but just rspond.
>>
>>
>>
>>
>> Sent from my Samsung Captivate Glide on AT&T
>>
>> Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>> Toerless,
>>
>> I think that's about right. I would probably invert the logic
>> in stage 1 (an enrolled node responds to discovery multicast by >> an unenrolled node) but that's a detail.
>>
>>     Brian
>>
>>
>> On 12/11/2015 18:00, Toerless Eckert wrote:
>>> My quick summary of how i could imagine the connection:
>>>
>>> A. Unenrolled node:
>>>
>>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled)= AN nodes:
>>>
>>>    instance of unsecure, unprotected L2-only GR= ASP.
>>>    Enrolled node periodically sends L2 IP multi= cast objective
>>>    discovery multicast "AN-node-who-wants-= to-get-enrolled"
>>>
>>>    AN nodes willing to enroll send unicast mess= age back
>>>
>>>    not sure if we want another unicast exchange= round to prohibit
>>>    some DoS attacks from other nodes on the sam= e LAN.
>>>
>>>    TBD: any attributes to include at "app-= level", eg: SUDI or the
>>>    like, might help, not sure.
>>>
>>> 2. Bootstrap continues with an EST/TLS connection where enroll= ed
>>>    node acts as TLS proxy.
>>>
>>>    Not sure if there further cases for GRASP in= the bootstrap process
>>>    or if everything we need would be within EST= . We do know that
>>>    we want specific details in the certificate = assigned. Not sure
>>>    enough about EST details yet.
>>>
>>> B. Enrolled Nodes creating ACP between each other.
>>>
>>> 1. GRASP (boring): same as A.1, except that the two nodes disc= overy
>>>    that they are claming both to be enrolled in= to same domain.
>>>
>>> 2. TLS (or dTLS ?) connection built between the two nodes.
>>>    GRASP inside TLS connection, also just singl= e-hop negotiating
>>>    ACP tunnel mode.
>>>
>>>    MTI ACP encryption: dTLS or IPsec. IPsec is = logical, but
>>>    talking to IOT folks it seems dTLS will be i= n every IOT
>>>    device that has any security, so maybe dTLS = is better lowest
>>>    common denominator.
>>>
>>> C. Primary GRASP instance inside ACP
>>>
>>>    This instance will be protected by ACP and b= e network wide,
>>>    eg: GRASP needs to forward hop-by-hop.
>>>
>>> 1. Main purpose for GRASP inside ACP for the ACP itself (every= thing
>>>    else is for future autonomic agents):
>>>
>>>    Service-discovery of registrar. Eg: the alre= ady enrolled AN node
>>>    in A. acting as proxy for enrollment will le= arn IP-address of
>>>    registrar via GRASP.
>>>
>>> There are some open questions i have here as well, but lets se= e
>>> if this is on the outset what we think it should be.
>>>
>>> Cheers
>>>     Toerless
>>>
>>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpente= r wrote:
>>>> On 11/11/2015 16:05, Michael Richardson wrote:
>>>>>
>>>>> I spent most of my 11h trip home on Monday catching tr= ying to empty my list
>>>>> of drafts to read...  I have a series of comments= on the documents which I'll
>>>>> post as seperate threads.
>>>>>
>>>>> I read through:
>>>>>   - draft-ietf-anima-grasp-01
>>>>>   - draft-ietf-anima-autonomic-control-plane= -01
>>>>>   - draft-behringer-anima-autonomic-addressi= ng-02
>>>>>   - draft-liu-anima-grasp-distribution-00 >>>>>   - draft-ietf-anima-autonomic-control-plane= -01
>>>>>   - draft-behringer-anima-reference-model-04=
>>>>>
>>>>> Reading the drafts I get a profound sense of dis-unity= ...
>>>>> It's about ACP vs GRASP, and how/where we do things. >>>>
>>>> Can you try to explain where you see a disconnect? Because= I don't.
>>>> The ACP provides a secure private Internet for ANs to use = as they
>>>> wisk, and GRASP runs over the ACP to offer higher level me= ssaging
>>>> functions to the ANs.
>>>>
>>>> Right now all that GRASP seems to need from the ACP is a s= tatus bit
>>>> saying "ACP is up" and a socket API. It might ne= ed to peek into the
>>>> adjacency table, but I'm not even sure about that.
>>>>
>>>> True, this chases its own tail a bit if GRASP is used for = initial discovery,
>>>> and that does need to be tied down.
>>>>
>>>>> I think we need a virtual interim or something like th= at where we can talk
>>>>> for a longer period of time in a smaller group.
>>>>
>>>> We certainly need to understand what's not fitting togethe= r.
>>>>
>>>>     Brian
>>>>
>>>> _______________________________________________
>>>> Anima mailing list
>>>> Anima@ietf.org
>>>>htt= ps://www.ietf.org/mailman/listinfo/anima
>>>
>>
>>
>> _______________________________________________
>> Anima mailing list
>> Anima@ietf.org
>>https://www= .ietf.org/mailman/listinfo/anima
>>
 --_000_sv1xlbyc61wim6vot6ssk50q1447363923764emailandroidcom_-- From nobody Fri Nov 13 00:08:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0471A037F for ; Fri, 13 Nov 2015 00:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 3t2P9dZKcCQ7 for ; Fri, 13 Nov 2015 00:08:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAAE41A037E for ; Fri, 13 Nov 2015 00:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8306; q=dns/txt; s=iport; t=1447402129; x=1448611729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mzG4SJLgco/HDeGDA+mB6vnZKZP7LwlRNzb5Vy0KzUQ=; b=KQeVxS35wePGahxmxczmkn62rVUlz9oN9kvT+iANdavN011BBwWWEHHJ GgleOyt5lpjQ0HIYoEW1fQJjG8thwPgLZSohRJ9oG+opDd2m6WxKqYOku SL2mGhpWrOF7ysPP1PiP6Uz7G1glfJm51P/hJ3wWitZPbX75rjTyrIAlT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgC7mUVW/4wNJK1egztTbwa+PAENg?= =?us-ascii?q?WUXCoVvAoE9OBQBAQEBAQEBgQqENAEBAQQBAQE3NAYFDAQCAQgRBAEBAR4JByE?= =?us-ascii?q?GCxQJCAIEAQ0FCIgRAxINvXANhGQBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUh?= =?us-ascii?q?H6CU4ZmBYYLCZA0AYsxgW6BYodlizKHUgEfAQFCghEdgVZyAYQ1gQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,286,1444694400"; d="scan'208";a="46482605" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 13 Nov 2015 08:08:48 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tAD88m0f028571 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 08:08:48 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 02:08:48 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 02:08:48 -0600 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , "Toerless Eckert (eckert)" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WrFabeMQ0DUKKD3Ewsi4fEJ6WmiYAgAGgFACAAPLugIAAE+yAgAAI9oCAAAChAIAAAuAAgAACIYCAAAHgAIAASRuw Date: Fri, 13 Nov 2015 08:08:48 +0000 Message-ID: References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com> <5644E8A1.8090204@gmail.com> <564500DB.8090506@joelhalpern.com> <564503CC.8000705@joelhalpern.com> <56450728.5090404@joelhalpern.com> In-Reply-To: <56450728.5090404@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 08:08:51 -0000 Yes we need to be clearer in both the reference draft and the bootstrap dra= ft that a new node is passive, and waits to be invited to join a domain.=20 The rest is actually there I think. Section 5 of the reference model says:= =20 If the node has bootstrapped into a domain (i.e., has a domain certificate), it will act as a proxy for neighboring nodes that need to be bootstrapped. Maybe I need to add "only if ...", and be more explicit about the new node = NOT being active.=20 The rest of the logic is there, I think, however the reference draft doesn'= t specify protocols (yet). Do we want to include them now?=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 12 November 2015 22:40 > To: Toerless Eckert (eckert) ; Brian E Carpenter > > Cc: Michael Richardson ; anima@ietf.org > Subject: Re: [Anima] comments on current drafts >=20 > No, the reference model document is not enlightening about this. >=20 > And if we are going to treat the reference model as reflecting WG agreeme= nt > (a desirable state) shouldn't we adopt the document as a working group > document instead of leaving it as an individual draft? >=20 > Yours, > Joel >=20 > On 11/12/15 4:33 PM, Toerless Eckert (eckert) wrote: > > If the reference model is not enlightening enough about this, id > > recommend we first fix that doc up to capture this. > > > > > > > > > > Sent from my Samsung Captivate Glide on AT&T > > > > "Joel M. Halpern" wrote: > > With the behaviors fragmented across the GRASP, ACP, and Bootstrap > > documents, this is veyr hard to determine. > > In particular, as far as I can tell the current bootstrap document > > does not have Proxies advertising. I missed where it said that a > > proxy must be enrolled before it starts forwarding. And the registrar > > is described as responding to requests. > > > > Yours, > > Joel > > > > On 11/12/15 4:15 PM, Toerless Eckert (eckert) wrote: > >> A registrar is the seed node > >> > >> > >> > >> > >> Sent from my Samsung Captivate Glide on AT&T > >> > >> "Joel M. Halpern" wrote: > >> I am missing something in the description. > >> > >> Initially, I assume, all nodes are unenrolled. > >> If the only way to get enrolled is to receive a message from an > >> enrolled node, then it seems that we simply stay in the state with > >> all nodes unenrolled. > >> So in either case, don't we need some way for two unenrolled nodes to > >> decide collectively taht they should declare themselves enrolled? > >> > >> Yours, > >> Joel > >> > >> On 11/12/15 3:40 PM, Toerless Eckert (eckert) wrote: > >>> We thought that it would be better this way around because: > >>> > >>> Already enrolled device can be less attacked, because it will not > >>> react to unsolicited messages. > >>> > >>> Client device sitting in a non-an environment will not generate > >>> messages unnecessary in this environment, but just rspond. > >>> > >>> > >>> > >>> > >>> Sent from my Samsung Captivate Glide on AT&T > >>> > >>> Brian E Carpenter wrote: > >>> Toerless, > >>> > >>> I think that's about right. I would probably invert the logic in > >>> stage 1 (an enrolled node responds to discovery multicast by an > >>> unenrolled node) but that's a detail. > >>> > >>> Brian > >>> > >>> > >>> On 12/11/2015 18:00, Toerless Eckert wrote: > >>>> My quick summary of how i could imagine the connection: > >>>> > >>>> A. Unenrolled node: > >>>> > >>>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN > nodes: > >>>> > >>>> instance of unsecure, unprotected L2-only GRASP. > >>>> Enrolled node periodically sends L2 IP multicast objective > >>>> discovery multicast "AN-node-who-wants-to-get-enrolled" > >>>> > >>>> AN nodes willing to enroll send unicast message back > >>>> > >>>> not sure if we want another unicast exchange round to prohibit > >>>> some DoS attacks from other nodes on the same LAN. > >>>> > >>>> TBD: any attributes to include at "app-level", eg: SUDI or the > >>>> like, might help, not sure. > >>>> > >>>> 2. Bootstrap continues with an EST/TLS connection where enrolled > >>>> node acts as TLS proxy. > >>>> > >>>> Not sure if there further cases for GRASP in the bootstrap proces= s > >>>> or if everything we need would be within EST. We do know that > >>>> we want specific details in the certificate assigned. Not sure > >>>> enough about EST details yet. > >>>> > >>>> B. Enrolled Nodes creating ACP between each other. > >>>> > >>>> 1. GRASP (boring): same as A.1, except that the two nodes discovery > >>>> that they are claming both to be enrolled into same domain. > >>>> > >>>> 2. TLS (or dTLS ?) connection built between the two nodes. > >>>> GRASP inside TLS connection, also just single-hop negotiating > >>>> ACP tunnel mode. > >>>> > >>>> MTI ACP encryption: dTLS or IPsec. IPsec is logical, but > >>>> talking to IOT folks it seems dTLS will be in every IOT > >>>> device that has any security, so maybe dTLS is better lowest > >>>> common denominator. > >>>> > >>>> C. Primary GRASP instance inside ACP > >>>> > >>>> This instance will be protected by ACP and be network wide, > >>>> eg: GRASP needs to forward hop-by-hop. > >>>> > >>>> 1. Main purpose for GRASP inside ACP for the ACP itself (everything > >>>> else is for future autonomic agents): > >>>> > >>>> Service-discovery of registrar. Eg: the already enrolled AN node > >>>> in A. acting as proxy for enrollment will learn IP-address of > >>>> registrar via GRASP. > >>>> > >>>> There are some open questions i have here as well, but lets see if > >>>> this is on the outset what we think it should be. > >>>> > >>>> Cheers > >>>> Toerless > >>>> > >>>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: > >>>>> On 11/11/2015 16:05, Michael Richardson wrote: > >>>>>> > >>>>>> I spent most of my 11h trip home on Monday catching trying to > >>>>>> empty my list of drafts to read... I have a series of comments > >>>>>> on the documents which I'll post as seperate threads. > >>>>>> > >>>>>> I read through: > >>>>>> - draft-ietf-anima-grasp-01 > >>>>>> - draft-ietf-anima-autonomic-control-plane-01 > >>>>>> - draft-behringer-anima-autonomic-addressing-02 > >>>>>> - draft-liu-anima-grasp-distribution-00 > >>>>>> - draft-ietf-anima-autonomic-control-plane-01 > >>>>>> - draft-behringer-anima-reference-model-04 > >>>>>> > >>>>>> Reading the drafts I get a profound sense of dis-unity... > >>>>>> It's about ACP vs GRASP, and how/where we do things. > >>>>> > >>>>> Can you try to explain where you see a disconnect? Because I don't. > >>>>> The ACP provides a secure private Internet for ANs to use as they > >>>>> wisk, and GRASP runs over the ACP to offer higher level messaging > >>>>> functions to the ANs. > >>>>> > >>>>> Right now all that GRASP seems to need from the ACP is a status > >>>>> bit saying "ACP is up" and a socket API. It might need to peek > >>>>> into the adjacency table, but I'm not even sure about that. > >>>>> > >>>>> True, this chases its own tail a bit if GRASP is used for initial > >>>>> discovery, and that does need to be tied down. > >>>>> > >>>>>> I think we need a virtual interim or something like that where we > >>>>>> can talk for a longer period of time in a smaller group. > >>>>> > >>>>> We certainly need to understand what's not fitting together. > >>>>> > >>>>> Brian > >>>>> > >>>>> _______________________________________________ > >>>>> Anima mailing list > >>>>> Anima@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/anima > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>>https://www.ietf.org/mailman/listinfo/anima > >>> >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Nov 13 00:23:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67A1A1A6A for ; Fri, 13 Nov 2015 00:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 2J4bXqy3FPoq for ; Fri, 13 Nov 2015 00:23:27 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64FF1A1A8D for ; Fri, 13 Nov 2015 00:22:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7599; q=dns/txt; s=iport; t=1447402954; x=1448612554; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7RvAb7JDOgdyIZSWMflFDvgEFB6ICOOB8WzbNIbSgc8=; b=KLvdXyAd/zJRPFl3Ws3nUiddyCNdXJbKpU8T7GdZFXV0ahyE1sT6FsVD R50CKsxAs0q930+y9wMjSgp6gJUl0NkGlXZ2TNzOsgWykW1O/RmOKxFjO CbG5fgUl2GiWbGqQdCogXdnA4MVyRM2CiiZ4fGtouvyAw2RlmYCfOqbSH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApAgCJnUVW/4MNJK1egztTbwa+PAENgWUXCoVvAoE9OBQBAQEBAQEBgQqENAEBAQMBAQEBNzQGBQUHBAIBCBEEAQEBHgkHIQYLFAkIAgQBDQUIiBEDCggNvWsNhGQBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6CU4FvhHcFhgsJkDQBizGBboFih2WLModSAR8BAUKEBHIBhDWBBwEBAQ X-IronPort-AV: E=Sophos;i="5.20,286,1444694400"; d="scan'208";a="207917452" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 13 Nov 2015 08:22:23 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tAD8MNxR007151 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 08:22:23 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 02:22:22 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 02:22:23 -0600 From: "Michael Behringer (mbehring)" To: "Joel M. Halpern" , Brian E Carpenter , "Toerless Eckert (eckert)" Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WrFabeMQ0DUKKD3Ewsi4fEJ6WmiYAgAGgFACAAPLugIAAE+yAgABFggCAAANJgIAAE1hw Date: Fri, 13 Nov 2015 08:22:22 +0000 Message-ID: <10cc6f4e010147f7ab21c1e6404bf773@XCH-RCD-006.cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com> <5644E8A1.8090204@gmail.com> <564533A6.5000508@gmail.com> <56453667.308@joelhalpern.com> In-Reply-To: <56453667.308@joelhalpern.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 08:23:29 -0000 > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: 13 November 2015 02:01 > To: Brian E Carpenter ; Toerless Eckert > (eckert) > Cc: Michael Richardson ; anima@ietf.org > Subject: Re: [Anima] comments on current drafts >=20 > This seems to require that all devices supporting the enrollment process, > once they are enrolled, must emit a steady, if somewhat low rate, stream = of > advertisements so that new non-enrolled devices on the net will see such > advertisements. >=20 > That seems unfortunate. Why?=20 If we're talking "autonomic", i.e., self-managing, there is no other way. I= f a network is really not centrally controlled (where someone explicitly te= lls the network where things have to happen), then network elements need to= keep their eyes open on what's happening around them. But this is generally true, also for enrolled devices in a fully establishe= d domain.=20 We shouldn't distinguish between the discovery protocol for an un-enrolled = device and one for enrolled devices. An enrolled autonomic node runs period= ic, link local discovery. Every autonomic node (enrolled or not) listens. T= his is ONE protocol. The result of this feeds the adjacency table, and then= , based on my state and my neighbor's state, different things will happen. = This is what section 5 of the reference draft aims to clarify.=20 I actually think apart from the fact that a new node is passive only, and a= n enrolled node actively sends discovery packets (see my previous message),= all else is there. Would love specific feedback on section 5.=20 Michael > Yours, > Joel >=20 > On 11/12/15 7:49 PM, Brian E Carpenter wrote: > > On 13/11/2015 09:40, Toerless Eckert (eckert) wrote: > >> We thought that it would be better this way around because: > >> > >> Already enrolled device can be less attacked, because it will not reac= t to > unsolicited messages. > >> > >> Client device sitting in a non-an environment will not generate messag= es > unnecessary in this environment, but just rspond. > > > > Well, yes, it will have to be a server in fact, listening for incoming > > discovery multicasts, but that's OK: all GRASP nodes are both clients > > and servers. Then once it starts the enrollment process, it stops > > listening for that particular type of discovery. > > > > Not a problem for GRASP. > > > > Brian > > > >> > >> > >> > >> > >> Sent from my Samsung Captivate Glide on AT&T > >> > >> Brian E Carpenter wrote: > >> Toerless, > >> > >> I think that's about right. I would probably invert the logic in > >> stage 1 (an enrolled node responds to discovery multicast by an > >> unenrolled node) but that's a detail. > >> > >> Brian > >> > >> > >> On 12/11/2015 18:00, Toerless Eckert wrote: > >>> My quick summary of how i could imagine the connection: > >>> > >>> A. Unenrolled node: > >>> > >>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN nod= es: > >>> > >>> instance of unsecure, unprotected L2-only GRASP. > >>> Enrolled node periodically sends L2 IP multicast objective > >>> discovery multicast "AN-node-who-wants-to-get-enrolled" > >>> > >>> AN nodes willing to enroll send unicast message back > >>> > >>> not sure if we want another unicast exchange round to prohibit > >>> some DoS attacks from other nodes on the same LAN. > >>> > >>> TBD: any attributes to include at "app-level", eg: SUDI or the > >>> like, might help, not sure. > >>> > >>> 2. Bootstrap continues with an EST/TLS connection where enrolled > >>> node acts as TLS proxy. > >>> > >>> Not sure if there further cases for GRASP in the bootstrap proces= s > >>> or if everything we need would be within EST. We do know that > >>> we want specific details in the certificate assigned. Not sure > >>> enough about EST details yet. > >>> > >>> B. Enrolled Nodes creating ACP between each other. > >>> > >>> 1. GRASP (boring): same as A.1, except that the two nodes discovery > >>> that they are claming both to be enrolled into same domain. > >>> > >>> 2. TLS (or dTLS ?) connection built between the two nodes. > >>> GRASP inside TLS connection, also just single-hop negotiating > >>> ACP tunnel mode. > >>> > >>> MTI ACP encryption: dTLS or IPsec. IPsec is logical, but > >>> talking to IOT folks it seems dTLS will be in every IOT > >>> device that has any security, so maybe dTLS is better lowest > >>> common denominator. > >>> > >>> C. Primary GRASP instance inside ACP > >>> > >>> This instance will be protected by ACP and be network wide, > >>> eg: GRASP needs to forward hop-by-hop. > >>> > >>> 1. Main purpose for GRASP inside ACP for the ACP itself (everything > >>> else is for future autonomic agents): > >>> > >>> Service-discovery of registrar. Eg: the already enrolled AN node > >>> in A. acting as proxy for enrollment will learn IP-address of > >>> registrar via GRASP. > >>> > >>> There are some open questions i have here as well, but lets see if > >>> this is on the outset what we think it should be. > >>> > >>> Cheers > >>> Toerless > >>> > >>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: > >>>> On 11/11/2015 16:05, Michael Richardson wrote: > >>>>> > >>>>> I spent most of my 11h trip home on Monday catching trying to > >>>>> empty my list of drafts to read... I have a series of comments on > >>>>> the documents which I'll post as seperate threads. > >>>>> > >>>>> I read through: > >>>>> - draft-ietf-anima-grasp-01 > >>>>> - draft-ietf-anima-autonomic-control-plane-01 > >>>>> - draft-behringer-anima-autonomic-addressing-02 > >>>>> - draft-liu-anima-grasp-distribution-00 > >>>>> - draft-ietf-anima-autonomic-control-plane-01 > >>>>> - draft-behringer-anima-reference-model-04 > >>>>> > >>>>> Reading the drafts I get a profound sense of dis-unity... > >>>>> It's about ACP vs GRASP, and how/where we do things. > >>>> > >>>> Can you try to explain where you see a disconnect? Because I don't. > >>>> The ACP provides a secure private Internet for ANs to use as they > >>>> wisk, and GRASP runs over the ACP to offer higher level messaging > >>>> functions to the ANs. > >>>> > >>>> Right now all that GRASP seems to need from the ACP is a status bit > >>>> saying "ACP is up" and a socket API. It might need to peek into the > >>>> adjacency table, but I'm not even sure about that. > >>>> > >>>> True, this chases its own tail a bit if GRASP is used for initial > >>>> discovery, and that does need to be tied down. > >>>> > >>>>> I think we need a virtual interim or something like that where we > >>>>> can talk for a longer period of time in a smaller group. > >>>> > >>>> We certainly need to understand what's not fitting together. > >>>> > >>>> Brian > >>>> > >>>> _______________________________________________ > >>>> Anima mailing list > >>>> Anima@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/anima > >>> > >> > > > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Nov 13 00:44:51 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A621A6EF4 for ; Fri, 13 Nov 2015 00:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 KH3LnfWt9xkE for ; Fri, 13 Nov 2015 00:44:49 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2793D1A1B87 for ; Fri, 13 Nov 2015 00:43:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5042; q=dns/txt; s=iport; t=1447404190; x=1448613790; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DGeZ2y1IWaUUa6FHz2/0rA3KP89vI1MyuEPCkHvHXik=; b=iWmTYUggXrou7DAMh8IGFSEYFtw2jIwYflGTBf2HOCCgvxMSsEg9a8Ix 5kLTsYNCFrMuj4chzx9zuQS4irxtUkvaEQHOpQYNnvE45xJYpyB57Ync9 zKw14sJmpXM22oILGi/S6UuQPxu0YcX7Uf1Rd3KuyHde68ObxfYGjUO7p 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAgA+oUVW/4kNJK1egztTbwa+PAENg?= =?us-ascii?q?WUXCoVvAhyBITgUAQEBAQEBAYEKhDQBAQEDAQEBASAROAIIAwUHBAIBCBEEAQE?= =?us-ascii?q?DAiMDAgICHwYLFAEICAIEAQ0FCIgRAwoIDbFxi2UNhGQBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEUBIEBhVOEfoJTgWKDQIFEBZZIAYsxgW6UeYdSAR8BAUKCER2BVnI?= =?us-ascii?q?Bg3MBHgccgQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,286,1444694400"; d="scan'208";a="49931247" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP; 13 Nov 2015 08:43:09 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tAD8h9RB000922 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 08:43:09 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 02:43:08 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 02:43:08 -0600 From: "Michael Behringer (mbehring)" To: "Liubing (Leo)" , "Max Pritikin (pritikin)" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WrFabeMQ0DUKKD3Ewsi4fEJ6WmiYAgAC3MQCAANSUgIABe99g Date: Fri, 13 Nov 2015 08:43:08 +0000 Message-ID: <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.132] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 08:44:50 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbmltYSBbbWFpbHRvOmFuaW1h LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMaXViaW5nIChMZW8pDQo+IFNlbnQ6IDEy IE5vdmVtYmVyIDIwMTUgMDQ6NDcNCj4gVG86IE1heCBQcml0aWtpbiAocHJpdGlraW4pIDxwcml0 aWtpbkBjaXNjby5jb20+OyBCcmlhbiBFIENhcnBlbnRlcg0KPiA8YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tPg0KPiBDYzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E+OyBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0FuaW1hXSBjb21tZW50cyBvbiBj dXJyZW50IGRyYWZ0cw0KPiANCj4gSGkgYWxsLA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+IEZyb206IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1heCBQcml0aWtpbg0KPiA+IChwcml0aWtpbikNCj4gLi4uDQo+ID4gVGhp cyBpcyB3aGF0IEkgY2FsbGVkIG91dCBkdXJpbmcgWW9rb2hhbWEgYXMgd2VsbC4gSXMgaXQgIkFD UCB0aGVuDQo+ID4gR1JBU1DigJ0gb3Ig4oCcR1JBU1AgdGhlbiBBQ1AgdGhlbiBHUkFTUCBhZ2Fp buKAnT8gQ2xlYXJseSBJIGhhdmUgYQ0KPiA+IGJvb3RzdHJhcHBpbmcgcGVyc3BlY3RpdmUgYnV0 IG1heWJlIE1pY2hhZWwgaXMgdGhpbmtpbmcgYWxvbmcgdGhlIHNhbWUNCj4gbGluZXMuDQo+IA0K PiBBcGFydCBmcm9tIEFTQXMsIHdlIGFsc28gbmVlZCB0aGUgZm9sbG93aW5nIHNpZ25hbGxpbmdz Og0KPiAtIGEgRGlzY292ZXJ5IG1lY2hhbmlzbSBkdXJpbmcgYm9vdHN0cmFwcGluZyAoQm9vdC1E aXNjb3ZlcnkpDQo+IC0gYSBEaXNjb3ZlcnkvTmVnb3RpYXRpb24gbWVjaGFuaXNtIGR1cmluZyBB Q1AgZXN0YWJsaXNoaW5nIChBQ1AtRGlzTmVnKQ0KPiANCj4gVGhlIEdSQVNQIG1pZ2h0IGhhdmUg dGhlIHNlY3VyaXR5IHN0YXRlOg0KPiAtIG5vIHNlY3VyaXR5IGF0IGFsbCAoR1JBU1AtTm9uU2Vj KQ0KPiAtIFRMUy9EVExTIHNlY3VyZWQgKEdSQVNQLShEKVRMUykNCj4gLSBSdW5uaW5nIGluIEFD UCwgbW9zdGx5IGZvciBBU0FzIGNvbW11bmljYXRpb24gKEdSQVNQLUFDUCkNCg0KSSB0aGluayBp dCdzIG5vdCB0aGF0IGNvbXBsaWNhdGVkLiANCg0KR1JBU1AgaW4gdGhlIEFDUCBpcyB0aGUgc2Ft ZSBHUkFTUCBydW5uaW5nIGluIHRoZSBkYXRhIHBsYW5lLiBJbiBvbmUgdGhlIGNvbnRleHQgaXMg c2VjdXJlLCBpbiB0aGUgb3RoZXIgbm90LiBCdXQgdGhlIHByb3RvY29sIC0gYXMgSSBzZWUgaXMg LSBpcyB0aGUgc2FtZS4gDQoNCkRpc2NvdmVyeSBpbiB0aGUgZGF0YSBwbGFuZSwgd2hpY2ggZmVl ZHMgdGhlIGFkamFjZW5jeSB0YWJsZSBpcyBpbnNlY3VyZS4gSXQgZmVlZHMgdGhlIGFkamFjZW5j eSB0YWJsZS4gTWVhbmluZyB0aGF0IHRoZSBpbmZvIGluIHRoZSBhZGphY2VuY3kgdGFibGUgY2Fu bm90IGJlIHRydXN0ZWQsIGl0J3MgYSB0YWJsZSBvZiAid2hhdCBub2RlcyBhcm91bmQgbWUgaGF2 ZSBjbGFpbWVkIi4gDQoNCldlIE1BWSBhbHNvIHZhbGlkYXRlIHNvbWUgaW5mbyBpbiB0aGUgYWRq YWNlbmN5IHRhYmxlLCBmb3IgZXhhbXBsZSB3ZSBjb3VsZCB2YWxpZGF0ZSB0aGUgU1VESSBvZiBh IG5ldywgbm90IHlldCBib290c3RyYXBwZWQgbmVpZ2hib3VyLiBUaGlzIGlzIHdoeSBJIGFkZGVk IGZpZWxkcyBmb3IgInZhbGlkaXR5IiBpbiB0aGUgdGFibGUgSSBwcmVzZW50ZWQgaW4gWW9rb2hh bWEuIEJ1dCBJJ20gbm90IHN1cmUgdGhhdCB0aGUgYmVuZWZpdCBvZiB0aGlzIHdvcnRoIGl0LiBJ IHNvbWVob3cgbGlrZSB0aGUgc2ltcGxpY2l0eSBvZiB0aGUgc3RhdGVtZW50ICJ0aGUgYWRqYWNl bmN5IHRhYmxlIGNhbm5vdCBiZSB0cnVzdGVkIi4gDQoNCk5vdyBldmVyeSBhY3Rpb24gYSBub2Rl IHRha2VzIG9uIHRoZSBhZGphY2VuY3kgdGFibGUgaGFzIHRvIGJlIGNsZWFyIHRoYXQgaXQncyBz dGFydGluZyB3aXRoIHBvdGVudGlhbGx5IGZha2UgZGF0YS4gVGhlcmVmb3JlLCB0aGUgQUNQIGJy aW5nLXVwLCBib290c3RyYXAsIGFuZCB3aGF0ZXZlciBlbHNlIHdlIG1heSB3YW50IHRvIGRvIE1V U1Qgc2VjdXJlLiBUaGF0IG1lYW5zIG5vdyB0aGF0ICpJRiogd2UgdXNlIEdSQVNQIGZvciBib290 c3RyYXAgKEkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBkZWNpZGVkIHlldD8pLCBpbiB0aGlzIHBhcnRp Y3VsYXIgY29udGV4dCwgR1JBUFMgKG9yIGFueSBvdGhlciBwcm90b2NvbCB3ZSBtYXkgY2hvb3Nl KSBuZWVkcyB0byBiZSBzZWN1cmVkLiANCg0KTm93IHRoZSBmYWN0IHRoYXQgdGhlIGFkamFjZW5j eSB0YWJsZSBtYXkgY29udGFpbiBmYWtlIGluZm9ybWF0aW9uIGdpdmVzIHVzIGEgc2VjdXJpdHkg ZXhwb3N1cmU6IEEgbm9kZSBjb3VsZCBhdCBsZWFzdCBmb3JjZSByZXBlYXRlZCBuZWdvdGlhdGlv bnMgKGZvciBleGFtcGxlIHRvIGVzdGFibGlzaCB0aGUgQUNQKS4gU28gd2UgbmVlZCB0aGUgY2Fw YWJpbGl0eSB0byByYXRlIGxpbWl0IG9yIGlnbm9yZSBhIHBhcnRpY3VsYXIgbm9kZSwgaWYgd2Ug bGVhcm4gdGhhdCBpdCdzIG1hbGljaW91cy4NCg0KRG8gd2UgYWdyZWUgd2l0aCB0aGlzIHN0YXRl bWVudCB0aGF0IHRoZSBhZGphY2VuY3kgdGFibGUgaXMgZmVkIGJ5IHVuc2VjdXJlZCBwcm90b2Nv bHMgYW5kIHRoZXJlZm9yZSBjYW5ub3QgYmUgdHJ1c3RlZCBibGluZGx5PyBJIHRoaW5rIHRoaXMg aXMgaW1wb3J0YW50IHRvIGNhcHR1cmUuIA0KDQpNaWNoYWVsDQoNCj4gSWYgdGhlIEJvb3QtRGlz Y292ZXJ5IGNob29zZSBHUkFTUCwgdGhlbiBJIGd1ZXNzIHdlIG5lZWQgdG8gbWFrZSB0aGUNCj4g R1JBU1AtTm9uU2VjIHZhbGlkIGFzIHdlbGwoaW4gY3VycmVudCBkcmFmdCwgdGhlcmUgaXMgbm8g Y2hvaWNlIGZvciBub24tDQo+IHNlY3VyZWQgR1JBU1ApLiBCZWNhdXNlIGl0IHdvdWxkIGJlIGRp ZmZpY3VsdCBmb3IgR1JBU1AgdG8gZ2FpbiAoRClUTFMNCj4gcHJvdGVjdGlvbiB3aXRob3V0IHRo ZSBib290c3RyYXBwaW5nIHJlYWR5Lg0KPiBIb3dldmVyLCBhcyBNYXggc2FpZCwgaXQgc2VlbXMg Ym9vdHN0cmFwcGluZyBwcmVmZXIgb3RoZXIgZGlzY292ZXJ5DQo+IG1lY2hhbmlzbXMgdGhhbiBH UkFTUD8gSSBuZWVkIHRvIGRvIGEgaG9tZXdvcmsgdG8gZmlndXJlIG91dCB0aGUNCj4gc2lnbmFs aW5nIHJlcXVpcmVtZW50cyBvZiBib290c3RyYXBwaW5nLiAoTWF4LCBpZiB5b3UgY291bGQgZ2l2 ZSBtZSBzb21lDQo+IGhpbnQsIHRoYXQgd291bGQgYmUgdmVyeSBoZWxwZnVsLiBNYW55IHRoYW5r cy4pDQo+IA0KPiBJbiBBQ1AgZHJhZnQsIGl0IHNwZWNpZmllcyB0aGF0IHRoZSBBQ1AtRGlzTmVn IE1VU1QgYmUgc2VjdXJlZC4gU28sIGlmIHRoZQ0KPiBBQ1AtRGlzTmVnIGlzIEdSQVNQLCBpdCBq dXN0IGFzc3VtZXMgR1JBU1AtKEQpVExTIGluIHVzZSwgd2hpY2ggaXMNCj4gYXBwbGljYWJsZSBh ZnRlciBib290c3RyYXBwaW5nLCBpcyB0aGVyZSBhbnkgZ2FwPw0KPiANCj4gQmVzdCByZWdhcmRz LA0KPiBCaW5nDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IEFuaW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FuaW1hDQo= From nobody Fri Nov 13 01:21:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78021A6F90 for ; Fri, 13 Nov 2015 01:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, 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 WuHRMKt7KRGX for ; Fri, 13 Nov 2015 01:21:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 312341A7028 for ; Fri, 13 Nov 2015 01:21:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEA83384; Fri, 13 Nov 2015 09:21:03 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 13 Nov 2015 09:21:02 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.20]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Fri, 13 Nov 2015 17:20:53 +0800 From: "Liubing (Leo)" To: "Michael Behringer (mbehring)" , "Max Pritikin (pritikin)" , Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3b8xH4138F2EW7mUsJDdz/GZ6Vr3UAgAC3MACAAUSpsIABdN0AgACHYgA= Date: Fri, 13 Nov 2015 09:20:52 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> In-Reply-To: <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5645AB80.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.20, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c1e2a6b20679748fe12b0de1fb2da297 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 09:21:10 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNoYWVsIEJlaHJpbmdlciAo bWJlaHJpbmcpIFttYWlsdG86bWJlaHJpbmdAY2lzY28uY29tXQ0KPiBTZW50OiBGcmlkYXksIE5v dmVtYmVyIDEzLCAyMDE1IDQ6NDMgUE0NCj4gVG86IExpdWJpbmcgKExlbyk7IE1heCBQcml0aWtp biAocHJpdGlraW4pOyBCcmlhbiBFIENhcnBlbnRlcg0KPiBDYzogTWljaGFlbCBSaWNoYXJkc29u OyBhbmltYUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW0FuaW1hXSBjb21tZW50cyBvbiBjdXJy ZW50IGRyYWZ0cw0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206 IEFuaW1hIFttYWlsdG86YW5pbWEtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExpdWJp bmcgKExlbykNCj4gPiBTZW50OiAxMiBOb3ZlbWJlciAyMDE1IDA0OjQ3DQo+ID4gVG86IE1heCBQ cml0aWtpbiAocHJpdGlraW4pIDxwcml0aWtpbkBjaXNjby5jb20+OyBCcmlhbiBFIENhcnBlbnRl cg0KPiA+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQo+ID4gQ2M6IE1pY2hhZWwgUmlj aGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgYW5pbWFAaWV0Zi5vcmcNCj4gPiBTdWJq ZWN0OiBSZTogW0FuaW1hXSBjb21tZW50cyBvbiBjdXJyZW50IGRyYWZ0cw0KPiA+DQo+ID4gSGkg YWxsLA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTog QW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWF4DQo+ ID4gPiBQcml0aWtpbg0KPiA+ID4gKHByaXRpa2luKQ0KPiA+IC4uLg0KPiA+ID4gVGhpcyBpcyB3 aGF0IEkgY2FsbGVkIG91dCBkdXJpbmcgWW9rb2hhbWEgYXMgd2VsbC4gSXMgaXQgIkFDUCB0aGVu DQo+ID4gPiBHUkFTUOKAnSBvciDigJxHUkFTUCB0aGVuIEFDUCB0aGVuIEdSQVNQIGFnYWlu4oCd PyBDbGVhcmx5IEkgaGF2ZSBhDQo+ID4gPiBib290c3RyYXBwaW5nIHBlcnNwZWN0aXZlIGJ1dCBt YXliZSBNaWNoYWVsIGlzIHRoaW5raW5nIGFsb25nIHRoZQ0KPiA+ID4gc2FtZQ0KPiA+IGxpbmVz Lg0KPiA+DQo+ID4gQXBhcnQgZnJvbSBBU0FzLCB3ZSBhbHNvIG5lZWQgdGhlIGZvbGxvd2luZyBz aWduYWxsaW5nczoNCj4gPiAtIGEgRGlzY292ZXJ5IG1lY2hhbmlzbSBkdXJpbmcgYm9vdHN0cmFw cGluZyAoQm9vdC1EaXNjb3ZlcnkpDQo+ID4gLSBhIERpc2NvdmVyeS9OZWdvdGlhdGlvbiBtZWNo YW5pc20gZHVyaW5nIEFDUCBlc3RhYmxpc2hpbmcNCj4gPiAoQUNQLURpc05lZykNCj4gPg0KPiA+ IFRoZSBHUkFTUCBtaWdodCBoYXZlIHRoZSBzZWN1cml0eSBzdGF0ZToNCj4gPiAtIG5vIHNlY3Vy aXR5IGF0IGFsbCAoR1JBU1AtTm9uU2VjKQ0KPiA+IC0gVExTL0RUTFMgc2VjdXJlZCAoR1JBU1At KEQpVExTKQ0KPiA+IC0gUnVubmluZyBpbiBBQ1AsIG1vc3RseSBmb3IgQVNBcyBjb21tdW5pY2F0 aW9uIChHUkFTUC1BQ1ApDQo+IA0KPiBJIHRoaW5rIGl0J3Mgbm90IHRoYXQgY29tcGxpY2F0ZWQu DQo+IA0KPiBHUkFTUCBpbiB0aGUgQUNQIGlzIHRoZSBzYW1lIEdSQVNQIHJ1bm5pbmcgaW4gdGhl IGRhdGEgcGxhbmUuIEluIG9uZSB0aGUNCj4gY29udGV4dCBpcyBzZWN1cmUsIGluIHRoZSBvdGhl ciBub3QuIEJ1dCB0aGUgcHJvdG9jb2wgLSBhcyBJIHNlZSBpcyAtIGlzIHRoZSBzYW1lLg0KW0Jp bmddIFllcywgZXhhY3RseS4gSSBqdXN0IHdhbnRlZCB0byBsaXN0IGFsbCB0aGUgcG9zc2liaWxp dGllcyBmb3IgZWFzZSBvZiBhbmFseXNpcy4NCg0KPiBEaXNjb3ZlcnkgaW4gdGhlIGRhdGEgcGxh bmUsIHdoaWNoIGZlZWRzIHRoZSBhZGphY2VuY3kgdGFibGUgaXMgaW5zZWN1cmUuIEl0DQo+IGZl ZWRzIHRoZSBhZGphY2VuY3kgdGFibGUuIE1lYW5pbmcgdGhhdCB0aGUgaW5mbyBpbiB0aGUgYWRq YWNlbmN5IHRhYmxlDQo+IGNhbm5vdCBiZSB0cnVzdGVkLCBpdCdzIGEgdGFibGUgb2YgIndoYXQg bm9kZXMgYXJvdW5kIG1lIGhhdmUgY2xhaW1lZCIuDQo+IA0KPiBXZSBNQVkgYWxzbyB2YWxpZGF0 ZSBzb21lIGluZm8gaW4gdGhlIGFkamFjZW5jeSB0YWJsZSwgZm9yIGV4YW1wbGUgd2UNCj4gY291 bGQgdmFsaWRhdGUgdGhlIFNVREkgb2YgYSBuZXcsIG5vdCB5ZXQgYm9vdHN0cmFwcGVkIG5laWdo Ym91ci4gVGhpcyBpcw0KPiB3aHkgSSBhZGRlZCBmaWVsZHMgZm9yICJ2YWxpZGl0eSIgaW4gdGhl IHRhYmxlIEkgcHJlc2VudGVkIGluIFlva29oYW1hLiBCdXQgSSdtDQo+IG5vdCBzdXJlIHRoYXQg dGhlIGJlbmVmaXQgb2YgdGhpcyB3b3J0aCBpdC4gSSBzb21laG93IGxpa2UgdGhlIHNpbXBsaWNp dHkgb2YgdGhlDQo+IHN0YXRlbWVudCAidGhlIGFkamFjZW5jeSB0YWJsZSBjYW5ub3QgYmUgdHJ1 c3RlZCIuDQo+IA0KPiBOb3cgZXZlcnkgYWN0aW9uIGEgbm9kZSB0YWtlcyBvbiB0aGUgYWRqYWNl bmN5IHRhYmxlIGhhcyB0byBiZSBjbGVhciB0aGF0DQo+IGl0J3Mgc3RhcnRpbmcgd2l0aCBwb3Rl bnRpYWxseSBmYWtlIGRhdGEuIFRoZXJlZm9yZSwgdGhlIEFDUCBicmluZy11cCwNCj4gYm9vdHN0 cmFwLCBhbmQgd2hhdGV2ZXIgZWxzZSB3ZSBtYXkgd2FudCB0byBkbyBNVVNUIHNlY3VyZS4gVGhh dCBtZWFucw0KPiBub3cgdGhhdCAqSUYqIHdlIHVzZSBHUkFTUCBmb3IgYm9vdHN0cmFwIChJIGRv bid0IHRoaW5rIHRoaXMgaXMgZGVjaWRlZCB5ZXQ/KSwNCj4gaW4gdGhpcyBwYXJ0aWN1bGFyIGNv bnRleHQsIEdSQVBTIChvciBhbnkgb3RoZXIgcHJvdG9jb2wgd2UgbWF5IGNob29zZSkNCj4gbmVl ZHMgdG8gYmUgc2VjdXJlZC4NCltCaW5nXSBGb3IgQUNQIGJyaW5nLXVwLCBpdCBtb3N0bHkgaGFw cGVucyBhZnRlciB0aGUgYm9vdHN0cmFwLCBzbyBJIGJlbGlldmUgaXQgd29uJ3QgYmUgYSBwcm9i bGVtIGZvciB0aGUgR1JBU1AgdG8gYmUgc2VjdXJlZChkb2luZyBUTFMvRFRMUyBzaG91bGQgbm90 IGJlIGRpZmZpY3VsdCBhZnRlciBib290c3RyYXApLg0KVGhlIG9ubHkgY2hhbGxlbmdlIEkgY2Fu IHNlZSBpcyBob3cgdG8gc2VjdXJlIEdSQVNQIGJlZm9yZSBib290c3RyYXAuIEV2ZW4gaWYgYm9v dHN0cmFwIGRvZXNuJ3QgdXNlIEdSQVNQLCBpdCBpcyBzdGlsbCBhIGNoYWxsZW5nZSBmb3Igc2Vj dXJlZCBzaWduYWxpbmcgYmVmb3JlIHRoYXQuDQoNCkJlc3QgcmVnYXJkcywNCkJpbmcNCg0KPiBO b3cgdGhlIGZhY3QgdGhhdCB0aGUgYWRqYWNlbmN5IHRhYmxlIG1heSBjb250YWluIGZha2UgaW5m b3JtYXRpb24gZ2l2ZXMgdXMNCj4gYSBzZWN1cml0eSBleHBvc3VyZTogQSBub2RlIGNvdWxkIGF0 IGxlYXN0IGZvcmNlIHJlcGVhdGVkIG5lZ290aWF0aW9ucyAoZm9yDQo+IGV4YW1wbGUgdG8gZXN0 YWJsaXNoIHRoZSBBQ1ApLiBTbyB3ZSBuZWVkIHRoZSBjYXBhYmlsaXR5IHRvIHJhdGUgbGltaXQg b3INCj4gaWdub3JlIGEgcGFydGljdWxhciBub2RlLCBpZiB3ZSBsZWFybiB0aGF0IGl0J3MgbWFs aWNpb3VzLg0KPiANCj4gRG8gd2UgYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudCB0aGF0IHRoZSBh ZGphY2VuY3kgdGFibGUgaXMgZmVkIGJ5IHVuc2VjdXJlZA0KPiBwcm90b2NvbHMgYW5kIHRoZXJl Zm9yZSBjYW5ub3QgYmUgdHJ1c3RlZCBibGluZGx5PyBJIHRoaW5rIHRoaXMgaXMgaW1wb3J0YW50 IHRvDQo+IGNhcHR1cmUuDQo+IA0KPiBNaWNoYWVsDQo+IA0KPiA+IElmIHRoZSBCb290LURpc2Nv dmVyeSBjaG9vc2UgR1JBU1AsIHRoZW4gSSBndWVzcyB3ZSBuZWVkIHRvIG1ha2UgdGhlDQo+ID4g R1JBU1AtTm9uU2VjIHZhbGlkIGFzIHdlbGwoaW4gY3VycmVudCBkcmFmdCwgdGhlcmUgaXMgbm8g Y2hvaWNlIGZvcg0KPiA+IG5vbi0gc2VjdXJlZCBHUkFTUCkuIEJlY2F1c2UgaXQgd291bGQgYmUg ZGlmZmljdWx0IGZvciBHUkFTUCB0byBnYWluDQo+ID4gKEQpVExTIHByb3RlY3Rpb24gd2l0aG91 dCB0aGUgYm9vdHN0cmFwcGluZyByZWFkeS4NCj4gPiBIb3dldmVyLCBhcyBNYXggc2FpZCwgaXQg c2VlbXMgYm9vdHN0cmFwcGluZyBwcmVmZXIgb3RoZXIgZGlzY292ZXJ5DQo+ID4gbWVjaGFuaXNt cyB0aGFuIEdSQVNQPyBJIG5lZWQgdG8gZG8gYSBob21ld29yayB0byBmaWd1cmUgb3V0IHRoZQ0K PiA+IHNpZ25hbGluZyByZXF1aXJlbWVudHMgb2YgYm9vdHN0cmFwcGluZy4gKE1heCwgaWYgeW91 IGNvdWxkIGdpdmUgbWUNCj4gPiBzb21lIGhpbnQsIHRoYXQgd291bGQgYmUgdmVyeSBoZWxwZnVs LiBNYW55IHRoYW5rcy4pDQo+ID4NCj4gPiBJbiBBQ1AgZHJhZnQsIGl0IHNwZWNpZmllcyB0aGF0 IHRoZSBBQ1AtRGlzTmVnIE1VU1QgYmUgc2VjdXJlZC4gU28sIGlmDQo+ID4gdGhlIEFDUC1EaXNO ZWcgaXMgR1JBU1AsIGl0IGp1c3QgYXNzdW1lcyBHUkFTUC0oRClUTFMgaW4gdXNlLCB3aGljaCBp cw0KPiA+IGFwcGxpY2FibGUgYWZ0ZXIgYm9vdHN0cmFwcGluZywgaXMgdGhlcmUgYW55IGdhcD8N Cj4gPg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBCaW5nDQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBBbmltYSBtYWlsaW5nIGxpc3QNCj4g PiBBbmltYUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYW5pbWENCg== From nobody Fri Nov 13 10:41:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0B1B2B19 for ; Fri, 13 Nov 2015 10:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, 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 BVpp3TEadccy for ; Fri, 13 Nov 2015 10:41:39 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 DF6221B2B14 for ; Fri, 13 Nov 2015 10:41:38 -0800 (PST) Received: by pacdm15 with SMTP id dm15so107475036pac.3 for ; Fri, 13 Nov 2015 10:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=HcKSVHgwGgHVjxFMjJ3g6yft32tH0GSauguUEdmq8SM=; b=xq9xkgVu9Y0mdRgSBh98g4KArX8eM+zNceI0J8eFE/2CopSGM78OJG2zgLqZwA7fJc OpIhGdibv79WnIOsmWuFpAeRlUphaic3jpg6ptJjoWUJrMo8wRKy1h6FrWMGSsAmP3ZF 3n7tmmIjt9xf1OuHpnDOZ3HaOkwBTcmWfN1c0FETQQyqKYpXxrW8Xeoelgw+UWhDm0jO 46yIelGnTAP/czZMtBWkU0ID1DyaWitEScFZh3j2FJw0JFII+gfYbFfojpZGVObvJcqr qd7wDoF7pvAvpi/kFAvnyTho30E48tFEyDQn2lK1zpsDFqEt9ZWS0bKa0pkVatbTah4f q/cw== X-Received: by 10.68.135.42 with SMTP id pp10mr34539397pbb.154.1447440098498; Fri, 13 Nov 2015 10:41:38 -0800 (PST) Received: from ?IPv6:2406:e007:7309:1:28cc:dc4c:9703:6781? ([2406:e007:7309:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id rv8sm4215541pbc.84.2015.11.13.10.41.34 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 10:41:37 -0800 (PST) To: "Liubing (Leo)" , "Michael Behringer (mbehring)" , "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56462EE4.8070200@gmail.com> Date: Sat, 14 Nov 2015 07:41:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 18:41:41 -0000 Bing, > The only challenge I can see is how to secure GRASP before bootstrap. E= ven if bootstrap doesn't use GRASP, it is still a challenge for secured s= ignaling before that. As far as I can tell, you're correct that there are three modes: Best: ACP is up, GRASP just sends packets Medium: No ACP, GRASP must wrap sessions in TLS Worst: No certificates available, GRASP is insecure. The reason I was asking Michael some weeks ago about multicast support in the ACP is because my understanding is that link-local multicast is intrinsically insecure, so LL discovery messages are intrinsically insecure. In any case, discovery before bootstrap is insecure, but I guess the bootstrap design will assume that. Regards Brian On 13/11/2015 22:20, Liubing (Leo) wrote: >> -----Original Message----- >> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >> Sent: Friday, November 13, 2015 4:43 PM >> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter >> Cc: Michael Richardson; anima@ietf.org >> Subject: RE: [Anima] comments on current drafts >> >>> -----Original Message----- >>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo= ) >>> Sent: 12 November 2015 04:47 >>> To: Max Pritikin (pritikin) ; Brian E Carpenter >>> >>> Cc: Michael Richardson ; anima@ietf.org >>> Subject: Re: [Anima] comments on current drafts >>> >>> Hi all, >>> >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max >>>> Pritikin >>>> (pritikin) >>> ... >>>> This is what I called out during Yokohama as well. Is it "ACP then >>>> GRASP=E2=80=9D or =E2=80=9CGRASP then ACP then GRASP again=E2=80=9D?= Clearly I have a >>>> bootstrapping perspective but maybe Michael is thinking along the >>>> same >>> lines. >>> >>> Apart from ASAs, we also need the following signallings: >>> - a Discovery mechanism during bootstrapping (Boot-Discovery) >>> - a Discovery/Negotiation mechanism during ACP establishing >>> (ACP-DisNeg) >>> >>> The GRASP might have the security state: >>> - no security at all (GRASP-NonSec) >>> - TLS/DTLS secured (GRASP-(D)TLS) >>> - Running in ACP, mostly for ASAs communication (GRASP-ACP) >> >> I think it's not that complicated. >> >> GRASP in the ACP is the same GRASP running in the data plane. In one t= he >> context is secure, in the other not. But the protocol - as I see is - = is the same. > [Bing] Yes, exactly. I just wanted to list all the possibilities for ea= se of analysis. >=20 >> Discovery in the data plane, which feeds the adjacency table is insecu= re. It >> feeds the adjacency table. Meaning that the info in the adjacency tabl= e >> cannot be trusted, it's a table of "what nodes around me have claimed"= =2E >> >> We MAY also validate some info in the adjacency table, for example we >> could validate the SUDI of a new, not yet bootstrapped neighbour. This= is >> why I added fields for "validity" in the table I presented in Yokohama= =2E But I'm >> not sure that the benefit of this worth it. I somehow like the simplic= ity of the >> statement "the adjacency table cannot be trusted". >> >> Now every action a node takes on the adjacency table has to be clear t= hat >> it's starting with potentially fake data. Therefore, the ACP bring-up,= >> bootstrap, and whatever else we may want to do MUST secure. That means= >> now that *IF* we use GRASP for bootstrap (I don't think this is decide= d yet?), >> in this particular context, GRAPS (or any other protocol we may choose= ) >> needs to be secured. > [Bing] For ACP bring-up, it mostly happens after the bootstrap, so I be= lieve it won't be a problem for the GRASP to be secured(doing TLS/DTLS sh= ould not be difficult after bootstrap). > The only challenge I can see is how to secure GRASP before bootstrap. E= ven if bootstrap doesn't use GRASP, it is still a challenge for secured s= ignaling before that. >=20 > Best regards, > Bing >=20 >> Now the fact that the adjacency table may contain fake information giv= es us >> a security exposure: A node could at least force repeated negotiations= (for >> example to establish the ACP). So we need the capability to rate limit= or >> ignore a particular node, if we learn that it's malicious. >> >> Do we agree with this statement that the adjacency table is fed by uns= ecured >> protocols and therefore cannot be trusted blindly? I think this is imp= ortant to >> capture. >> >> Michael >> >>> If the Boot-Discovery choose GRASP, then I guess we need to make the >>> GRASP-NonSec valid as well(in current draft, there is no choice for >>> non- secured GRASP). Because it would be difficult for GRASP to gain >>> (D)TLS protection without the bootstrapping ready. >>> However, as Max said, it seems bootstrapping prefer other discovery >>> mechanisms than GRASP? I need to do a homework to figure out the >>> signaling requirements of bootstrapping. (Max, if you could give me >>> some hint, that would be very helpful. Many thanks.) >>> >>> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, i= f >>> the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which i= s >>> applicable after bootstrapping, is there any gap? >>> >>> Best regards, >>> Bing >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima From nobody Fri Nov 13 10:54:41 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97591B2F9B for ; Fri, 13 Nov 2015 10:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FR_ALMOST_VIAG2=10.357, MANGLED_VIAGRA=2.5, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 SZD-UNYXD37b for ; Fri, 13 Nov 2015 10:54:38 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCB471B2F93 for ; Fri, 13 Nov 2015 10:54:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6497; q=dns/txt; s=iport; t=1447440877; x=1448650477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Mc/vCcPGIxBCc0vKB7WCI4l6lTGjHKIcS7Ck3aLODQQ=; b=D4gyIU0zKMxqVG/il+PRbzRuNgpodjITKR7/z2SmBsSjhtg38fLOQiBt +/lk7FFjAnfKSYQItGI75Z9KjmFITCR7NXCpBur2Jpbvt2NuhiEWPpKtU 89j3rEcmn9sjpYdswUTWP8qh9rXVg9/AUb4af+V9FefZDJZJzVxH2jLGW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAgBiMUZW/5BdJa1egztTb75HAQ2BZ?= =?us-ascii?q?RcKhW8CgTs4FAEBAQEBAQGBCoQ0AQEBAwEBAQE3NAYFBQsCAQgYHhAhBgslAgQ?= =?us-ascii?q?OBYgZAwoIDbtkDYRXAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASIZIJuglOBbxeDS?= =?us-ascii?q?4EVBYYLCZA0AYsxgXWBW4dlizKHUgEfAQFChARyAYU8AQEB?= X-IronPort-AV: E=Sophos;i="5.20,288,1444694400"; d="scan'208";a="46609932" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP; 13 Nov 2015 18:54:36 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id tADIsar0002865 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 18:54:36 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 12:54:36 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 12:54:35 -0600 From: "Max Pritikin (pritikin)" To: "Joel M. Halpern" Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WbFNlXfA390qGwfzbG5IpEJ6WmiYAgAGgFACAAPLugIAAE+yAgABFggCAAANJgIAAx0Ax Date: Fri, 13 Nov 2015 18:54:35 +0000 Message-ID: References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <20151112050008.GA16599@cisco.com> <5644E8A1.8090204@gmail.com> <564533A6.5000508@gmail.com>,<56453667.308@joelhalpern.com> In-Reply-To: <56453667.308@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "Toerless Eckert \(eckert\)" , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 18:54:39 -0000 I second this concern. A polling model like this is just as susceptible to = attack (on the polling interval) as listening for a new device -- and invol= ves the steady stream of announcements.=20 Let's address any underlying security concern and optimize the initiator/re= sponder independently.=20 - max=20 > On Nov 12, 2015, at 5:01 PM, Joel M. Halpern wrote: >=20 > This seems to require that all devices supporting the enrollment process,= once they are enrolled, must emit a steady, if somewhat low rate, stream o= f advertisements so that new non-enrolled devices on the net will see such = advertisements. >=20 > That seems unfortunate. > Yours, > Joel >=20 >> On 11/12/15 7:49 PM, Brian E Carpenter wrote: >>> On 13/11/2015 09:40, Toerless Eckert (eckert) wrote: >>> We thought that it would be better this way around because: >>>=20 >>> Already enrolled device can be less attacked, because it will not react= to unsolicited messages. >>>=20 >>> Client device sitting in a non-an environment will not generate message= s unnecessary in this environment, but just rspond. >>=20 >> Well, yes, it will have to be a server in fact, listening for incoming >> discovery multicasts, but that's OK: all GRASP nodes are both clients >> and servers. Then once it starts the enrollment process, it stops listen= ing >> for that particular type of discovery. >>=20 >> Not a problem for GRASP. >>=20 >> Brian >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Sent from my Samsung Captivate Glide on AT&T >>>=20 >>> Brian E Carpenter wrote: >>> Toerless, >>>=20 >>> I think that's about right. I would probably invert the logic >>> in stage 1 (an enrolled node responds to discovery multicast by >>> an unenrolled node) but that's a detail. >>>=20 >>> Brian >>>=20 >>>=20 >>>> On 12/11/2015 18:00, Toerless Eckert wrote: >>>> My quick summary of how i could imagine the connection: >>>>=20 >>>> A. Unenrolled node: >>>>=20 >>>> 1. GRASP1 (boring): L2 discovery of neighboring (not enrolled) AN node= s: >>>>=20 >>>> instance of unsecure, unprotected L2-only GRASP. >>>> Enrolled node periodically sends L2 IP multicast objective >>>> discovery multicast "AN-node-who-wants-to-get-enrolled" >>>>=20 >>>> AN nodes willing to enroll send unicast message back >>>>=20 >>>> not sure if we want another unicast exchange round to prohibit >>>> some DoS attacks from other nodes on the same LAN. >>>>=20 >>>> TBD: any attributes to include at "app-level", eg: SUDI or the >>>> like, might help, not sure. >>>>=20 >>>> 2. Bootstrap continues with an EST/TLS connection where enrolled >>>> node acts as TLS proxy. >>>>=20 >>>> Not sure if there further cases for GRASP in the bootstrap process >>>> or if everything we need would be within EST. We do know that >>>> we want specific details in the certificate assigned. Not sure >>>> enough about EST details yet. >>>>=20 >>>> B. Enrolled Nodes creating ACP between each other. >>>>=20 >>>> 1. GRASP (boring): same as A.1, except that the two nodes discovery >>>> that they are claming both to be enrolled into same domain. >>>>=20 >>>> 2. TLS (or dTLS ?) connection built between the two nodes. >>>> GRASP inside TLS connection, also just single-hop negotiating >>>> ACP tunnel mode. >>>>=20 >>>> MTI ACP encryption: dTLS or IPsec. IPsec is logical, but >>>> talking to IOT folks it seems dTLS will be in every IOT >>>> device that has any security, so maybe dTLS is better lowest >>>> common denominator. >>>>=20 >>>> C. Primary GRASP instance inside ACP >>>>=20 >>>> This instance will be protected by ACP and be network wide, >>>> eg: GRASP needs to forward hop-by-hop. >>>>=20 >>>> 1. Main purpose for GRASP inside ACP for the ACP itself (everything >>>> else is for future autonomic agents): >>>>=20 >>>> Service-discovery of registrar. Eg: the already enrolled AN node >>>> in A. acting as proxy for enrollment will learn IP-address of >>>> registrar via GRASP. >>>>=20 >>>> There are some open questions i have here as well, but lets see >>>> if this is on the outset what we think it should be. >>>>=20 >>>> Cheers >>>> Toerless >>>>=20 >>>>> On Wed, Nov 11, 2015 at 05:10:56PM +1300, Brian E Carpenter wrote: >>>>>> On 11/11/2015 16:05, Michael Richardson wrote: >>>>>>=20 >>>>>> I spent most of my 11h trip home on Monday catching trying to empty = my list >>>>>> of drafts to read... I have a series of comments on the documents w= hich I'll >>>>>> post as seperate threads. >>>>>>=20 >>>>>> I read through: >>>>>> - draft-ietf-anima-grasp-01 >>>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>>> - draft-behringer-anima-autonomic-addressing-02 >>>>>> - draft-liu-anima-grasp-distribution-00 >>>>>> - draft-ietf-anima-autonomic-control-plane-01 >>>>>> - draft-behringer-anima-reference-model-04 >>>>>>=20 >>>>>> Reading the drafts I get a profound sense of dis-unity... >>>>>> It's about ACP vs GRASP, and how/where we do things. >>>>>=20 >>>>> Can you try to explain where you see a disconnect? Because I don't. >>>>> The ACP provides a secure private Internet for ANs to use as they >>>>> wisk, and GRASP runs over the ACP to offer higher level messaging >>>>> functions to the ANs. >>>>>=20 >>>>> Right now all that GRASP seems to need from the ACP is a status bit >>>>> saying "ACP is up" and a socket API. It might need to peek into the >>>>> adjacency table, but I'm not even sure about that. >>>>>=20 >>>>> True, this chases its own tail a bit if GRASP is used for initial dis= covery, >>>>> and that does need to be tied down. >>>>>=20 >>>>>> I think we need a virtual interim or something like that where we ca= n talk >>>>>> for a longer period of time in a smaller group. >>>>>=20 >>>>> We certainly need to understand what's not fitting together. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >>=20 >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Fri Nov 13 10:58:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FBD1B2FC7 for ; Fri, 13 Nov 2015 10:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, 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 nC9_uN6KZotr for ; Fri, 13 Nov 2015 10:58:48 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 437701B2FCC for ; Fri, 13 Nov 2015 10:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1889; q=dns/txt; s=iport; t=1447441126; x=1448650726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=c5Ka3nMcazUL+SoVKDiv1c7u2hl3GTL0xJScuSHInJQ=; b=PSWxe3HwU5zYAV+KV2F0Kcc46Bk0RqLcNVqcueb1wyWEJG3YAImSru5V ip4Da39g1t5hSLiV66VywOx7OxYC5O47ZgkT3pKqXMqc7Gj0oXmZVLIiH IgMM8P9aoaAEK02oBxQnYHf5R4G8tj4qvnaKMrtYCUR8bc1VtGjkj2+Af U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgBXMkZW/5xdJa1egzuBQr5HAQ2BZ?= =?us-ascii?q?YYQAoE7OBQBAQEBAQEBgQqENAEBAQMBbAoDBQcEAgEIFQMnBzIUEQIEDgWIJgj?= =?us-ascii?q?AWgEBAQEBAQEBAQEBAQEBAQEBAQEaiGSCboRZg0uBFQEElkgBiA2FGZxEAR8BA?= =?us-ascii?q?UKCER2BVnKFPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,288,1444694400"; d="scan'208";a="46509230" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2015 18:58:45 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id tADIwjWo015820 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 18:58:45 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 12:58:45 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 12:58:44 -0600 From: "Max Pritikin (pritikin)" To: "Liubing (Leo)" Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WbFNlXfA390qGwfzbG5IpEJ6WmiYAgAC3MICAANSVgIACLFyD Date: Fri, 13 Nov 2015 18:58:44 +0000 Message-ID: <582DB86C-85E0-4A8A-AA2E-CD67647196F1@cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com>, <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 18:58:50 -0000 Inline, > On Nov 11, 2015, at 7:47 PM, Liubing (Leo) wrote= : >=20 > Hi all, >=20 >> -----Original Message----- >> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max Pritikin >> (pritikin) > ... >> This is what I called out during Yokohama as well. Is it "ACP then GRASP= =94 or >> =93GRASP then ACP then GRASP again=94? Clearly I have a bootstrapping >> perspective but maybe Michael is thinking along the same lines. >=20 > Apart from ASAs, we also need the following signallings: > - a Discovery mechanism during bootstrapping (Boot-Discovery) > - a Discovery/Negotiation mechanism during ACP establishing (ACP-DisNeg) >=20 > The GRASP might have the security state: > - no security at all (GRASP-NonSec) > - TLS/DTLS secured (GRASP-(D)TLS) > - Running in ACP, mostly for ASAs communication (GRASP-ACP) >=20 > If the Boot-Discovery choose GRASP, then I guess we need to make the GRAS= P-NonSec valid as well(in current draft, there is no choice for non-secured= GRASP). Because it would be difficult for GRASP to gain (D)TLS protection = without the bootstrapping ready. > However, as Max said, it seems bootstrapping prefer other discovery mecha= nisms than GRASP? I need to do a homework to figure out the signaling requi= rements of bootstrapping. (Max, if you could give me some hint, that would = be very helpful. Many thanks.) I'm not sure the question you are asking. The new entity needs to establish= a communication channel with the domain. The bootstrapping draft details a= list of possible methods (and a proposed order).=20 - max=20 (mobile device) >=20 > In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if th= e ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is applic= able after bootstrapping, is there any gap? >=20 > Best regards, > Bing From nobody Fri Nov 13 11:07:48 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DAC1B301C for ; Fri, 13 Nov 2015 11:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, 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 RM5N2yYLxGLX for ; Fri, 13 Nov 2015 11:07:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D9ED1B302F for ; Fri, 13 Nov 2015 11:07:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5975; q=dns/txt; s=iport; t=1447441664; x=1448651264; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=30lpz1Ioitunci5u8qGCvjOFTzn5Ai7zlsULlSi4lXI=; b=T/CCOknBb829TsKs7puVZe7CnTKkw8de4ZAJ1H0Y/Y234AYydXBKo3VW eEsF7Bh+2DBKCWhKYUdPR83MVEC1CWFrqBBo1itrlJ5j3MFzQrvgipzf0 vQv1wOIYxnsrPbW32EDXqUsu54xcn0b9jO19V8K17ElBV1nJMNoppemta 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AnAgDKM0ZW/5FdJa1egztTb75HAQ2BZRcKhW8CgTs4FAEBAQEBAQGBCoQ0AQEBAwEBAQFpAgIGAwUHBAIBCBEEAQEBJwchBgsUCQgCBA4FiBkDCggNu14NhFcBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIhkgm6CU4FiJINLgRUFlkgBizGBdZRyh1IBHwEBQoIRHYFWcgGDcwEeB4EjAQEB X-IronPort-AV: E=Sophos;i="5.20,288,1444694400"; d="scan'208";a="208106243" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 13 Nov 2015 19:07:42 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tADJ7g5W030018 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 13 Nov 2015 19:07:42 GMT Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 13 Nov 2015 13:07:41 -0600 Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1104.000; Fri, 13 Nov 2015 13:07:41 -0600 From: "Max Pritikin (pritikin)" To: Brian E Carpenter Thread-Topic: [Anima] comments on current drafts Thread-Index: AQHRHC3WbFNlXfA390qGwfzbG5IpEJ6WmiYAgAC3MICAANSVgIAB5PIAgAAKiwCAAJyvAP//orBW Date: Fri, 13 Nov 2015 19:07:41 +0000 Message-ID: <6B573309-829E-4A13-8392-13E6FD24513F@cisco.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com>, <56462EE4.8070200@gmail.com> In-Reply-To: <56462EE4.8070200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Michael Richardson , "anima@ietf.org" , "Michael Behringer \(mbehring\)" , "Liubing \(Leo\)" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 19:07:46 -0000 Inline, > On Nov 13, 2015, at 10:41 AM, Brian E Carpenter wrote: >=20 > Bing, >=20 >> The only challenge I can see is how to secure GRASP before bootstrap. Ev= en if bootstrap doesn't use GRASP, it is still a challenge for secured sign= aling before that. >=20 > As far as I can tell, you're correct that there are three modes: >=20 > Best: ACP is up, GRASP just sends packets > Medium: No ACP, GRASP must wrap sessions in TLS > Worst: No certificates available, GRASP is insecure. The security considerations for a protocol that only sometimes runs over a = secure transport is going to be painful.=20 - Max=20 >=20 > The reason I was asking Michael some weeks ago about multicast support > in the ACP is because my understanding is that link-local multicast is > intrinsically insecure, so LL discovery messages are intrinsically > insecure. In any case, discovery before bootstrap is insecure, but > I guess the bootstrap design will assume that. >=20 > Regards > Brian >=20 >=20 >=20 > On 13/11/2015 22:20, Liubing (Leo) wrote: >>> -----Original Message----- >>> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >>> Sent: Friday, November 13, 2015 4:43 PM >>> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter >>> Cc: Michael Richardson; anima@ietf.org >>> Subject: RE: [Anima] comments on current drafts >>>=20 >>>> -----Original Message----- >>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) >>>> Sent: 12 November 2015 04:47 >>>> To: Max Pritikin (pritikin) ; Brian E Carpenter >>>> >>>> Cc: Michael Richardson ; anima@ietf.org >>>> Subject: Re: [Anima] comments on current drafts >>>>=20 >>>> Hi all, >>>>=20 >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max >>>>> Pritikin >>>>> (pritikin) >>>> ... >>>>> This is what I called out during Yokohama as well. Is it "ACP then >>>>> GRASP=94 or =93GRASP then ACP then GRASP again=94? Clearly I have a >>>>> bootstrapping perspective but maybe Michael is thinking along the >>>>> same >>>> lines. >>>>=20 >>>> Apart from ASAs, we also need the following signallings: >>>> - a Discovery mechanism during bootstrapping (Boot-Discovery) >>>> - a Discovery/Negotiation mechanism during ACP establishing >>>> (ACP-DisNeg) >>>>=20 >>>> The GRASP might have the security state: >>>> - no security at all (GRASP-NonSec) >>>> - TLS/DTLS secured (GRASP-(D)TLS) >>>> - Running in ACP, mostly for ASAs communication (GRASP-ACP) >>>=20 >>> I think it's not that complicated. >>>=20 >>> GRASP in the ACP is the same GRASP running in the data plane. In one th= e >>> context is secure, in the other not. But the protocol - as I see is - i= s the same. >> [Bing] Yes, exactly. I just wanted to list all the possibilities for eas= e of analysis. >>=20 >>> Discovery in the data plane, which feeds the adjacency table is insecur= e. It >>> feeds the adjacency table. Meaning that the info in the adjacency table >>> cannot be trusted, it's a table of "what nodes around me have claimed". >>>=20 >>> We MAY also validate some info in the adjacency table, for example we >>> could validate the SUDI of a new, not yet bootstrapped neighbour. This = is >>> why I added fields for "validity" in the table I presented in Yokohama.= But I'm >>> not sure that the benefit of this worth it. I somehow like the simplici= ty of the >>> statement "the adjacency table cannot be trusted". >>>=20 >>> Now every action a node takes on the adjacency table has to be clear th= at >>> it's starting with potentially fake data. Therefore, the ACP bring-up, >>> bootstrap, and whatever else we may want to do MUST secure. That means >>> now that *IF* we use GRASP for bootstrap (I don't think this is decided= yet?), >>> in this particular context, GRAPS (or any other protocol we may choose) >>> needs to be secured. >> [Bing] For ACP bring-up, it mostly happens after the bootstrap, so I bel= ieve it won't be a problem for the GRASP to be secured(doing TLS/DTLS shoul= d not be difficult after bootstrap). >> The only challenge I can see is how to secure GRASP before bootstrap. Ev= en if bootstrap doesn't use GRASP, it is still a challenge for secured sign= aling before that. >>=20 >> Best regards, >> Bing >>=20 >>> Now the fact that the adjacency table may contain fake information give= s us >>> a security exposure: A node could at least force repeated negotiations = (for >>> example to establish the ACP). So we need the capability to rate limit = or >>> ignore a particular node, if we learn that it's malicious. >>>=20 >>> Do we agree with this statement that the adjacency table is fed by unse= cured >>> protocols and therefore cannot be trusted blindly? I think this is impo= rtant to >>> capture. >>>=20 >>> Michael >>>=20 >>>> If the Boot-Discovery choose GRASP, then I guess we need to make the >>>> GRASP-NonSec valid as well(in current draft, there is no choice for >>>> non- secured GRASP). Because it would be difficult for GRASP to gain >>>> (D)TLS protection without the bootstrapping ready. >>>> However, as Max said, it seems bootstrapping prefer other discovery >>>> mechanisms than GRASP? I need to do a homework to figure out the >>>> signaling requirements of bootstrapping. (Max, if you could give me >>>> some hint, that would be very helpful. Many thanks.) >>>>=20 >>>> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if >>>> the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is >>>> applicable after bootstrapping, is there any gap? >>>>=20 >>>> Best regards, >>>> Bing >>>> _______________________________________________ >>>> Anima mailing list >>>> Anima@ietf.org >>>> https://www.ietf.org/mailman/listinfo/anima >=20 From nobody Fri Nov 13 11:17:49 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43141B4225 for ; Fri, 13 Nov 2015 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, 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 4ziztAgqSFIR for ; Fri, 13 Nov 2015 11:17:46 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 135301B4224 for ; Fri, 13 Nov 2015 11:17:46 -0800 (PST) Received: by pabfh17 with SMTP id fh17so108613823pab.0 for ; Fri, 13 Nov 2015 11:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=mBrxZz3ndyDI2OYIrYAteNx2Z/u269TN5GprwhcYcYU=; b=z8j6HMG76ASnd8NOeF/61Vhs74N3fMoKVnzqWAHONxAHa4ryXZBx3Xns7TK3clLLVQ i2HbtnRbQ/yU9eEssbdpI+o71xsOVAxkm3OyETB7Z/jHACgvJ3gg+vDQ4FOCChua+7Ti c+kRphHE/LMfnJaG7dbqdkWckwIpj3hzU/uHxNQksgTAmfoG3VTyQqFFxOr6dmBVwZhY w5hR7Tb1QwKtG8T/aRogfaqWGUylRVlxxOhUrENqNeeyrV79REEkyTi9FbLX/zV8ifTN seVN8C5Czun9b/+xA0C0fqkpgOxLQlrcFZJaPVFXgtbjb69akLf1G5FJsRpvBmtfO2dk gRYQ== X-Received: by 10.68.169.34 with SMTP id ab2mr34667525pbc.44.1447442265705; Fri, 13 Nov 2015 11:17:45 -0800 (PST) Received: from ?IPv6:2406:e007:7309:1:28cc:dc4c:9703:6781? ([2406:e007:7309:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xw9sm17716588pab.1.2015.11.13.11.17.41 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 11:17:44 -0800 (PST) To: "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> <56462EE4.8070200@gmail.com> <6B573309-829E-4A13-8392-13E6FD24513F@cisco.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56463760.6060901@gmail.com> Date: Sat, 14 Nov 2015 08:17:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <6B573309-829E-4A13-8392-13E6FD24513F@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Michael Richardson , "anima@ietf.org" , "Michael Behringer \(mbehring\)" , "Liubing \(Leo\)" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 19:17:48 -0000 On 14/11/2015 08:07, Max Pritikin (pritikin) wrote: > Inline, >=20 >> On Nov 13, 2015, at 10:41 AM, Brian E Carpenter wrote: >> >> Bing, >> >>> The only challenge I can see is how to secure GRASP before bootstrap.= Even if bootstrap doesn't use GRASP, it is still a challenge for secured= signaling before that. >> >> As far as I can tell, you're correct that there are three modes: >> >> Best: ACP is up, GRASP just sends packets >> Medium: No ACP, GRASP must wrap sessions in TLS >> Worst: No certificates available, GRASP is insecure. >=20 > The security considerations for a protocol that only sometimes runs ove= r a secure transport is going to be painful.=20 I think we will simply have to restrict operations in a specific way. It seems inevitable to me that only very limited operations are allowed before the bootstrap is complete. (I'm glad we're having this conversatio= n, because that thought has been at the back of my mind for a while.) Brian >=20 > - Max=20 >=20 >> >> The reason I was asking Michael some weeks ago about multicast support= >> in the ACP is because my understanding is that link-local multicast is= >> intrinsically insecure, so LL discovery messages are intrinsically >> insecure. In any case, discovery before bootstrap is insecure, but >> I guess the bootstrap design will assume that. >> >> Regards >> Brian >> >> >> >> On 13/11/2015 22:20, Liubing (Leo) wrote: >>>> -----Original Message----- >>>> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >>>> Sent: Friday, November 13, 2015 4:43 PM >>>> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter >>>> Cc: Michael Richardson; anima@ietf.org >>>> Subject: RE: [Anima] comments on current drafts >>>> >>>>> -----Original Message----- >>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (L= eo) >>>>> Sent: 12 November 2015 04:47 >>>>> To: Max Pritikin (pritikin) ; Brian E Carpenter= >>>>> >>>>> Cc: Michael Richardson ; anima@ietf.org >>>>> Subject: Re: [Anima] comments on current drafts >>>>> >>>>> Hi all, >>>>> >>>>>> -----Original Message----- >>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max >>>>>> Pritikin >>>>>> (pritikin) >>>>> ... >>>>>> This is what I called out during Yokohama as well. Is it "ACP then= >>>>>> GRASP=E2=80=9D or =E2=80=9CGRASP then ACP then GRASP again=E2=80=9D= ? Clearly I have a >>>>>> bootstrapping perspective but maybe Michael is thinking along the >>>>>> same >>>>> lines. >>>>> >>>>> Apart from ASAs, we also need the following signallings: >>>>> - a Discovery mechanism during bootstrapping (Boot-Discovery) >>>>> - a Discovery/Negotiation mechanism during ACP establishing >>>>> (ACP-DisNeg) >>>>> >>>>> The GRASP might have the security state: >>>>> - no security at all (GRASP-NonSec) >>>>> - TLS/DTLS secured (GRASP-(D)TLS) >>>>> - Running in ACP, mostly for ASAs communication (GRASP-ACP) >>>> >>>> I think it's not that complicated. >>>> >>>> GRASP in the ACP is the same GRASP running in the data plane. In one= the >>>> context is secure, in the other not. But the protocol - as I see is = - is the same. >>> [Bing] Yes, exactly. I just wanted to list all the possibilities for = ease of analysis. >>> >>>> Discovery in the data plane, which feeds the adjacency table is inse= cure. It >>>> feeds the adjacency table. Meaning that the info in the adjacency ta= ble >>>> cannot be trusted, it's a table of "what nodes around me have claime= d". >>>> >>>> We MAY also validate some info in the adjacency table, for example w= e >>>> could validate the SUDI of a new, not yet bootstrapped neighbour. Th= is is >>>> why I added fields for "validity" in the table I presented in Yokoha= ma. But I'm >>>> not sure that the benefit of this worth it. I somehow like the simpl= icity of the >>>> statement "the adjacency table cannot be trusted". >>>> >>>> Now every action a node takes on the adjacency table has to be clear= that >>>> it's starting with potentially fake data. Therefore, the ACP bring-u= p, >>>> bootstrap, and whatever else we may want to do MUST secure. That mea= ns >>>> now that *IF* we use GRASP for bootstrap (I don't think this is deci= ded yet?), >>>> in this particular context, GRAPS (or any other protocol we may choo= se) >>>> needs to be secured. >>> [Bing] For ACP bring-up, it mostly happens after the bootstrap, so I = believe it won't be a problem for the GRASP to be secured(doing TLS/DTLS = should not be difficult after bootstrap). >>> The only challenge I can see is how to secure GRASP before bootstrap.= Even if bootstrap doesn't use GRASP, it is still a challenge for secured= signaling before that. >>> >>> Best regards, >>> Bing >>> >>>> Now the fact that the adjacency table may contain fake information g= ives us >>>> a security exposure: A node could at least force repeated negotiatio= ns (for >>>> example to establish the ACP). So we need the capability to rate lim= it or >>>> ignore a particular node, if we learn that it's malicious. >>>> >>>> Do we agree with this statement that the adjacency table is fed by u= nsecured >>>> protocols and therefore cannot be trusted blindly? I think this is i= mportant to >>>> capture. >>>> >>>> Michael >>>> >>>>> If the Boot-Discovery choose GRASP, then I guess we need to make th= e >>>>> GRASP-NonSec valid as well(in current draft, there is no choice for= >>>>> non- secured GRASP). Because it would be difficult for GRASP to gai= n >>>>> (D)TLS protection without the bootstrapping ready. >>>>> However, as Max said, it seems bootstrapping prefer other discovery= >>>>> mechanisms than GRASP? I need to do a homework to figure out the >>>>> signaling requirements of bootstrapping. (Max, if you could give me= >>>>> some hint, that would be very helpful. Many thanks.) >>>>> >>>>> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So,= if >>>>> the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which= is >>>>> applicable after bootstrapping, is there any gap? >>>>> >>>>> Best regards, >>>>> Bing >>>>> _______________________________________________ >>>>> Anima mailing list >>>>> Anima@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Fri Nov 13 13:32:55 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60E31B32AA for ; Fri, 13 Nov 2015 13:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 jGTsD-uoZd5A for ; Fri, 13 Nov 2015 13:32:50 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC121B32AC for ; Fri, 13 Nov 2015 13:32:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4D5951CAE04; Fri, 13 Nov 2015 13:32:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 703D41C05A9; Fri, 13 Nov 2015 13:32:49 -0800 (PST) To: Brian E Carpenter , "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> <56462EE4.8070200@gmail.com> <6B573309-829E-4A13-8392-13E6FD24513F@cisco.com> <56463760.6060901@gmail.com> From: "Joel M. Halpern" Message-ID: <564656FF.7010702@joelhalpern.com> Date: Fri, 13 Nov 2015 16:32:47 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56463760.6060901@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Liubing \(Leo\)" , Michael Richardson , "Michael Behringer \(mbehring\)" , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 21:32:54 -0000 When I read the ACP and GRASP drafts, one of the things that caused me difficulty was that ACP talks about using GRASP, and GRASP talks about using ACP. Now, from reading the recent discussion it is clear that this is not a contradiction, but a descritpion of different phases of operation. Would it be clearer to talk about GRASP-insecure with specific restrictions on what it can do and a focus on supporting the bootstrap process, and grasp-secure which is used later. With ACP interaction more clearly described in terms of two different mechanisms that it interacts with? Yours, Joel On 11/13/15 2:17 PM, Brian E Carpenter wrote: > On 14/11/2015 08:07, Max Pritikin (pritikin) wrote: >> Inline, >> >>> On Nov 13, 2015, at 10:41 AM, Brian E Carpenter wrote: >>> >>> Bing, >>> >>>> The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a challenge for secured signaling before that. >>> >>> As far as I can tell, you're correct that there are three modes: >>> >>> Best: ACP is up, GRASP just sends packets >>> Medium: No ACP, GRASP must wrap sessions in TLS >>> Worst: No certificates available, GRASP is insecure. >> >> The security considerations for a protocol that only sometimes runs over a secure transport is going to be painful. > > I think we will simply have to restrict operations in a specific way. > It seems inevitable to me that only very limited operations are allowed > before the bootstrap is complete. (I'm glad we're having this conversation, > because that thought has been at the back of my mind for a while.) > > Brian > > >> >> - Max >> >>> >>> The reason I was asking Michael some weeks ago about multicast support >>> in the ACP is because my understanding is that link-local multicast is >>> intrinsically insecure, so LL discovery messages are intrinsically >>> insecure. In any case, discovery before bootstrap is insecure, but >>> I guess the bootstrap design will assume that. >>> >>> Regards >>> Brian >>> >>> >>> >>> On 13/11/2015 22:20, Liubing (Leo) wrote: >>>>> -----Original Message----- >>>>> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >>>>> Sent: Friday, November 13, 2015 4:43 PM >>>>> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter >>>>> Cc: Michael Richardson; anima@ietf.org >>>>> Subject: RE: [Anima] comments on current drafts >>>>> >>>>>> -----Original Message----- >>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing (Leo) >>>>>> Sent: 12 November 2015 04:47 >>>>>> To: Max Pritikin (pritikin) ; Brian E Carpenter >>>>>> >>>>>> Cc: Michael Richardson ; anima@ietf.org >>>>>> Subject: Re: [Anima] comments on current drafts >>>>>> >>>>>> Hi all, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max >>>>>>> Pritikin >>>>>>> (pritikin) >>>>>> ... >>>>>>> This is what I called out during Yokohama as well. Is it "ACP then >>>>>>> GRASP†or “GRASP then ACP then GRASP again� Clearly I have a >>>>>>> bootstrapping perspective but maybe Michael is thinking along the >>>>>>> same >>>>>> lines. >>>>>> >>>>>> Apart from ASAs, we also need the following signallings: >>>>>> - a Discovery mechanism during bootstrapping (Boot-Discovery) >>>>>> - a Discovery/Negotiation mechanism during ACP establishing >>>>>> (ACP-DisNeg) >>>>>> >>>>>> The GRASP might have the security state: >>>>>> - no security at all (GRASP-NonSec) >>>>>> - TLS/DTLS secured (GRASP-(D)TLS) >>>>>> - Running in ACP, mostly for ASAs communication (GRASP-ACP) >>>>> >>>>> I think it's not that complicated. >>>>> >>>>> GRASP in the ACP is the same GRASP running in the data plane. In one the >>>>> context is secure, in the other not. But the protocol - as I see is - is the same. >>>> [Bing] Yes, exactly. I just wanted to list all the possibilities for ease of analysis. >>>> >>>>> Discovery in the data plane, which feeds the adjacency table is insecure. It >>>>> feeds the adjacency table. Meaning that the info in the adjacency table >>>>> cannot be trusted, it's a table of "what nodes around me have claimed". >>>>> >>>>> We MAY also validate some info in the adjacency table, for example we >>>>> could validate the SUDI of a new, not yet bootstrapped neighbour. This is >>>>> why I added fields for "validity" in the table I presented in Yokohama. But I'm >>>>> not sure that the benefit of this worth it. I somehow like the simplicity of the >>>>> statement "the adjacency table cannot be trusted". >>>>> >>>>> Now every action a node takes on the adjacency table has to be clear that >>>>> it's starting with potentially fake data. Therefore, the ACP bring-up, >>>>> bootstrap, and whatever else we may want to do MUST secure. That means >>>>> now that *IF* we use GRASP for bootstrap (I don't think this is decided yet?), >>>>> in this particular context, GRAPS (or any other protocol we may choose) >>>>> needs to be secured. >>>> [Bing] For ACP bring-up, it mostly happens after the bootstrap, so I believe it won't be a problem for the GRASP to be secured(doing TLS/DTLS should not be difficult after bootstrap). >>>> The only challenge I can see is how to secure GRASP before bootstrap. Even if bootstrap doesn't use GRASP, it is still a challenge for secured signaling before that. >>>> >>>> Best regards, >>>> Bing >>>> >>>>> Now the fact that the adjacency table may contain fake information gives us >>>>> a security exposure: A node could at least force repeated negotiations (for >>>>> example to establish the ACP). So we need the capability to rate limit or >>>>> ignore a particular node, if we learn that it's malicious. >>>>> >>>>> Do we agree with this statement that the adjacency table is fed by unsecured >>>>> protocols and therefore cannot be trusted blindly? I think this is important to >>>>> capture. >>>>> >>>>> Michael >>>>> >>>>>> If the Boot-Discovery choose GRASP, then I guess we need to make the >>>>>> GRASP-NonSec valid as well(in current draft, there is no choice for >>>>>> non- secured GRASP). Because it would be difficult for GRASP to gain >>>>>> (D)TLS protection without the bootstrapping ready. >>>>>> However, as Max said, it seems bootstrapping prefer other discovery >>>>>> mechanisms than GRASP? I need to do a homework to figure out the >>>>>> signaling requirements of bootstrapping. (Max, if you could give me >>>>>> some hint, that would be very helpful. Many thanks.) >>>>>> >>>>>> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. So, if >>>>>> the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, which is >>>>>> applicable after bootstrapping, is there any gap? >>>>>> >>>>>> Best regards, >>>>>> Bing >>>>>> _______________________________________________ >>>>>> Anima mailing list >>>>>> Anima@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/anima >>> >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Fri Nov 13 14:36:35 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABA81B339F for ; Fri, 13 Nov 2015 14:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_42=0.6, J_CHICKENPOX_75=0.6, 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 szZZZKiinzQV for ; Fri, 13 Nov 2015 14:36:32 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 07DB21B339D for ; Fri, 13 Nov 2015 14:36:32 -0800 (PST) Received: by pacej9 with SMTP id ej9so5915921pac.2 for ; Fri, 13 Nov 2015 14:36:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=irHDRGHIO3q9MfK+qLJqrSIWorIMNgIpx8y1fWn0BvU=; b=K9qtl9TtEUbSHGPphB0qiFRuAgQaeyY4fG4SEqD50U9m2RJtecHCUOTtmUPsBMLoHF CnaX+an/DSLuj0RrTITDXakZLMd1eqsRS5otEhx8fqRl6McZy5vl7nKwqkh1RnJwhpDI 9+LyJ/CXLAYY7nnEMEZpMfBI9YnT+Se0giF2Fqf8ZJp+4PSo8iAsLYDIiX2mfUJq/Y21 LiSrKY/6s3+uQevqUNecz1TUkglCYj7S7Mtqak/8IGMiYElAfNM/Dx2MTL+snNSn54+p +N0m3vg5hSmO00/nsKZlitatevFyRjEQOpVig3m2E0FFa+WiX7yU7ttshIqkDsHoEkHS M47A== X-Received: by 10.66.251.193 with SMTP id zm1mr36427550pac.154.1447454191666; Fri, 13 Nov 2015 14:36:31 -0800 (PST) Received: from ?IPv6:2406:e007:7309:1:28cc:dc4c:9703:6781? ([2406:e007:7309:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xr8sm15922769pab.26.2015.11.13.14.36.27 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 Nov 2015 14:36:30 -0800 (PST) To: "Joel M. Halpern" , "Max Pritikin (pritikin)" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231D56C@nkgeml506-mbx.china.huawei.com> <3ee37c67bb644099891f9d019f990012@XCH-RCD-006.cisco.com> <8AE0F17B87264D4CAC7DE0AA6C406F45C231DC79@nkgeml506-mbx.china.huawei.com> <56462EE4.8070200@gmail.com> <6B573309-829E-4A13-8392-13E6FD24513F@cisco.com> <56463760.6060901@gmail.com> <564656FF.7010702@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <564665F6.3040602@gmail.com> Date: Sat, 14 Nov 2015 11:36:38 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564656FF.7010702@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Liubing \(Leo\)" , Michael Richardson , "Michael Behringer \(mbehring\)" , "anima@ietf.org" Subject: Re: [Anima] comments on current drafts X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2015 22:36:34 -0000 On 14/11/2015 10:32, Joel M. Halpern wrote: > When I read the ACP and GRASP drafts, one of the things that caused me = difficulty was that ACP talks about using GRASP, and > GRASP talks about using ACP. Now, from reading the recent discussion i= t is clear that this is not a contradiction, but a > descritpion of different phases of operation. >=20 > Would it be clearer to talk about GRASP-insecure with specific restrict= ions on what it can do and a focus on supporting the > bootstrap process, and grasp-secure which is used later. With ACP inte= raction more clearly described in terms of two different > mechanisms that it interacts with? Yes. I think most of that belongs in the reference model, with some speci= fics in the GRASP and ACP drafts. Regards Brian >=20 > Yours, > Joel >=20 > On 11/13/15 2:17 PM, Brian E Carpenter wrote: >> On 14/11/2015 08:07, Max Pritikin (pritikin) wrote: >>> Inline, >>> >>>> On Nov 13, 2015, at 10:41 AM, Brian E Carpenter wrote: >>>> >>>> Bing, >>>> >>>>> The only challenge I can see is how to secure GRASP before bootstra= p. Even if bootstrap doesn't use GRASP, it is still a >>>>> challenge for secured signaling before that. >>>> >>>> As far as I can tell, you're correct that there are three modes: >>>> >>>> Best: ACP is up, GRASP just sends packets >>>> Medium: No ACP, GRASP must wrap sessions in TLS >>>> Worst: No certificates available, GRASP is insecure. >>> >>> The security considerations for a protocol that only sometimes runs o= ver a secure transport is going to be painful. >> >> I think we will simply have to restrict operations in a specific way. >> It seems inevitable to me that only very limited operations are allowe= d >> before the bootstrap is complete. (I'm glad we're having this conversa= tion, >> because that thought has been at the back of my mind for a while.) >> >> Brian >> >> >>> >>> - Max >>> >>>> >>>> The reason I was asking Michael some weeks ago about multicast suppo= rt >>>> in the ACP is because my understanding is that link-local multicast = is >>>> intrinsically insecure, so LL discovery messages are intrinsically >>>> insecure. In any case, discovery before bootstrap is insecure, but >>>> I guess the bootstrap design will assume that. >>>> >>>> Regards >>>> Brian >>>> >>>> >>>> >>>> On 13/11/2015 22:20, Liubing (Leo) wrote: >>>>>> -----Original Message----- >>>>>> From: Michael Behringer (mbehring) [mailto:mbehring@cisco.com] >>>>>> Sent: Friday, November 13, 2015 4:43 PM >>>>>> To: Liubing (Leo); Max Pritikin (pritikin); Brian E Carpenter >>>>>> Cc: Michael Richardson; anima@ietf.org >>>>>> Subject: RE: [Anima] comments on current drafts >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Liubing = (Leo) >>>>>>> Sent: 12 November 2015 04:47 >>>>>>> To: Max Pritikin (pritikin) ; Brian E Carpent= er >>>>>>> >>>>>>> Cc: Michael Richardson ; anima@ietf.org >>>>>>> Subject: Re: [Anima] comments on current drafts >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Max >>>>>>>> Pritikin >>>>>>>> (pritikin) >>>>>>> ... >>>>>>>> This is what I called out during Yokohama as well. Is it "ACP th= en >>>>>>>> GRASP=E2=80=9D or =E2=80=9CGRASP then ACP then GRASP again=E2=80= =9D? Clearly I have a >>>>>>>> bootstrapping perspective but maybe Michael is thinking along th= e >>>>>>>> same >>>>>>> lines. >>>>>>> >>>>>>> Apart from ASAs, we also need the following signallings: >>>>>>> - a Discovery mechanism during bootstrapping (Boot-Discovery) >>>>>>> - a Discovery/Negotiation mechanism during ACP establishing >>>>>>> (ACP-DisNeg) >>>>>>> >>>>>>> The GRASP might have the security state: >>>>>>> - no security at all (GRASP-NonSec) >>>>>>> - TLS/DTLS secured (GRASP-(D)TLS) >>>>>>> - Running in ACP, mostly for ASAs communication (GRASP-ACP) >>>>>> >>>>>> I think it's not that complicated. >>>>>> >>>>>> GRASP in the ACP is the same GRASP running in the data plane. In o= ne the >>>>>> context is secure, in the other not. But the protocol - as I see i= s - is the same. >>>>> [Bing] Yes, exactly. I just wanted to list all the possibilities fo= r ease of analysis. >>>>> >>>>>> Discovery in the data plane, which feeds the adjacency table is in= secure. It >>>>>> feeds the adjacency table. Meaning that the info in the adjacency = table >>>>>> cannot be trusted, it's a table of "what nodes around me have clai= med". >>>>>> >>>>>> We MAY also validate some info in the adjacency table, for example= we >>>>>> could validate the SUDI of a new, not yet bootstrapped neighbour. = This is >>>>>> why I added fields for "validity" in the table I presented in Yoko= hama. But I'm >>>>>> not sure that the benefit of this worth it. I somehow like the sim= plicity of the >>>>>> statement "the adjacency table cannot be trusted". >>>>>> >>>>>> Now every action a node takes on the adjacency table has to be cle= ar that >>>>>> it's starting with potentially fake data. Therefore, the ACP bring= -up, >>>>>> bootstrap, and whatever else we may want to do MUST secure. That m= eans >>>>>> now that *IF* we use GRASP for bootstrap (I don't think this is de= cided yet?), >>>>>> in this particular context, GRAPS (or any other protocol we may ch= oose) >>>>>> needs to be secured. >>>>> [Bing] For ACP bring-up, it mostly happens after the bootstrap, so = I believe it won't be a problem for the GRASP to be >>>>> secured(doing TLS/DTLS should not be difficult after bootstrap). >>>>> The only challenge I can see is how to secure GRASP before bootstra= p. Even if bootstrap doesn't use GRASP, it is still a >>>>> challenge for secured signaling before that. >>>>> >>>>> Best regards, >>>>> Bing >>>>> >>>>>> Now the fact that the adjacency table may contain fake information= gives us >>>>>> a security exposure: A node could at least force repeated negotiat= ions (for >>>>>> example to establish the ACP). So we need the capability to rate l= imit or >>>>>> ignore a particular node, if we learn that it's malicious. >>>>>> >>>>>> Do we agree with this statement that the adjacency table is fed by= unsecured >>>>>> protocols and therefore cannot be trusted blindly? I think this is= important to >>>>>> capture. >>>>>> >>>>>> Michael >>>>>> >>>>>>> If the Boot-Discovery choose GRASP, then I guess we need to make = the >>>>>>> GRASP-NonSec valid as well(in current draft, there is no choice f= or >>>>>>> non- secured GRASP). Because it would be difficult for GRASP to g= ain >>>>>>> (D)TLS protection without the bootstrapping ready. >>>>>>> However, as Max said, it seems bootstrapping prefer other discove= ry >>>>>>> mechanisms than GRASP? I need to do a homework to figure out the >>>>>>> signaling requirements of bootstrapping. (Max, if you could give = me >>>>>>> some hint, that would be very helpful. Many thanks.) >>>>>>> >>>>>>> In ACP draft, it specifies that the ACP-DisNeg MUST be secured. S= o, if >>>>>>> the ACP-DisNeg is GRASP, it just assumes GRASP-(D)TLS in use, whi= ch is >>>>>>> applicable after bootstrapping, is there any gap? >>>>>>> >>>>>>> Best regards, >>>>>>> Bing >>>>>>> _______________________________________________ >>>>>>> Anima mailing list >>>>>>> Anima@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/anima >>>> >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >=20 From nobody Thu Nov 19 22:56:00 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782A11A88EA for ; Thu, 19 Nov 2015 22:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 IAXURvq-EQdO for ; Thu, 19 Nov 2015 22:55:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 195741A88E4 for ; Thu, 19 Nov 2015 22:55:55 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAO79292; Fri, 20 Nov 2015 06:55:54 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 20 Nov 2015 06:55:53 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Fri, 20 Nov 2015 14:55:47 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: ANIMA minutes - IETF 94 Thread-Index: AdEjYHmklGswhedgRlyBM/EASGyDDg== Date: Fri, 20 Nov 2015 06:55:46 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BC0C3DB@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.564EC3FA.00C6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 492ffc8f85b009632ca0cb3692d60788 Archived-At: Cc: Laurent Ciavaglia , Toerless Eckert , "anima-chairs@tools.ietf.org" Subject: [Anima] ANIMA minutes - IETF 94 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 06:55:59 -0000 SGksIGFsbCwNCg0KVGhlIG1pbnV0ZXMgZm9yIHRoZSBBTklNQSBzZXNzaW9ucyBhdCBJRVRGOTQg aW4gWW9rb2hhbWEgY2FuIGJlIGZvdW5kIGF0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j ZWVkaW5ncy85NC9taW51dGVzL21pbnV0ZXMtOTQtYW5pbWENCg0KTWFueSB0aGFua3MgdG8gTGF1 cmVudCBDaWF2YWdsaWEgZm9yIHRha2luZyBtaW51dGVzLg0KDQpQbGVhc2Ugc2VuZCBhbnkgY29y cmVjdGlvbnMgdG8gdGhlIGNoYWlycy4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZyArIFRvZXJs ZXNzDQo= From nobody Mon Nov 23 00:59:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1211B386E for ; Mon, 23 Nov 2015 00:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_PENIS=2.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 Fh4skH04HMOc for ; Mon, 23 Nov 2015 00:59:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 092C51B386B for ; Mon, 23 Nov 2015 00:59:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAR39471; Mon, 23 Nov 2015 08:59:40 +0000 (GMT) Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 23 Nov 2015 08:59:39 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.25]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0235.001; Mon, 23 Nov 2015 16:59:34 +0800 From: "Liubing (Leo)" To: "anima@ietf.org" Thread-Topic: GRASP open issues confirmation Thread-Index: AdElzRwnB/gsJizkRlGzwJnWwel+Kw== Date: Mon, 23 Nov 2015 08:59:34 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C234BA35@nkgeml506-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5652D57D.0014, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 57a6771e4a1b73a3d8a8f2a757b4b38d Archived-At: Cc: Carsten Bormann Subject: [Anima] GRASP open issues confirmation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 08:59:45 -0000 Hi Dear all, In Yokohama, we had very constructive discussion of the GRASP open issues. = Thanks for all your valuable comments. As I perceived, there were some issues that seemed consensus during the dis= cussion, let me list them as below. If you have any different opinions, ple= ase feel free to comment. (We also had some issued not reached consensus or clear solution yet, let m= e discuss them separately by different threads later.) - Discovery issues: d1) Handling of multiple valid discovery responses Consensus: multiple responses should be valid use case. However, how to cho= se the most proper response, should NOT within GRASP scope. d2) Do we need "fast withdrawal" of discovery responses? Consensus: GRASP doesn't decide withdrawal of the discovery results; but it= should be able to do the withdrawal indicated by ASAs. d3) Clarify if/when discovery needs to be repeated Consensus: GRASP should NOT decide the repeat time period. It is a use case= specific, should be decided by the ASA. d4) Do we need random delay in discovery response? Consensus: No. But we might need to limit the response rate from the same r= esponder, to prevent DOS attack. - Security issues: s1) Mandatory/Optional to run GRASP in ACP? Consensus: GRASP runs in ACP by default. Data-plane GRASP is allowed as a s= eparate instance. TLS/DTLS needs to be used to protect the data-plane GRASP= . s2) State that role-based authorization of ASAs is out of scope for GRASP Consensus: Agreed. - Other issues: o1) We have specified repeats for failed discovery etc. Is that sufficient = to deal with sleeping nodes? Consensus: It should NOT be GRASP's job to deal with sleeping nodes. (ASA's= job) o2) Private Enterprise Number(PEN) is used to distinguish vendor options. W= ould a domain name be better? Consensus: PEN might not make sense for autonomic nodes; domain name might = be better. o3) Is Session ID sufficient to identify relayed responses? Consensus: Not sufficient, originator's address should be needed. o4) Clarify that a node will contain one GRASP instance supporting multiple= ASAs Consensus: Agreed. Best regards, Bing From nobody Mon Nov 23 11:14:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF811ACDC7 for ; Mon, 23 Nov 2015 11:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 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, MANGLED_PENIS=2.3, 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 FgVzFOybAtVp for ; Mon, 23 Nov 2015 11:14:05 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::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 F351A1ACD87 for ; Mon, 23 Nov 2015 11:14:04 -0800 (PST) Received: by pacdm15 with SMTP id dm15so199892241pac.3 for ; Mon, 23 Nov 2015 11:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=t+AwlSnGpszZI9DUwI09bIFDgDAPLswC9XvQqyxRSrk=; b=qsJD/yXn52iyjrZmUHhIr4QZwH3DYPzOVYMP/4DH1uvVubbfZv2OrexTLVlUyeLs+E SBhRAjK2ZgnxCBq+w6mu3NXjZdtDwocihI1tarW+Cs4pN50rXO6vtnr/4YlWw1C9C888 hS1VXGr2f21lRL9mVO2Suo7iyD7e4YTWHe77Wpuj2MlsarnraPjr66vcx1D7uaE3arKG ZuhxH3iV2G1MDDO2vW7VFanYpaG9tFWNE+apMC4eUHKhPM4JaHW2BCmFVXNj8IiR28b0 pL0zI1gvxgucEu7kowDax7M2UsAoQ6SQFDJiGCsmH1kMTIQHVK4whKatjroK0D4ZtzVI 5twg== X-Received: by 10.67.24.97 with SMTP id ih1mr37824473pad.65.1448306044698; Mon, 23 Nov 2015 11:14:04 -0800 (PST) Received: from [192.168.178.25] (217.24.255.123.static.snap.net.nz. [123.255.24.217]) by smtp.gmail.com with ESMTPSA id g79sm10931580pfj.13.2015.11.23.11.14.00 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 11:14:03 -0800 (PST) To: "Liubing (Leo)" , "anima@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C234BA35@nkgeml506-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56536572.5090906@gmail.com> Date: Tue, 24 Nov 2015 08:13:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C234BA35@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Carsten Bormann Subject: Re: [Anima] GRASP open issues confirmation X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:14:07 -0000 Hi, On 23/11/2015 21:59, Liubing (Leo) wrote: > Hi Dear all, > > In Yokohama, we had very constructive discussion of the GRASP open issues. Thanks for all your valuable comments. > > As I perceived, there were some issues that seemed consensus during the discussion, let me list them as below. If you have any different opinions, please feel free to comment. > (We also had some issued not reached consensus or clear solution yet, let me discuss them separately by different threads later.) > > - Discovery issues: > d1) Handling of multiple valid discovery responses > Consensus: multiple responses should be valid use case. However, how to chose the most proper response, should NOT within GRASP scope. Agreed. It should be left to the ASA. However, I would expect the GRASP engine to have a default choice in case the ASA doesn't care. For the moment I think that can be left as an implementation choice. > d2) Do we need "fast withdrawal" of discovery responses? > Consensus: GRASP doesn't decide withdrawal of the discovery results; but it should be able to do the withdrawal indicated by ASAs. In practice I think an explicit withdrawal isn't needed: what is needed is that an ASA can deregister an objective, so that future requests for that objective will fail. The same thing should happen automatically when an ASA exits. A related issue is whether discovery reponses need an individual TTL (like DNS). At the moment we specify indefinite caching. This also affects the next issue... > d3) Clarify if/when discovery needs to be repeated > Consensus: GRASP should NOT decide the repeat time period. It is a use case specific, should be decided by the ASA. ...which suggests that we do need a TTL. > d4) Do we need random delay in discovery response? > Consensus: No. But we might need to limit the response rate from the same responder, to prevent DOS attack. I think the draft already suggests this when relaying responses. > > - Security issues: > s1) Mandatory/Optional to run GRASP in ACP? > Consensus: GRASP runs in ACP by default. Data-plane GRASP is allowed as a separate instance. TLS/DTLS needs to be used to protect the data-plane GRASP. That is more or less what the draft says now. The IESG has just had an interesting discussion of a similar point for HNCP. We need to be clear about the difference between "mandatory to implement" and "mandatory to use". > s2) State that role-based authorization of ASAs is out of scope for GRASP > Consensus: Agreed. > > - Other issues: > o1) We have specified repeats for failed discovery etc. Is that sufficient to deal with sleeping nodes? > Consensus: It should NOT be GRASP's job to deal with sleeping nodes. (ASA's job) Generally agreed, but we surely need to think about what happens if the GRASP engine itself sleeps. > o2) Private Enterprise Number(PEN) is used to distinguish vendor options. Would a domain name be better? > Consensus: PEN might not make sense for autonomic nodes; domain name might be better. I will send a separate message about this. > o3) Is Session ID sufficient to identify relayed responses? > Consensus: Not sufficient, originator's address should be needed. Probably correct, although the collision probability is extremely low. > o4) Clarify that a node will contain one GRASP instance supporting multiple ASAs > Consensus: Agreed. > > > Best regards, > Bing > From nobody Mon Nov 23 11:34:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F261B32C3 for ; Mon, 23 Nov 2015 11:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 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, MANGLED_PENIS=2.3, 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 1Vc3d1fIPKgh for ; Mon, 23 Nov 2015 11:34:51 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 21A151B32C8 for ; Mon, 23 Nov 2015 11:34:51 -0800 (PST) Received: by pabfh17 with SMTP id fh17so206342238pab.0 for ; Mon, 23 Nov 2015 11:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=6qJDLO93xtl2C9YJJDz3IELOr+JcnhB5/jWhNEAjGLM=; b=wMIo+duHmQMKNwoENR+zFBWpqV3nPJTsVvaqz70JvBUd01r+QfUuXMoljzU1isL0HD 4oWXvUKtGimVIRPp71y77+vDARCouHbOcjLsjy3p/dwl3DO0/GtqZrYWA66y2wh5IU6C TTISzGPbZA3X42iWZ6f+8P4u9uWweMWvSgvEK5K4nqPBSQjsYXFZyCi1VT/My1YXwmpk CauPoSW+05seX60G/VTVOt2QoFxicDVylUoPDt8pOAbppnC4eZtMayHrZFSUqqzDGmFK MTwZ1zzYEiV0LdhfJhK+SK0MPt1yC0MCzkB71CI7XHClM8m500Rd8n6fS7ePtYNWwq7g E/0g== X-Received: by 10.68.113.194 with SMTP id ja2mr38143223pbb.52.1448307290776; Mon, 23 Nov 2015 11:34:50 -0800 (PST) Received: from [192.168.178.25] (217.24.255.123.static.snap.net.nz. [123.255.24.217]) by smtp.gmail.com with ESMTPSA id cm2sm3564812pbb.77.2015.11.23.11.34.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 23 Nov 2015 11:34:48 -0800 (PST) To: "Liubing (Leo)" , "anima@ietf.org" References: <8AE0F17B87264D4CAC7DE0AA6C406F45C234BA35@nkgeml506-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <56536A58.2030005@gmail.com> Date: Tue, 24 Nov 2015 08:34:48 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <8AE0F17B87264D4CAC7DE0AA6C406F45C234BA35@nkgeml506-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Carsten Bormann Subject: [Anima] PEN v domain name [GRASP open issues confirmation] X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 19:34:52 -0000 >> o2) Private Enterprise Number(PEN) is used to distinguish vendor options. Would a domain name be better? >> Consensus: PEN might not make sense for autonomic nodes; domain name might be better. The point here is that some GRASP objectives will be standardised and their names will be in an IANA registry; they don't need either a PEN or a domain name. Other objectives will be non-standardised; we call them "vendor" options but of course they could be private in any way, open-source, or whatever. However, to make them unique, they need some tag that is guaranteed to be unique, which means we need to pick something that is registered somewhere. The two obvious choices are PEN numbers or domain names. PEN numbers (draft-liang-iana-pen) are fixed length (32 bit) integers introduced for SNMP (but with no dependency on SNMP), allocated FCFS at no cost. This morning, there are 46768 of them allocated. Domain names are variable length strings. They cost money to obtain and maintain. They can vanish or be re-assigned. >From a GRASP efficiency point of view, I think that 32 bit integers are marginally better. Regards Brian From nobody Sun Nov 29 13:00:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991B31B3AF8 for ; Sun, 29 Nov 2015 13:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, RP_MATCHES_RCVD=-0.585, 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 u1q4uagM4ulP for ; Sun, 29 Nov 2015 13:00:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CB11B3AF7 for ; Sun, 29 Nov 2015 13:00:30 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DD4672009E for ; Sun, 29 Nov 2015 16:05:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 44B1163753; Sun, 29 Nov 2015 16:00:29 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 24B34636C4 for ; Sun, 29 Nov 2015 16:00:29 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: [Anima] some comments/edits on -- draft-ietf-anima-autonomic-control-plane-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:00:32 -0000 --=-=-= Content-Type: text/plain I mentioned a series of comments that I had on the ANIMA documents back in a thread. I formed these opinions on the airplane home, here is the first of my detailed comments. {I've sent some edits to Michael Behringer via github, see also: https://github.com/mcr/anima-control-plane/commit/4d7e60e17502d0b5025014e9cb8ad93dc95f831d } 1) In (page 2) "Today, the management..." I suggest "console ports" -> "console (craft) ports". I didn't know the term "craft terminal" to refer to an out-of-band serial console interface, but apparently that's the telco term going back decades. 2) about section 2.3: Data plane connectivity can be affected by errors and faults, for example certain AAA misconfigurations can lock an administrator out of a device; routing or addressing issues can make a device unreachable; shutting down interfaces over which a current management session is running can lock an admin irreversibly out of the device. Traditionally only console access can help recover from such issues. ===> when I was first introduced to the ANIMA ACP concept, one of the things that I understood was that the ANIMA ACP might even operate across interfaces which were marked administratively down. I suspect that a bunch of platforms can simply physically not do this, and even on ones where this can be done, it may violate expectations of administrators. On the other hand, downing an interface is a common shoot-yourself-in-the-foot experience that "lock an admin irreversibly out of the device", and is a common reason to have the craft terminal place in the first place. There are also sometimes changes that require an interface (or line card) to be shutdown in order to change the major characteristics of the interface. That can include things like changing what port-based VLAN the untagged interface belongs to, changing the lambda for the laser, switching from the copper to SPF interface... Some of these things might really cause the ACP to fail on that port. I think that section 2.3 should mention the "admin down" situation, and perhaps should introduce some new term which distinguishes between "admin down" (but ACP up), and "port logically unplugged". Further, it's clear that the ACP needs to place a requirement on the routing protocol, which is the ability to for a port to announce that it is "going away", and to determine what the topology is going to be once that link is down, and if any other devices will be orphaned as a result. 3) questions about 5.3: " Autonomic devices may have different capabilities based on the type of device, OS version, etc. To establish a trusted secure ACP channel, devices must first negotiate their mutual capabilities in the data plane. This allows for the support of different channel types in the future. For each node on the candidate ACP neighbor list, capabilities need to be exchanged. The capability negotiation is based on GRASP [I-D.ietf-anima-grasp]. The relevant protocol details are defined in Section 7. This negotiation MUST be secure: The identity of the other node MUST be validated during capability negotiation, and the exchange MUST be authenticated. The first parameter to be negotiated is the ACP Channel type. The channel types are defined in Section 8. Other parameters may be added later. " I find this section to be of extreme concern *as written*. Section 7 is essentially unwritten at present. a) We can use GRASP to get the list of nodes which might speak ACP, and we can even get the list of channel types, which I guess would today include the singleton "IKEv2". (There being no other IETF standard secure transports for *IP* packets) I don't think that we can validate the identity of the node during capability negotiation. b) I don't think we want to do capability negotiation in the clear. IKEv2 has more than enough facilities for doing this privately, and for permitting all kinds of new capabilities to be negotiated. Section 8 should not list "GRE with IPsec transport", but should list, "IKEv2". Whether to do GRE+IPsec or some other structure involving IPsec (such as IP proto = 98 + transport or IP proto = 4 + transport) can be negotiated by IKEv2. 4) Section 7's says: > This section describes the negotiation exchange in detail. It is > based on GRASP [I-D.ietf-anima-grasp]. Since at the time of > establishing the ACP channel there is obviously no ACP yet, this > negotiation protocol must run in the data plane. This negotiation > MUST be authenticated, to avoid downgrade attackes, where an attacker > injects bogus negotiation messages demanding a less secure ACP > channel type. The negotiation MAY be encrypted. I don't like the term "data plane" here, I think it's confusing, but I understand what is being said. I think we need a different term here. For ethernet-type wired interfaces, it means doing this: 1) using link-layer IPv6 2) over untagged, 802.3 layer 3) we might even need to say something about a specific default lambda, or way to figure out what is being used, etc. For 802.11-type interfaces, we probably also need to talk about ESSIDs, ad-hoc vs managed mode, WEP/WPA keys (or lack of them), etc. As I said above, this negotiation can not be authenticated, nor do we want any kind of "negotiation" here. It's just a solicitation of possible peers. An IKEv2 SA_INIT message sent to a multicast destination would actually work rather well, and would have the advantage that the GRASP daemon would never see hostile packets. section 9. Self-Healing Properties ... > If an existing device gets revoked, it will automatically be > denied access to the ACP as its domain certificate will be > validated against a Certificate Revocation List during > authentication. Since the revocation check is only done at the > establishment of a new security association, existing ones are not > automatically torn down. If an immediate disconnect is required, > existing sessions to a freshly revoked device can be re-set. This is a pretty sticky issue, I think. Too much poking into the ACP from management process, I think, and not enough self-healing. The IPSEC WG has struggled with this question repeatedly, and in the end came to the view that IKEv2 SAs and associated IPsec SAs do not expire when the certificate expires, and that the duration of the CRL does not limit the SA lifetime. RFC4945, section 3.2.3 discusses not sending CRLs in-band, and I was sure that 7296 (IKEv2) said something specific that confirmed this point, but I can't find it. It would be best perhaps to limit IKEv2 PARENT SA lifetimes to something on the order of the CRL lifetime in the ACP context. <*all for ACP document*> -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVltnbICLcPvd0N1lAQJjPQf/U2xqkvYLWet5okMmNsviBAMT6Fa0mVdg ZIFFjkKkri2jPReBvDHazdhGGWBHEcw5XyOCOIwfhEkEX5ilgJ0gJhQen2EVgIZl JiBeq2uiTy5zF296L3olAHgNHfYwpAdRUQzvgOj/bjTw296ix2bOgBvDmUFlwxoj DygbpXZ20m561CKk6ArT3GLnWQQnCDlpG7WZFT7iuEi154pAHHec5vncP8rpxLUg YLSQWN+ITP4mILCBhEypDR/imgqnWLVA6jJDR79P/anzQ5pQlG6WKqU5M/Ptogof PPMgMkRnxdbTFr57rdLgs3p17eun2AUySbbMmOJxjB9OFVvQtkyf7Q== =CebX -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 29 13:43:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E51B3531 for ; Sun, 29 Nov 2015 13:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585, 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 KnSQhdfD18v6 for ; Sun, 29 Nov 2015 13:43:45 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AAE01B352D for ; Sun, 29 Nov 2015 13:43:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 289BB200A5 for ; Sun, 29 Nov 2015 16:48:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 6E9B063753; Sun, 29 Nov 2015 16:43:44 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5934A636C4 for ; Sun, 29 Nov 2015 16:43:44 -0500 (EST) From: Michael Richardson To: anima@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: [Anima] some comments on -- draft-ietf-anima-grasp-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 21:43:47 -0000 --=-=-= Content-Type: text/plain section 2.1, part 2. >2.1. Requirements for Discovery > 2. When an ASA first starts up, it has no knowledge of the specific > network to which it is attached. Therefore the discovery process > must be able to support any network scenario, assuming only that the > device concerned is bootstrapped from factory condition. I'm thinking that there is more to this: the ASA may assume that the device, having been bootstrapped, now has a secured ACP with the local machine. (The exception being a bootstrap ASA, but I'm not convinced GRASP should be used for that) I think that we should also need to think about channel binding mechanisms so that the ASA doesn't have to do all it's own security work, and so that an ASA can potentially put a bit more trust into the source address of a packet. We also need to discuss how/if an ASA that do wants to do its own security gets access to the validated device identity. The possibility that the device would act as a sub-CA signing each of the ASAs. Another model would have the device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating that ASA-specific-CA being a meta goal.) > 8. The discovery process must not generate excessive (multicast) > traffic and must take account of sleeping nodes in the case of a > resource-constrained network [RFC7228]. First, 7228 defines constrained devices, and challenged networks. "resource-constrained network" isn't a thing in 7228, so that needs to be clarified. Second, if the ACP is implemented as I think it ought to, we won't support any kind of native multicast. We could provide multicast via draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM. I don't think it's worth doing any of these things at the IP layer, I think that there will be grasp daemons running at each vertice of the ACP, and so I think that we should do flooding at the application layer, much like DNCP does for Homenet. > 25. The protocol needs to be fully secured against forged messages > and man-in-the middle attacks, and secured as much as reasonably > possible against denial of service attacks. It needs to be capable > of encryption in order to resist unwanted monitoring, although this > capability may not be required in all deployments. However, it is > not required that the protocol itself provides these security > features; it may depend on an existing secure environment. I feel like there is too much hedging. This is where my comment that we seem to be writing at cross-purposes come to play. I think it would be better to say: + 25. The protocol is expected to run on top of a secure infrastructure provided by the Autonomic Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane]. The ACP is expected to defend against: forged messages and man-in-the middle attacks, as well as provide for mitigation of against denial of service attacks from nodes not into the ACP. The ACP is further expected to provide a private channel. I think that the words here: > , although this > capability may not be required in all deployments. are insufficiently supported. Why should the protocol be complicated in this fashion? 3.3.1 goes on to say: >3.3.1. Required External Security Mechanism > > The protocol SHOULD run within a secure Autonomic Control Plane (ACP) > [I-D.ietf-anima-autonomic-control-plane]. The ACP MUST provide a > status indicator to inform GRASP that the ACP is operational. > > If there is no ACP, the protocol MUST use another form of strong > authentication and SHOULD use a form of strong encryption. TLS > [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based > on a local Public Key Infrastructure (PKI) [RFC5280] managed within > the autonomic network itself. so, let's not sit on the fence here. Can we please decide if we want an ACP, and if we don't, then let's stop working on it. If the designers of GRASP are thinking of using it in some other non-Autonomic situation, then please write a new document that inherits from draft-ietf-anima-grasp for that purpose. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVltxkICLcPvd0N1lAQJdHwgAlw/mwoDuX2kgaKJO4i97+XL9+VLk2IvH hxjX1Fwqm5ZCi1fUt2yudxGkGwwmCFCFkmtC3HyEkdy3p7URuYNBmrIA6u0IdhOg b97/Lcjn4s0VQ6AG13WYGyMgmP3ESRyYSJNr6kMsZ4VC3JW0GZY+yo6KkOqHsbjl UUb/K9YvW6GBmfvTu4dDOwGYB3Huh6jY5q4ymcUOiwJQwyhn4pZMF1qEp/0EjNOw dTx1808ISyvzaqQ/14yDbSGcDcH5ukwiCuiswBjZWZHFDW5e5Zj0L0i6KUTVV5UG DP3yH/x7kfNpteIn107ApcvfNI9ECs/yOvx55I8EaniQ5FWyPI6vHw== =4YEV -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 29 15:21:25 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE91B3B54 for ; Sun, 29 Nov 2015 15:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, 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 lKSPjXFqj3N4 for ; Sun, 29 Nov 2015 15:21:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FB01B3B52 for ; Sun, 29 Nov 2015 15:21:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0562C2009E for ; Sun, 29 Nov 2015 18:26:24 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1A87963753; Sun, 29 Nov 2015 18:21:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 065BE636C4 for ; Sun, 29 Nov 2015 18:21:21 -0500 (EST) From: Michael Richardson To: "anima\@ietf.org" In-Reply-To: <5643949B.8050602@gmail.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: [Anima] discoverying ACP peers (was Re: comments on current drafts) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 23:21:24 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > As far as I can see so far, when the GRASP protocol engine comes up, > the first thing it will do is ask the ACP "are you up?". Assuming the > ACP says no, GRASP knows that it is running insecurely. Apart from that > its discovery mechanism will be available and if either the secure > bootstrap mechanism or the ACP wants to execute GRASP discovery it can > do so. That would imply that the bootstrap and the ACP each supports a > notional GRASP objective to allow discovery; these could be objectives > with no value field. For example, assume every bootstrap relay supports > an objective called "bootRelay" and every ACP engine supports an > objective called "ACP". There are really two scenarios ACP.areyouup = false. 1) before bootstrap. 2) when device is not connected to any other ANIMA connected device. Those are not the same thing. And for #2, this condition can persist on a per-interface basis for a long time. We also, in the context of running GRASP insecurely on a particular interface, need to think hard about what GRASP might reveal from a privacy point of view. Some interfaces may *never* be used for the ACP, they could be customer facing, etc. Yet, we need to periodically see if as a result of some cables being re-arranged, there is now a machine that *is* part of the domain. An example here would be where an ISP's switches from using the ISP provided CPE to their own CPE, or back again. We also need to consider if/how we run on virtual interfaces: for instance VLANs. One might argue that GRASP should only run on physical (untagged) interfaces, but it is not uncommon in access networks for a single fat (containing hundreds of tagged VLANs) pipe to come in a datacenter, and be broken out by an external entity into physical connectors elsewhere, which plug into equipment that should be part of the domain. This is typically when purchasing lit fiber from an incumbent telco for instance. > Then when each bootstrap relay agent comes up it tells its local GRASP > engine that it's available to be discovered. In my prototype that would > use a function called grasp.register_obj(). Any device that wanted to > find a relay agent would ask its local GRASP engine using a function > called grasp.discover(). ACP engines would discover each other > similarly. What they do when they've found each other is out of scope > for GRASP. In your context/mind, what is a "bootstrap relay agent"? > Clearly at that stage everybody is using non-ACP addresses (link-local > mainly) until the bootstrap phase is over and the ACP is established. > Does this make any sense? Yes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVluIcICLcPvd0N1lAQJNdggAmfsZH91jEcJA6eYfeEKvOXI7GH55uRem ogYn0Mhjc3/t8gxU9nu9UQfNGRy7pNldYig7pfUFbmi41C8gkUTw5nt6+JVYXfUX 1VT8ofNp8l+WUH6MBYB1JBAdbP8zh1nXZvBpWxLYgjFGYL2ntbQky8fP0vIdZn1W aTV/sI1owo6Ll5sV2wYKH0hRgoHM/fIKrsacLaFQUdMP2AGtoCx0YbMQlHfdo67j tdE51gMxbFxuBtP2TfNkTvxrmxGkabxDeMFh73OQQ7CgJUSXooRJW/aqTiA4ofox f5HvaFqWHab+9HkZzT7yczR0kmbD3C9m0Pfq+BNFzfhdjWORv89MNg== =JB3K -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Nov 29 17:23:10 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABC61B3D9A; Sun, 29 Nov 2015 17:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 pKCmDnO3TpmQ; Sun, 29 Nov 2015 17:23:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DADE1B3D98; Sun, 29 Nov 2015 17:23:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAZ06787; Mon, 30 Nov 2015 01:23:02 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 Nov 2015 01:23:00 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Mon, 30 Nov 2015 09:22:54 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, Thread-Index: AdErDZ/OREk3eq6SSMm035pLFX9CVQ== Date: Mon, 30 Nov 2015 01:22:53 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BC13A99@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0204.565BA4F7.0082, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5e74eb588f0b07679c82270138a67423 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 01:23:08 -0000 VGhlcmUgd2FzIGNsZWFyIGNvbnNlbnN1cyBmb3IgYWRvcHRpbmcgZHJhZnQtZWNrZXJ0LWFuaW1h LXN0YWJsZS1jb25uZWN0aXZpdHkgYXMgYQ0KQU5JTUEgd29ya2luZyBncm91cCBkb2N1bWVudCBp biB0aGUgSUVURiA5NCBBTklNQSBXRyBtZWV0aW5nLCBZb2tvaGFtYS4gDQpUaGlzIG1lc3NhZ2Ug c3RhcnRzIGEgdHdvLXdlZWsgY2FsbCBvbiBjb25maXJtaW5nIHRoZSBjb25zZW5zdXMgZnJvbSB0 aGUgV0cgbWVldGluZy4NCg0KICBUaXRsZTogICAgICBVc2luZyBBdXRvbm9taWMgQ29udHJvbCBQ bGFuZSBmb3IgU3RhYmxlIENvbm5lY3Rpdml0eSBvZiBOZXR3b3JrIE9BTQ0KICAgICAgICAgICAg ICAgZHJhZnQtZWNrZXJ0LWFuaW1hLXN0YWJsZS1jb25uZWN0aXZpdHktMDINCiAgQXV0aG9ycyA6 ICAgRWNrZXJ0ICYgQmVocmluZ2VyDQogIEZpbGVuYW1lOiAgZHJhZnQtZWNrZXJ0LWFuaW1hLXN0 YWJsZS1jb25uZWN0aXZpdHkNCiAgDQogIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1lY2tlcnQtYW5pbWEtc3RhYmxlLWNvbm5lY3Rpdml0eS0wMg0KDQpQbGVhc2UgZXhwcmVzcyB5 b3VyIHN1cHBvcnQgb3IgcmVqZWN0aW9uLiBJZiB5b3UgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91 bGQgX25vdF8gYmUNCmFkb3B0ZWQsIHBsZWFzZSBhbHNvIGV4cGxpY2l0bHkgaW5kaWNhdGUgdGhl IHJlYXNvbnMuDQoNClRoaXMgYWRvcHRpb24gY2FsbCB3aWxsIGVuZCBvbiBEZWNlbWJlciAxMywg MjAxNS4NCg0KUmVnYXJkcywNCg0KU2hlbmcgKyBUb2VybGVzcw0K From nobody Sun Nov 29 17:26:46 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77631B3DAB; Sun, 29 Nov 2015 17:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 GWjkMDwHW3BK; Sun, 29 Nov 2015 17:26:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3621B3DA9; Sun, 29 Nov 2015 17:26:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAZ06978; Mon, 30 Nov 2015 01:26:41 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 Nov 2015 01:26:40 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Mon, 30 Nov 2015 09:26:24 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, Thread-Index: AdErDh0mdYVIx5VPSHyXP1QccUJaDg== Date: Mon, 30 Nov 2015 01:26:23 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.565BA5D1.00E0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a33f54c741e15f6581a2c8555e14b0af Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 01:26:45 -0000 VGhlcmUgd2FzIGNsZWFyIGNvbnNlbnN1cyBmb3IgYWRvcHRpbmcgZHJhZnQtamlhbmctYW5pbWEt cHJlZml4LW1hbmFnZW1lbnQgYXMgYQ0KQU5JTUEgd29ya2luZyBncm91cCBkb2N1bWVudCBpbiB0 aGUgSUVURiA5NCBBTklNQSBXRyBtZWV0aW5nLCBZb2tvaGFtYS4gDQpUaGlzIG1lc3NhZ2Ugc3Rh cnRzIGEgdHdvLXdlZWsgY2FsbCBvbiBjb25maXJtaW5nIHRoZSBjb25zZW5zdXMgZnJvbSB0aGUg V0cgbWVldGluZy4NCg0KICBUaXRsZTogICAgICBBdXRvbm9taWMgUHJlZml4IE1hbmFnZW1lbnQg aW4gTGFyZ2Utc2NhbGUgTmV0d29ya3MNCiAgQXV0aG9ycyA6ICAgSmlhbmcsIGV0IGFsLg0KICBG aWxlbmFtZTogIGRyYWZ0LWppYW5nLWFuaW1hLXByZWZpeC1tYW5hZ2VtZW50DQogIA0KICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtamlhbmctYW5pbWEtcHJlZml4LW1hbmFnZW1l bnQNCg0KUGxlYXNlIGV4cHJlc3MgeW91ciBzdXBwb3J0IG9yIHJlamVjdGlvbi4gSWYgeW91IHRo aW5rIHRoaXMgZG9jdW1lbnQgc2hvdWxkIF9ub3RfIGJlDQphZG9wdGVkLCBwbGVhc2UgYWxzbyBl eHBsaWNpdGx5IGluZGljYXRlIHRoZSByZWFzb25zLg0KDQpUaGlzIGFkb3B0aW9uIGNhbGwgd2ls bCBlbmQgb24gRGVjZW1iZXIgMTMsIDIwMTUuDQoNClJlZ2FyZHMsDQoNClNoZW5nICsgVG9lcmxl c3MNCg== From nobody Sun Nov 29 18:03:42 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC791A1B3D; Sun, 29 Nov 2015 18:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.786 X-Spam-Level: X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585, 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 Yl8tRNItJ3yt; Sun, 29 Nov 2015 18:03:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DED91A1B3C; Sun, 29 Nov 2015 18:03:39 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAZ08899; Mon, 30 Nov 2015 02:03:37 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 30 Nov 2015 02:03:36 +0000 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.181]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Mon, 30 Nov 2015 10:03:26 +0800 From: Sheng Jiang To: "anima@ietf.org" Thread-Topic: Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, Thread-Index: AdErE0vY9sfhGHquQrmKmfMK1Vb58w== Date: Mon, 30 Nov 2015 02:03:26 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.565BAE79.016B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.181, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d44c50dc4076c7b98390aa2665348fbc Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:03:42 -0000 VGhlcmUgd2FzIGNsZWFyIGNvbnNlbnN1cyBmb3IgYWRvcHRpbmcgZHJhZnQtYmVocmluZ2VyLWFu aW1hLXJlZmVyZW5jZS1tb2RlbCBhcyBhDQpBTklNQSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGlu IHRoZSBJRVRGIDk0IEFOSU1BIFdHIG1lZXRpbmcsIFlva29oYW1hLiANClRoaXMgbWVzc2FnZSBz dGFydHMgYSB0d28td2VlayBjYWxsIG9uIGNvbmZpcm1pbmcgdGhlIGNvbnNlbnN1cyBmcm9tIHRo ZSBXRyBtZWV0aW5nLg0KDQogIFRpdGxlOiAgICAgIEEgUmVmZXJlbmNlIE1vZGVsIGZvciBBdXRv bm9taWMgTmV0d29ya2luZw0KICBBdXRob3JzIDogICBDYXJwZW50ZXIsIGV0IGFsLg0KICBGaWxl bmFtZTogIGRyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwtMDQNCiAgDQogIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNl LW1vZGVsLTA0DQoNClBsZWFzZSBleHByZXNzIHlvdXIgc3VwcG9ydCBvciByZWplY3Rpb24uIElm IHlvdSB0aGluayB0aGlzIGRvY3VtZW50IHNob3VsZCBfbm90XyBiZQ0KYWRvcHRlZCwgcGxlYXNl IGFsc28gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGUgcmVhc29ucy4NCg0KVGhpcyBhZG9wdGlvbiBj YWxsIHdpbGwgZW5kIG9uIERlY2VtYmVyIDEzLCAyMDE1Lg0KDQpSZWdhcmRzLA0KDQpTaGVuZyAr IFRvZXJsZXNzDQo= From nobody Sun Nov 29 18:44:32 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54AB1A1E0F; Sun, 29 Nov 2015 18:44:31 -0800 (PST) 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 EqR1kR4V3d8c; Sun, 29 Nov 2015 18:44:29 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 C9DD61A1EB7; Sun, 29 Nov 2015 18:44:29 -0800 (PST) Received: by pabfh17 with SMTP id fh17so173796606pab.0; Sun, 29 Nov 2015 18:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=H6KLBb84eArE+HqS8kNiogaVTDUAyQUNKZ4dqmUR/Kc=; b=l1r9QYqBViUAPEdnvxbajFRFzHM22PSRGS2jnxNXR5spaWuZSvoz0uO1KkpU+BdctF 9cx907i2+GL7aVMg1PSd7fkVluyWoJb9jeP0u+hQ21EwFOV3jke8t8Ndti2219y0+pPj Gi/dit/n6BriCPgW7agEEAQQLM2pZ0uDJjEvh2xDj/yR6RUkKBSned74x7GmvozsvF9k +JxEYcpC2PlXlDjvqmwXzafJM/E7zDzcI+S3KKhrykfzvfDwnJTgGsVUDtk60D2NRyPH Y8Z6QaAPST9u6qcs37XS3diPi8WwrQrv7z2F+C/bwVU4LpkU88+SLZUdZNspMErbEFs4 qB2A== X-Received: by 10.66.190.66 with SMTP id go2mr88215609pac.114.1448851469110; Sun, 29 Nov 2015 18:44:29 -0800 (PST) Received: from ?IPv6:2406:e007:6509:1:28cc:dc4c:9703:6781? ([2406:e007:6509:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 186sm18975993pfa.24.2015.11.29.18.44.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 18:44:28 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13A99@nkgeml512-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565BB809.6020707@gmail.com> Date: Mon, 30 Nov 2015 15:44:25 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13A99@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:44:31 -0000 Hi, I support this being adopted. Although it's an 'internal' use case, I think it covers a very important aspect of the Anima environment. Regards Brian On 30/11/2015 14:22, Sheng Jiang wrote: > There was clear consensus for adopting draft-eckert-anima-stable-connectivity as a > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the WG meeting. > > Title: Using Autonomic Control Plane for Stable Connectivity of Network OAM > draft-eckert-anima-stable-connectivity-02 > Authors : Eckert & Behringer > Filename: draft-eckert-anima-stable-connectivity > > https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity-02 > > Please express your support or rejection. If you think this document should _not_ be > adopted, please also explicitly indicate the reasons. > > This adoption call will end on December 13, 2015. > > Regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Nov 29 18:46:26 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A631A1EF1; Sun, 29 Nov 2015 18:46:23 -0800 (PST) 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 kMoPLcKthMLL; Sun, 29 Nov 2015 18:46:22 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e: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 ACD7D1A1EED; Sun, 29 Nov 2015 18:46:22 -0800 (PST) Received: by pacej9 with SMTP id ej9so168682809pac.2; Sun, 29 Nov 2015 18:46:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=K0e677R6FOJ6VyKOsyfsw6CpinnOzW1seS17u2insYM=; b=yMnpVAPD+tsO6IytZDFFCkuIvWkwXXt6f99sJOMik0qx+SFiwqIhegjaEwo1boKRwV 1lC+5OUZvmGBQB0MvGIPrpliO/1Ehl+LjBKCpU72MTXU+sEWv9tUZd9ykaNohCVnfhkU mdKzH0Hh32y4mi2FggyyEOCCLZXV7h1n0Ir85MtquKS2Lhz+VCVy0u/Mzc73l/V3tjvl 6nd+JZTNpXA+eoUnP4ped3rqe9kQiK4zP00ACXb2lRRbzWZSrQxGFQukOfaycT4UBz1I q7joZXGDA4hVu6iQvjEparhveyx6PqSA0XNDmsqJh0S1a/mWzz5Va0JqYJV4blgP6sHe w20A== X-Received: by 10.98.17.152 with SMTP id 24mr67188242pfr.41.1448851582375; Sun, 29 Nov 2015 18:46:22 -0800 (PST) Received: from ?IPv6:2406:e007:6509:1:28cc:dc4c:9703:6781? ([2406:e007:6509:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id p26sm47251766pfi.94.2015.11.29.18.46.19 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 18:46:21 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565BB87C.3000504@gmail.com> Date: Mon, 30 Nov 2015 15:46:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:46:24 -0000 Hi, I'm a co-author of this draft but in any case I support its adoption. I'm very well aware it still needs work; in fact I expect it to remain unfinished until at least the GRASP, ACP and bootstrap specifications are stable. Regards Brian On 30/11/2015 15:03, Sheng Jiang wrote: > There was clear consensus for adopting draft-behringer-anima-reference-model as a > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the WG meeting. > > Title: A Reference Model for Autonomic Networking > Authors : Carpenter, et al. > Filename: draft-behringer-anima-reference-model-04 > > https://tools.ietf.org/html/draft-behringer-anima-reference-model-04 > > Please express your support or rejection. If you think this document should _not_ be > adopted, please also explicitly indicate the reasons. > > This adoption call will end on December 13, 2015. > > Regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Nov 29 18:48:07 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1571A1F02; Sun, 29 Nov 2015 18:48:06 -0800 (PST) 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 KZbEPKVXBGKM; Sun, 29 Nov 2015 18:48:04 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::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 B8E371A1EFF; Sun, 29 Nov 2015 18:48:04 -0800 (PST) Received: by padhx2 with SMTP id hx2so168776357pad.1; Sun, 29 Nov 2015 18:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=KDmPp23++R90XrOyQfe7dmQP+Zb0qip3JKcqxekyBRA=; b=VdKtYpL4oMrllnRAhUnPZCpsDHXD2giXf4niEGCArh1RLfGLGl9pnB2HazUhbGy9/u ncmt+ZkSD1ix1diulOmLypElKg3PKnvlmr/kMDDhD/jXt3CeNoSZIAvuCfhWK00gyIgN G2ZFpo3vMfwigUSkJ9H52KtjAzegQCoJqy7z+hobAnRW17uKbM4ye590j1m0+ytfruHz OwQcR5dew2kbNlmWV1oc76owsNpgJ9u4fegEbeye3+aYBUsi/s4hQeq+Q4NfyGJNL/Il wW8WeB72L8GTgpZJlqgFVF21gNic29fbKQIfZKxicozIipp7cH0hubbAPvNNlQUyGk9U scfw== X-Received: by 10.66.101.2 with SMTP id fc2mr86716486pab.139.1448851684429; Sun, 29 Nov 2015 18:48:04 -0800 (PST) Received: from ?IPv6:2406:e007:6509:1:28cc:dc4c:9703:6781? ([2406:e007:6509:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id fn4sm47921329pab.46.2015.11.29.18.48.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 18:48:03 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565BB8E1.2090408@gmail.com> Date: Mon, 30 Nov 2015 15:48:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 02:48:06 -0000 Hi, I am also a co-author of this draft and I support its adoption, although I believe we still have work to do on improving the use case description and on mapping it to the Anima toolkit. Regards Brian On 30/11/2015 14:26, Sheng Jiang wrote: > There was clear consensus for adopting draft-jiang-anima-prefix-management as a > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the WG meeting. > > Title: Autonomic Prefix Management in Large-scale Networks > Authors : Jiang, et al. > Filename: draft-jiang-anima-prefix-management > > https://tools.ietf.org/html/draft-jiang-anima-prefix-management > > Please express your support or rejection. If you think this document should _not_ be > adopted, please also explicitly indicate the reasons. > > This adoption call will end on December 13, 2015. > > Regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Nov 29 19:23:13 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25D31A0087 for ; Sun, 29 Nov 2015 19:23:11 -0800 (PST) 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 SKr12ZpPNkGF for ; Sun, 29 Nov 2015 19:23:10 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 E069A1A0052 for ; Sun, 29 Nov 2015 19:23:09 -0800 (PST) Received: by pacej9 with SMTP id ej9so169569723pac.2 for ; Sun, 29 Nov 2015 19:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=qe8tWm7kD2Mxh6N71ISVeh9LVtZRkZG69yYRUGOOlsY=; b=F4wjOqVhpLBs/aLTUWJQ/W9GC3LTNDr5NtMNX6auA0vq/IhUvmSgB72ZoeNsy8YFRj VbQ0sFegG8Mki5wr+zpRsmiZf6ujNnzLqGQWehCqg0kohafR2CIoH/5ZnIN2Duohy8Ns vv5e940nHtHTqUqlR/OwrpiyQLcvv+gfPxzFc+vY3fmH3t/gnWnmI63hv9vunXpgyxQZ dWCEQLlHYrHQycOHrSPMJNyV0K0w0KYuSGVrwSzjwLlQ9CMZ5OheUBvsfRPD19F+VjZn Go6kLIiBV1N1FdDvYDWAk+Im6ByyjBg6KTGjecLUN8fAcXNTwQzZIhVmGqa0oYCZ1/8o frmA== X-Received: by 10.66.160.36 with SMTP id xh4mr45295340pab.149.1448853789506; Sun, 29 Nov 2015 19:23:09 -0800 (PST) Received: from ?IPv6:2406:e007:6509:1:28cc:dc4c:9703:6781? ([2406:e007:6509:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id k2sm47396362pfj.25.2015.11.29.19.23.06 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 19:23:07 -0800 (PST) To: Michael Richardson , anima@ietf.org References: <32380.1448833424@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565BC11A.9070005@gmail.com> Date: Mon, 30 Nov 2015 16:23:06 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <32380.1448833424@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] some comments on -- draft-ietf-anima-grasp-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:23:11 -0000 Hi Michael, Thanks for reading and commenting. On 30/11/2015 10:43, Michael Richardson wrote: > > > section 2.1, part 2. > >> 2.1. Requirements for Discovery >> 2. When an ASA first starts up, it has no knowledge of the specific >> network to which it is attached. Therefore the discovery process >> must be able to support any network scenario, assuming only that the >> device concerned is bootstrapped from factory condition. > > I'm thinking that there is more to this: the ASA may assume that the device, > having been bootstrapped, now has a secured ACP with the local machine. Yes, you could argue that there's a local sandbox I guess, but is that a protocol issue? > > (The exception being a bootstrap ASA, but I'm not convinced GRASP should be > used for that) I tend to agree - we can have a *dummy* ASA for discovery purposes, but I don't think the actual bootstrapping transaction needs to or should go through GRASP. > > I think that we should also need to think about channel binding mechanisms so > that the ASA doesn't have to do all it's own security work, and so that an > ASA can potentially put a bit more trust into the source address of a packet. Well, GRASP effectively provides a session layer and the spec says it MUST be secured, preferably by the ACP. I'm not clear what more you want. > > We also need to discuss how/if an ASA that do wants to do its own security > gets access to the validated device identity. The possibility that the device > would act as a sub-CA signing each of the ASAs. Another model would have the > device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating > that ASA-specific-CA being a meta goal.) Right, but given that ASA authorization is out of scope for GRASP, what are you asking for? I agree there should be an API giving access to the security credentials such as the ID, but shouldn't that be provided by the security function itself, not by GRASP? > >> 8. The discovery process must not generate excessive (multicast) >> traffic and must take account of sleeping nodes in the case of a >> resource-constrained network [RFC7228]. > > First, 7228 defines constrained devices, and challenged networks. > "resource-constrained network" isn't a thing in 7228, so that needs to be > clarified. OK, wording detail, got it. > > Second, if the ACP is implemented as I think it ought to, we won't support > any kind of native multicast. We could provide multicast via > draft-ietf/roll-trickle-mcast, or draft-bergmann-bier-ccast perhaps, or PIM. There *will* be link-local multicast. In fact I spent most of today finding out how to send and receive IPv6 LL multicasts in Python, and just half an hour ago my code said: My goodness, I received a multicast b'\xf0\x00\xba\xaa' ('fe80::28cc:dc4c:9703:6781%12', 53330, 0, 12) However, I agree that we should not ask the ACP to support multicast routing. If there was some magic by which the ACP could secure LL multicast, that would be wonderful, but I assume not. > I don't think it's worth doing any of these things at the IP layer, I think > that there will be grasp daemons running at each vertice of the ACP, and so I > think that we should do flooding at the application layer, much like DNCP > does for Homenet. Yes and no. Absolutely there needs to be a GRASP relay agent on every box that has more than one interface. But do you really want to do unicast replication if there are a hundred nodes on the link? > >> 25. The protocol needs to be fully secured against forged messages >> and man-in-the middle attacks, and secured as much as reasonably >> possible against denial of service attacks. It needs to be capable >> of encryption in order to resist unwanted monitoring, although this >> capability may not be required in all deployments. However, it is >> not required that the protocol itself provides these security >> features; it may depend on an existing secure environment. > > I feel like there is too much hedging. This is where my comment that we seem > to be writing at cross-purposes come to play. I think it would be better to > say: > > + 25. The protocol is expected to run on top of a secure > infrastructure provided by the Autonomic Control Plane (ACP) > [I-D.ietf-anima-autonomic-control-plane]. The ACP is > expected to defend against: forged messages and man-in-the > middle attacks, as well as provide for mitigation of against > denial of service attacks from nodes not into the ACP. The > ACP is further expected to provide a private channel. The thing is that the ACP is supposed to be a SHOULD but the external security has to be a MUST. Life would be simpler if the ACP was a MUST but that would be a big change. More below. > > I think that the words here: > > , although this > > capability may not be required in all deployments. > > are insufficiently supported. Why should the protocol be complicated in this > fashion? That was specifically qualifying the encryption requirement. Personally, I wouldn't mind removing it, but that's a WG decision. > 3.3.1 goes on to say: > >> 3.3.1. Required External Security Mechanism >> >> The protocol SHOULD run within a secure Autonomic Control Plane (ACP) >> [I-D.ietf-anima-autonomic-control-plane]. The ACP MUST provide a >> status indicator to inform GRASP that the ACP is operational. >> >> If there is no ACP, the protocol MUST use another form of strong >> authentication and SHOULD use a form of strong encryption. TLS >> [RFC5246] or DTLS [RFC6347] are RECOMMENDED for this purpose, based >> on a local Public Key Infrastructure (PKI) [RFC5280] managed within >> the autonomic network itself. > > so, let's not sit on the fence here. Can we please decide if we want an ACP, > and if we don't, then let's stop working on it. Of course we want an ACP. > If the designers of GRASP are thinking of using it in some other > non-Autonomic situation, then please write a new document that inherits from > draft-ietf-anima-grasp for that purpose. That isn't that point. The point is (I thought this was made somewhere in the draft, but maybe not) two operators might want to use some autonomic capability across the boundary between them, and they will not want to merge their ACPs. So that specific autonomic capability would need to be protected separately, presumably by a conventional solution such as TLS. So we don't want to exclude that by construction; IMHO it has no impact on the protocol itself either way. Regards Brian From nobody Sun Nov 29 19:38:31 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378601A6F53 for ; Sun, 29 Nov 2015 19:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_38=0.6, 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 N7MMGQv4voUh for ; Sun, 29 Nov 2015 19:38:27 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 AD15E1A6F1D for ; Sun, 29 Nov 2015 19:38:27 -0800 (PST) Received: by pacdm15 with SMTP id dm15so170037757pac.3 for ; Sun, 29 Nov 2015 19:38:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=M3sR2gISnlh3JlghZo1S8sSXlc0aVTb+zAqSgmn8eS0=; b=xvr2Ci8BnmBO9yaO5Fl7vRPZizhYKpk3s966zHcbIdDxbDMn3sBIMTnIhxJcytq+ku AH+buCFuSOeUJ54XcvuFUpueJ2uzlc4WPsYG/d/53IqdOBGB9IB1DBmwxiBY/NarmC+O 4YwQKpw28bweaHokECX2Z1Wkfg9ZPIo/wPdyQ4m3Nvyv78bgIbJqCJhOEg588+6S+Ec5 dcIo8+J1hP3JHgrL7iRc1uxkWgbsC9RaiIDITKLamGgjlIX7FWeFpre3YeHdtlgFe+AT bk6+gmur9BMrgGqKpk+X+hPqgNWUJpisKMa45dLnuO0qi9zjvYsq3JBFyfbQIfbevYtR sNiA== X-Received: by 10.98.0.137 with SMTP id 131mr67605981pfa.137.1448854707340; Sun, 29 Nov 2015 19:38:27 -0800 (PST) Received: from ?IPv6:2406:e007:6509:1:28cc:dc4c:9703:6781? ([2406:e007:6509:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id xi8sm31953547pab.9.2015.11.29.19.38.24 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 29 Nov 2015 19:38:26 -0800 (PST) To: Michael Richardson , "anima@ietf.org" References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> <21960.1448839281@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565BC4B0.8040502@gmail.com> Date: Mon, 30 Nov 2015 16:38:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <21960.1448839281@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] discoverying ACP peers (was Re: comments on current drafts) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 03:38:29 -0000 On 30/11/2015 12:21, Michael Richardson wrote: > > Brian E Carpenter wrote: > > As far as I can see so far, when the GRASP protocol engine comes up, > > the first thing it will do is ask the ACP "are you up?". Assuming the > > ACP says no, GRASP knows that it is running insecurely. Apart from that > > its discovery mechanism will be available and if either the secure > > bootstrap mechanism or the ACP wants to execute GRASP discovery it can > > do so. That would imply that the bootstrap and the ACP each supports a > > notional GRASP objective to allow discovery; these could be objectives > > with no value field. For example, assume every bootstrap relay supports > > an objective called "bootRelay" and every ACP engine supports an > > objective called "ACP". > > There are really two scenarios ACP.areyouup = false. > > 1) before bootstrap. > 2) when device is not connected to any other ANIMA connected device. > > Those are not the same thing. True, but in both cases GRASP will say "Oh, no security here" and refuse to do much of anything except discovery. There are definitely details to be defined here, of course. > And for #2, this condition can persist on a per-interface basis for a long time. Yes, but I assume that a device with multiple interfaces will maintain per-interface status and per-adjacency status (see Michael B's adjacency table for the ACP). > > We also, in the context of running GRASP insecurely on a particular > interface, need to think hard about what GRASP might reveal from a privacy > point of view. > Some interfaces may *never* be used for the ACP, they could be customer facing, etc. > Yet, we need to periodically see if as a result of some cables being > re-arranged, there is now a machine that *is* part of the domain. An example > here would be where an ISP's switches from using the ISP provided CPE to > their own CPE, or back again. Yes. The ACP will have to monitor interfaces and adjacencies continuously for that reason, and will thereby reveal its existence. GRASP discovery traffic will reveal GRASP's existence. But we need to ensure that valuable content is only sent on a secure channel. > We also need to consider if/how we run on virtual interfaces: for instance > VLANs. One might argue that GRASP should only run on physical (untagged) > interfaces, but it is not uncommon in access networks for a single fat > (containing hundreds of tagged VLANs) pipe to come in a datacenter, and be > broken out by an external entity into physical connectors elsewhere, which > plug into equipment that should be part of the domain. > > This is typically when purchasing lit fiber from an incumbent telco for instance. Yes, I don't see how we can restrict it to physical interfaces. > > > > Then when each bootstrap relay agent comes up it tells its local GRASP > > engine that it's available to be discovered. In my prototype that would > > use a function called grasp.register_obj(). Any device that wanted to > > find a relay agent would ask its local GRASP engine using a function > > called grasp.discover(). ACP engines would discover each other > > similarly. What they do when they've found each other is out of scope > > for GRASP. > > In your context/mind, what is a "bootstrap relay agent"? It's labelled "Proxy" at https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-01#page-6 > > Clearly at that stage everybody is using non-ACP addresses (link-local > > mainly) until the bootstrap phase is over and the ACP is established. > > > Does this make any sense? > > Yes. Regards Brian From nobody Sun Nov 29 20:05:18 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707DF1A7011; Sun, 29 Nov 2015 20:05:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 eUVZnI8SwhtY; Sun, 29 Nov 2015 20:05:16 -0800 (PST) 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 410821A700B; Sun, 29 Nov 2015 20:05:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 02C46259F37; Sun, 29 Nov 2015 20:05:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 73299259F2D; Sun, 29 Nov 2015 20:05:15 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> From: "Joel M. Halpern" Message-ID: <565BCAFA.60807@joelhalpern.com> Date: Sun, 29 Nov 2015 23:05:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 04:05:17 -0000 I do not think this document is in shape to be adopted by the working group. It does not clearly state what sort of address prefix handling it is attempting to address, and is nowhere near sufficient for the general case. I am sorry that due to the need to chair another working group, I could not be in the room for the discussion. Yours, Joel M. Halpern On 11/29/15 8:26 PM, Sheng Jiang wrote: > There was clear consensus for adopting draft-jiang-anima-prefix-management as a > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the WG meeting. > > Title: Autonomic Prefix Management in Large-scale Networks > Authors : Jiang, et al. > Filename: draft-jiang-anima-prefix-management > > https://tools.ietf.org/html/draft-jiang-anima-prefix-management > > Please express your support or rejection. If you think this document should _not_ be > adopted, please also explicitly indicate the reasons. > > This adoption call will end on December 13, 2015. > > Regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Sun Nov 29 20:06:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015721A701D; Sun, 29 Nov 2015 20:06:35 -0800 (PST) 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, 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 g-gJph1YDMpw; Sun, 29 Nov 2015 20:06:33 -0800 (PST) Received: from mxb2.tigertech.net (mxb2.tigertech.net [208.80.4.164]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA4061A701A; Sun, 29 Nov 2015 20:06:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C47A31C043D; Sun, 29 Nov 2015 20:06:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 036152E4962; Sun, 29 Nov 2015 20:06:24 -0800 (PST) To: Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> From: "Joel M. Halpern" Message-ID: <565BCB3E.2030704@joelhalpern.com> Date: Sun, 29 Nov 2015 23:06:22 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 04:06:35 -0000 I strongly support adoption by the working group of this document. It is provides a very necessary reference for our work, and is a good sstart on what we need for that. Yours, Joel M. Halpern On 11/29/15 9:03 PM, Sheng Jiang wrote: > There was clear consensus for adopting draft-behringer-anima-reference-model as a > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the WG meeting. > > Title: A Reference Model for Autonomic Networking > Authors : Carpenter, et al. > Filename: draft-behringer-anima-reference-model-04 > > https://tools.ietf.org/html/draft-behringer-anima-reference-model-04 > > Please express your support or rejection. If you think this document should _not_ be > adopted, please also explicitly indicate the reasons. > > This adoption call will end on December 13, 2015. > > Regards, > > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Nov 30 08:12:37 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D471ACE6D; Mon, 30 Nov 2015 08:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epRN6YwAfgKG; Mon, 30 Nov 2015 08:12:34 -0800 (PST) Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (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 3C6B41ACE6C; Mon, 30 Nov 2015 08:12:34 -0800 (PST) Received: by iofh3 with SMTP id h3so179298218iof.3; Mon, 30 Nov 2015 08:12:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=/7Ce1Cn9nBShzfrJQkjXg7FLF4v33/NMideLZlp/DVk=; b=RRKmk8X5IToHvhh2x2iy8CnfenplEAdswoHrrobegQBiV4Ug5obSOMbFQVx4+efpNM 9k27DAYm+tNpGBfcFqNF88j+Hgo5YaDurYqBfubIESiBXnLMXkNwRkBMBURJQK3n8HHm +/cuc2mevwMLNapaE/2TzxiMYPx2leRWgIZhacLTaGKQjjU9Bfx608EX09NN22CqzCNK sD6+KNJshmr0pcIrDT89eLb4oQklY4s2hMXDIBJeKzg2v9dMKHoQ5SVi8PEl+k2KsbXj En4cs4MJ6kT5+azuHAv6KdBoLCsnkKNhrF8jWocsg+QQSXHIF7WbxaQj5i5D9e2htETD K+Bw== X-Received: by 10.107.138.28 with SMTP id m28mr68181257iod.24.1448899953549; Mon, 30 Nov 2015 08:12:33 -0800 (PST) MIME-Version: 1.0 References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> <565BCB3E.2030704@joelhalpern.com> In-Reply-To: <565BCB3E.2030704@joelhalpern.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Mon, 30 Nov 2015 16:12:24 +0000 Message-ID: To: "anima@ietf.org" Content-Type: multipart/alternative; boundary=001a113fe7620be6be0525c44f27 Archived-At: Cc: "anima-chairs@ietf.org" Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:12:36 -0000 --001a113fe7620be6be0525c44f27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am a co-author and I support the adoption of this draft. Cheers. J=C3=A9ferson Em seg, 30 de nov de 2015 =C3=A0s 02:06, Joel M. Halpern escreveu: > I strongly support adoption by the working group of this document. It > is provides a very necessary reference for our work, and is a good > sstart on what we need for that. > > Yours, > Joel M. Halpern > > On 11/29/15 9:03 PM, Sheng Jiang wrote: > > There was clear consensus for adopting > draft-behringer-anima-reference-model as a > > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > > This message starts a two-week call on confirming the consensus from th= e > WG meeting. > > > > Title: A Reference Model for Autonomic Networking > > Authors : Carpenter, et al. > > Filename: draft-behringer-anima-reference-model-04 > > > > https://tools.ietf.org/html/draft-behringer-anima-reference-model-04 > > > > Please express your support or rejection. If you think this document > should _not_ be > > adopted, please also explicitly indicate the reasons. > > > > This adoption call will end on December 13, 2015. > > > > Regards, > > > > Sheng + Toerless > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --001a113fe7620be6be0525c44f27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a co-author and I support the adoption of this draft.=
Cheers.
J=C3=A9ferson

Em seg, 30 de nov de 2015 =C3=A0s 02:06, Joel M. Halpern <<= a href=3D"mailto:jmh@joelhalpern.com">jmh@joelhalpern.com> escreveu:=
I strongly support adoption by the= working group of this document.=C2=A0 It
is provides a very necessary reference for our work, and is a good
sstart on what we need for that.

Yours,
Joel M. Halpern

On 11/29/15 9:03 PM, Sheng Jiang wrote:
> There was clear consensus for adopting draft-behringer-anima-reference= -model as a
> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama= .
> This message starts a two-week call on confirming the consensus from t= he WG meeting.
>
>=C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 A Reference Model for Autonomi= c Networking
>=C2=A0 =C2=A0 Authors :=C2=A0 =C2=A0Carpenter, et al.
>=C2=A0 =C2=A0 Filename:=C2=A0 draft-behringer-anima-reference-model-04<= br> >
>=C2=A0 =C2=A0 https://tools.= ietf.org/html/draft-behringer-anima-reference-model-04
>
> Please express your support or rejection. If you think this document s= hould _not_ be
> adopted, please also explicitly indicate the reasons.
>
> This adoption call will end on December 13, 2015.
>
> Regards,
>
> Sheng + Toerless
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima
>

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--001a113fe7620be6be0525c44f27-- From nobody Mon Nov 30 08:18:43 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B603A1ACE95; Mon, 30 Nov 2015 08:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NdS94ewSCY4; Mon, 30 Nov 2015 08:18:40 -0800 (PST) Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) (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 67F4D1ACE7F; Mon, 30 Nov 2015 08:18:40 -0800 (PST) Received: by igl9 with SMTP id 9so67733018igl.0; Mon, 30 Nov 2015 08:18:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=KLRNmjxZq/QpF4s34vCnGYhHPUJiPvguE+Jo35QEZiI=; b=miVtgBoKSheQZrKYHa2vHJmqQDBR6+KKIqu0Xp0mw1LvPsZJl6yiFOojwsI+jA7g6G lQX6anhAmkDjGz/wQRibzJeAYVVINXJaLv694m6fxDsc5Z+QEBUB6HV8eHW5nLiVmq0g 1pxLd0jPFYIpN38+e/OaOJuvUr8oSS0V+BVID6g0q/+RMZr17aEerImheiLahD10ZDMF OhORKU6L//GA5tl8Ulme9lOc1qvYycOA2XHwyrVOv3l2URQ5wmyzeHzysuQjAMJ6H+Hk tiBihGsvGl8LpRgxKbnHJrw+Irk0gjWBuQpOsDPOc5pv3lmN6RRLqaXPk/wgzeDEMJbW +J3w== X-Received: by 10.50.64.147 with SMTP id o19mr20519977igs.52.1448900318354; Mon, 30 Nov 2015 08:18:38 -0800 (PST) MIME-Version: 1.0 References: <5D36713D8A4E7348A7E10DF7437A4B927BC13A99@nkgeml512-mbx.china.huawei.com> <565BB809.6020707@gmail.com> In-Reply-To: <565BB809.6020707@gmail.com> From: =?UTF-8?Q?J=C3=A9ferson_Campos_Nobre?= Date: Mon, 30 Nov 2015 16:18:29 +0000 Message-ID: To: "anima@ietf.org" Content-Type: multipart/alternative; boundary=047d7bea2f98ca64e80525c464cf Archived-At: Cc: "anima-chairs@ietf.org" Subject: Re: [Anima] Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 16:18:41 -0000 --047d7bea2f98ca64e80525c464cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi. I support the adoption of this draft. Best. J=C3=A9ferson Em seg, 30 de nov de 2015 =C3=A0s 00:44, Brian E Carpenter < brian.e.carpenter@gmail.com> escreveu: > Hi, > > I support this being adopted. Although it's an 'internal' use case, I thi= nk > it covers a very important aspect of the Anima environment. > > Regards > Brian > > On 30/11/2015 14:22, Sheng Jiang wrote: > > There was clear consensus for adopting > draft-eckert-anima-stable-connectivity as a > > ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. > > This message starts a two-week call on confirming the consensus from th= e > WG meeting. > > > > Title: Using Autonomic Control Plane for Stable Connectivity of > Network OAM > > draft-eckert-anima-stable-connectivity-02 > > Authors : Eckert & Behringer > > Filename: draft-eckert-anima-stable-connectivity > > > > https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity-02 > > > > Please express your support or rejection. If you think this document > should _not_ be > > adopted, please also explicitly indicate the reasons. > > > > This adoption call will end on December 13, 2015. > > > > Regards, > > > > Sheng + Toerless > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > --047d7bea2f98ca64e80525c464cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi.
I support the adoption of this draft.
Be= st.
J=C3=A9ferson

Em seg, 30 de nov de 2015 =C3=A0s 00:44, Brian E Carpenter <brian.e.carpenter@gmail.com>= escreveu:
Hi,

I support this being adopted. Although it's an 'internal' use c= ase, I think
it covers a very important aspect of the Anima environment.

Regards
=C2=A0 =C2=A0Brian

On 30/11/2015 14:22, Sheng Jiang wrote:
> There was clear consensus for adopting draft-eckert-anima-stable-conne= ctivity as a
> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama= .
> This message starts a two-week call on confirming the consensus from t= he WG meeting.
>
>=C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 Using Autonomic Control Plane f= or Stable Connectivity of Network OAM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-eckert-an= ima-stable-connectivity-02
>=C2=A0 =C2=A0Authors :=C2=A0 =C2=A0Eckert & Behringer
>=C2=A0 =C2=A0Filename:=C2=A0 draft-eckert-anima-stable-connectivity
>
>=C2=A0 =C2=A0https://tools.= ietf.org/html/draft-eckert-anima-stable-connectivity-02
>
> Please express your support or rejection. If you think this document s= hould _not_ be
> adopted, please also explicitly indicate the reasons.
>
> This adoption call will end on December 13, 2015.
>
> Regards,
>
> Sheng + Toerless
> _______________________________________________
> Anima mailing list
> Anima@ietf.org=
> https://www.ietf.org/mailman/listinfo/anima
>

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
--047d7bea2f98ca64e80525c464cf-- From nobody Mon Nov 30 10:07:29 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD31B2AC2; Mon, 30 Nov 2015 10:07:28 -0800 (PST) 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 nExu7jPAqYb0; Mon, 30 Nov 2015 10:07:26 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::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 9B6231B2ABB; Mon, 30 Nov 2015 10:07:26 -0800 (PST) Received: by vkbs1 with SMTP id s1so107442979vkb.1; Mon, 30 Nov 2015 10:07:25 -0800 (PST) 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=iZny5rD2DfpVTplPxs/xwGIcnpKPIWfaGBL0JQ+SHNU=; b=FXONy/vuENM1SwtdSfgBU9lhAgdnUl7xZZ+qa/G4VPlXMGTkShCnAMrGLqU6PuEXDo 80l42K9LVKcQL5fd82DlWk85CVp+PT++rCkRJmW0dO2s8iLwstB4Gl/zng6fhNu2kkfv 4rfVY+pUDBv0OyrV0+BGb3j15vv0H43Vt37FPmsXEMRYnswWnNsTi4NuOxUNNWkmzgGF eU8LBeWF+9z2rs9N4IXPqS23ZkWT+VQO/Xow81zuBP6dqS8Uvf1eLan2KGbkiftyejpx bYeqo3AJgJUACtxxX7LEb4vGT6FbZpiJUHD0JxV+BC4WP7q0YAu/bqcDI2Q7gsCFtlIv OALg== MIME-Version: 1.0 X-Received: by 10.31.162.16 with SMTP id l16mr55614811vke.69.1448906845657; Mon, 30 Nov 2015 10:07:25 -0800 (PST) Received: by 10.103.40.131 with HTTP; Mon, 30 Nov 2015 10:07:25 -0800 (PST) In-Reply-To: <565BCB3E.2030704@joelhalpern.com> References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> <565BCB3E.2030704@joelhalpern.com> Date: Mon, 30 Nov 2015 10:07:25 -0800 Message-ID: From: John Strassner To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a114402ded91fb10525c5e9f0 Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert , "anima@ietf.org" , Sheng Jiang Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 18:07:28 -0000 --001a114402ded91fb10525c5e9f0 Content-Type: text/plain; charset=UTF-8 I also strongly support adoption by the working group of this document. I am planning to review and add to it. Note: I am a co-author. regards, John On Sun, Nov 29, 2015 at 8:06 PM, Joel M. Halpern wrote: > I strongly support adoption by the working group of this document. It is > provides a very necessary reference for our work, and is a good sstart on > what we need for that. > > Yours, > Joel M. Halpern > > On 11/29/15 9:03 PM, Sheng Jiang wrote: > >> There was clear consensus for adopting >> draft-behringer-anima-reference-model as a >> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. >> This message starts a two-week call on confirming the consensus from the >> WG meeting. >> >> Title: A Reference Model for Autonomic Networking >> Authors : Carpenter, et al. >> Filename: draft-behringer-anima-reference-model-04 >> >> https://tools.ietf.org/html/draft-behringer-anima-reference-model-04 >> >> Please express your support or rejection. If you think this document >> should _not_ be >> adopted, please also explicitly indicate the reasons. >> >> This adoption call will end on December 13, 2015. >> >> Regards, >> >> Sheng + Toerless >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> >> > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- regards, John --001a114402ded91fb10525c5e9f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also strongly support adoption by the working group= of this document. I am planning to review and add to it. Note: I am a co-a= uthor.

regards,
John

On Sun, Nov 29, 2015 at 8= :06 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
I strongly support adoption by the working gro= up of this document.=C2=A0 It is provides a very necessary reference for ou= r work, and is a good sstart on what we need for that.

Yours,
Joel M. Halpern

On 11/29/15 9:03 PM, Sheng Jiang wrote:
There was clear consensus for adopting draft-behringer-anima-reference-mode= l as a
ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama.
This message starts a two-week call on confirming the consensus from the WG= meeting.

=C2=A0 =C2=A0Title:=C2=A0 =C2=A0 =C2=A0 A Reference Model for Autonomic Net= working
=C2=A0 =C2=A0Authors :=C2=A0 =C2=A0Carpenter, et al.
=C2=A0 =C2=A0Filename:=C2=A0 draft-behringer-anima-reference-model-04

=C2=A0 =C2=A0https://tools.ietf.= org/html/draft-behringer-anima-reference-model-04

Please express your support or rejection. If you think this document should= _not_ be
adopted, please also explicitly indicate the reasons.

This adoption call will end on December 13, 2015.

Regards,

Sheng + Toerless
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima


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



--
regards,
John
--001a114402ded91fb10525c5e9f0-- From nobody Mon Nov 30 11:02:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCA31ABC74; Mon, 30 Nov 2015 11:02:31 -0800 (PST) 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 eqcDuDKyt2Yr; Mon, 30 Nov 2015 11:02:30 -0800 (PST) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 394311A909B; Mon, 30 Nov 2015 11:02:30 -0800 (PST) Received: by pacdm15 with SMTP id dm15so193283545pac.3; Mon, 30 Nov 2015 11:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=qpJomZFWiTtITT4Byb52h4nHfeA5SNtQpV2am4Dw4LY=; b=Qzl+KH/clmK3UJ4aFI7b+8/8RNSAM69iLFvuUcuFE3QEbRhi3jpZDCrZ+1cTrdEMpm gPekfb9ClfyvlwlofbOFB1NUPqTcG1sEJpIKxd/EvtuEPhMwZr1IMDwnDK2RWar1DwXX j6VLEAQNvo7ePeF6I3HfWdw26v6Avp9DMuFvei0g8KNbWFth7tUJVWxglH2gWZ4L+X9o 5nVkP0iXdIC2wdptO0rGSGPIwmdvVVFiYEEEvWNsSfPIunduqVsVZmel1bObWj+uLjW/ Twxho6JSdBgce36oo+MIrFiCSTyehd3rAqwONfn7HhGHxF+Br/Y62qV6ywDeKykfxmT7 FXtQ== X-Received: by 10.66.141.103 with SMTP id rn7mr91256197pab.126.1448910149816; Mon, 30 Nov 2015 11:02:29 -0800 (PST) Received: from ?IPv6:2406:e007:48f5:1:28cc:dc4c:9703:6781? ([2406:e007:48f5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id v2sm52752376pfi.44.2015.11.30.11.02.26 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 11:02:28 -0800 (PST) To: "Joel M. Halpern" , Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> <565BCAFA.60807@joelhalpern.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565C9D44.1040303@gmail.com> Date: Tue, 1 Dec 2015 08:02:28 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <565BCAFA.60807@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:02:32 -0000 Joel, As I said in my own comment, the use case aspect of the draft definitely needs work. It was never intended to be sufficient for the general case. Actually, it says that it's limited to ISP networks. It probably needs an explicit applicability section with more details on that. In particular, is it intended to be used during network creation (and would it then use something like RFC 7695) or is it only for prefix allocation to customer stubs in an established network? (If it's used for network creation, there would be some interesting questions about bootstrapping that I won't go into here.) It's also not at all aligned with the current GRASP proposal, and that needs to be fixed in the next version. Its overall role in Anima is really supposed to be a worked example to validate the infrastructure components. Regards Brian On 30/11/2015 17:05, Joel M. Halpern wrote: > I do not think this document is in shape to be adopted by the working group. It does not clearly state what sort of address > prefix handling it is attempting to address, and is nowhere near sufficient for the general case. > > I am sorry that due to the need to chair another working group, I could not be in the room for the discussion. > > Yours, > Joel M. Halpern > > On 11/29/15 8:26 PM, Sheng Jiang wrote: >> There was clear consensus for adopting draft-jiang-anima-prefix-management as a >> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. >> This message starts a two-week call on confirming the consensus from the WG meeting. >> >> Title: Autonomic Prefix Management in Large-scale Networks >> Authors : Jiang, et al. >> Filename: draft-jiang-anima-prefix-management >> >> https://tools.ietf.org/html/draft-jiang-anima-prefix-management >> >> Please express your support or rejection. If you think this document should _not_ be >> adopted, please also explicitly indicate the reasons. >> >> This adoption call will end on December 13, 2015. >> >> Regards, >> >> Sheng + Toerless >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Mon Nov 30 11:09:34 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78D41B2AE3; Mon, 30 Nov 2015 11:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 XKHgIVsPFzTD; Mon, 30 Nov 2015 11:09:31 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770F81B2AE2; Mon, 30 Nov 2015 11:09:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 6470C1C075B; Mon, 30 Nov 2015 11:09:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id C8DFD1C0E2D; Mon, 30 Nov 2015 11:09:30 -0800 (PST) To: Brian E Carpenter , Sheng Jiang , "anima@ietf.org" References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> <565BCAFA.60807@joelhalpern.com> <565C9D44.1040303@gmail.com> From: "Joel M. Halpern" Message-ID: <565C9EE8.3000903@joelhalpern.com> Date: Mon, 30 Nov 2015 14:09:28 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <565C9D44.1040303@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 19:09:33 -0000 I can well believe that there is a valuable demonstration case that could be covered by that document. However, as I read it, the current document is not clear enough to even say that it is a good starting point on describing that case and its value to the group. So I would like to se a round of clarity improvement by the authors, after which it is likely we could adopt the document. Yours, Joel On 11/30/15 2:02 PM, Brian E Carpenter wrote: > Joel, > > As I said in my own comment, the use case aspect of the draft definitely > needs work. It was never intended to be sufficient for the general > case. Actually, it says that it's limited to ISP networks. It probably > needs an explicit applicability section with more details on that. > In particular, is it intended to be used during network creation > (and would it then use something like RFC 7695) or is it only for > prefix allocation to customer stubs in an established network? > > (If it's used for network creation, there would be some interesting > questions about bootstrapping that I won't go into here.) > > It's also not at all aligned with the current GRASP proposal, and that > needs to be fixed in the next version. > > Its overall role in Anima is really supposed to be a worked example > to validate the infrastructure components. > > Regards > Brian > > > On 30/11/2015 17:05, Joel M. Halpern wrote: >> I do not think this document is in shape to be adopted by the working group. It does not clearly state what sort of address >> prefix handling it is attempting to address, and is nowhere near sufficient for the general case. >> >> I am sorry that due to the need to chair another working group, I could not be in the room for the discussion. >> >> Yours, >> Joel M. Halpern >> >> On 11/29/15 8:26 PM, Sheng Jiang wrote: >>> There was clear consensus for adopting draft-jiang-anima-prefix-management as a >>> ANIMA working group document in the IETF 94 ANIMA WG meeting, Yokohama. >>> This message starts a two-week call on confirming the consensus from the WG meeting. >>> >>> Title: Autonomic Prefix Management in Large-scale Networks >>> Authors : Jiang, et al. >>> Filename: draft-jiang-anima-prefix-management >>> >>> https://tools.ietf.org/html/draft-jiang-anima-prefix-management >>> >>> Please express your support or rejection. If you think this document should _not_ be >>> adopted, please also explicitly indicate the reasons. >>> >>> This adoption call will end on December 13, 2015. >>> >>> Regards, >>> >>> Sheng + Toerless >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > From nobody Mon Nov 30 13:24:27 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26931B352C for ; Mon, 30 Nov 2015 13:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_38=0.6, SPF_PASS=-0.001, 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 R2VBK08gIKCI for ; Mon, 30 Nov 2015 13:24:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BA51B3530 for ; Mon, 30 Nov 2015 13:24:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A99EE2009E; Mon, 30 Nov 2015 16:29:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7BC7463757; Mon, 30 Nov 2015 16:24:22 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5E4CC63753; Mon, 30 Nov 2015 16:24:22 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <565BC4B0.8040502@gmail.com> References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> <21960.1448839281@sandelman.ca> <565BC4B0.8040502@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] discoverying ACP peers (was Re: comments on current drafts) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 21:24:25 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> There are really two scenarios ACP.areyouup = false. >> >> 1) before bootstrap. >> 2) when device is not connected to any other >> ANIMA connected device. >> >> Those are not the same thing. > True, but in both cases GRASP will say "Oh, no security here" and > refuse to do much of anything except discovery. There are definitely > details to be defined here, of course. During the period that bootstrap is occuring, after a bootstrap relay agent has been discovered, running GRASP on any interface is not, I think desireable. The reason is mostly concern for some kind of DoS or initial-configuration vulnerability. (remember: "FIELD"/"SUPPORT" stuff in VMS?) Should bootstrap fail, enabling it again to find a different bootstrap relay *is* desireable. >> And for #2, this condition can persist on a per-interface basis for a >> long time. > Yes, but I assume that a device with multiple interfaces will maintain > per-interface status and per-adjacency status (see Michael B's > adjacency table for the ACP). Yes, exactly. I'm think that once bootstraped, the bootstrap relay agent ASA would then want to *respond* on that interface. >> We also, in the context of running GRASP insecurely on a particular >> interface, need to think hard about what GRASP might reveal from a >> privacy point of view. Some interfaces may *never* be used for the >> ACP, they could be customer facing, etc. Yet, we need to periodically >> see if as a result of some cables being re-arranged, there is now a >> machine that *is* part of the domain. An example here would be where >> an ISP's switches from using the ISP provided CPE to their own CPE, or >> back again. > Yes. The ACP will have to monitor interfaces and adjacencies > continuously for that reason, and will thereby reveal its > existence. GRASP discovery traffic will reveal GRASP's existence. But > we need to ensure that valuable content is only sent on a secure > channel. This is partly why I think that a multicast IKEv2 INIT might be easier. I understand that some people want to hedge their bets with building the ACP using IKEv2, but we make everything configurable, I'd like to see some clear use case. >> We also need to consider if/how we run on virtual interfaces: for >> instance VLANs. One might argue that GRASP should only run on >> physical (untagged) interfaces, but it is not uncommon in access >> networks for a single fat (containing hundreds of tagged VLANs) pipe >> to come in a datacenter, and be broken out by an external entity into >> physical connectors elsewhere, which plug into equipment that should >> be part of the domain. >> >> This is typically when purchasing lit fiber from an incumbent telco >> for instance. > Yes, I don't see how we can restrict it to physical interfaces. I believe that we will have to have some documented heuristics: we want ACPs to come up wherever feasible, but we don't want to annoy ASAs with hundreds to thousands of virtual interfaces which can never have an ACP. You will have noticed when configuring your multicast socket, that you don't have to create a socket per-interface, but can get the interface ifIndex out along with each packet that you receive. So listening to multicasts on thousands of interfaces doesn't have to be very expensive in terms of program state. (Except, as it turns out, with GRE interfaces on Linux, which do not return their ifIndex, which seem to have a bug in this fashion, which I hope to fix) As such, we may want to have interfaces which are in four states: 0) insecure GRASP announcements 1) interface being used for bootstrap, suppress 2) listen for insecure GRASP queries only 3) ACP up on this interface, skeptically listen. [when the ACP is up, it is likely that there is another interface to listen to, but one has to continue listening because new devices could show up and want to bootstrap, or the ACP could fail] >> In your context/mind, what is a "bootstrap relay agent"? > It's labelled "Proxy" at > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-01#page-6 Ah, okay! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVly+g4CLcPvd0N1lAQIP2AgAnx18xYLakAgDYOV/cawIgoSBtHK7uCR/ aYiW0KqZlEviX7i4XFd+hyqcy4tF03wiVP9wA86697eOETJIESE7RygI4vG3b7nL oRnxx0Cxjo2l0ZnW/jIB8RDkFc4iVlnFLxYnJGhKdsfucKhRjdyXG6xVrYcgmyCO BAIiSEQZMMWLCRLKuhn4jYqzE51TuIys3yKqsKh9KpEjoxuiq3BDeyAmr4rOoXtX Ki4IWCBpgszeejHCZjTzEyz1Si06E7AoadkjdR/plZY6DHECVVzLq3Tc+imlF7BQ Wo612UoLYjVcERpAjYPC+91NNVkBDUUcDZW+GQzoLtcul5POEeYGVA== =QcmD -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 30 14:19:53 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52931ACDED for ; Mon, 30 Nov 2015 14:19:51 -0800 (PST) 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 HGBmAA5A0lJI for ; Mon, 30 Nov 2015 14:19:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D38A51A8A28 for ; Mon, 30 Nov 2015 14:19:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 26CB82009E for ; Mon, 30 Nov 2015 17:24:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D560C63757; Mon, 30 Nov 2015 17:19:47 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B3DB063753 for ; Mon, 30 Nov 2015 17:19:47 -0500 (EST) From: Michael Richardson To: anima@ietf.org In-Reply-To: <565BC11A.9070005@gmail.com> References: <32380.1448833424@sandelman.ca> <565BC11A.9070005@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [Anima] some comments on -- draft-ietf-anima-grasp-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Nov 2015 22:19:51 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >>> 2.1. Requirements for Discovery >>> 2. When an ASA first starts up, it has no knowledge of the specific >>> network to which it is attached. Therefore the discovery process >>> must be able to support any network scenario, assuming only that the >>> device concerned is bootstrapped from factory condition. >> >> I'm thinking that there is more to this: the ASA may assume that the device, >> having been bootstrapped, now has a secured ACP with the local machine. > Yes, you could argue that there's a local sandbox I guess, but is that > a protocol issue? Yes, I suspect that there is something here. There is a transitivity of trust that GRASP will have to deal with if the ASAs do *not* have access to the private key for the device. I think that SIP did it right, explaining how the SIP proxies interacted, while not saying too much about how/what they did. >> I think that we should also need to think about channel binding mechanisms so >> that the ASA doesn't have to do all it's own security work, and so that an >> ASA can potentially put a bit more trust into the source address of a packet. > Well, GRASP effectively provides a session layer and the spec says it MUST > be secured, preferably by the ACP. I'm not clear what more you want. Channel binding may involve the two ASA cryptographically connecting the communication they have at layer "5" with the security provided at layer 3. It can be as simple as each end asking the layer-3 for the hash of the public keys used to secure the channel 3, and then sending that in-protocol to establish that there is no MITM. It may be that GRASP will have to *explicitely* support a trusted MITM because multi-hop GRASP messages will be necessary before stable addresses are available. >> We also need to discuss how/if an ASA that do wants to do its own security >> gets access to the validated device identity. The possibility that the device >> would act as a sub-CA signing each of the ASAs. Another model would have the >> device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating >> that ASA-specific-CA being a meta goal.) > Right, but given that ASA authorization is out of scope for GRASP, > what are you asking for? I agree there should be an API giving access > to the security credentials such as the ID, but shouldn't that be provided > by the security function itself, not by GRASP? When we have seperated security functions from protocols, and assumed some unspecified API, we have created unbound channels that can be attacked. - TCP SYN values were divorced from IP end points gave us NAPT. - lack of TLS ClientCertificates gives us hijacked HTTPS sessions (one end of not bound to the channel, the other has been trojaned by policy) - ... > However, I agree that we should not ask the ACP to support multicast routing. > If there was some magic by which the ACP could secure LL multicast, that > would be wonderful, but I assume not. Yes, it could be done. We can use the enrolled certificates to bring up a multicast key manager like rfc3830, but I'd like to know why we need it... >> I don't think it's worth doing any of these things at the IP layer, I think >> that there will be grasp daemons running at each vertice of the ACP, and so I >> think that we should do flooding at the application layer, much like DNCP >> does for Homenet. > Yes and no. Absolutely there needs to be a GRASP relay agent on every > box that has more than one interface. But do you really want to do > unicast replication if there are a hundred nodes on the link? Quite possibly yes. 1) most links are not truly multicast the way 10base2 was, but are in fact star topologies... and: 2) the switching device at the hub of the star topology is running ANIMA, and it sees 48 ethernet ports, not one LAN. > The thing is that the ACP is supposed to be a SHOULD but the external > security has to be a MUST. > Life would be simpler if the ACP was a MUST but that would be a big change. Okay, good to have this conflict clearly stated. >> If the designers of GRASP are thinking of using it in some other >> non-Autonomic situation, then please write a new document that inherits from >> draft-ietf-anima-grasp for that purpose. > That isn't that point. The point is (I thought this was made somewhere in > the draft, but maybe not) two operators might want to use some autonomic > capability across the boundary between them, and they will not want > to merge their ACPs. So that specific autonomic capability would need > to be protected separately, presumably by a conventional solution > such as TLS. So we don't want to exclude that by construction; IMHO it > has no impact on the protocol itself either way. ah, okay. I agree that they don't want to *merge* their ACPs. I would claim that they want a new ACP to link their two domains, one which is not yet another "VRF". Let me add a diagram: http://www.sandelman.ca/SSW/ietf/anima/diagrams/ACP-between-two-ISPs.svg (also, .dia, and .png if you don't have svg in your browser) I've drawn two ISPs, A and B. Each has a NOC and four routers. An ACP (in purple for ISP A, in green for ISP B) connects each ISPs routers together. A second overlap in ORANGE is a new ACP. I suggest it could be a double tunnel, using ACP-A's addresses inside ISP-A to connect NOC-A directly to router A3, which has a interconnect to ISP-B's B2. (It could also be that ORANGE-ACP uses dataplane addresses) The end result is that the appropriate inter-ISP ASAs that need to do things communicate with each other. I suspect that it isn't just A3/B2 that need to talk, but rather and ASA on NOC-A and needs to talk to an ASA on NOC-B, but that it may well need to know something about the Interconnection topology. (I'm trying hard not to make this specific to DiffServ...) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: image/svg+xml; charset=utf-8 Content-Disposition: attachment; filename=ACP-between-two-ISPs.svg Content-Transfer-Encoding: base64 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPHN2ZyB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvMjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5 L3hsaW5rIiB3aWR0aD0iOTg4cHQiIGhlaWdodD0iNjIzcHQiIHZpZXdCb3g9IjAgMCA5ODggNjIz IiB2ZXJzaW9uPSIxLjEiPgo8ZGVmcz4KPGc+CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlk PSJnbHlwaDAtMCI+CjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZTsiIGQ9Ik0gMC42NDA2MjUgMi4y OTY4NzUgTCAwLjY0MDYyNSAtOS4xNzE4NzUgTCA3LjE0MDYyNSAtOS4xNzE4NzUgTCA3LjE0MDYy NSAyLjI5Njg3NSBaIE0gMS4zNzUgMS41NzgxMjUgTCA2LjQyMTg3NSAxLjU3ODEyNSBMIDYuNDIx ODc1IC04LjQzNzUgTCAxLjM3NSAtOC40Mzc1IFogIi8+Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJm bG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTEiPgo8cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBk PSJNIDEuMjgxMjUgLTkuNDg0Mzc1IEwgMyAtOS40ODQzNzUgTCA3LjIwMzEyNSAtMS41NDY4NzUg TCA3LjIwMzEyNSAtOS40ODQzNzUgTCA4LjQ1MzEyNSAtOS40ODQzNzUgTCA4LjQ1MzEyNSAwIEwg Ni43MTg3NSAwIEwgMi41MTU2MjUgLTcuOTIxODc1IEwgMi41MTU2MjUgMCBMIDEuMjgxMjUgMCBa ICIvPgo8L3N5bWJvbD4KPHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC0yIj4K PHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIgZD0iTSA1LjEyNSAtOC42MDkzNzUgQyA0LjE4NzUg LTguNjA5Mzc1IDMuNDQxNDA2IC04LjI1NzgxMiAyLjg5MDYyNSAtNy41NjI1IEMgMi4zNDc2NTYg LTYuODc1IDIuMDc4MTI1IC01LjkyOTY4OCAyLjA3ODEyNSAtNC43MzQzNzUgQyAyLjA3ODEyNSAt My41MzUxNTYgMi4zNDc2NTYgLTIuNTg1OTM4IDIuODkwNjI1IC0xLjg5MDYyNSBDIDMuNDQxNDA2 IC0xLjIwMzEyNSA0LjE4NzUgLTAuODU5Mzc1IDUuMTI1IC0wLjg1OTM3NSBDIDYuMDUwNzgxIC0w Ljg1OTM3NSA2Ljc4NTE1NiAtMS4yMDMxMjUgNy4zMjgxMjUgLTEuODkwNjI1IEMgNy44Nzg5MDYg LTIuNTg1OTM4IDguMTU2MjUgLTMuNTM1MTU2IDguMTU2MjUgLTQuNzM0Mzc1IEMgOC4xNTYyNSAt NS45Mjk2ODggNy44Nzg5MDYgLTYuODc1IDcuMzI4MTI1IC03LjU2MjUgQyA2Ljc4NTE1NiAtOC4y NTc4MTIgNi4wNTA3ODEgLTguNjA5Mzc1IDUuMTI1IC04LjYwOTM3NSBaIE0gNS4xMjUgLTkuNjU2 MjUgQyA2LjQ0NTMxMiAtOS42NTYyNSA3LjUwMzkwNiAtOS4yMDcwMzEgOC4yOTY4NzUgLTguMzEy NSBDIDkuMDk3NjU2IC03LjQxNDA2MiA5LjUgLTYuMjIyNjU2IDkuNSAtNC43MzQzNzUgQyA5LjUg LTMuMjM0Mzc1IDkuMDk3NjU2IC0yLjAzNTE1NiA4LjI5Njg3NSAtMS4xNDA2MjUgQyA3LjUwMzkw NiAtMC4yNTM5MDYgNi40NDUzMTIgMC4xODc1IDUuMTI1IDAuMTg3NSBDIDMuNzg5MDYyIDAuMTg3 NSAyLjcyMjY1NiAtMC4yNTM5MDYgMS45MjE4NzUgLTEuMTQwNjI1IEMgMS4xMjg5MDYgLTIuMDM1 MTU2IDAuNzM0Mzc1IC0zLjIzNDM3NSAwLjczNDM3NSAtNC43MzQzNzUgQyAwLjczNDM3NSAtNi4y MjI2NTYgMS4xMjg5MDYgLTcuNDE0MDYyIDEuOTIxODc1IC04LjMxMjUgQyAyLjcyMjY1NiAtOS4y MDcwMzEgMy43ODkwNjIgLTkuNjU2MjUgNS4xMjUgLTkuNjU2MjUgWiAiLz4KPC9zeW1ib2w+Cjxz eW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJnbHlwaDAtMyI+CjxwYXRoIHN0eWxlPSJzdHJv a2U6bm9uZTsiIGQ9Ik0gOC4zNzUgLTguNzUgTCA4LjM3NSAtNy4zOTA2MjUgQyA3LjkzNzUgLTcu Nzk2ODc1IDcuNDcyNjU2IC04LjA5NzY1NiA2Ljk4NDM3NSAtOC4yOTY4NzUgQyA2LjUwMzkwNiAt OC40OTIxODggNS45ODgyODEgLTguNTkzNzUgNS40Mzc1IC04LjU5Mzc1IEMgNC4zNTE1NjIgLTgu NTkzNzUgMy41MTk1MzEgLTguMjU3ODEyIDIuOTM3NSAtNy41OTM3NSBDIDIuMzYzMjgxIC02Ljkz NzUgMi4wNzgxMjUgLTUuOTg0Mzc1IDIuMDc4MTI1IC00LjczNDM3NSBDIDIuMDc4MTI1IC0zLjQ4 NDM3NSAyLjM2MzI4MSAtMi41MjM0MzggMi45Mzc1IC0xLjg1OTM3NSBDIDMuNTE5NTMxIC0xLjIw MzEyNSA0LjM1MTU2MiAtMC44NzUgNS40Mzc1IC0wLjg3NSBDIDUuOTg4MjgxIC0wLjg3NSA2LjUw MzkwNiAtMC45NzI2NTYgNi45ODQzNzUgLTEuMTcxODc1IEMgNy40NzI2NTYgLTEuMzY3MTg4IDcu OTM3NSAtMS42NjQwNjIgOC4zNzUgLTIuMDYyNSBMIDguMzc1IC0wLjczNDM3NSBDIDcuOTI1Nzgx IC0wLjQyMTg3NSA3LjQ1MzEyNSAtMC4xODc1IDYuOTUzMTI1IC0wLjAzMTI1IEMgNi40NTMxMjUg MC4xMTMyODEgNS45MjE4NzUgMC4xODc1IDUuMzU5Mzc1IDAuMTg3NSBDIDMuOTIxODc1IDAuMTg3 NSAyLjc4OTA2MiAtMC4yNSAxLjk2ODc1IC0xLjEyNSBDIDEuMTQ0NTMxIC0yLjAwNzgxMiAwLjcz NDM3NSAtMy4yMTA5MzggMC43MzQzNzUgLTQuNzM0Mzc1IEMgMC43MzQzNzUgLTYuMjUzOTA2IDEu MTQ0NTMxIC03LjQ1MzEyNSAxLjk2ODc1IC04LjMyODEyNSBDIDIuNzg5MDYyIC05LjIxMDkzOCAz LjkyMTg3NSAtOS42NTYyNSA1LjM1OTM3NSAtOS42NTYyNSBDIDUuOTIxODc1IC05LjY1NjI1IDYu NDUzMTI1IC05LjU3ODEyNSA2Ljk1MzEyNSAtOS40MjE4NzUgQyA3LjQ2MDkzOCAtOS4yNzM0Mzgg Ny45Mzc1IC05LjA1MDc4MSA4LjM3NSAtOC43NSBaICIvPgo8L3N5bWJvbD4KPHN5bWJvbCBvdmVy Zmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC00Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIg ZD0iIi8+Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTUi Pgo8cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDQuNDM3NSAtOC4yMTg3NSBMIDIuNzAz MTI1IC0zLjUgTCA2LjE4NzUgLTMuNSBaIE0gMy43MTg3NSAtOS40ODQzNzUgTCA1LjE3MTg3NSAt OS40ODQzNzUgTCA4Ljc4MTI1IDAgTCA3LjQ1MzEyNSAwIEwgNi41OTM3NSAtMi40Mzc1IEwgMi4z MTI1IC0yLjQzNzUgTCAxLjQ1MzEyNSAwIEwgMC4xMDkzNzUgMCBaICIvPgo8L3N5bWJvbD4KPHN5 bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC02Ij4KPHBhdGggc3R5bGU9InN0cm9r ZTpub25lOyIgZD0iTSAxLjYwOTM3NSAtMS4wNzgxMjUgTCAzLjcwMzEyNSAtMS4wNzgxMjUgTCAz LjcwMzEyNSAtOC4zMTI1IEwgMS40MjE4NzUgLTcuODU5Mzc1IEwgMS40MjE4NzUgLTkuMDE1NjI1 IEwgMy42ODc1IC05LjQ4NDM3NSBMIDQuOTg0Mzc1IC05LjQ4NDM3NSBMIDQuOTg0Mzc1IC0xLjA3 ODEyNSBMIDcuMDc4MTI1IC0xLjA3ODEyNSBMIDcuMDc4MTI1IDAgTCAxLjYwOTM3NSAwIFogIi8+ Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTciPgo8cGF0 aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDIuNSAtMS4wNzgxMjUgTCA2Ljk2ODc1IC0xLjA3 ODEyNSBMIDYuOTY4NzUgMCBMIDAuOTUzMTI1IDAgTCAwLjk1MzEyNSAtMS4wNzgxMjUgQyAxLjQ0 MTQwNiAtMS41NzgxMjUgMi4xMDE1NjIgLTIuMjUgMi45Mzc1IC0zLjA5Mzc1IEMgMy43ODEyNSAt My45NDUzMTIgNC4zMTI1IC00LjUgNC41MzEyNSAtNC43NSBDIDQuOTM3NSAtNS4yMDcwMzEgNS4y MTg3NSAtNS41OTc2NTYgNS4zNzUgLTUuOTIxODc1IEMgNS41MzkwNjIgLTYuMjQyMTg4IDUuNjI1 IC02LjU1NDY4OCA1LjYyNSAtNi44NTkzNzUgQyA1LjYyNSAtNy4zNjcxODggNS40NDUzMTIgLTcu NzgxMjUgNS4wOTM3NSAtOC4wOTM3NSBDIDQuNzUgLTguNDA2MjUgNC4yODkwNjIgLTguNTYyNSAz LjcxODc1IC04LjU2MjUgQyAzLjMxMjUgLTguNTYyNSAyLjg4MjgxMiAtOC40OTIxODggMi40Mzc1 IC04LjM1OTM3NSBDIDIgLTguMjIyNjU2IDEuNTIzNDM4IC04LjAwNzgxMiAxLjAxNTYyNSAtNy43 MTg3NSBMIDEuMDE1NjI1IC05LjAxNTYyNSBDIDEuNTM1MTU2IC05LjIyMjY1NiAyLjAxOTUzMSAt OS4zNzg5MDYgMi40Njg3NSAtOS40ODQzNzUgQyAyLjkxNDA2MiAtOS41OTc2NTYgMy4zMjAzMTIg LTkuNjU2MjUgMy42ODc1IC05LjY1NjI1IEMgNC42NzU3ODEgLTkuNjU2MjUgNS40NjA5MzggLTku NDA2MjUgNi4wNDY4NzUgLTguOTA2MjUgQyA2LjYyODkwNiAtOC40MTQwNjIgNi45MjE4NzUgLTcu NzU3ODEyIDYuOTIxODc1IC02LjkzNzUgQyA2LjkyMTg3NSAtNi41NTA3ODEgNi44NDc2NTYgLTYu MTc5Njg4IDYuNzAzMTI1IC01LjgyODEyNSBDIDYuNTU0Njg4IC01LjQ4NDM3NSA2LjI4OTA2MiAt NS4wNzgxMjUgNS45MDYyNSAtNC42MDkzNzUgQyA1LjgwMDc4MSAtNC40ODQzNzUgNS40NjA5Mzgg LTQuMTI1IDQuODkwNjI1IC0zLjUzMTI1IEMgNC4zMjgxMjUgLTIuOTQ1MzEyIDMuNTMxMjUgLTIu MTI4OTA2IDIuNSAtMS4wNzgxMjUgWiAiLz4KPC9zeW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9InZp c2libGUiIGlkPSJnbHlwaDAtOCI+CjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZTsiIGQ9Ik0gNS4y ODEyNSAtNS4xMDkzNzUgQyA1Ljg5NDUzMSAtNC45NzI2NTYgNi4zNzUgLTQuNjk1MzEyIDYuNzE4 NzUgLTQuMjgxMjUgQyA3LjA2MjUgLTMuODc1IDcuMjM0Mzc1IC0zLjM2MzI4MSA3LjIzNDM3NSAt Mi43NSBDIDcuMjM0Mzc1IC0xLjgyMDMxMiA2LjkxMDE1NiAtMS4wOTc2NTYgNi4yNjU2MjUgLTAu NTc4MTI1IEMgNS42MTcxODggLTAuMDY2NDA2MiA0LjcwMzEyNSAwLjE4NzUgMy41MTU2MjUgMC4x ODc1IEMgMy4xMTcxODggMC4xODc1IDIuNzA3MDMxIDAuMTQ0NTMxIDIuMjgxMjUgMC4wNjI1IEMg MS44NjMyODEgLTAuMDA3ODEyNSAxLjQyOTY4OCAtMC4xMjUgMC45ODQzNzUgLTAuMjgxMjUgTCAw Ljk4NDM3NSAtMS41MzEyNSBDIDEuMzQ3NjU2IC0xLjMyMDMxMiAxLjczODI4MSAtMS4xNjAxNTYg Mi4xNTYyNSAtMS4wNDY4NzUgQyAyLjU4MjAzMSAtMC45NDE0MDYgMy4wMjM0MzggLTAuODkwNjI1 IDMuNDg0Mzc1IC0wLjg5MDYyNSBDIDQuMjg1MTU2IC0wLjg5MDYyNSA0Ljg5NDUzMSAtMS4wNDY4 NzUgNS4zMTI1IC0xLjM1OTM3NSBDIDUuNzM4MjgxIC0xLjY3OTY4OCA1Ljk1MzEyNSAtMi4xNDQ1 MzEgNS45NTMxMjUgLTIuNzUgQyA1Ljk1MzEyNSAtMy4zMTI1IDUuNzUzOTA2IC0zLjc1IDUuMzU5 Mzc1IC00LjA2MjUgQyA0Ljk3MjY1NiAtNC4zNzUgNC40Mjk2ODggLTQuNTMxMjUgMy43MzQzNzUg LTQuNTMxMjUgTCAyLjYyNSAtNC41MzEyNSBMIDIuNjI1IC01LjU5Mzc1IEwgMy43ODEyNSAtNS41 OTM3NSBDIDQuNDE0MDYyIC01LjU5Mzc1IDQuODk4NDM4IC01LjcxODc1IDUuMjM0Mzc1IC01Ljk2 ODc1IEMgNS41NjY0MDYgLTYuMjE4NzUgNS43MzQzNzUgLTYuNTgyMDMxIDUuNzM0Mzc1IC03LjA2 MjUgQyA1LjczNDM3NSAtNy41MzkwNjIgNS41NjI1IC03LjkxMDE1NiA1LjIxODc1IC04LjE3MTg3 NSBDIDQuODc1IC04LjQyOTY4OCA0LjM3ODkwNiAtOC41NjI1IDMuNzM0Mzc1IC04LjU2MjUgQyAz LjM3ODkwNiAtOC41NjI1IDMgLTguNTIzNDM4IDIuNTkzNzUgLTguNDUzMTI1IEMgMi4xOTUzMTIg LTguMzc4OTA2IDEuNzU3ODEyIC04LjI1NzgxMiAxLjI4MTI1IC04LjA5Mzc1IEwgMS4yODEyNSAt OS4yNSBDIDEuNzU3ODEyIC05LjM4MjgxMiAyLjIxMDkzOCAtOS40ODQzNzUgMi42NDA2MjUgLTku NTQ2ODc1IEMgMy4wNjY0MDYgLTkuNjE3MTg4IDMuNDY4NzUgLTkuNjU2MjUgMy44NDM3NSAtOS42 NTYyNSBDIDQuODIwMzEyIC05LjY1NjI1IDUuNTkzNzUgLTkuNDI5Njg4IDYuMTU2MjUgLTguOTg0 Mzc1IEMgNi43MjY1NjIgLTguNTQ2ODc1IDcuMDE1NjI1IC03Ljk0NTMxMiA3LjAxNTYyNSAtNy4x ODc1IEMgNy4wMTU2MjUgLTYuNjY0MDYyIDYuODYzMjgxIC02LjIyMjY1NiA2LjU2MjUgLTUuODU5 Mzc1IEMgNi4yNTc4MTIgLTUuNDkyMTg4IDUuODMyMDMxIC01LjI0MjE4OCA1LjI4MTI1IC01LjEw OTM3NSBaICIvPgo8L3N5bWJvbD4KPHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBo MC05Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIgZD0iTSA0LjkwNjI1IC04LjM1OTM3NSBM IDEuNjcxODc1IC0zLjI5Njg3NSBMIDQuOTA2MjUgLTMuMjk2ODc1IFogTSA0LjU3ODEyNSAtOS40 ODQzNzUgTCA2LjE4NzUgLTkuNDg0Mzc1IEwgNi4xODc1IC0zLjI5Njg3NSBMIDcuNTQ2ODc1IC0z LjI5Njg3NSBMIDcuNTQ2ODc1IC0yLjIzNDM3NSBMIDYuMTg3NSAtMi4yMzQzNzUgTCA2LjE4NzUg MCBMIDQuOTA2MjUgMCBMIDQuOTA2MjUgLTIuMjM0Mzc1IEwgMC42NDA2MjUgLTIuMjM0Mzc1IEwg MC42NDA2MjUgLTMuNDY4NzUgWiAiLz4KPC9zeW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2li bGUiIGlkPSJnbHlwaDAtMTAiPgo8cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDIuNTYy NSAtNC41MzEyNSBMIDIuNTYyNSAtMS4wNDY4NzUgTCA0LjYwOTM3NSAtMS4wNDY4NzUgQyA1LjMw NDY4OCAtMS4wNDY4NzUgNS44MTY0MDYgLTEuMTg3NSA2LjE0MDYyNSAtMS40Njg3NSBDIDYuNDcy NjU2IC0xLjc1NzgxMiA2LjY0MDYyNSAtMi4yMDMxMjUgNi42NDA2MjUgLTIuNzk2ODc1IEMgNi42 NDA2MjUgLTMuMzkwNjI1IDYuNDcyNjU2IC0zLjgyODEyNSA2LjE0MDYyNSAtNC4xMDkzNzUgQyA1 LjgxNjQwNiAtNC4zOTA2MjUgNS4zMDQ2ODggLTQuNTMxMjUgNC42MDkzNzUgLTQuNTMxMjUgWiBN IDIuNTYyNSAtOC40MjE4NzUgTCAyLjU2MjUgLTUuNTYyNSBMIDQuNDUzMTI1IC01LjU2MjUgQyA1 LjA3ODEyNSAtNS41NjI1IDUuNTM5MDYyIC01LjY3NTc4MSA1Ljg0Mzc1IC01LjkwNjI1IEMgNi4x NTYyNSAtNi4xNDQ1MzEgNi4zMTI1IC02LjUwNzgxMiA2LjMxMjUgLTcgQyA2LjMxMjUgLTcuNDc2 NTYyIDYuMTU2MjUgLTcuODMyMDMxIDUuODQzNzUgLTguMDYyNSBDIDUuNTM5MDYyIC04LjMwMDc4 MSA1LjA3ODEyNSAtOC40MjE4NzUgNC40NTMxMjUgLTguNDIxODc1IFogTSAxLjI4MTI1IC05LjQ4 NDM3NSBMIDQuNTQ2ODc1IC05LjQ4NDM3NSBDIDUuNTIzNDM4IC05LjQ4NDM3NSA2LjI4MTI1IC05 LjI4MTI1IDYuODEyNSAtOC44NzUgQyA3LjM0Mzc1IC04LjQ2ODc1IDcuNjA5Mzc1IC03Ljg5MDYy NSA3LjYwOTM3NSAtNy4xNDA2MjUgQyA3LjYwOTM3NSAtNi41NTQ2ODggNy40NzI2NTYgLTYuMDkz NzUgNy4yMDMxMjUgLTUuNzUgQyA2LjkyOTY4OCAtNS40MDYyNSA2LjUzMTI1IC01LjE5MTQwNiA2 IC01LjEwOTM3NSBDIDYuNjMyODEyIC00Ljk3MjY1NiA3LjEyNSAtNC42OTE0MDYgNy40Njg3NSAt NC4yNjU2MjUgQyA3LjgyMDMxMiAtMy44MzU5MzggOCAtMy4zMDA3ODEgOCAtMi42NTYyNSBDIDgg LTEuODEyNSA3LjcwNzAzMSAtMS4xNTYyNSA3LjEyNSAtMC42ODc1IEMgNi41NTA3ODEgLTAuMjI2 NTYyIDUuNzM0Mzc1IDAgNC42NzE4NzUgMCBMIDEuMjgxMjUgMCBaICIvPgo8L3N5bWJvbD4KPHN5 bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC0xMSI+CjxwYXRoIHN0eWxlPSJzdHJv a2U6bm9uZTsiIGQ9Ik0gMi41NjI1IC04LjQyMTg3NSBMIDIuNTYyNSAtNC44NTkzNzUgTCA0LjE3 MTg3NSAtNC44NTkzNzUgQyA0Ljc2NTYyNSAtNC44NTkzNzUgNS4yMjI2NTYgLTUuMDE1NjI1IDUu NTQ2ODc1IC01LjMyODEyNSBDIDUuODc4OTA2IC01LjY0MDYyNSA2LjA0Njg3NSAtNi4wNzgxMjUg Ni4wNDY4NzUgLTYuNjQwNjI1IEMgNi4wNDY4NzUgLTcuMjEwOTM4IDUuODc4OTA2IC03LjY0ODQz OCA1LjU0Njg3NSAtNy45NTMxMjUgQyA1LjIyMjY1NiAtOC4yNjU2MjUgNC43NjU2MjUgLTguNDIx ODc1IDQuMTcxODc1IC04LjQyMTg3NSBaIE0gMS4yODEyNSAtOS40ODQzNzUgTCA0LjE3MTg3NSAt OS40ODQzNzUgQyA1LjIzNDM3NSAtOS40ODQzNzUgNi4wMzUxNTYgLTkuMjM4MjgxIDYuNTc4MTI1 IC04Ljc1IEMgNy4xMTcxODggLTguMjY5NTMxIDcuMzkwNjI1IC03LjU2NjQwNiA3LjM5MDYyNSAt Ni42NDA2MjUgQyA3LjM5MDYyNSAtNS43MTA5MzggNy4xMTcxODggLTUuMDA3ODEyIDYuNTc4MTI1 IC00LjUzMTI1IEMgNi4wMzUxNTYgLTQuMDUwNzgxIDUuMjM0Mzc1IC0zLjgxMjUgNC4xNzE4NzUg LTMuODEyNSBMIDIuNTYyNSAtMy44MTI1IEwgMi41NjI1IDAgTCAxLjI4MTI1IDAgWiAiLz4KPC9z eW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJnbHlwaDAtMTIiPgo8cGF0aCBz dHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDYuMzQzNzUgLTYuODQzNzUgTCA2LjM0Mzc1IC01Ljc1 IEMgNi4wMDc4MTIgLTUuOTI1NzgxIDUuNjc1NzgxIC02LjA2MjUgNS4zNDM3NSAtNi4xNTYyNSBD IDUuMDA3ODEyIC02LjI1IDQuNjc1NzgxIC02LjI5Njg3NSA0LjM0Mzc1IC02LjI5Njg3NSBDIDMu NTgyMDMxIC02LjI5Njg3NSAyLjk5MjE4OCAtNi4wNTA3ODEgMi41NzgxMjUgLTUuNTYyNSBDIDIu MTYwMTU2IC01LjA4MjAzMSAxLjk1MzEyNSAtNC40MTAxNTYgMS45NTMxMjUgLTMuNTQ2ODc1IEMg MS45NTMxMjUgLTIuNjc5Njg4IDIuMTYwMTU2IC0yLjAwNzgxMiAyLjU3ODEyNSAtMS41MzEyNSBD IDIuOTkyMTg4IC0xLjA1MDc4MSAzLjU4MjAzMSAtMC44MTI1IDQuMzQzNzUgLTAuODEyNSBDIDQu Njc1NzgxIC0wLjgxMjUgNS4wMDc4MTIgLTAuODUxNTYyIDUuMzQzNzUgLTAuOTM3NSBDIDUuNjc1 NzgxIC0xLjAzMTI1IDYuMDA3ODEyIC0xLjE3MTg3NSA2LjM0Mzc1IC0xLjM1OTM3NSBMIDYuMzQz NzUgLTAuMjY1NjI1IEMgNi4wMTk1MzEgLTAuMTE3MTg4IDUuNjc5Njg4IC0wLjAwNzgxMjUgNS4z MjgxMjUgMC4wNjI1IEMgNC45ODQzNzUgMC4xNDQ1MzEgNC42MTMyODEgMC4xODc1IDQuMjE4NzUg MC4xODc1IEMgMy4xNDQ1MzEgMC4xODc1IDIuMjg5MDYyIC0wLjE0NDUzMSAxLjY1NjI1IC0wLjgx MjUgQyAxLjAzMTI1IC0xLjQ4ODI4MSAwLjcxODc1IC0yLjM5ODQzOCAwLjcxODc1IC0zLjU0Njg3 NSBDIDAuNzE4NzUgLTQuNzAzMTI1IDEuMDM1MTU2IC01LjYxMzI4MSAxLjY3MTg3NSAtNi4yODEy NSBDIDIuMzA0Njg4IC02Ljk0NTMxMiAzLjE3OTY4OCAtNy4yODEyNSA0LjI5Njg3NSAtNy4yODEy NSBDIDQuNjQ4NDM4IC03LjI4MTI1IDUgLTcuMjQyMTg4IDUuMzQzNzUgLTcuMTcxODc1IEMgNS42 ODc1IC03LjA5NzY1NiA2LjAxOTUzMSAtNi45ODgyODEgNi4zNDM3NSAtNi44NDM3NSBaICIvPgo8 L3N5bWJvbD4KPHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC0xMyI+CjxwYXRo IHN0eWxlPSJzdHJva2U6bm9uZTsiIGQ9Ik0gMy45ODQzNzUgLTYuMjk2ODc1IEMgMy4zNTkzNzUg LTYuMjk2ODc1IDIuODYzMjgxIC02LjA1MDc4MSAyLjUgLTUuNTYyNSBDIDIuMTMyODEyIC01LjA3 MDMxMiAxLjk1MzEyNSAtNC4zOTg0MzggMS45NTMxMjUgLTMuNTQ2ODc1IEMgMS45NTMxMjUgLTIu NjkxNDA2IDIuMTI4OTA2IC0yLjAxOTUzMSAyLjQ4NDM3NSAtMS41MzEyNSBDIDIuODQ3NjU2IC0x LjA1MDc4MSAzLjM0NzY1NiAtMC44MTI1IDMuOTg0Mzc1IC0wLjgxMjUgQyA0LjU5NzY1NiAtMC44 MTI1IDUuMDg1OTM4IC0xLjA1NDY4OCA1LjQ1MzEyNSAtMS41NDY4NzUgQyA1LjgxNjQwNiAtMi4w MzUxNTYgNiAtMi43MDMxMjUgNiAtMy41NDY4NzUgQyA2IC00LjM5MDYyNSA1LjgxNjQwNiAtNS4w NTQ2ODggNS40NTMxMjUgLTUuNTQ2ODc1IEMgNS4wODU5MzggLTYuMDQ2ODc1IDQuNTk3NjU2IC02 LjI5Njg3NSAzLjk4NDM3NSAtNi4yOTY4NzUgWiBNIDMuOTg0Mzc1IC03LjI4MTI1IEMgNC45OTIx ODggLTcuMjgxMjUgNS43ODkwNjIgLTYuOTQ1MzEyIDYuMzc1IC02LjI4MTI1IEMgNi45NTcwMzEg LTUuNjI1IDcuMjUgLTQuNzEwOTM4IDcuMjUgLTMuNTQ2ODc1IEMgNy4yNSAtMi4zNzg5MDYgNi45 NTcwMzEgLTEuNDYwOTM4IDYuMzc1IC0wLjc5Njg3NSBDIDUuNzg5MDYyIC0wLjE0MDYyNSA0Ljk5 MjE4OCAwLjE4NzUgMy45ODQzNzUgMC4xODc1IEMgMi45NjA5MzggMC4xODc1IDIuMTYwMTU2IC0w LjE0MDYyNSAxLjU3ODEyNSAtMC43OTY4NzUgQyAxLjAwMzkwNiAtMS40NjA5MzggMC43MTg3NSAt Mi4zNzg5MDYgMC43MTg3NSAtMy41NDY4NzUgQyAwLjcxODc1IC00LjcxMDkzOCAxLjAwMzkwNiAt NS42MjUgMS41NzgxMjUgLTYuMjgxMjUgQyAyLjE2MDE1NiAtNi45NDUzMTIgMi45NjA5MzggLTcu MjgxMjUgMy45ODQzNzUgLTcuMjgxMjUgWiAiLz4KPC9zeW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9 InZpc2libGUiIGlkPSJnbHlwaDAtMTQiPgo8cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJN IDcuMTQwNjI1IC00LjI5Njg3NSBMIDcuMTQwNjI1IDAgTCA1Ljk2ODc1IDAgTCA1Ljk2ODc1IC00 LjI1IEMgNS45Njg3NSAtNC45MjU3ODEgNS44MzU5MzggLTUuNDI5Njg4IDUuNTc4MTI1IC01Ljc2 NTYyNSBDIDUuMzE2NDA2IC02LjA5NzY1NiA0LjkyMTg3NSAtNi4yNjU2MjUgNC4zOTA2MjUgLTYu MjY1NjI1IEMgMy43NjU2MjUgLTYuMjY1NjI1IDMuMjY5NTMxIC02LjA2MjUgMi45MDYyNSAtNS42 NTYyNSBDIDIuNTM5MDYyIC01LjI1NzgxMiAyLjM1OTM3NSAtNC43MTA5MzggMi4zNTkzNzUgLTQu MDE1NjI1IEwgMi4zNTkzNzUgMCBMIDEuMTg3NSAwIEwgMS4xODc1IC03LjEwOTM3NSBMIDIuMzU5 Mzc1IC03LjEwOTM3NSBMIDIuMzU5Mzc1IC02IEMgMi42NDA2MjUgLTYuNDI1NzgxIDIuOTY4NzUg LTYuNzQyMTg4IDMuMzQzNzUgLTYuOTUzMTI1IEMgMy43MTg3NSAtNy4xNzE4NzUgNC4xNTYyNSAt Ny4yODEyNSA0LjY1NjI1IC03LjI4MTI1IEMgNS40Njg3NSAtNy4yODEyNSA2LjA4MjAzMSAtNy4w MjM0MzggNi41IC02LjUxNTYyNSBDIDYuOTI1NzgxIC02LjAxNTYyNSA3LjE0MDYyNSAtNS4yNzM0 MzggNy4xNDA2MjUgLTQuMjk2ODc1IFogIi8+Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJmbG93PSJ2 aXNpYmxlIiBpZD0iZ2x5cGgwLTE1Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIgZD0iTSA3 LjMxMjUgLTMuODQzNzUgTCA3LjMxMjUgLTMuMjgxMjUgTCAxLjkzNzUgLTMuMjgxMjUgQyAxLjk4 ODI4MSAtMi40Njg3NSAyLjIyNjU2MiAtMS44NTE1NjIgMi42NTYyNSAtMS40Mzc1IEMgMy4wOTM3 NSAtMS4wMTk1MzEgMy42OTUzMTIgLTAuODEyNSA0LjQ2ODc1IC0wLjgxMjUgQyA0LjkxNDA2MiAt MC44MTI1IDUuMzQ3NjU2IC0wLjg2MzI4MSA1Ljc2NTYyNSAtMC45Njg3NSBDIDYuMTkxNDA2IC0x LjA4MjAzMSA2LjYxMzI4MSAtMS4yNSA3LjAzMTI1IC0xLjQ2ODc1IEwgNy4wMzEyNSAtMC4zNTkz NzUgQyA2LjYxMzI4MSAtMC4xNzk2ODggNi4xNzk2ODggLTAuMDQ2ODc1IDUuNzM0Mzc1IDAuMDQ2 ODc1IEMgNS4yOTY4NzUgMC4xNDA2MjUgNC44NTE1NjIgMC4xODc1IDQuNDA2MjUgMC4xODc1IEMg My4yNjk1MzEgMC4xODc1IDIuMzY3MTg4IC0wLjE0MDYyNSAxLjcwMzEyNSAtMC43OTY4NzUgQyAx LjA0Njg3NSAtMS40NjA5MzggMC43MTg3NSAtMi4zNTkzNzUgMC43MTg3NSAtMy40ODQzNzUgQyAw LjcxODc1IC00LjY0ODQzOCAxLjAzMTI1IC01LjU3MDMxMiAxLjY1NjI1IC02LjI1IEMgMi4yODkw NjIgLTYuOTM3NSAzLjE0MDYyNSAtNy4yODEyNSA0LjIwMzEyNSAtNy4yODEyNSBDIDUuMTYwMTU2 IC03LjI4MTI1IDUuOTE0MDYyIC02Ljk3MjY1NiA2LjQ2ODc1IC02LjM1OTM3NSBDIDcuMDMxMjUg LTUuNzQyMTg4IDcuMzEyNSAtNC45MDYyNSA3LjMxMjUgLTMuODQzNzUgWiBNIDYuMTQwNjI1IC00 LjE4NzUgQyA2LjEyODkwNiAtNC44MjAzMTIgNS45NDUzMTIgLTUuMzMyMDMxIDUuNTkzNzUgLTUu NzE4NzUgQyA1LjI1IC02LjEwMTU2MiA0Ljc4OTA2MiAtNi4yOTY4NzUgNC4yMTg3NSAtNi4yOTY4 NzUgQyAzLjU2MjUgLTYuMjk2ODc1IDMuMDM1MTU2IC02LjEwOTM3NSAyLjY0MDYyNSAtNS43MzQz NzUgQyAyLjI1MzkwNiAtNS4zNjcxODggMi4wMzEyNSAtNC44NTE1NjIgMS45Njg3NSAtNC4xODc1 IFogIi8+Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTE2 Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIgZD0iTSAyLjM3NSAtOS4xMjUgTCAyLjM3NSAt Ny4xMDkzNzUgTCA0Ljc4MTI1IC03LjEwOTM3NSBMIDQuNzgxMjUgLTYuMjAzMTI1IEwgMi4zNzUg LTYuMjAzMTI1IEwgMi4zNzUgLTIuMzQzNzUgQyAyLjM3NSAtMS43NTc4MTIgMi40NTMxMjUgLTEu MzgyODEyIDIuNjA5Mzc1IC0xLjIxODc1IEMgMi43NzM0MzggLTEuMDYyNSAzLjEwMTU2MiAtMC45 ODQzNzUgMy41OTM3NSAtMC45ODQzNzUgTCA0Ljc4MTI1IC0wLjk4NDM3NSBMIDQuNzgxMjUgMCBM IDMuNTkzNzUgMCBDIDIuNjg3NSAwIDIuMDYyNSAtMC4xNjQwNjIgMS43MTg3NSAtMC41IEMgMS4z NzUgLTAuODQzNzUgMS4yMDMxMjUgLTEuNDU3MDMxIDEuMjAzMTI1IC0yLjM0Mzc1IEwgMS4yMDMx MjUgLTYuMjAzMTI1IEwgMC4zNDM3NSAtNi4yMDMxMjUgTCAwLjM0Mzc1IC03LjEwOTM3NSBMIDEu MjAzMTI1IC03LjEwOTM3NSBMIDEuMjAzMTI1IC05LjEyNSBaICIvPgo8L3N5bWJvbD4KPHN5bWJv bCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC0xNyI+CjxwYXRoIHN0eWxlPSJzdHJva2U6 bm9uZTsiIGQ9Ik0gNi45NTMxMjUgLTkuMTcxODc1IEwgNi45NTMxMjUgLTcuOTIxODc1IEMgNi40 NzI2NTYgLTguMTQ4NDM4IDYuMDE1NjI1IC04LjMyMDMxMiA1LjU3ODEyNSAtOC40Mzc1IEMgNS4x NDg0MzggLTguNTUwNzgxIDQuNzM0Mzc1IC04LjYwOTM3NSA0LjMyODEyNSAtOC42MDkzNzUgQyAz LjYyODkwNiAtOC42MDkzNzUgMy4wODU5MzggLTguNDcyNjU2IDIuNzAzMTI1IC04LjIwMzEyNSBD IDIuMzI4MTI1IC03LjkyOTY4OCAyLjE0MDYyNSAtNy41NDY4NzUgMi4xNDA2MjUgLTcuMDQ2ODc1 IEMgMi4xNDA2MjUgLTYuNjI4OTA2IDIuMjY1NjI1IC02LjMxMjUgMi41MTU2MjUgLTYuMDkzNzUg QyAyLjc3MzQzOCAtNS44ODI4MTIgMy4yNTM5MDYgLTUuNzEwOTM4IDMuOTUzMTI1IC01LjU3ODEy NSBMIDQuNzM0Mzc1IC01LjQyMTg3NSBDIDUuNjc5Njg4IC01LjIzNDM3NSA2LjM4MjgxMiAtNC45 MTAxNTYgNi44NDM3NSAtNC40NTMxMjUgQyA3LjMwMDc4MSAtMy45OTIxODggNy41MzEyNSAtMy4z Nzg5MDYgNy41MzEyNSAtMi42MDkzNzUgQyA3LjUzMTI1IC0xLjY5MTQwNiA3LjIyMjY1NiAtMC45 OTIxODggNi42MDkzNzUgLTAuNTE1NjI1IEMgNS45OTIxODggLTAuMDQ2ODc1IDUuMDg1OTM4IDAu MTg3NSAzLjg5MDYyNSAwLjE4NzUgQyAzLjQ0MTQwNiAwLjE4NzUgMi45NjA5MzggMC4xMzI4MTIg Mi40NTMxMjUgMC4wMzEyNSBDIDEuOTUzMTI1IC0wLjA3MDMxMjUgMS40Mjk2ODggLTAuMjIyNjU2 IDAuODkwNjI1IC0wLjQyMTg3NSBMIDAuODkwNjI1IC0xLjczNDM3NSBDIDEuNDEwMTU2IC0xLjQ0 MTQwNiAxLjkyMTg3NSAtMS4yMjI2NTYgMi40MjE4NzUgLTEuMDc4MTI1IEMgMi45MjE4NzUgLTAu OTI5Njg4IDMuNDEwMTU2IC0wLjg1OTM3NSAzLjg5MDYyNSAtMC44NTkzNzUgQyA0LjYyODkwNiAt MC44NTkzNzUgNS4xOTUzMTIgLTEgNS41OTM3NSAtMS4yODEyNSBDIDUuOTg4MjgxIC0xLjU3MDMx MiA2LjE4NzUgLTEuOTg0Mzc1IDYuMTg3NSAtMi41MTU2MjUgQyA2LjE4NzUgLTIuOTg0Mzc1IDYu MDM5MDYyIC0zLjM0NzY1NiA1Ljc1IC0zLjYwOTM3NSBDIDUuNDY4NzUgLTMuODY3MTg4IDUuMDAz OTA2IC00LjA2NjQwNiA0LjM1OTM3NSAtNC4yMDMxMjUgTCAzLjU3ODEyNSAtNC4zNTkzNzUgQyAy LjYxNzE4OCAtNC41NDY4NzUgMS45MjU3ODEgLTQuODQzNzUgMS41IC01LjI1IEMgMS4wNzAzMTIg LTUuNjU2MjUgMC44NTkzNzUgLTYuMjE4NzUgMC44NTkzNzUgLTYuOTM3NSBDIDAuODU5Mzc1IC03 Ljc4MTI1IDEuMTQ4NDM4IC04LjQ0MTQwNiAxLjczNDM3NSAtOC45MjE4NzUgQyAyLjMyODEyNSAt OS40MTAxNTYgMy4xNDQ1MzEgLTkuNjU2MjUgNC4xODc1IC05LjY1NjI1IEMgNC42MjUgLTkuNjU2 MjUgNS4wNzAzMTIgLTkuNjEzMjgxIDUuNTMxMjUgLTkuNTMxMjUgQyA2IC05LjQ0NTMxMiA2LjQ3 MjY1NiAtOS4zMjgxMjUgNi45NTMxMjUgLTkuMTcxODc1IFogIi8+Cjwvc3ltYm9sPgo8c3ltYm9s IG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTE4Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpu b25lOyIgZD0iTSAxLjI4MTI1IC05LjQ4NDM3NSBMIDYuNzE4NzUgLTkuNDg0Mzc1IEwgNi43MTg3 NSAtOC4zOTA2MjUgTCAyLjU2MjUgLTguMzkwNjI1IEwgMi41NjI1IC01LjYwOTM3NSBMIDYuMzEy NSAtNS42MDkzNzUgTCA2LjMxMjUgLTQuNTMxMjUgTCAyLjU2MjUgLTQuNTMxMjUgTCAyLjU2MjUg MCBMIDEuMjgxMjUgMCBaICIvPgo8L3N5bWJvbD4KPHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIg aWQ9ImdseXBoMC0xOSI+CjxwYXRoIHN0eWxlPSJzdHJva2U6bm9uZTsiIGQ9Ik0gMS4yODEyNSAt OS40ODQzNzUgTCAyLjU2MjUgLTkuNDg0Mzc1IEwgMi41NjI1IDAgTCAxLjI4MTI1IDAgWiAiLz4K PC9zeW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJnbHlwaDAtMjAiPgo8cGF0 aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDIuNTYyNSAtOC40MjE4NzUgTCAyLjU2MjUgLTEu MDQ2ODc1IEwgNC4xMDkzNzUgLTEuMDQ2ODc1IEMgNS40MTAxNTYgLTEuMDQ2ODc1IDYuMzYzMjgx IC0xLjM0Mzc1IDYuOTY4NzUgLTEuOTM3NSBDIDcuNTgyMDMxIC0yLjUzMTI1IDcuODkwNjI1IC0z LjQ2ODc1IDcuODkwNjI1IC00Ljc1IEMgNy44OTA2MjUgLTYuMDE5NTMxIDcuNTgyMDMxIC02Ljk0 NTMxMiA2Ljk2ODc1IC03LjUzMTI1IEMgNi4zNjMyODEgLTguMTI1IDUuNDEwMTU2IC04LjQyMTg3 NSA0LjEwOTM3NSAtOC40MjE4NzUgWiBNIDEuMjgxMjUgLTkuNDg0Mzc1IEwgMy45MDYyNSAtOS40 ODQzNzUgQyA1Ljc1IC05LjQ4NDM3NSA3LjA5NzY1NiAtOS4wOTc2NTYgNy45NTMxMjUgLTguMzI4 MTI1IEMgOC44MTY0MDYgLTcuNTY2NDA2IDkuMjUgLTYuMzc1IDkuMjUgLTQuNzUgQyA5LjI1IC0z LjExMzI4MSA4LjgxNjQwNiAtMS45MTAxNTYgNy45NTMxMjUgLTEuMTQwNjI1IEMgNy4wODU5Mzgg LTAuMzc4OTA2IDUuNzM4MjgxIDAgMy45MDYyNSAwIEwgMS4yODEyNSAwIFogIi8+Cjwvc3ltYm9s Pgo8c3ltYm9sIG92ZXJmbG93PSJ2aXNpYmxlIiBpZD0iZ2x5cGgwLTIxIj4KPHBhdGggc3R5bGU9 InN0cm9rZTpub25lOyIgZD0iTSA1LjM0Mzc1IC02LjAxNTYyNSBDIDUuMjA3MDMxIC02LjA4NTkz OCA1LjA2MjUgLTYuMTQwNjI1IDQuOTA2MjUgLTYuMTcxODc1IEMgNC43NTc4MTIgLTYuMjEwOTM4 IDQuNTkzNzUgLTYuMjM0Mzc1IDQuNDA2MjUgLTYuMjM0Mzc1IEMgMy43NSAtNi4yMzQzNzUgMy4y NDIxODggLTYuMDE5NTMxIDIuODkwNjI1IC01LjU5Mzc1IEMgMi41MzUxNTYgLTUuMTY0MDYyIDIu MzU5Mzc1IC00LjU1MDc4MSAyLjM1OTM3NSAtMy43NSBMIDIuMzU5Mzc1IDAgTCAxLjE4NzUgMCBM IDEuMTg3NSAtNy4xMDkzNzUgTCAyLjM1OTM3NSAtNy4xMDkzNzUgTCAyLjM1OTM3NSAtNiBDIDIu NTk3NjU2IC02LjQzNzUgMi45MTQwNjIgLTYuNzU3ODEyIDMuMzEyNSAtNi45Njg3NSBDIDMuNzA3 MDMxIC03LjE3NTc4MSA0LjE4NzUgLTcuMjgxMjUgNC43NSAtNy4yODEyNSBDIDQuODMyMDMxIC03 LjI4MTI1IDQuOTIxODc1IC03LjI3MzQzOCA1LjAxNTYyNSAtNy4yNjU2MjUgQyA1LjEwOTM3NSAt Ny4yNTM5MDYgNS4yMTg3NSAtNy4yMzgyODEgNS4zNDM3NSAtNy4yMTg3NSBaICIvPgo8L3N5bWJv bD4KPHN5bWJvbCBvdmVyZmxvdz0idmlzaWJsZSIgaWQ9ImdseXBoMC0yMiI+CjxwYXRoIHN0eWxl PSJzdHJva2U6bm9uZTsiIGQ9Ik0gMC42NDA2MjUgLTQuMDc4MTI1IEwgNC4wNjI1IC00LjA3ODEy NSBMIDQuMDYyNSAtMy4wNDY4NzUgTCAwLjY0MDYyNSAtMy4wNDY4NzUgWiAiLz4KPC9zeW1ib2w+ CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJnbHlwaDAtMjMiPgo8cGF0aCBzdHlsZT0i c3Ryb2tlOm5vbmU7IiBkPSJNIDQuNDUzMTI1IC0zLjU3ODEyNSBDIDMuNTE1NjI1IC0zLjU3ODEy NSAyLjg2MzI4MSAtMy40Njg3NSAyLjUgLTMuMjUgQyAyLjEzMjgxMiAtMy4wMzEyNSAxLjk1MzEy NSAtMi42NjAxNTYgMS45NTMxMjUgLTIuMTQwNjI1IEMgMS45NTMxMjUgLTEuNzM0Mzc1IDIuMDg1 OTM4IC0xLjQwNjI1IDIuMzU5Mzc1IC0xLjE1NjI1IEMgMi42Mjg5MDYgLTAuOTE0MDYyIDMgLTAu Nzk2ODc1IDMuNDY4NzUgLTAuNzk2ODc1IEMgNC4xMTMyODEgLTAuNzk2ODc1IDQuNjMyODEyIC0x LjAyMzQzOCA1LjAzMTI1IC0xLjQ4NDM3NSBDIDUuNDI1NzgxIC0xLjk0MTQwNiA1LjYyNSAtMi41 NTA3ODEgNS42MjUgLTMuMzEyNSBMIDUuNjI1IC0zLjU3ODEyNSBaIE0gNi43ODEyNSAtNC4wNjI1 IEwgNi43ODEyNSAwIEwgNS42MjUgMCBMIDUuNjI1IC0xLjA3ODEyNSBDIDUuMzUxNTYyIC0wLjY0 ODQzOCA1LjAxOTUzMSAtMC4zMzIwMzEgNC42MjUgLTAuMTI1IEMgNC4yMjY1NjIgMC4wODIwMzEy IDMuNzM4MjgxIDAuMTg3NSAzLjE1NjI1IDAuMTg3NSBDIDIuNDI1NzgxIDAuMTg3NSAxLjg0NzY1 NiAtMC4wMTU2MjUgMS40MjE4NzUgLTAuNDIxODc1IEMgMC45OTIxODggLTAuODM1OTM4IDAuNzgx MjUgLTEuMzgyODEyIDAuNzgxMjUgLTIuMDYyNSBDIDAuNzgxMjUgLTIuODYzMjgxIDEuMDQ2ODc1 IC0zLjQ2ODc1IDEuNTc4MTI1IC0zLjg3NSBDIDIuMTE3MTg4IC00LjI4MTI1IDIuOTIxODc1IC00 LjQ4NDM3NSAzLjk4NDM3NSAtNC40ODQzNzUgTCA1LjYyNSAtNC40ODQzNzUgTCA1LjYyNSAtNC42 MDkzNzUgQyA1LjYyNSAtNS4xNDA2MjUgNS40NDUzMTIgLTUuNTUwNzgxIDUuMDkzNzUgLTUuODQz NzUgQyA0LjczODI4MSAtNi4xNDQ1MzEgNC4yMzgyODEgLTYuMjk2ODc1IDMuNTkzNzUgLTYuMjk2 ODc1IEMgMy4xODc1IC02LjI5Njg3NSAyLjc4OTA2MiAtNi4yNDIxODggMi40MDYyNSAtNi4xNDA2 MjUgQyAyLjAxOTUzMSAtNi4wNDY4NzUgMS42NDg0MzggLTUuODk4NDM4IDEuMjk2ODc1IC01Ljcw MzEyNSBMIDEuMjk2ODc1IC02Ljc4MTI1IEMgMS43MjI2NTYgLTYuOTQ1MzEyIDIuMTQwNjI1IC03 LjA3MDMxMiAyLjU0Njg3NSAtNy4xNTYyNSBDIDIuOTUzMTI1IC03LjIzODI4MSAzLjM0Mzc1IC03 LjI4MTI1IDMuNzE4NzUgLTcuMjgxMjUgQyA0Ljc1IC03LjI4MTI1IDUuNTE1NjI1IC03LjAxNTYy NSA2LjAxNTYyNSAtNi40ODQzNzUgQyA2LjUyMzQzOCAtNS45NTMxMjUgNi43ODEyNSAtNS4xNDQ1 MzEgNi43ODEyNSAtNC4wNjI1IFogIi8+Cjwvc3ltYm9sPgo8c3ltYm9sIG92ZXJmbG93PSJ2aXNp YmxlIiBpZD0iZ2x5cGgwLTI0Ij4KPHBhdGggc3R5bGU9InN0cm9rZTpub25lOyIgZD0iTSAxLjIx ODc1IC05Ljg3NSBMIDIuMzkwNjI1IC05Ljg3NSBMIDIuMzkwNjI1IDAgTCAxLjIxODc1IDAgWiAi Lz4KPC9zeW1ib2w+CjxzeW1ib2wgb3ZlcmZsb3c9InZpc2libGUiIGlkPSJnbHlwaDAtMjUiPgo8 cGF0aCBzdHlsZT0ic3Ryb2tlOm5vbmU7IiBkPSJNIDUuNzUgLTYuOTA2MjUgTCA1Ljc1IC01Ljc5 Njg3NSBDIDUuNDI1NzgxIC01Ljk2MDkzOCA1LjA4NTkzOCAtNi4wODU5MzggNC43MzQzNzUgLTYu MTcxODc1IEMgNC4zNzg5MDYgLTYuMjUzOTA2IDQuMDA3ODEyIC02LjI5Njg3NSAzLjYyNSAtNi4y OTY4NzUgQyAzLjAzOTA2MiAtNi4yOTY4NzUgMi42MDE1NjIgLTYuMjA3MDMxIDIuMzEyNSAtNi4w MzEyNSBDIDIuMDMxMjUgLTUuODUxNTYyIDEuODkwNjI1IC01LjU4NTkzOCAxLjg5MDYyNSAtNS4y MzQzNzUgQyAxLjg5MDYyNSAtNC45NjA5MzggMS45ODgyODEgLTQuNzUgMi4xODc1IC00LjU5Mzc1 IEMgMi4zOTQ1MzEgLTQuNDQ1MzEyIDIuODE2NDA2IC00LjMwMDc4MSAzLjQ1MzEyNSAtNC4xNTYy NSBMIDMuODQzNzUgLTQuMDYyNSBDIDQuNjc1NzgxIC0zLjg4MjgxMiA1LjI2NTYyNSAtMy42MzI4 MTIgNS42MDkzNzUgLTMuMzEyNSBDIDUuOTYwOTM4IC0yLjk4ODI4MSA2LjE0MDYyNSAtMi41Mzkw NjIgNi4xNDA2MjUgLTEuOTY4NzUgQyA2LjE0MDYyNSAtMS4zMDA3ODEgNS44Nzg5MDYgLTAuNzcz NDM4IDUuMzU5Mzc1IC0wLjM5MDYyNSBDIDQuODM1OTM4IC0wLjAwMzkwNjI1IDQuMTE3MTg4IDAu MTg3NSAzLjIwMzEyNSAwLjE4NzUgQyAyLjgxNjQwNiAwLjE4NzUgMi40MTQwNjIgMC4xNDg0Mzgg MiAwLjA3ODEyNSBDIDEuNTkzNzUgMC4wMDM5MDYyNSAxLjE2MDE1NiAtMC4xMDkzNzUgMC43MDMx MjUgLTAuMjY1NjI1IEwgMC43MDMxMjUgLTEuNDY4NzUgQyAxLjE0MDYyNSAtMS4yMzgyODEgMS41 NjY0MDYgLTEuMDY2NDA2IDEuOTg0Mzc1IC0wLjk1MzEyNSBDIDIuMzk4NDM4IC0wLjg0NzY1NiAy LjgxMjUgLTAuNzk2ODc1IDMuMjE4NzUgLTAuNzk2ODc1IEMgMy43Njk1MzEgLTAuNzk2ODc1IDQu MTkxNDA2IC0wLjg5MDYyNSA0LjQ4NDM3NSAtMS4wNzgxMjUgQyA0Ljc4NTE1NiAtMS4yNjU2MjUg NC45Mzc1IC0xLjUzMTI1IDQuOTM3NSAtMS44NzUgQyA0LjkzNzUgLTIuMTg3NSA0LjgyODEyNSAt Mi40MjU3ODEgNC42MDkzNzUgLTIuNTkzNzUgQyA0LjM5ODQzOCAtMi43Njk1MzEgMy45Mzc1IC0y LjkzNzUgMy4yMTg3NSAtMy4wOTM3NSBMIDIuODEyNSAtMy4xODc1IEMgMi4wODIwMzEgLTMuMzQz NzUgMS41NTQ2ODggLTMuNTc4MTI1IDEuMjM0Mzc1IC0zLjg5MDYyNSBDIDAuOTEwMTU2IC00LjIw MzEyNSAwLjc1IC00LjYzMjgxMiAwLjc1IC01LjE4NzUgQyAwLjc1IC01Ljg1MTU2MiAwLjk4NDM3 NSAtNi4zNjcxODggMS40NTMxMjUgLTYuNzM0Mzc1IEMgMS45Mjk2ODggLTcuMDk3NjU2IDIuNjA5 Mzc1IC03LjI4MTI1IDMuNDg0Mzc1IC03LjI4MTI1IEMgMy45MTAxNTYgLTcuMjgxMjUgNC4zMTY0 MDYgLTcuMjUgNC43MDMxMjUgLTcuMTg3NSBDIDUuMDg1OTM4IC03LjEyNSA1LjQzNzUgLTcuMDMx MjUgNS43NSAtNi45MDYyNSBaICIvPgo8L3N5bWJvbD4KPC9nPgo8L2RlZnM+CjxnIGlkPSJzdXJm YWNlNzYyOTgiPgo8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iOTg4IiBoZWlnaHQ9IjYyMyIgc3R5 bGU9ImZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2U6bm9uZTsi Lz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsNzUuMjk0MTE5 JSw3OS42MDc4NDQlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5l Y2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoNTQuNTA5ODA3JSw0MS4x NzY0NzElLDcuODQzMTM4JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsi IGQ9Ik0gMC45IDEwLjIgTCAyMy41NSAxMC4yIEwgMjMuNTUgMzQuMTUgTCAwLjkgMzQuMTUgWiAi IHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZp bGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDYyLjM1Mjk0MyUsNjIuMzUyOTQzJSw2Mi4zNTI5NDMl KTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ry b2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7 c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDUuMDUgMjAuMzUgTCA4LjU1IDIwLjM1IEwgOC41 NSAyMy44NSBMIDUuMDUgMjMuODUgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcs LTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1s aW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0 cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDUuMDUgMjAuMzUgTCA4 LjU1IDIwLjM1IEwgOC41NSAyMy44NSBMIDUuMDUgMjMuODUgWiAiIHRyYW5zZm9ybT0ibWF0cml4 KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lk dGg6MC4xMztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6 cmdiKDEwMCUsMTAwJSwxMDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEw OyIgZD0iTSA3LjAxNjYwMiAyMC45MTY2MDIgQyA3LjAxNjYwMiAyMi42NjY2MDIgNy4zNjY2MDIg MjIuMzE2NjAyIDUuNjE2NjAyIDIyLjMxNjYwMiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwy MCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4wODtz dHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAl LDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA3LjAxNjYw MiAyMC45MTY2MDIgQyA3LjAxNjYwMiAyMi42NjY2MDIgNy4zNjY2MDIgMjIuMzE2NjAyIDUuNjE2 NjAyIDIyLjMxNjYwMiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4K PHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9w YWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1p dGVybGltaXQ6MTA7IiBkPSJNIDcuMTg0OTYxIDIxLjE5MDAzOSBMIDcuMDA5OTYxIDIwLjg0MDAz OSBMIDYuODM0OTYxIDIxLjE5MDAzOSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0x NywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUs MCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtz dHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6 MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNS44OTAwMzkgMjIuMTM0OTYxIEwgNS41NDAw MzkgMjIuMzA5OTYxIEwgNS44OTAwMzkgMjIuNDg0OTYxIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgy MCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRo OjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJn YigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsi IGQ9Ik0gOC4wNTUwNzggMjEuOTAwOTc3IEMgNi4zMDUwNzggMjEuOTAwOTc3IDYuNjU1MDc4IDIx LjU1MDk3NyA2LjY1NTA3OCAyMy4zMDA5NzcgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAs LTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMDg7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSww JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gOC4wNTUwNzgg MjEuOTAwOTc3IEMgNi4zMDUwNzggMjEuOTAwOTc3IDYuNjU1MDc4IDIxLjU1MDk3NyA2LjY1NTA3 OCAyMy4zMDA5NzcgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+Cjxw YXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFj aXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9p bjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRl cmxpbWl0OjEwOyIgZD0iTSA3Ljc0NDkyMiAyMi4wNjUwMzkgTCA4LjA5NDkyMiAyMS44OTAwMzkg TCA3Ljc0NDkyMiAyMS43MTUwMzkgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcs LTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAl KTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ry b2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7 c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDYuNDUgMjMuMDA5OTYxIEwgNi42MjUgMjMuMzU5 OTYxIEwgNi44IDIzLjAwOTk2MSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywt MjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoNjIuMzUyOTQz JSw2Mi4zNTI5NDMlLDYyLjM1Mjk0MyUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7 c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSww JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTguNTQw MDM5IDE3LjAwOTk2MSBMIDIyLjA0MDAzOSAxNy4wMDk5NjEgTCAyMi4wNDAwMzkgMjAuNTA5OTYx IEwgMTguNTQwMDM5IDIwLjUwOTk2MSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0x NywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tl LWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTguNTQwMDM5IDE3 LjAwOTk2MSBMIDIyLjA0MDAzOSAxNy4wMDk5NjEgTCAyMi4wNDAwMzkgMjAuNTA5OTYxIEwgMTgu NTQwMDM5IDIwLjUwOTk2MSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAz KSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjEzO3N0cm9rZS1saW5l Y2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSwxMDAlLDEwMCUp O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDIwLjUwNjY0MSAx Ny41NzY1NjIgQyAyMC41MDY2NDEgMTkuMzI2NTYyIDIwLjg1NjY0MSAxOC45NzY1NjIgMTkuMTA2 NjQxIDE4Ljk3NjU2MiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4K PHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4wODtzdHJva2UtbGluZWNhcDpi dXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3Bh Y2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAyMC41MDY2NDEgMTcuNTc2NTYyIEMg MjAuNTA2NjQxIDE5LjMyNjU2MiAyMC44NTY2NDEgMTguOTc2NTYyIDE5LjEwNjY0MSAxOC45NzY1 NjIgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxl PSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7c3Ry b2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEw OyIgZD0iTSAyMC42NzUgMTcuODUgTCAyMC41IDE3LjUgTCAyMC4zMjUgMTcuODUgWiAiIHRyYW5z Zm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVs ZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6 MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2Io MCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDE5 LjM4MDA3OCAxOC43OTQ5MjIgTCAxOS4wMzAwNzggMTguOTY5OTIyIEwgMTkuMzgwMDc4IDE5LjE0 NDkyMiBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBz dHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjEzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ry b2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSwxMDAlLDEwMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDIxLjU0NTExNyAxOC41NjExMzMgQyAx OS43OTUxMTcgMTguNTYxMTMzIDIwLjE0NTExNyAxOC4yMTExMzMgMjAuMTQ1MTE3IDE5Ljk2MTEz MyAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9 ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4wODtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1s aW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9r ZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAyMS41NDUxMTcgMTguNTYxMTMzIEMgMTkuNzk1MTE3IDE4 LjU2MTEzMyAyMC4xNDUxMTcgMTguMjExMTMzIDIwLjE0NTExNyAxOS45NjExMzMgIiB0cmFuc2Zv cm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6 ZXZlbm9kZDtmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAu MTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAl LDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAyMS4y MzQ5NjEgMTguNzI1IEwgMjEuNTg0OTYxIDE4LjU1IEwgMjEuMjM0OTYxIDE4LjM3NSBaICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1y dWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0 aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJn YigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0g MTkuOTQwMDM5IDE5LjY2OTkyMiBMIDIwLjExNTAzOSAyMC4wMTk5MjIgTCAyMC4yOTAwMzkgMTku NjY5OTIyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRo IHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig2Mi4zNTI5NDMlLDYyLjM1Mjk0MyUs NjIuMzUyOTQzJSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNh cDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Ut b3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxMC42ODAwNzggMTQuNzY5OTIy IEwgMTQuMTgwMDc4IDE0Ljc2OTkyMiBMIDE0LjE4MDA3OCAxOC4yNjk5MjIgTCAxMC42ODAwNzgg MTguMjY5OTIyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+Cjxw YXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0 eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxMC42ODAwNzggMTQuNzY5OTIyIEwgMTQu MTgwMDc4IDE0Ljc2OTkyMiBMIDE0LjE4MDA3OCAxOC4yNjk5MjIgTCAxMC42ODAwNzggMTguMjY5 OTIyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNp dHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTIuNjQ2NDg0IDE1LjMzNjUyMyBDIDEy LjY0NjQ4NCAxNy4wODY1MjMgMTIuOTk2NDg0IDE2LjczNjUyMyAxMS4yNDY0ODQgMTYuNzM2NTIz ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0i ZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxp bmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tl LW1pdGVybGltaXQ6MTA7IiBkPSJNIDEyLjY0NjQ4NCAxNS4zMzY1MjMgQyAxMi42NDY0ODQgMTcu MDg2NTIzIDEyLjk5NjQ4NCAxNi43MzY1MjMgMTEuMjQ2NDg0IDE2LjczNjUyMyAiIHRyYW5zZm9y bT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpl dmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4x O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUs MCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDEyLjgx NTAzOSAxNS42MDk5NjEgTCAxMi42NDAwMzkgMTUuMjU5OTYxIEwgMTIuNDY1MDM5IDE1LjYwOTk2 MSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHls ZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0 cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDox MDsiIGQ9Ik0gMTEuNTE5OTIyIDE2LjU1NTA3OCBMIDExLjE2OTkyMiAxNi43MzAwNzggTCAxMS41 MTk5MjIgMTYuOTA1MDc4IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMp Ii8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVj YXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTMuNjg0OTYxIDE2 LjMyMTA5NCBDIDExLjkzNDk2MSAxNi4zMjEwOTQgMTIuMjg0OTYxIDE1Ljk3MTA5NCAxMi4yODQ5 NjEgMTcuNzIxMDk0ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8 cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDEzLjY4NDk2MSAxNi4zMjEwOTQgQyAx MS45MzQ5NjEgMTYuMzIxMDk0IDEyLjI4NDk2MSAxNS45NzEwOTQgMTIuMjg0OTYxIDE3LjcyMTA5 NCAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9 ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJv a2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7 IiBkPSJNIDEzLjM3NSAxNi40ODQ5NjEgTCAxMy43MjUgMTYuMzA5OTYxIEwgMTMuMzc1IDE2LjEz NDk2MSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBz dHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eTox O3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0 ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1p dDoxMDsiIGQ9Ik0gMTIuMDgwMDc4IDE3LjQzMDA3OCBMIDEyLjI1NTA3OCAxNy43ODAwNzggTCAx Mi40MzAwNzggMTcuNDMwMDc4IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0y MDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig2Mi4zNTI5NDMl LDYyLjM1Mjk0MyUsNjIuMzUyOTQzJSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtz dHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAl LDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxMC43Njk5 MjIgMjUuNjgwMDc4IEwgMTQuMjY5OTIyIDI1LjY4MDA3OCBMIDE0LjI2OTkyMiAyOS4xODAwNzgg TCAxMC43Njk5MjIgMjkuMTgwMDc4IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3 LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2Ut bGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtz dHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxMC43Njk5MjIgMjUu NjgwMDc4IEwgMTQuMjY5OTIyIDI1LjY4MDA3OCBMIDE0LjI2OTkyMiAyOS4xODAwNzggTCAxMC43 Njk5MjIgMjkuMTgwMDc4IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMp Ii8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVj YXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTIuNzM2NTIzIDI2 LjI0NjQ4NCBDIDEyLjczNjUyMyAyNy45OTY0ODQgMTMuMDg2NTIzIDI3LjY0NjQ4NCAxMS4zMzY1 MjMgMjcuNjQ2NDg0ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8 cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDEyLjczNjUyMyAyNi4yNDY0ODQgQyAx Mi43MzY1MjMgMjcuOTk2NDg0IDEzLjA4NjUyMyAyNy42NDY0ODQgMTEuMzM2NTIzIDI3LjY0NjQ4 NCAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9 ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJv a2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7 IiBkPSJNIDEyLjkwNTA3OCAyNi41MTk5MjIgTCAxMi43MzAwNzggMjYuMTY5OTIyIEwgMTIuNTU1 MDc4IDI2LjUxOTkyMiBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIv Pgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwt b3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2Ut bWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTEuNjA5OTYxIDI3LjQ2NTAzOSBMIDExLjI1OTk2MSAyNy42 NDAwMzkgTCAxMS42MDk5NjEgMjcuODE1MDM5IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAs MjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7 c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAl LDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0g MTMuNzc1IDI3LjIzMTA1NSBDIDEyLjAyNSAyNy4yMzEwNTUgMTIuMzc1IDI2Ljg4MTA1NSAxMi4z NzUgMjguNjMxMDU1ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8 cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDEzLjc3NSAyNy4yMzEwNTUgQyAxMi4w MjUgMjcuMjMxMDU1IDEyLjM3NSAyNi44ODEwNTUgMTIuMzc1IDI4LjYzMTA1NSAiIHRyYW5zZm9y bT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpl dmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4x O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUs MCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDEzLjQ2 NTAzOSAyNy4zOTQ5MjIgTCAxMy44MTUwMzkgMjcuMjE5OTIyIEwgMTMuNDY1MDM5IDI3LjA0NDky MiBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHls ZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0 cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDox MDsiIGQ9Ik0gMTIuMTY5OTIyIDI4LjM0MDAzOSBMIDEyLjM0NDkyMiAyOC42OTAwMzkgTCAxMi41 MTk5MjIgMjguMzQwMDM5IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMp Ii8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig3MC4xOTYwOCUsNzAu MTk2MDglLDcwLjE5NjA4JSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMDU7c3Ryb2tl LWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNC4zMzMwMDggMTIg TCA2LjgxMjY5NSAxMiBMIDYuODEyNjk1IDEzLjg1OTc2NiBMIDQuMzMzMDA4IDEzLjg1OTc2NiBa ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0i IHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9w YWNpdHk6MTsiIGQ9Ik0gNzUuMDM1MTU2IDQyLjM3MTA5NCBMIDExMy44ODI4MTIgNDIuMzcxMDk0 IEwgMTEzLjg4MjgxMiA2Ny45OTYwOTQgTCA3NS4wMzUxNTYgNjcuOTk2MDk0IFogIi8+CjxwYXRo IHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig3MC4xOTYwOCUsNzAuMTk2MDglLDcw LjE5NjA4JSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMDU7c3Ryb2tlLWxpbmVjYXA6 YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNC42Njg3NSAxMy44NTk3NjYgTCA1 Ljk0NDkyMiAxMy44NTk3NjYgTCA1Ljk0NDkyMiAxNC4xNDkwMjMgTCA0LjczNTkzNyAxNC4xNDkw MjMgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5 bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDcwLjE5NjA4JSw3MC4xOTYwOCUsNzAuMTk2 MDglKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4wNTtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0 eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA1Ljk0NDkyMiAxMy44NTk3NjYgTCA2LjQ3 Njk1MyAxMy44NTk3NjYgTCA2LjQwOTc2NiAxNC4xNDkwMjMgTCA1Ljk0NDkyMiAxNC4xNDkwMjMg WiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9 ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6 MTtzdHJva2Utd2lkdGg6MC4wNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxp bWl0OjEwOyIgZD0iTSA2LjAzMTY0MSAxMy45NDY0ODQgTCA2LjE0NzI2NiAxMy45NDY0ODQgTCA2 LjE0NzI2NiAxNC4wNjIxMDkgTCA2LjAzMTY0MSAxNC4wNjIxMDkgWiAiIHRyYW5zZm9ybT0ibWF0 cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2Rk O2ZpbGw6cmdiKDcwLjE5NjA4JSw3MC4xOTYwOCUsNzAuMTk2MDglKTtmaWxsLW9wYWNpdHk6MTtz dHJva2Utd2lkdGg6MC4wNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRl cjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSA1LjMyNSAxNC4xNDkwMjMgTCA1LjgyMDg5OCAxNC4xNDkwMjMgTCA1LjgyMDg5 OCAxNC4yOTM3NSBMIDYuMDY4NzUgMTQuMjkzNzUgTCA2LjA2ODc1IDE0LjQzODI4MSBMIDUuMDc2 OTUzIDE0LjQzODI4MSBMIDUuMDc2OTUzIDE0LjI5Mzc1IEwgNS4zMjUgMTQuMjkzNzUgWiAiIHRy YW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPGcgc3R5bGU9ImZpbGw6cmdi KDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTsiPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0x IiB4PSI3My40MjE4NzUiIHk9Ijk5LjQxNzk2OSIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBo MC0yIiB4PSI4My4xNDg0MzgiIHk9Ijk5LjQxNzk2OSIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2ds eXBoMC0zIiB4PSI5My4zODI4MTIiIHk9Ijk5LjQxNzk2OSIvPgogIDx1c2UgeGxpbms6aHJlZj0i I2dseXBoMC00IiB4PSIxMDIuNDY0ODQ0IiB5PSI5OS40MTc5NjkiLz4KICA8dXNlIHhsaW5rOmhy ZWY9IiNnbHlwaDAtNSIgeD0iMTA2LjYwNTQ2OSIgeT0iOTkuNDE3OTY5Ii8+CjwvZz4KPGcgc3R5 bGU9ImZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTsiPgogIDx1c2UgeGxpbms6aHJl Zj0iI2dseXBoMC01IiB4PSIyMjMiIHk9IjE3NSIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBo MC02IiB4PSIyMzEuODg2NzE5IiB5PSIxNzUiLz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpyZ2IoMCUs MCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTUiIHg9 IjExMC44MDA3ODEiIHk9IjI5Mi4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAt NyIgeD0iMTE5LjY4NzUiIHk9IjI5Mi4xMDE1NjIiLz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpyZ2Io MCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTUi IHg9IjIyMy44MDA3ODEiIHk9IjQwNS4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlw aDAtOCIgeD0iMjMyLjY4NzUiIHk9IjQwNS4xMDE1NjIiLz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpy Z2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgw LTUiIHg9IjM4MS44MDA3ODEiIHk9IjIyNy4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNn bHlwaDAtOSIgeD0iMzkwLjY4NzUiIHk9IjIyNy4xMDE1NjIiLz4KPC9nPgo8cGF0aCBzdHlsZT0i ZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYig4Mi4zNTI5NDIlLDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtz dHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA1Ljc3OTg4MyAxNC41 MjI2NTYgTCAxMC40NzI4NTIgMTYuNDM1NTQ3ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIw LC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYig4Mi4zNTI5 NDIlLDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxp bWl0OjEwOyIgZD0iTSA2LjIzMzc4OSAxNC40Mzc2OTUgTCA1LjY3NjM2NyAxNC40ODA0NjkgTCA2 LjA0NTExNyAxNC45MDA3ODEgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMp Ii8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNh cDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDgyLjM1Mjk0MiUsNjYuMjc0 NTEyJSw5Mi41NDkwMiUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBk PSJNIDEwLjAxOTE0MSAxNi41MjA1MDggTCAxMC41NzY1NjIgMTYuNDc3NzM0IEwgMTAuMjA3ODEy IDE2LjA1NzYxNyAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBh dGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7 c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoODIuMzUyOTQyJSw2Ni4yNzQ1MTIlLDky LjU0OTAyJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNS42 MTgzNTkgMTQuNjU3MjI3IEwgNi43NTQ0OTIgMjAuMTMxMDU1ICIgdHJhbnNmb3JtPSJtYXRyaXgo MjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0 aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJn Yig4Mi4zNTI5NDIlLDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9r ZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA1Ljk0MTk5MiAxNC45ODY1MjMgTCA1LjU5NTUwOCAxNC41 NDc4NTIgTCA1LjQ1MjUzOSAxNS4wODgwODYgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAs LTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJv a2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDgyLjM1Mjk0 MiUsNjYuMjc0NTEyJSw5Mi41NDkwMiUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGlt aXQ6MTA7IiBkPSJNIDYuNDMwODU5IDE5LjgwMTc1OCBMIDYuNzc3MzQ0IDIwLjI0MDYyNSBMIDYu OTIwNTA4IDE5LjcwMDE5NSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMyki Lz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2Fw OmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoODIuMzUyOTQyJSw2Ni4yNzQ1 MTIlLDkyLjU0OTAyJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9 Ik0gNi45NjYwMTYgMjMuOTk5ODA1IEwgMTAuNjAzOTA2IDI3LjI4MDI3MyAiIHRyYW5zZm9ybT0i bWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJv a2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZTpyZ2IoODIuMzUyOTQyJSw2Ni4yNzQ1MTIlLDkyLjU0OTAyJSk7c3Ryb2tlLW9wYWNpdHk6 MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNy40MjE2OCAyNC4wNzQwMjMgTCA2Ljg4MzAw OCAyMy45MjQ4MDUgTCA3LjA4NjkxNCAyNC40NDUzMTIgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCww LDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAu MTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDgy LjM1Mjk0MiUsNjYuMjc0NTEyJSw5Mi41NDkwMiUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1p dGVybGltaXQ6MTA7IiBkPSJNIDEwLjE0ODI0MiAyNy4yMDU4NTkgTCAxMC42ODY5MTQgMjcuMzU1 MDc4IEwgMTAuNDgzMDA4IDI2LjgzNDU3ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0x NywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tl LWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYig4Mi4zNTI5NDIl LDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSAxNC4zNzg5MDYgMTYuNjIyMjY2IEwgMTguMzQxMDE2IDE4LjY1NzgxMiAiIHRy YW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6 bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoODIuMzUyOTQyJSw2Ni4yNzQ1MTIlLDkyLjU0OTAyJSk7c3Ryb2tl LW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTQuODM4NDc3IDE2LjU3NzE0 OCBMIDE0LjI3OTQ5MiAxNi41NzEwOTQgTCAxNC42MDk5NjEgMTcuMDIxODc1ICIgdHJhbnNmb3Jt PSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0 cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYig4Mi4zNTI5NDIlLDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtzdHJva2Utb3BhY2l0 eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxNy44ODE2NDEgMTguNzAyNzM0IEwgMTgu NDQwNjI1IDE4LjcwODk4NCBMIDE4LjExMDE1NiAxOC4yNTgwMDggIiB0cmFuc2Zvcm09Im1hdHJp eCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtm aWxsOnJnYig1Ni40NzA1OTElLDkzLjMzMzMzNCUsNTYuNDcwNTkxJSk7ZmlsbC1vcGFjaXR5OjE7 c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRl cjtzdHJva2U6cmdiKDU0LjUwOTgwNyUsNDEuMTc2NDcxJSw3Ljg0MzEzOCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDI3LjU5MDAzOSAxNy4zMDk5NjEgTCA1 MC4yNDAwMzkgMTcuMzA5OTYxIEwgNTAuMjQwMDM5IDQxLjI1OTk2MSBMIDI3LjU5MDAzOSA0MS4y NTk5NjEgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGgg c3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDYyLjM1Mjk0MyUsNjIuMzUyOTQzJSw2 Mi4zNTI5NDMlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2Fw OmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1v cGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDMxLjc0MDAzOSAyNy40NTk5NjEg TCAzNS4yNDAwMzkgMjcuNDU5OTYxIEwgMzUuMjQwMDM5IDMwLjk1OTk2MSBMIDMxLjc0MDAzOSAz MC45NTk5NjEgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBh dGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7 c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5 OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDMxLjc0MDAzOSAyNy40NTk5NjEgTCAzNS4y NDAwMzkgMjcuNDU5OTYxIEwgMzUuMjQwMDM5IDMwLjk1OTk2MSBMIDMxLjc0MDAzOSAzMC45NTk5 NjEgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5 bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xMztzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsMTAwJSwxMDAlKTtzdHJva2Utb3BhY2l0 eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzMy43MDY2NDEgMjguMDI2NTYyIEMgMzMu NzA2NjQxIDI5Ljc3NjU2MiAzNC4wNTY2NDEgMjkuNDI2NTYyIDMyLjMwNjY0MSAyOS40MjY1NjIg IiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJm aWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMDg7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2Ut bWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzMuNzA2NjQxIDI4LjAyNjU2MiBDIDMzLjcwNjY0MSAyOS43 NzY1NjIgMzQuMDU2NjQxIDI5LjQyNjU2MiAzMi4zMDY2NDEgMjkuNDI2NTYyICIgdHJhbnNmb3Jt PSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2 ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7 c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSww JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzMuODc1 IDI4LjMgTCAzMy43IDI3Ljk1IEwgMzMuNTI1IDI4LjMgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIw LDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6 cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5l Y2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9r ZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDMyLjU4MDA3OCAyOS4yNDQ5 MjIgTCAzMi4yMzAwNzggMjkuNDE5OTIyIEwgMzIuNTgwMDc4IDI5LjU5NDkyMiBaICIgdHJhbnNm b3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25l O3N0cm9rZS13aWR0aDowLjEzO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1p dGVyO3N0cm9rZTpyZ2IoMTAwJSwxMDAlLDEwMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1p dGVybGltaXQ6MTA7IiBkPSJNIDM0Ljc0NTExNyAyOS4wMTExMzMgQyAzMi45OTUxMTcgMjkuMDEx MTMzIDMzLjM0NTExNyAyOC42NjExMzMgMzMuMzQ1MTE3IDMwLjQxMTEzMyAiIHRyYW5zZm9ybT0i bWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJv a2Utd2lkdGg6MC4wODtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEw OyIgZD0iTSAzNC43NDUxMTcgMjkuMDExMTMzIEMgMzIuOTk1MTE3IDI5LjAxMTEzMyAzMy4zNDUx MTcgMjguNjYxMTMzIDMzLjM0NTExNyAzMC40MTExMzMgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCww LDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJn YigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNh cDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Ut b3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNC40MzQ5NjEgMjkuMTc1IEwg MzQuNzg0OTYxIDI5IEwgMzQuNDM0OTYxIDI4LjgyNSBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAs MCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpy Z2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVj YXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tl LW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzMuMTQwMDM5IDMwLjExOTky MiBMIDMzLjMxNTAzOSAzMC40Njk5MjIgTCAzMy40OTAwMzkgMzAuMTE5OTIyIFogIiB0cmFuc2Zv cm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsLXJ1bGU6 ZXZlbm9kZDtmaWxsOnJnYig2Mi4zNTI5NDMlLDYyLjM1Mjk0MyUsNjIuMzUyOTQzJSk7ZmlsbC1v cGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5l am9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1t aXRlcmxpbWl0OjEwOyIgZD0iTSA0NS4yMzAwNzggMjQuMTE5OTIyIEwgNDguNzMwMDc4IDI0LjEx OTkyMiBMIDQ4LjczMDA3OCAyNy42MTk5MjIgTCA0NS4yMzAwNzggMjcuNjE5OTIyIFogIiB0cmFu c2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5v bmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxp bWl0OjEwOyIgZD0iTSA0NS4yMzAwNzggMjQuMTE5OTIyIEwgNDguNzMwMDc4IDI0LjExOTkyMiBM IDQ4LjczMDA3OCAyNy42MTk5MjIgTCA0NS4yMzAwNzggMjcuNjE5OTIyIFogIiB0cmFuc2Zvcm09 Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ry b2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJs aW1pdDoxMDsiIGQ9Ik0gNDcuMTk2NDg0IDI0LjY4NjUyMyBDIDQ3LjE5NjQ4NCAyNi40MzY1MjMg NDcuNTQ2NDg0IDI2LjA4NjUyMyA0NS43OTY0ODQgMjYuMDg2NTIzICIgdHJhbnNmb3JtPSJtYXRy aXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13 aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9r ZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBk PSJNIDQ3LjE5NjQ4NCAyNC42ODY1MjMgQyA0Ny4xOTY0ODQgMjYuNDM2NTIzIDQ3LjU0NjQ4NCAy Ni4wODY1MjMgNDUuNzk2NDg0IDI2LjA4NjUyMyAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwy MCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAl LDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQ3LjM2NTAzOSAyNC45NTk5NjEgTCA0 Ny4xOTAwMzkgMjQuNjA5OTYxIEwgNDcuMDE1MDM5IDI0Ljk1OTk2MSBaICIgdHJhbnNmb3JtPSJt YXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5v ZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSww JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDYuMDY5OTIy IDI1LjkwNTA3OCBMIDQ1LjcxOTkyMiAyNi4wODAwNzggTCA0Ni4wNjk5MjIgMjYuMjU1MDc4IFog IiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJm aWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtz dHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDguMjM0OTYxIDI1LjY3MTA5NCBDIDQ2LjQ4NDk2 MSAyNS42NzEwOTQgNDYuODM0OTYxIDI1LjMyMTA5NCA0Ni44MzQ5NjEgMjcuMDcxMDk0ICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpu b25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVy bGltaXQ6MTA7IiBkPSJNIDQ4LjIzNDk2MSAyNS42NzEwOTQgQyA0Ni40ODQ5NjEgMjUuNjcxMDk0 IDQ2LjgzNDk2MSAyNS4zMjEwOTQgNDYuODM0OTYxIDI3LjA3MTA5NCAiIHRyYW5zZm9ybT0ibWF0 cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2Rk O2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUp O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQ3LjkyNSAyNS44 MzQ5NjEgTCA0OC4yNzUgMjUuNjU5OTYxIEwgNDcuOTI1IDI1LjQ4NDk2MSBaICIgdHJhbnNmb3Jt PSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2 ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7 c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSww JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDYuNjMw MDc4IDI2Ljc4MDA3OCBMIDQ2LjgwNTA3OCAyNy4xMzAwNzggTCA0Ni45ODAwNzggMjYuNzgwMDc4 IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxl PSJmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig2Mi4zNTI5NDMlLDYyLjM1Mjk0MyUsNjIuMzUy OTQzJSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0 eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNy4zNjk5MjIgMjEuODgwMDc4IEwgNDAu ODY5OTIyIDIxLjg4MDA3OCBMIDQwLjg2OTkyMiAyNS4zODAwNzggTCAzNy4zNjk5MjIgMjUuMzgw MDc4IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0 cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNy4zNjk5MjIgMjEuODgwMDc4IEwgNDAuODY5OTIy IDIxLjg4MDA3OCBMIDQwLjg2OTkyMiAyNS4zODAwNzggTCAzNy4zNjk5MjIgMjUuMzgwMDc4IFog IiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJm aWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGlu ZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtz dHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzkuMzM2NTIzIDIyLjQ0NjQ4NCBDIDM5LjMzNjUy MyAyNC4xOTY0ODQgMzkuNjg2NTIzIDIzLjg0NjQ4NCAzNy45MzY1MjMgMjMuODQ2NDg0ICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpu b25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVy bGltaXQ6MTA7IiBkPSJNIDM5LjMzNjUyMyAyMi40NDY0ODQgQyAzOS4zMzY1MjMgMjQuMTk2NDg0 IDM5LjY4NjUyMyAyMy44NDY0ODQgMzcuOTM2NTIzIDIzLjg0NjQ4NCAiIHRyYW5zZm9ybT0ibWF0 cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2Rk O2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUp O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDM5LjUwNTA3OCAy Mi43MTk5MjIgTCAzOS4zMzAwNzggMjIuMzY5OTIyIEwgMzkuMTU1MDc4IDIyLjcxOTkyMiBaICIg dHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmls bC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13 aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tl OnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9 Ik0gMzguMjA5OTYxIDIzLjY2NTAzOSBMIDM3Ljg1OTk2MSAyMy44NDAwMzkgTCAzOC4yMDk5NjEg MjQuMDE1MDM5IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+Cjxw YXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0 dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tl LW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDAuMzc1IDIzLjQzMTA1NSBD IDM4LjYyNSAyMy40MzEwNTUgMzguOTc1IDIzLjA4MTA1NSAzOC45NzUgMjQuODMxMDU1ICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpu b25lO3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVy bGltaXQ6MTA7IiBkPSJNIDQwLjM3NSAyMy40MzEwNTUgQyAzOC42MjUgMjMuNDMxMDU1IDM4Ljk3 NSAyMy4wODEwNTUgMzguOTc1IDI0LjgzMTA1NSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwy MCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAl LDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1 dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQwLjA2NTAzOSAyMy41OTQ5MjIgTCA0 MC40MTUwMzkgMjMuNDE5OTIyIEwgNDAuMDY1MDM5IDIzLjI0NDkyMiBaICIgdHJhbnNmb3JtPSJt YXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5v ZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSww JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzguNzY5OTIy IDI0LjU0MDAzOSBMIDM4Ljk0NDkyMiAyNC44OTAwMzkgTCAzOS4xMTk5MjIgMjQuNTQwMDM5IFog IiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJm aWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig2Mi4zNTI5NDMlLDYyLjM1Mjk0MyUsNjIuMzUyOTQz JSk7ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0 cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eTox O3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNy40NTk5NjEgMzIuNzkwMDM5IEwgNDAuOTU5 OTYxIDMyLjc5MDAzOSBMIDQwLjk1OTk2MSAzNi4yOTAwMzkgTCAzNy40NTk5NjEgMzYuMjkwMDM5 IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxl PSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1s aW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9r ZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNy40NTk5NjEgMzIuNzkwMDM5IEwgNDAuOTU5OTYxIDMy Ljc5MDAzOSBMIDQwLjk1OTk2MSAzNi4yOTAwMzkgTCAzNy40NTk5NjEgMzYuMjkwMDM5IFogIiB0 cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxs Om5vbmU7c3Ryb2tlLXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpv aW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzkuNDI2NTYyIDMzLjM1NjY0MSBDIDM5LjQyNjU2MiAz NS4xMDY2NDEgMzkuNzc2NTYyIDM0Ljc1NjY0MSAzOC4wMjY1NjIgMzQuNzU2NjQxICIgdHJhbnNm b3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25l O3N0cm9rZS13aWR0aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1p dGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGlt aXQ6MTA7IiBkPSJNIDM5LjQyNjU2MiAzMy4zNTY2NDEgQyAzOS40MjY1NjIgMzUuMTA2NjQxIDM5 Ljc3NjU2MiAzNC43NTY2NDEgMzguMDI2NTYyIDM0Ljc1NjY0MSAiIHRyYW5zZm9ybT0ibWF0cml4 KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2Zp bGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1s aW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0 cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDM5LjU5NDkyMiAzMy42 MzAwNzggTCAzOS40MTk5MjIgMzMuMjgwMDc4IEwgMzkuMjQ0OTIyIDMzLjYzMDA3OCBaICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1y dWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0 aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJn YigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0g MzguMyAzNC41NzUgTCAzNy45NSAzNC43NSBMIDM4LjMgMzQuOTI1IFogIiB0cmFuc2Zvcm09Im1h dHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tl LXdpZHRoOjAuMTM7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ry b2tlOnJnYigxMDAlLDEwMCUsMTAwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1p dDoxMDsiIGQ9Ik0gNDAuNDY1MDM5IDM0LjM0MTAxNiBDIDM4LjcxNTAzOSAzNC4zNDEwMTYgMzku MDY1MDM5IDMzLjk5MTAxNiAzOS4wNjUwMzkgMzUuNzQxMDE2ICIgdHJhbnNmb3JtPSJtYXRyaXgo MjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0 aDowLjA4O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpy Z2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJN IDQwLjQ2NTAzOSAzNC4zNDEwMTYgQyAzOC43MTUwMzkgMzQuMzQxMDE2IDM5LjA2NTAzOSAzMy45 OTEwMTYgMzkuMDY1MDM5IDM1Ljc0MTAxNiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwt MTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAl LDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7 c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5 OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQwLjE1NTA3OCAzNC41MDUwNzggTCA0MC41 MDUwNzggMzQuMzMwMDc4IEwgNDAuMTU1MDc4IDM0LjE1NTA3OCBaICIgdHJhbnNmb3JtPSJtYXRy aXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7 ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tl LWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzguODU5OTYxIDM1 LjQ1IEwgMzkuMDM0OTYxIDM1LjggTCAzOS4yMDk5NjEgMzUuNDUgWiAiIHRyYW5zZm9ybT0ibWF0 cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2Rk O2ZpbGw6cmdiKDcwLjE5NjA4JSw3MC4xOTYwOCUsNzAuMTk2MDglKTtmaWxsLW9wYWNpdHk6MTtz dHJva2Utd2lkdGg6MC4wNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRl cjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSA0NC44MjMwNDcgMzEuODA5OTYxIEwgNDcuMzAyNzM0IDMxLjgwOTk2MSBMIDQ3 LjMwMjczNCAzMy42Njk3MjcgTCA0NC44MjMwNDcgMzMuNjY5NzI3IFogIiB0cmFuc2Zvcm09Im1h dHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7Zmls bC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSA4 ODQuODMyMDMxIDQzOC41NzQyMTkgTCA5MjMuNjc5Njg4IDQzOC41NzQyMTkgTCA5MjMuNjc5Njg4 IDQ2NC4xOTkyMTkgTCA4ODQuODMyMDMxIDQ2NC4xOTkyMTkgWiAiLz4KPHBhdGggc3R5bGU9ImZp bGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDcwLjE5NjA4JSw3MC4xOTYwOCUsNzAuMTk2MDglKTtm aWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4wNTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0 cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0NS4xNTg3ODkgMzMuNjY5NzI3IEwgNDYuNDM0NzY2 IDMzLjY2OTcyNyBMIDQ2LjQzNDc2NiAzMy45NTg5ODQgTCA0NS4yMjU5NzcgMzMuOTU4OTg0IFog IiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJm aWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYig3MC4xOTYwOCUsNzAuMTk2MDglLDcwLjE5NjA4JSk7 ZmlsbC1vcGFjaXR5OjE7c3Ryb2tlLXdpZHRoOjAuMDU7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtz dHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDYuNDM0NzY2IDMzLjY2OTcyNyBMIDQ2Ljk2Njk5 MiAzMy42Njk3MjcgTCA0Ni44OTk4MDUgMzMuOTU4OTg0IEwgNDYuNDM0NzY2IDMzLjk1ODk4NCBa ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0i ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eTox O3N0cm9rZS13aWR0aDowLjA1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1p dGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGlt aXQ6MTA7IiBkPSJNIDQ2LjUyMTY4IDMzLjc1NjQ0NSBMIDQ2LjYzNzMwNSAzMy43NTY0NDUgTCA0 Ni42MzczMDUgMzMuODcyMDcgTCA0Ni41MjE2OCAzMy44NzIwNyBaICIgdHJhbnNmb3JtPSJtYXRy aXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7 ZmlsbDpyZ2IoNzAuMTk2MDglLDcwLjE5NjA4JSw3MC4xOTYwOCUpO2ZpbGwtb3BhY2l0eToxO3N0 cm9rZS13aWR0aDowLjA1O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVy O3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6 MTA7IiBkPSJNIDQ1LjgxNDg0NCAzMy45NTg5ODQgTCA0Ni4zMTA5MzcgMzMuOTU4OTg0IEwgNDYu MzEwOTM3IDM0LjEwMzcxMSBMIDQ2LjU1ODc4OSAzNC4xMDM3MTEgTCA0Ni41NTg3ODkgMzQuMjQ4 MjQyIEwgNDUuNTY2OTkyIDM0LjI0ODI0MiBMIDQ1LjU2Njk5MiAzNC4xMDM3MTEgTCA0NS44MTQ4 NDQgMzQuMTAzNzExIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+ CjxnIHN0eWxlPSJmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7Ij4KICA8dXNlIHhs aW5rOmhyZWY9IiNnbHlwaDAtMSIgeD0iODgzLjIwMzEyNSIgeT0iNDk1LjYyMTA5NCIvPgogIDx1 c2UgeGxpbms6aHJlZj0iI2dseXBoMC0yIiB4PSI4OTIuOTI5Njg4IiB5PSI0OTUuNjIxMDk0Ii8+ CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTMiIHg9IjkwMy4xNjQwNjIiIHk9IjQ5NS42MjEw OTQiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtNCIgeD0iOTEyLjI0NjA5NCIgeT0iNDk1 LjYyMTA5NCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMCIgeD0iOTE2LjM4NjcxOSIg eT0iNDk1LjYyMTA5NCIvPgo8L2c+CjxnIHN0eWxlPSJmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1v cGFjaXR5OjE7Ij4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTAiIHg9Ijc1Ni44MDA3ODEi IHk9IjMxNy4xOTkyMTkiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtNiIgeD0iNzY1Ljcy NjU2MiIgeT0iMzE3LjE5OTIxOSIvPgo8L2c+CjxnIHN0eWxlPSJmaWxsOnJnYigwJSwwJSwwJSk7 ZmlsbC1vcGFjaXR5OjE7Ij4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTAiIHg9IjY0NC42 MDE1NjIiIHk9IjQzNC4zMDA3ODEiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtNyIgeD0i NjUzLjUyNzM0NCIgeT0iNDM0LjMwMDc4MSIvPgo8L2c+CjxnIHN0eWxlPSJmaWxsOnJnYigwJSww JSwwJSk7ZmlsbC1vcGFjaXR5OjE7Ij4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTAiIHg9 Ijc1Ny42MDE1NjIiIHk9IjU0Ny4zMDA3ODEiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAt OCIgeD0iNzY2LjUyNzM0NCIgeT0iNTQ3LjMwMDc4MSIvPgo8L2c+CjxnIHN0eWxlPSJmaWxsOnJn YigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7Ij4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAt MTAiIHg9IjkyOC42MDE1NjIiIHk9IjM2Ny4zMDA3ODEiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNn bHlwaDAtOSIgeD0iOTM3LjUyNzM0NCIgeT0iMzY3LjMwMDc4MSIvPgo8L2c+CjxwYXRoIHN0eWxl PSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1s aW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDY1LjA5ODA0MSUsMzEuMzcyNTUlKTtzdHJva2Ut b3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0Ni4zMTEzMjggMzEuNTY0NDUz IEwgNDYuOTQyNTc4IDI3Ljg0MDQzICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywt MjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxp bmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSw2NS4wOTgwNDEl LDMxLjM3MjU1JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0g NDYuMTI5Njg3IDMxLjEzOTg0NCBMIDQ2LjI5MjU3OCAzMS42NzQ2MDkgTCA0Ni42MjI2NTYgMzEu MjIzNDM3ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBz dHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSw2NS4wOTgwNDElLDMxLjM3MjU1JSk7c3Ry b2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDcuMTI0MjE5IDI4LjI2 NTAzOSBMIDQ2Ljk2MTMyOCAyNy43MzAyNzMgTCA0Ni42MzEyNSAyOC4xODE0NDUgIiB0cmFuc2Zv cm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7 c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRl cjtzdHJva2U6cmdiKDAlLDY1LjA5ODA0MSUsMzEuMzcyNTUlKTtzdHJva2Utb3BhY2l0eToxO3N0 cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0NC41ODc2OTUgMzMuNDY2MDE2IEwgNDEuMTc0NDE0 IDM0LjQ3NjU2MiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBh dGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7 c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsNjUuMDk4MDQxJSwzMS4zNzI1NSUp O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQ0LjI4NjUyMyAz My44MTU4MiBMIDQ0LjY5NDkyMiAzMy40MzQxOCBMIDQ0LjE0NDUzMSAzMy4zMzYzMjggIiB0cmFu c2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5v bmU7c3Ryb2tlLXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2U6cmdiKDAlLDY1LjA5ODA0MSUsMzEuMzcyNTUlKTtzdHJva2Utb3BhY2l0eTox O3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0MS40NzU1ODYgMzQuMTI2NTYyIEwgNDEuMDY3 MTg3IDM0LjUwODIwMyBMIDQxLjYxNzU3OCAzNC42MDYwNTUgIiB0cmFuc2Zvcm09Im1hdHJpeCgy MCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRo OjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdi KDAlLDY1LjA5ODA0MSUsMzEuMzcyNTUlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxp bWl0OjEwOyIgZD0iTSAzMy42NTYwNTUgMzEuMTA5NzY2IEwgMzcuMjkzOTQ1IDM0LjM5MDIzNCAi IHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZp bGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsNjUuMDk4MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFj aXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDM0LjExMTcxOSAzMS4xODM5ODQgTCAz My41NzMwNDcgMzEuMDM0OTYxIEwgMzMuNzc2OTUzIDMxLjU1NTQ2OSAiIHRyYW5zZm9ybT0ibWF0 cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Ut d2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9r ZTpyZ2IoMCUsNjUuMDk4MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1p dGVybGltaXQ6MTA7IiBkPSJNIDM2LjgzODI4MSAzNC4zMTYwMTYgTCAzNy4zNzY5NTMgMzQuNDY1 MDM5IEwgMzcuMTczMDQ3IDMzLjk0NDUzMSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwt MTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsNjUuMDk4 MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBk PSJNIDQxLjA2ODk0NSAyMy43MzIyMjcgTCA0NS4wMzEwNTUgMjUuNzY3NzczICIgdHJhbnNmb3Jt PSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0 cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYigwJSw2NS4wOTgwNDElLDMxLjM3MjU1JSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDEuNTI4NTE2IDIzLjY4NzMwNSBMIDQwLjk2OTUzMSAy My42ODEwNTUgTCA0MS4zIDI0LjEzMjAzMSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwt MTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsNjUuMDk4 MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBk PSJNIDQ0LjU3MTQ4NCAyNS44MTI2OTUgTCA0NS4xMzA0NjkgMjUuODE4OTQ1IEwgNDQuOCAyNS4z Njc5NjkgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0 cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAxNC40ODYxMzMgMjcuNDUxOTUzIEwgMzEuNTI0MDIz IDI5LjE4Nzg5MSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBh dGggc3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNp dHk6MTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVy bGltaXQ6MTA7IiBkPSJNIDE0LjI2OTkyMiAyNy40MzAwNzggTCAxNC41NDQxNDEgMjcuMjA2NjQx IEwgMTQuNzY3MzgzIDI3LjQ4MDY2NCBMIDE0LjQ5MzM1OSAyNy43MDQxMDIgWiAiIHRyYW5zZm9y bT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGwtcnVsZTpl dmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTtzdHJva2Utd2lkdGg6MC4y O3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUs MCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDMxLjc0 MDAzOSAyOS4yMDk5NjEgTCAzMS40NjYwMTYgMjkuNDMzMzk4IEwgMzEuMjQyNTc4IDI5LjE1OTM3 NSBMIDMxLjUxNjYwMiAyOC45MzU5MzcgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwt MTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUp O3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDIwLjQ2Mjg5MSAy MC42NDE0MDYgTCAzMS41NjcxODcgMjkuMDc4NzExICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCww LDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2Io MCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6 YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMjAuMjkwMDM5IDIwLjUwOTk2MSBM IDIwLjY0MDIzNCAyMC40NjIxMDkgTCAyMC42ODgwODYgMjAuODEyNSBMIDIwLjMzNzg5MSAyMC44 NjAzNTIgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGgg c3R5bGU9ImZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6 MTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1p dGVyO3N0cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGlt aXQ6MTA7IiBkPSJNIDMxLjc0MDAzOSAyOS4yMDk5NjEgTCAzMS4zODk2NDggMjkuMjU3ODEyIEwg MzEuMzQxNzk3IDI4LjkwNzQyMiBMIDMxLjY5MjE4NyAyOC44NTk3NjYgWiAiIHRyYW5zZm9ybT0i bWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJv a2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZTpyZ2IoMCUsMCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7 IiBkPSJNIDIyLjI0Njg3NSAxOC44MjU3ODEgTCAzNy4xNjMwODYgMjMuNTY0MjU4ICIgdHJhbnNm b3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxl OmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDow LjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigw JSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMjIu MDQwMDM5IDE4Ljc1OTk2MSBMIDIyLjM1MzkwNiAxOC41OTc0NjEgTCAyMi41MTY2MDIgMTguOTEx MzI4IEwgMjIuMjAyNTM5IDE5LjA3NDAyMyBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIw LC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUs MCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0 dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNp dHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzcuMzY5OTIyIDIzLjYzMDA3OCBMIDM3 LjA1NjA1NSAyMy43OTI1NzggTCAzNi44OTM1NTUgMjMuNDc4NzExIEwgMzcuMjA3NDIyIDIzLjMx NjAxNiBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8ZyBzdHls ZT0iZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVm PSIjZ2x5cGgwLTExIiB4PSI0NzgiIHk9IjE3MCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBo MC01IiB4PSI0ODUuMDMxMjUiIHk9IjE3MCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0y IiB4PSI0OTMuNzAzMTI1IiB5PSIxNzAiLz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpyZ2IoMCUsMCUs MCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTEyIiB4PSI0 NzgiIHk9IjE4NiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMyIgeD0iNDg1LjE0ODQz OCIgeT0iMTg2Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE0IiB4PSI0OTMuMDk3NjU2 IiB5PSIxODYiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTQiIHg9IjUwMS4zMzk4NDQi IHk9IjE4NiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xNSIgeD0iNTA5LjU4MjAzMSIg eT0iMTg2Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTEyIiB4PSI1MTcuNTg5ODQ0IiB5 PSIxODYiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTYiIHg9IjUyNC43MzgyODEiIHk9 IjE4NiIvPgo8L2c+CjxnIHN0eWxlPSJmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7 Ij4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTciIHg9IjQ2OS44MDA3ODEiIHk9IjMxMC4x MDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTgiIHg9IjQ3OC4wNjI1IiB5PSIz MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIiIHg9IjQ4NS41NDI5Njki IHk9IjMxMC4xMDE1NjIiLz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwt b3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTEyIiB4PSI0NjkuODAwNzgx IiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTEzIiB4PSI0NzYu OTQ5MjE5IiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE0IiB4 PSI0ODQuODk4NDM4IiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgw LTE0IiB4PSI0OTMuMTQwNjI1IiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIj Z2x5cGgwLTE1IiB4PSI1MDEuMzgyODEyIiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpo cmVmPSIjZ2x5cGgwLTEyIiB4PSI1MDkuMzkwNjI1IiB5PSIzMjYuMTAxNTYyIi8+CiAgPHVzZSB4 bGluazpocmVmPSIjZ2x5cGgwLTE2IiB4PSI1MTYuNTM5MDYyIiB5PSIzMjYuMTAxNTYyIi8+Cjwv Zz4KPGcgc3R5bGU9ImZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6MTsiPgogIDx1c2Ug eGxpbms6aHJlZj0iI2dseXBoMC0xOSIgeD0iNDY5LjgwMDc4MSIgeT0iMzg4LjEwMTU2MiIvPgog IDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC01IiB4PSI0NzMuNjI4OTA2IiB5PSIzODguMTAxNTYy Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIwIiB4PSI0ODIuNTE1NjI1IiB5PSIzODgu MTAxNTYyIi8+CjwvZz4KPGcgc3R5bGU9ImZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9wYWNpdHk6 MTsiPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMiIgeD0iNDY5LjgwMDc4MSIgeT0iNDA0 LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMyIgeD0iNDc2Ljk0OTIxOSIg eT0iNDA0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xNCIgeD0iNDg0Ljg5 ODQzOCIgeT0iNDA0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xNCIgeD0i NDkzLjE0MDYyNSIgeT0iNDA0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0x NSIgeD0iNTAxLjM4MjgxMiIgeT0iNDA0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2ds eXBoMC0xMiIgeD0iNTA5LjM5MDYyNSIgeT0iNDA0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJl Zj0iI2dseXBoMC0xNiIgeD0iNTE2LjUzOTA2MiIgeT0iNDA0LjEwMTU2MiIvPgo8L2c+CjxwYXRo IHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0 cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tl LW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMjIuNjMwODU5IDIwLjE0NjQ4 NCBMIDM1LjkzOTA2MiAyMy40ODY5MTQgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3 LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7Zmls bDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSA0MjUuMTk1MzEyIDE5 Mi4xNjAxNTYgTCA0MTIuMzM1OTM4IDE5NC4wODk4NDQgTCA0MjIuNzU3ODEyIDIwMS44NTkzNzUg WiAiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJn YigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDQzNi44MzIwMzEgMTk1LjA4 MjAzMSBMIDQyMy45NzY1NjIgMTk3LjAxMTcxOSBMIDQzNC4zOTg0MzggMjA0Ljc4MTI1IFogIi8+ CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpi dXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMjIuMDEyNjk1IDE5 LjczMzU5NCBMIDIxLjQ2Njc5NyAxOS44NTQ0OTIgTCAyMS44OTEwMTYgMjAuMjE4NTU1IFogIiB0 cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxs Om5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9p bjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtz dHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMjIuNjkxNjAyIDE5LjkwNDEwMiBMIDIyLjE0NTg5 OCAyMC4wMjQ4MDUgTCAyMi41Njk5MjIgMjAuMzg5MDYyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgy MCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7ZmlsbC1ydWxl OmV2ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSA3 MTIuMjAzMTI1IDI3NC41MTE3MTkgTCA3MjUuMDU4NTk0IDI3Mi41ODIwMzEgTCA3MTQuNjM2NzE5 IDI2NC44MTI1IFogIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2ZW5v ZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSA3MDAuNTYy NSAyNzEuNTg5ODQ0IEwgNzEzLjQxNzk2OSAyNjkuNjYwMTU2IEwgNzAyLjk5NjA5NCAyNjEuODkw NjI1IFogIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2Ut bGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1 ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzYu NTU3MDMxIDIzLjg5OTgwNSBMIDM3LjEwMjkzIDIzLjc3OTEwMiBMIDM2LjY3ODkwNiAyMy40MTQ4 NDQgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5 bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tl LWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3Bh Y2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSAzNS44NzgxMjUgMjMuNzI5NDkyIEwg MzYuNDI0MDIzIDIzLjYwODU5NCBMIDM1Ljk5OTgwNSAyMy4yNDQ1MzEgWiAiIHRyYW5zZm9ybT0i bWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJv a2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0 cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRl cmxpbWl0OjEwOyIgZD0iTSAxNS43MzgyODEgMjguNTAzOTA2IEwgMzAuMjcyODUyIDI5LjczNzY5 NSAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9 IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7 ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDI4Ni4yMzA0NjkgMzYxLjA4MjAzMSBMIDI3My44NTE1NjIg MzY1LjA0Njg3NSBMIDI4NS4zODY3MTkgMzcxLjA0Njg3NSBaICIvPgo8cGF0aCBzdHlsZT0iIHN0 cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxs LW9wYWNpdHk6MTsiIGQ9Ik0gMjk4LjE4NzUgMzYyLjA5NzY1NiBMIDI4NS44MDg1OTQgMzY2LjA2 MjUgTCAyOTcuMzQzNzUgMzcyLjA1ODU5NCBaICIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0 cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7 c3Ryb2tlOnJnYigxMDAlLDY0LjcwNTg4NCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1p dGVybGltaXQ6MTA7IiBkPSJNIDE1LjA2MTkxNCAyOC4xOTU1MDggTCAxNC41NDI1NzggMjguNDAy MzQ0IEwgMTUuMDE5NTMxIDI4LjY5Mzc1IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAs LTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJv a2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQu NzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0g MTUuNzU5Mzc1IDI4LjI1NDg4MyBMIDE1LjI0MDAzOSAyOC40NjE1MjMgTCAxNS43MTcxODcgMjgu NzUyOTMgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGgg c3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAlLDEwMCUs MTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDU5OS45ODgyODEgMzk3Ljc1IEwgNjEyLjM3MTA5 NCAzOTMuNzgxMjUgTCA2MDAuODM1OTM4IDM4Ny43ODUxNTYgWiAiLz4KPHBhdGggc3R5bGU9IiBz dHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7Zmls bC1vcGFjaXR5OjE7IiBkPSJNIDU4OC4wMzEyNSAzOTYuNzM0Mzc1IEwgNjAwLjQxNDA2MiAzOTIu NzY5NTMxIEwgNTg4Ljg3ODkwNiAzODYuNzY5NTMxIFogIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5v bmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzAuOTQ5MDIzIDMwLjA0NTg5OCBMIDMxLjQ2ODU1NSAy OS44MzkwNjIgTCAzMC45OTE0MDYgMjkuNTQ3NjU2IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCww LDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAu MjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEw MCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsi IGQ9Ik0gMzAuMjUxNTYyIDI5Ljk4NjcxOSBMIDMwLjc3MDg5OCAyOS43Nzk4ODMgTCAzMC4yOTM5 NDUgMjkuNDg4NDc3IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+ CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpi dXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDEuNDc4NzExIDI2 LjU4OTI1OCBMIDQ0LjM1MjkzIDMwLjYyNjk1MyAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwy MCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9k ZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDgwOS42ODc1 IDMxNi4xMDkzNzUgTCA3OTguNjU2MjUgMzA5LjIzNDM3NSBMIDgwMS41NDI5NjkgMzIxLjkxMDE1 NiBaICIvPgo8cGF0aCBzdHlsZT0iIHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6 cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6MTsiIGQ9Ik0gODE2LjY0ODQzOCAzMjUu ODg2NzE5IEwgODA1LjYxMzI4MSAzMTkuMDExNzE5IEwgODA4LjUgMzMxLjY4NzUgWiAiLz4KPHBh dGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7 c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJv a2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0MS4yNzYzNjcgMjUuODc0 MDIzIEwgNDAuNzgyODEyIDI1LjYxMTcxOSBMIDQwLjg2OTE0MSAyNi4xNjQwNjIgWiAiIHRyYW5z Zm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9u ZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1p dGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9r ZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0MS42ODI0MjIgMjYuNDQ0MzM2IEwgNDEuMTg4NjcyIDI2 LjE4MjAzMSBMIDQxLjI3NSAyNi43MzQzNzUgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwy MCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9k ZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDg3Mi45NDUz MTIgNDIyLjIxNDg0NCBMIDg4My45NzY1NjIgNDI5LjA4OTg0NCBMIDg4MS4wODk4NDQgNDE2LjQx Nzk2OSBaICIvPgo8cGF0aCBzdHlsZT0iIHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2Zp bGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6MTsiIGQ9Ik0gODY1Ljk4NDM3NSA0 MTIuNDM3NSBMIDg3Ny4wMTU2MjUgNDE5LjMxNjQwNiBMIDg3NC4xMzI4MTIgNDA2LjY0MDYyNSBa ICIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVj YXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDY0LjcwNTg4NCUs MCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDQ0LjU1NTA3 OCAzMS4zNDIxODcgTCA0NS4wNDg4MjggMzEuNjA0NDkyIEwgNDQuOTYyNSAzMS4wNTIzNDQgWiAi IHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZp bGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVq b2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eTox O3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA0NC4xNDkyMTkgMzAuNzcxODc1IEwgNDQuNjQy NzczIDMxLjAzNDM3NSBMIDQ0LjU1NjY0MSAzMC40ODIwMzEgWiAiIHRyYW5zZm9ybT0ibWF0cml4 KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lk dGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpy Z2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSA3LjI2NDI1OCAxNi40ODEwNTUgTCAxMS4zNTI3MzQgMjQuMzY2NDA2ICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iIHN0cm9r ZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9w YWNpdHk6MTsiIGQ9Ik0gMTI3LjE5OTIxOSAxMTMuNjY3OTY5IEwgMTE3LjIzODI4MSAxMDUuMzE2 NDA2IEwgMTE4LjMyMDMxMiAxMTguMjY5NTMxIFogIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5v bmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0 eToxOyIgZD0iTSAxMzIuNzIyNjU2IDEyNC4zMjAzMTIgTCAxMjIuNzYxNzE5IDExNS45Njg3NSBM IDEyMy44NDM3NSAxMjguOTIxODc1IFogIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tl LXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJv a2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJs aW1pdDoxMDsiIGQ9Ik0gNy4xNjM4NjcgMTUuNzQ0NTMxIEwgNi43MTE5MTQgMTUuNDE1ODIgTCA2 LjcyMDExNyAxNS45NzQ2MDkgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIw MykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5l Y2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQl LDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA3LjQ4NjEz MyAxNi4zNjYwMTYgTCA3LjAzMzk4NCAxNi4wMzcxMDkgTCA3LjA0MjE4NyAxNi41OTYwOTQgWiAi IHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9IiBz dHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7Zmls bC1vcGFjaXR5OjE7IiBkPSJNIDIxMS4xNDA2MjUgMjk3LjI4MTI1IEwgMjIxLjEwMTU2MiAzMDUu NjMyODEyIEwgMjIwLjAxOTUzMSAyOTIuNjc5Njg4IFogIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tl Om5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3Bh Y2l0eToxOyIgZD0iTSAyMDUuNjE3MTg4IDI4Ni42Mjg5MDYgTCAyMTUuNTc4MTI1IDI5NC45ODA0 NjkgTCAyMTQuNDk2MDk0IDI4Mi4wMjczNDQgWiAiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtz dHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVy O3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1t aXRlcmxpbWl0OjEwOyIgZD0iTSAxMS40NTMxMjUgMjUuMTAyOTMgTCAxMS45MDUwNzggMjUuNDMx NjQxIEwgMTEuODk2ODc1IDI0Ljg3MjY1NiBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIw LC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjI7c3Ry b2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDY0 LjcwNTg4NCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJN IDExLjEzMDg1OSAyNC40ODE0NDUgTCAxMS41ODMwMDggMjQuODEwMTU2IEwgMTEuNTc0ODA1IDI0 LjI1MTM2NyBaICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0 aCBzdHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtz dHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDY0LjcwNTg4NCUsMCUpO3N0cm9r ZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDM2LjY2NTIzNCAzMC42NjM4 NjcgTCA0My40MTg1NTUgMzIuMzYzNjcyICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0x NywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iIHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2Zp bGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6MTsiIGQ9Ik0gNzA1Ljg4NjcxOSA0 MDIuNSBMIDY5My4wMjczNDQgNDA0LjQyMTg3NSBMIDcwMy40NDUzMTIgNDEyLjE5OTIxOSBaICIv Pgo8cGF0aCBzdHlsZT0iIHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEw MCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNpdHk6MTsiIGQ9Ik0gNzE3LjUyMzQzOCA0MDUuNDI5Njg4 IEwgNzA0LjY2Nzk2OSA0MDcuMzQ3NjU2IEwgNzE1LjA4MjAzMSA0MTUuMTI4OTA2IFogIi8+Cjxw YXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0 O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ry b2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzYuMDQ3MjY2IDMwLjI1 MDU4NiBMIDM1LjUwMTM2NyAzMC4zNzEwOTQgTCAzNS45MjUzOTEgMzAuNzM1NTQ3IFogIiB0cmFu c2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5v bmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjpt aXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJv a2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMzYuNzI2MTcyIDMwLjQyMTQ4NCBMIDM2LjE4MDI3MyAz MC41NDE3OTcgTCAzNi42MDQxMDIgMzAuOTA2NDQ1IFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCww LDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2 ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSA4NjEu Nzg5MDYyIDQ1Mi4wNTA3ODEgTCA4NzQuNjQ0NTMxIDQ1MC4xMjg5MDYgTCA4NjQuMjMwNDY5IDQ0 Mi4zNTE1NjIgWiAiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9k ZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDg1MC4xNTIz NDQgNDQ5LjEyMTA5NCBMIDg2My4wMDc4MTIgNDQ3LjIwMzEyNSBMIDg1Mi41OTM3NSA0MzkuNDI1 NzgxIFogIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2Ut bGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1 ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDQu MDM2MzI4IDMyLjc3Njk1MyBMIDQ0LjU4MjIyNyAzMi42NTY0NDUgTCA0NC4xNTgzOTggMzIuMjkx OTkyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gNDMuMzU3NjE3IDMyLjYwNjA1NSBM IDQzLjkwMzUxNiAzMi40ODU3NDIgTCA0My40Nzk2ODcgMzIuMTIxMjg5IFogIiB0cmFuc2Zvcm09 Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ry b2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0 ZXJsaW1pdDoxMDsiIGQ9Ik0gOC4xNTQxMDIgMTQuMjgxMjUgTCAxNy4xNzM4MjggMTcuOTkyNzcz ICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0i IHN0cm9rZTpub25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtm aWxsLW9wYWNpdHk6MTsiIGQ9Ik0gMTM2Ljg4NjcxOSA3My40Mzc1IEwgMTIzLjg4NjcxOSA3My40 OTIxODggTCAxMzMuMDgyMDMxIDgyLjY4MzU5NCBaICIvPgo8cGF0aCBzdHlsZT0iIHN0cm9rZTpu b25lO2ZpbGwtcnVsZTpldmVub2RkO2ZpbGw6cmdiKDEwMCUsMTAwJSwxMDAlKTtmaWxsLW9wYWNp dHk6MTsiIGQ9Ik0gMTQ3Ljk4NDM3NSA3OC4wMDM5MDYgTCAxMzQuOTg0Mzc1IDc4LjA1ODU5NCBM IDE0NC4xNzk2ODggODcuMjUgWiAiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lk dGg6MC4yO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpy Z2IoMTAwJSw2NC43MDU4ODQlLDAlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSA3LjYwMTk1MyAxMy43ODM3ODkgTCA3LjA0NDMzNiAxMy44MjQ2MDkgTCA3LjQx MTcxOSAxNC4yNDYwOTQgWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMyki Lz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4yO3N0cm9rZS1saW5lY2Fw OmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoMTAwJSw2NC43MDU4ODQlLDAl KTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA4LjI0OTIxOSAx NC4wNTAxOTUgTCA3LjY5MTc5NyAxNC4wOTEwMTYgTCA4LjA1ODk4NCAxNC41MTI1IFogIiB0cmFu c2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tl Om5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3Bh Y2l0eToxOyIgZD0iTSAzMzUuNjcxODc1IDE2Ni4wNDI5NjkgTCAzNDguNjcxODc1IDE2NS45ODgy ODEgTCAzMzkuNDc2NTYyIDE1Ni43OTY4NzUgWiAiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9u ZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5 OjE7IiBkPSJNIDMyNC41NzQyMTkgMTYxLjQ3NjU2MiBMIDMzNy41NzQyMTkgMTYxLjQyMTg3NSBM IDMyOC4zNzg5MDYgMTUyLjIzMDQ2OSBaICIvPgo8cGF0aCBzdHlsZT0iZmlsbDpub25lO3N0cm9r ZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ry b2tlOnJnYigxMDAlLDY0LjcwNTg4NCUsMCUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVy bGltaXQ6MTA7IiBkPSJNIDE3LjcyNTk3NyAxOC40OTAyMzQgTCAxOC4yODM1OTQgMTguNDQ5NDE0 IEwgMTcuOTE2MjExIDE4LjAyNzkzIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3 LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2Ut bGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1 ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTcu MDc4NzExIDE4LjIyMzgyOCBMIDE3LjYzNjEzMyAxOC4xODMwMDggTCAxNy4yNjg5NDUgMTcuNzYx NTIzIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0 eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9r ZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9w YWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gOS43OTQxNDEgMzUuOTUxMzY3IEwg MTQuODI2MzY3IDM1Ljk4OTI1OCAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIw MykiLz4KPHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJn YigxMDAlLDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDE2Ni45MjE4NzUgNTEwLjkz MzU5NCBMIDE1NC44ODI4MTIgNTE1Ljg0Mzc1IEwgMTY2Ljg0Mzc1IDUyMC45MzM1OTQgWiAiLz4K PHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAl LDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDE3OC45MTc5NjkgNTExLjAyNzM0NCBM IDE2Ni44ODI4MTIgNTE1LjkzMzU5NCBMIDE3OC44NDM3NSA1MjEuMDIzNDM4IFogIi8+CjxwYXRo IHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0 cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tl LW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gOS4wOTYwOTQgMzUuNjk2MDk0 IEwgOC41OTQxNDEgMzUuOTQyMTg3IEwgOS4wOTIxODcgMzYuMTk1ODk4IFogIiB0cmFuc2Zvcm09 Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ry b2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0 ZXJsaW1pdDoxMDsiIGQ9Ik0gOS43OTU4OTggMzUuNzAxMzY3IEwgOS4yOTQxNDEgMzUuOTQ3NDYx IEwgOS43OTIxODcgMzYuMjAxMTcyIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3 LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSIgc3Ryb2tlOm5vbmU7ZmlsbC1ydWxlOmV2ZW5vZGQ7Zmls bDpyZ2IoMTAwJSwxMDAlLDEwMCUpO2ZpbGwtb3BhY2l0eToxOyIgZD0iTSAyOTEuNDkyMTg4IDUy MS44NzUgTCAzMDMuNTI3MzQ0IDUxNi45NjQ4NDQgTCAyOTEuNTY2NDA2IDUxMS44NzUgWiAiLz4K PHBhdGggc3R5bGU9IiBzdHJva2U6bm9uZTtmaWxsLXJ1bGU6ZXZlbm9kZDtmaWxsOnJnYigxMDAl LDEwMCUsMTAwJSk7ZmlsbC1vcGFjaXR5OjE7IiBkPSJNIDI3OS40OTIxODggNTIxLjc4NTE1NiBM IDI5MS41MjczNDQgNTE2Ljg3NSBMIDI3OS41NjY0MDYgNTExLjc4NTE1NiBaICIvPgo8cGF0aCBz dHlsZT0iZmlsbDpub25lO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigxMDAlLDY0LjcwNTg4NCUsMCUpO3N0cm9rZS1v cGFjaXR5OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDE1LjUyNDYwOSAzNi4yNDQ1MzEg TCAxNi4wMjYzNjcgMzUuOTk4MjQyIEwgMTUuNTI4MzIgMzUuNzQ0NTMxIFogIiB0cmFuc2Zvcm09 Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ry b2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtz dHJva2U6cmdiKDEwMCUsNjQuNzA1ODg0JSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0 ZXJsaW1pdDoxMDsiIGQ9Ik0gMTQuODI0NjA5IDM2LjIzOTI1OCBMIDE1LjMyNjM2NyAzNS45OTI5 NjkgTCAxNC44MjgzMiAzNS43MzkyNTggWiAiIHRyYW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwt MTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9r ZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2IoODIuMzUyOTQy JSw2Ni4yNzQ1MTIlLDkyLjU0OTAyJSk7c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1p dDoxMDsiIGQ9Ik0gOC45ODQxOCAzNy4zMzI4MTIgTCAxNS43MjYzNjcgMzcuMzk3ODUyICIgdHJh bnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbDpu b25lO3N0cm9rZS13aWR0aDowLjE7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46 bWl0ZXI7c3Ryb2tlOnJnYig4Mi4zNTI5NDIlLDY2LjI3NDUxMiUsOTIuNTQ5MDIlKTtzdHJva2Ut b3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA5LjM3NDgwNSAzNy4wODY1MjMg TCA4Ljg3MjQ2MSAzNy4zMzE2NDEgTCA5LjM2OTkyMiAzNy41ODY1MjMgIiB0cmFuc2Zvcm09Im1h dHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tl LXdpZHRoOjAuMTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJv a2U6cmdiKDgyLjM1Mjk0MiUsNjYuMjc0NTEyJSw5Mi41NDkwMiUpO3N0cm9rZS1vcGFjaXR5OjE7 c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDE1LjMzNTc0MiAzNy42NDQxNDEgTCAxNS44Mzgy ODEgMzcuMzk4ODI4IEwgMTUuMzQwNjI1IDM3LjE0NDE0MSAiIHRyYW5zZm9ybT0ibWF0cml4KDIw LDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6bm9uZTtzdHJva2Utd2lkdGg6 MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2luOm1pdGVyO3N0cm9rZTpyZ2Io MCUsNjUuMDk4MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFjaXR5OjE7c3Ryb2tlLW1pdGVybGlt aXQ6MTA7IiBkPSJNIDkuMjg0MTggMzguNjI5Njg3IEwgMTUuNjc2MzY3IDM4LjYwMDk3NyAiIHRy YW5zZm9ybT0ibWF0cml4KDIwLDAsMCwyMCwtMTcsLTIwMykiLz4KPHBhdGggc3R5bGU9ImZpbGw6 bm9uZTtzdHJva2Utd2lkdGg6MC4xO3N0cm9rZS1saW5lY2FwOmJ1dHQ7c3Ryb2tlLWxpbmVqb2lu Om1pdGVyO3N0cm9rZTpyZ2IoMCUsNjUuMDk4MDQxJSwzMS4zNzI1NSUpO3N0cm9rZS1vcGFjaXR5 OjE7c3Ryb2tlLW1pdGVybGltaXQ6MTA7IiBkPSJNIDkuNjcxMjg5IDM4LjM3NzkzIEwgOS4xNzI0 NjEgMzguNjMwMDc4IEwgOS42NzM0MzcgMzguODc3OTMgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCww LDAsMjAsLTE3LC0yMDMpIi8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAu MTtzdHJva2UtbGluZWNhcDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAl LDY1LjA5ODA0MSUsMzEuMzcyNTUlKTtzdHJva2Utb3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0 OjEwOyIgZD0iTSAxNS4yODkyNTggMzguODUyNzM0IEwgMTUuNzg4MjgxIDM4LjYwMDU4NiBMIDE1 LjI4NzEwOSAzOC4zNTI3MzQgIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMp Ii8+CjxwYXRoIHN0eWxlPSJmaWxsOm5vbmU7c3Ryb2tlLXdpZHRoOjAuMjtzdHJva2UtbGluZWNh cDpidXR0O3N0cm9rZS1saW5lam9pbjptaXRlcjtzdHJva2U6cmdiKDAlLDAlLDAlKTtzdHJva2Ut b3BhY2l0eToxO3N0cm9rZS1taXRlcmxpbWl0OjEwOyIgZD0iTSA5LjQxNzE4NyA0MC40NDg0Mzcg TCAxNS41MzI4MTIgNDAuNDAxNTYyICIgdHJhbnNmb3JtPSJtYXRyaXgoMjAsMCwwLDIwLC0xNywt MjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7ZmlsbDpyZ2IoMCUsMCUsMCUp O2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tlLWxpbmVjYXA6YnV0dDtzdHJv a2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7c3Ryb2tlLW9wYWNpdHk6MTtz dHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gOS4yIDQwLjQ1IEwgOS40NDgwNDcgNDAuMTk4MDQ3 IEwgOS43IDQwLjQ0NjA5NCBMIDkuNDUxOTUzIDQwLjY5ODA0NyBaICIgdHJhbnNmb3JtPSJtYXRy aXgoMjAsMCwwLDIwLC0xNywtMjAzKSIvPgo8cGF0aCBzdHlsZT0iZmlsbC1ydWxlOmV2ZW5vZGQ7 ZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxO3N0cm9rZS13aWR0aDowLjI7c3Ryb2tl LWxpbmVjYXA6YnV0dDtzdHJva2UtbGluZWpvaW46bWl0ZXI7c3Ryb2tlOnJnYigwJSwwJSwwJSk7 c3Ryb2tlLW9wYWNpdHk6MTtzdHJva2UtbWl0ZXJsaW1pdDoxMDsiIGQ9Ik0gMTUuNzUgNDAuNCBM IDE1LjUwMTk1MyA0MC42NTE5NTMgTCAxNS4yNSA0MC40MDM5MDYgTCAxNS40OTgwNDcgNDAuMTUx OTUzIFogIiB0cmFuc2Zvcm09Im1hdHJpeCgyMCwwLDAsMjAsLTE3LC0yMDMpIi8+CjxnIHN0eWxl PSJmaWxsOnJnYigwJSwwJSwwJSk7ZmlsbC1vcGFjaXR5OjE7Ij4KICA8dXNlIHhsaW5rOmhyZWY9 IiNnbHlwaDAtMTkiIHg9IjMyMCIgeT0iNTE4Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgw LTE0IiB4PSIzMjMuODI4MTI1IiB5PSI1MTgiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAt MTYiIHg9IjMzMi4wNzAzMTIiIHk9IjUxOCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0x NSIgeD0iMzM3LjE2Nzk2OSIgeT0iNTE4Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIx IiB4PSIzNDUuMTc1NzgxIiB5PSI1MTgiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMjIi IHg9IjM0OS43MjY1NjIiIHk9IjUxOCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xOSIg eD0iMzU0LjQxNDA2MiIgeT0iNTE4Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE3IiB4 PSIzNTguMjQyMTg4IiB5PSI1MTgiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTEiIHg9 IjM2Ni41MDM5MDYiIHk9IjUxOCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC00IiB4PSIz NzQuMzM1OTM4IiB5PSI1MTgiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtNSIgeD0iMzc4 LjQ3NjU2MiIgeT0iNTE4Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTMiIHg9IjM4Ny4x NDg0MzgiIHk9IjUxOCIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMSIgeD0iMzk2LjIz MDQ2OSIgeT0iNTE4Ii8+CjwvZz4KPGcgc3R5bGU9ImZpbGw6cmdiKDAlLDAlLDAlKTtmaWxsLW9w YWNpdHk6MTsiPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xOSIgeD0iMzIxLjgwMDc4MSIg eT0iNTUwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xNyIgeD0iMzI1LjYy ODkwNiIgeT0iNTUwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xMSIgeD0i MzMzLjg5MDYyNSIgeT0iNTUwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0y MiIgeD0iMzQxLjQ2ODc1IiB5PSI1NTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5 cGgwLTUiIHg9IjM0NS45MDIzNDQiIHk9IjU1MC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9 IiNnbHlwaDAtNCIgeD0iMzU0Ljc4OTA2MiIgeT0iNTUwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6 aHJlZj0iI2dseXBoMC01IiB4PSIzNTguOTI5Njg4IiB5PSI1NTAuMTAxNTYyIi8+CiAgPHVzZSB4 bGluazpocmVmPSIjZ2x5cGgwLTMiIHg9IjM2Ny42MDE1NjIiIHk9IjU1MC4xMDE1NjIiLz4KICA8 dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTEiIHg9IjM3Ni42ODM1OTQiIHk9IjU1MC4xMDE1NjIi Lz4KPC9nPgo8ZyBzdHlsZT0iZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAg PHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE5IiB4PSIzMjMuODAwNzgxIiB5PSI1NzQuMTAxNTYy Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE3IiB4PSIzMjcuNjI4OTA2IiB5PSI1NzQu MTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTExIiB4PSIzMzUuODkwNjI1IiB5 PSI1NzQuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIyIiB4PSIzNDMuNDY4 NzUiIHk9IjU3NC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTAiIHg9IjM0 Ny43MDcwMzEiIHk9IjU3NC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtNCIg eD0iMzU2LjYzMjgxMiIgeT0iNTc0LjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBo MC01IiB4PSIzNjAuNzczNDM4IiB5PSI1NzQuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIj Z2x5cGgwLTMiIHg9IjM2OS40NDUzMTIiIHk9IjU3NC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhy ZWY9IiNnbHlwaDAtMTEiIHg9IjM3OC41MjczNDQiIHk9IjU3NC4xMDE1NjIiLz4KPC9nPgo8ZyBz dHlsZT0iZmlsbDpyZ2IoMCUsMCUsMCUpO2ZpbGwtb3BhY2l0eToxOyI+CiAgPHVzZSB4bGluazpo cmVmPSIjZ2x5cGgwLTIwIiB4PSIzMTYuODAwNzgxIiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4 bGluazpocmVmPSIjZ2x5cGgwLTIzIiB4PSIzMjYuODIwMzEyIiB5PSI2MTAuMTAxNTYyIi8+CiAg PHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTE2IiB4PSIzMzQuNzg5MDYyIiB5PSI2MTAuMTAxNTYy Ii8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIzIiB4PSIzMzkuODg2NzE5IiB5PSI2MTAu MTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIyIiB4PSIzNDcuODU1NDY5IiB5 PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTExIiB4PSIzNTIuNTQy OTY5IiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTI0IiB4PSIz NjAuMzc1IiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgwLTIzIiB4 PSIzNjMuOTg4MjgxIiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIjZ2x5cGgw LTE0IiB4PSIzNzEuOTU3MDMxIiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpocmVmPSIj Z2x5cGgwLTE1IiB4PSIzODAuMTk5MjE5IiB5PSI2MTAuMTAxNTYyIi8+CiAgPHVzZSB4bGluazpo cmVmPSIjZ2x5cGgwLTQiIHg9IjM4OC4yMDcwMzEiIHk9IjYxMC4xMDE1NjIiLz4KICA8dXNlIHhs aW5rOmhyZWY9IiNnbHlwaDAtMTkiIHg9IjM5Mi4zNDc2NTYiIHk9IjYxMC4xMDE1NjIiLz4KICA8 dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTQiIHg9IjM5Ni4xNzU3ODEiIHk9IjYxMC4xMDE1NjIi Lz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTYiIHg9IjQwNC40MTc5NjkiIHk9IjYxMC4x MDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTUiIHg9IjQwOS41MTU2MjUiIHk9 IjYxMC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMjEiIHg9IjQxNy41MjM0 MzgiIHk9IjYxMC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTIiIHg9IjQy Mi42MjEwOTQiIHk9IjYxMC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlwaDAtMTMi IHg9IjQyOS43Njk1MzEiIHk9IjYxMC4xMDE1NjIiLz4KICA8dXNlIHhsaW5rOmhyZWY9IiNnbHlw aDAtMTQiIHg9IjQzNy43MTg3NSIgeT0iNjEwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6aHJlZj0i I2dseXBoMC0xNCIgeD0iNDQ1Ljk2MDkzOCIgeT0iNjEwLjEwMTU2MiIvPgogIDx1c2UgeGxpbms6 aHJlZj0iI2dseXBoMC0xNSIgeD0iNDU0LjIwMzEyNSIgeT0iNjEwLjEwMTU2MiIvPgogIDx1c2Ug eGxpbms6aHJlZj0iI2dseXBoMC0xMiIgeD0iNDYyLjIxMDkzOCIgeT0iNjEwLjEwMTU2MiIvPgog IDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0xNiIgeD0iNDY5LjM1OTM3NSIgeT0iNjEwLjEwMTU2 MiIvPgogIDx1c2UgeGxpbms6aHJlZj0iI2dseXBoMC0yNSIgeD0iNDc0LjQ1NzAzMSIgeT0iNjEw LjEwMTU2MiIvPgo8L2c+CjwvZz4KPC9zdmc+Cg== --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVlzLgICLcPvd0N1lAQLaNQf9HP+vD10KZBKxjmo/aoreJRqNp1op59UT XELcwhlXNdl8YlOZKETa8+65Aiw4qOlKrnET5bCmRrSVjDuHd4W3Lome67tPhS6P XsEg4o0CF8JXeoRHkSfS8pTH+neyFAejl1w+ZGA+q9aRTHBxqE4a2HxgDcIZw/8H 9Ix+TcgpXmaMhmLRk9EdFGiRQETJIBccNF5cm4spzUvpJ70/PthX0c0yx1MsE0KR TIE5Ut6j16PVki/ZEvs0HTkvy939umoecxv9v+ztfd6vLoixhJP1ucM9RYO+zvSn MYvOhjZ5oW10/MBCnBMmtaEcy0Ukuf1/PL4t4hF2dfFYv7yHbm6m8w== =BGvx -----END PGP SIGNATURE----- --==-=-=-- From nobody Mon Nov 30 18:01:47 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62561B36AC; Mon, 30 Nov 2015 18:01:45 -0800 (PST) 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 gfdjYZqBXGFi; Mon, 30 Nov 2015 18:01:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 824991B36AA; Mon, 30 Nov 2015 18:01:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEV46837; Tue, 01 Dec 2015 02:01:40 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 02:01:39 +0000 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.49]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 10:01:26 +0800 From: Duzongpeng To: Sheng Jiang , "anima@ietf.org" , Toerless Eckert , "anima-chairs@ietf.org" Thread-Topic: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, Thread-Index: AQHRKyRQQ5K6x7mxE0Kg/jtxteHD3Z60ZusAgAAB9ACAAPeoQA== Date: Tue, 1 Dec 2015 02:01:25 +0000 Message-ID: References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> <565BCAFA.60807@joelhalpern.com> <565C9D44.1040303@gmail.com> <565C9EE8.3000903@joelhalpern.com> In-Reply-To: <565C9EE8.3000903@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.149.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.565CFF84.01C3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.49, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bd0854a4f97057fc9ba6f4608c524726 Archived-At: Cc: "Joel M. Halpern" Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 02:01:46 -0000 I think the use case is clear, and support the adoption of this draft. IMO, more use cases are needed besides this one, as the concept of autonomi= c network is hard to understand without some use cases. -----Original Message----- From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Tuesday, December 01, 2015 3:09 AM To: Brian E Carpenter; Sheng Jiang; anima@ietf.org Cc: anima-chairs@ietf.org; Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-p= refix-management as ANIMA WG document, ends December 13, 2015,=20 I can well believe that there is a valuable demonstration case that could b= e covered by that document. However, as I read it, the current document is not clear enough to even say= that it is a good starting point on describing that case and its value to = the group. So I would like to se a round of clarity improvement by the authors, after = which it is likely we could adopt the document. Yours, Joel On 11/30/15 2:02 PM, Brian E Carpenter wrote: > Joel, > > As I said in my own comment, the use case aspect of the draft=20 > definitely needs work. It was never intended to be sufficient for the=20 > general case. Actually, it says that it's limited to ISP networks. It=20 > probably needs an explicit applicability section with more details on tha= t. > In particular, is it intended to be used during network creation (and=20 > would it then use something like RFC 7695) or is it only for prefix=20 > allocation to customer stubs in an established network? > > (If it's used for network creation, there would be some interesting=20 > questions about bootstrapping that I won't go into here.) > > It's also not at all aligned with the current GRASP proposal, and that=20 > needs to be fixed in the next version. > > Its overall role in Anima is really supposed to be a worked example to=20 > validate the infrastructure components. > > Regards > Brian > > > On 30/11/2015 17:05, Joel M. Halpern wrote: >> I do not think this document is in shape to be adopted by the working=20 >> group. It does not clearly state what sort of address prefix handling i= t is attempting to address, and is nowhere near sufficient for the general = case. >> >> I am sorry that due to the need to chair another working group, I could = not be in the room for the discussion. >> >> Yours, >> Joel M. Halpern >> >> On 11/29/15 8:26 PM, Sheng Jiang wrote: >>> There was clear consensus for adopting=20 >>> draft-jiang-anima-prefix-management as a ANIMA working group document i= n the IETF 94 ANIMA WG meeting, Yokohama. >>> This message starts a two-week call on confirming the consensus from th= e WG meeting. >>> >>> Title: Autonomic Prefix Management in Large-scale Networks >>> Authors : Jiang, et al. >>> Filename: draft-jiang-anima-prefix-management >>> >>> https://tools.ietf.org/html/draft-jiang-anima-prefix-management >>> >>> Please express your support or rejection. If you think this document=20 >>> should _not_ be adopted, please also explicitly indicate the reasons. >>> >>> This adoption call will end on December 13, 2015. >>> >>> Regards, >>> >>> Sheng + Toerless >>> _______________________________________________ >>> Anima mailing list >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >>> >> >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima >> > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Mon Nov 30 19:08:54 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F11B3871; Mon, 30 Nov 2015 19:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9zek9ZQNyZBH; Mon, 30 Nov 2015 19:08:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D84C1B386F; Mon, 30 Nov 2015 19:08:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CEV51475; Tue, 01 Dec 2015 03:08:47 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 03:08:45 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.25]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 11:08:34 +0800 From: "Liubing (Leo)" To: "anima@ietf.org" Thread-Topic: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, Thread-Index: AQHRKyR5LC+gZ2+cdE2bGmEJcuMpsZ60N2YAgAE65eA= Date: Tue, 1 Dec 2015 03:08:33 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2350A89@nkgeml506-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AE8@nkgeml512-mbx.china.huawei.com> <565BCB3E.2030704@joelhalpern.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2350A89nkgeml506mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.565D0F3F.016E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 37af08b032b646d42a4e2e1cd869a760 Archived-At: Cc: "anima-chairs@ietf.org" Subject: Re: [Anima] Confirmation of consensus to adopt draft-behringer-anima-reference-model as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:08:52 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2350A89nkgeml506mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGVhciBhbGwsDQoNCkkgYmVsaWV2ZSB0aGlzIGlzIGEgbXVzdCB0byBoYXZlIGRvY3VtZW50 IHRvIGRlc2NyaWJlIHRoZSB0ZWNobm9sb2dpZXMgaW4gYSB3aG9sZSBwaWN0dXJlLiBTbyBJIHN1 cHBvcnQgdGhlIGFkb3B0aW9uIChhcyBhIGNvLWF1dGhvcikuDQoNCkJlc3QgcmVnYXJkcywNCkJp bmcNCg0KRnJvbTogQW5pbWEgW21haWx0bzphbmltYS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSsOpZmVyc29uIENhbXBvcyBOb2JyZQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDEs IDIwMTUgMTI6MTIgQU0NClRvOiBhbmltYUBpZXRmLm9yZw0KQ2M6IGFuaW1hLWNoYWlyc0BpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtBbmltYV0gQ29uZmlybWF0aW9uIG9mIGNvbnNlbnN1cyB0byBh ZG9wdCBkcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsIGFzIEFOSU1BIFdHIGRv Y3VtZW50LCBlbmRzIERlY2VtYmVyIDEzLCAyMDE1LA0KDQpJIGFtIGEgY28tYXV0aG9yIGFuZCBJ IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQuDQpDaGVlcnMuDQpKw6lmZXJzb24N CkVtIHNlZywgMzAgZGUgbm92IGRlIDIwMTUgw6BzIDAyOjA2LCBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiBlc2NyZXZldToN Ckkgc3Ryb25nbHkgc3VwcG9ydCBhZG9wdGlvbiBieSB0aGUgd29ya2luZyBncm91cCBvZiB0aGlz IGRvY3VtZW50LiAgSXQNCmlzIHByb3ZpZGVzIGEgdmVyeSBuZWNlc3NhcnkgcmVmZXJlbmNlIGZv ciBvdXIgd29yaywgYW5kIGlzIGEgZ29vZA0Kc3N0YXJ0IG9uIHdoYXQgd2UgbmVlZCBmb3IgdGhh dC4NCg0KWW91cnMsDQpKb2VsIE0uIEhhbHBlcm4NCg0KT24gMTEvMjkvMTUgOTowMyBQTSwgU2hl bmcgSmlhbmcgd3JvdGU6DQo+IFRoZXJlIHdhcyBjbGVhciBjb25zZW5zdXMgZm9yIGFkb3B0aW5n IGRyYWZ0LWJlaHJpbmdlci1hbmltYS1yZWZlcmVuY2UtbW9kZWwgYXMgYQ0KPiBBTklNQSB3b3Jr aW5nIGdyb3VwIGRvY3VtZW50IGluIHRoZSBJRVRGIDk0IEFOSU1BIFdHIG1lZXRpbmcsIFlva29o YW1hLg0KPiBUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgdHdvLXdlZWsgY2FsbCBvbiBjb25maXJtaW5n IHRoZSBjb25zZW5zdXMgZnJvbSB0aGUgV0cgbWVldGluZy4NCj4NCj4gICAgVGl0bGU6ICAgICAg QSBSZWZlcmVuY2UgTW9kZWwgZm9yIEF1dG9ub21pYyBOZXR3b3JraW5nDQo+ICAgIEF1dGhvcnMg OiAgIENhcnBlbnRlciwgZXQgYWwuDQo+ICAgIEZpbGVuYW1lOiAgZHJhZnQtYmVocmluZ2VyLWFu aW1hLXJlZmVyZW5jZS1tb2RlbC0wNA0KPg0KPiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJlZmVyZW5jZS1tb2RlbC0wNA0KPg0KPiBQbGVhc2Ug ZXhwcmVzcyB5b3VyIHN1cHBvcnQgb3IgcmVqZWN0aW9uLiBJZiB5b3UgdGhpbmsgdGhpcyBkb2N1 bWVudCBzaG91bGQgX25vdF8gYmUNCj4gYWRvcHRlZCwgcGxlYXNlIGFsc28gZXhwbGljaXRseSBp bmRpY2F0ZSB0aGUgcmVhc29ucy4NCj4NCj4gVGhpcyBhZG9wdGlvbiBjYWxsIHdpbGwgZW5kIG9u IERlY2VtYmVyIDEzLCAyMDE1Lg0KPg0KPiBSZWdhcmRzLA0KPg0KPiBTaGVuZyArIFRvZXJsZXNz DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEFu aW1hIG1haWxpbmcgbGlzdA0KPiBBbmltYUBpZXRmLm9yZzxtYWlsdG86QW5pbWFAaWV0Zi5vcmc+ DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWENCj4NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFuaW1hIG1haWxp bmcgbGlzdA0KQW5pbWFAaWV0Zi5vcmc8bWFpbHRvOkFuaW1hQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYQ0K --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2350A89nkgeml506mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcy LjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBEZWFy IGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRoaXMg aXMgYSBtdXN0IHRvIGhhdmUgZG9jdW1lbnQgdG8gZGVzY3JpYmUgdGhlIHRlY2hub2xvZ2llcyBp biBhIHdob2xlIHBpY3R1cmUuIFNvIEkgc3VwcG9ydCB0aGUgYWRvcHRpb24gKGFzIGEgY28tYXV0 aG9yKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmluZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBBbmltYSBbbWFpbHRvOmFuaW1hLWJvdW5jZXNAaWV0Zi5vcmddDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkrDqWZlcnNvbiBDYW1wb3MgTm9icmU8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgRGVjZW1iZXIgMDEsIDIwMTUgMTI6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IGFu aW1hQGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBhbmltYS1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtBbmltYV0gQ29uZmlybWF0aW9uIG9mIGNvbnNlbnN1cyB0byBh ZG9wdCBkcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsIGFzIEFOSU1BIFdHIGRv Y3VtZW50LCBlbmRzIERlY2VtYmVyIDEzLCAyMDE1LA0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkkgYW0gYSBjby1hdXRob3IgYW5kIEkgc3VwcG9ydCB0aGUgYWRv cHRpb24gb2YgdGhpcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVycy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5Kw6lmZXJzb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5FbSBzZWcsIDMwIGRlIG5vdiBkZSAyMDE1IMOgcyAwMjowNiwgSm9lbCBNLiBIYWxw ZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+am1oQGpvZWxoYWxw ZXJuLmNvbTwvYT4mZ3Q7IGVzY3JldmV1OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHN0 cm9uZ2x5IHN1cHBvcnQgYWRvcHRpb24gYnkgdGhlIHdvcmtpbmcgZ3JvdXAgb2YgdGhpcyBkb2N1 bWVudC4mbmJzcDsgSXQ8YnI+DQppcyBwcm92aWRlcyBhIHZlcnkgbmVjZXNzYXJ5IHJlZmVyZW5j ZSBmb3Igb3VyIHdvcmssIGFuZCBpcyBhIGdvb2Q8YnI+DQpzc3RhcnQgb24gd2hhdCB3ZSBuZWVk IGZvciB0aGF0Ljxicj4NCjxicj4NCllvdXJzLDxicj4NCkpvZWwgTS4gSGFscGVybjxicj4NCjxi cj4NCk9uIDExLzI5LzE1IDk6MDMgUE0sIFNoZW5nIEppYW5nIHdyb3RlOjxicj4NCiZndDsgVGhl cmUgd2FzIGNsZWFyIGNvbnNlbnN1cyBmb3IgYWRvcHRpbmcgZHJhZnQtYmVocmluZ2VyLWFuaW1h LXJlZmVyZW5jZS1tb2RlbCBhcyBhPGJyPg0KJmd0OyBBTklNQSB3b3JraW5nIGdyb3VwIGRvY3Vt ZW50IGluIHRoZSBJRVRGIDk0IEFOSU1BIFdHIG1lZXRpbmcsIFlva29oYW1hLjxicj4NCiZndDsg VGhpcyBtZXNzYWdlIHN0YXJ0cyBhIHR3by13ZWVrIGNhbGwgb24gY29uZmlybWluZyB0aGUgY29u c2Vuc3VzIGZyb20gdGhlIFdHIG1lZXRpbmcuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5i c3A7IFRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7IEEgUmVmZXJlbmNlIE1vZGVsIGZvciBBdXRv bm9taWMgTmV0d29ya2luZzxicj4NCiZndDsmbmJzcDsgJm5ic3A7IEF1dGhvcnMgOiZuYnNwOyAm bmJzcDtDYXJwZW50ZXIsIGV0IGFsLjxicj4NCiZndDsmbmJzcDsgJm5ic3A7IEZpbGVuYW1lOiZu YnNwOyBkcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0PGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1iZWhyaW5nZXItYW5pbWEtcmVmZXJlbmNlLW1vZGVsLTA0IiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVocmluZ2VyLWFuaW1hLXJl ZmVyZW5jZS1tb2RlbC0wNDwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OyBQbGVhc2UgZXhwcmVzcyB5 b3VyIHN1cHBvcnQgb3IgcmVqZWN0aW9uLiBJZiB5b3UgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91 bGQgX25vdF8gYmU8YnI+DQomZ3Q7IGFkb3B0ZWQsIHBsZWFzZSBhbHNvIGV4cGxpY2l0bHkgaW5k aWNhdGUgdGhlIHJlYXNvbnMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhpcyBhZG9wdGlvbiBjYWxs IHdpbGwgZW5kIG9uIERlY2VtYmVyIDEzLCAyMDE1Ljxicj4NCiZndDs8YnI+DQomZ3Q7IFJlZ2Fy ZHMsPGJyPg0KJmd0Ozxicj4NCiZndDsgU2hlbmcgJiM0MzsgVG9lcmxlc3M8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBB bmltYSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpBbmltYUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPkFuaW1hQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJfYmxh bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PGJyPg0K Jmd0Ozxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KQW5pbWEgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkFuaW1h QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QW5pbWFAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmltYSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5pbWE8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2350A89nkgeml506mbxchi_-- From nobody Mon Nov 30 19:19:28 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33131B38A3; Mon, 30 Nov 2015 19:19:26 -0800 (PST) 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 j__hIcHcLLXA; Mon, 30 Nov 2015 19:19:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7CC1B389E; Mon, 30 Nov 2015 19:19:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA36150; Tue, 01 Dec 2015 03:19:22 +0000 (GMT) Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 03:19:21 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.25]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 11:19:16 +0800 From: "Liubing (Leo)" To: "anima@ietf.org" Thread-Topic: [Anima] Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, Thread-Index: AQHRKxkTFPXFhTxl8Uy12FikgvB3R561dP6A Date: Tue, 1 Dec 2015 03:19:15 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2350AAD@nkgeml506-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927BC13A99@nkgeml512-mbx.china.huawei.com> <565BB809.6020707@gmail.com> In-Reply-To: <565BB809.6020707@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.565D11BA.0089, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: a365f55cfde5f6edcd8ab6ab20b403f9 Archived-At: Cc: "anima-chairs@ietf.org" Subject: Re: [Anima] Confirmation of consensus to adopt draft-eckert-anima-stable-connectivity as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:19:26 -0000 Hi all, I support the adoption. OAM is a decent use case of ACP. Best regards, Bing =20 > On 30/11/2015 14:22, Sheng Jiang wrote: > > There was clear consensus for adopting > > draft-eckert-anima-stable-connectivity as a ANIMA working group > document in the IETF 94 ANIMA WG meeting, Yokohama. > > This message starts a two-week call on confirming the consensus from th= e > WG meeting. > > > > Title: Using Autonomic Control Plane for Stable Connectivity of > Network OAM > > draft-eckert-anima-stable-connectivity-02 > > Authors : Eckert & Behringer > > Filename: draft-eckert-anima-stable-connectivity > > > > > > https://tools.ietf.org/html/draft-eckert-anima-stable-connectivity-02 > > > > Please express your support or rejection. If you think this document > > should _not_ be adopted, please also explicitly indicate the reasons. > > > > This adoption call will end on December 13, 2015. > > > > Regards, > > > > Sheng + Toerless > > _______________________________________________ > > Anima mailing list > > Anima@ietf.org > > https://www.ietf.org/mailman/listinfo/anima > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Nov 30 19:44:36 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FBC1A016E for ; Mon, 30 Nov 2015 19:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_38=0.6, 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 40dklBval2gX for ; Mon, 30 Nov 2015 19:44:32 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e: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 D51941A0116 for ; Mon, 30 Nov 2015 19:44:32 -0800 (PST) Received: by padhx2 with SMTP id hx2so206737623pad.1 for ; Mon, 30 Nov 2015 19:44:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=NljxYkBiZrfumyxFogJiFvWYJurCD1g0ib2IqdQqxo8=; b=D+xhQq/TCgjaA5luccZ2DLDeSAyHEAmpdkrbS1eLKNCjODvp7h2lb4bEfkJhYxITgs MqSeW2SXPGMuG0GHOqWsL+Huiuk4wsB6oX8tfDTv4B/8u1m8+DXT2MeJl5KaWb4GWNba B+RSI42xR86+XginFt+vAzsK8nrXVxlwRZLvw8PsqoCJYx+7nom/R/buFtyAb85KM9Ux izzPld58IEZUDCU09EPxm8BjntpMRNiE3at5AoPHJ6+HqyEOAvT3H70/j3SLmsS3ZuvN JJTJQtSrDCEKXHW30qChgKmYl32NAolMuNMH84SVQh8h+BZ3u3wzDgv5gKK+6b2k3lyc E5JQ== X-Received: by 10.67.24.104 with SMTP id ih8mr23963982pad.124.1448941472480; Mon, 30 Nov 2015 19:44:32 -0800 (PST) Received: from ?IPv6:2406:e007:48f5:1:28cc:dc4c:9703:6781? ([2406:e007:48f5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id a23sm54181349pfj.46.2015.11.30.19.44.29 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 19:44:31 -0800 (PST) To: Michael Richardson References: <20901.1447211126@sandelman.ca> <5642BFD0.3000805@gmail.com> <991C7F2D-EA2F-48FF-A84D-B665CE7B5DEB@cisco.com> <5643949B.8050602@gmail.com> <21960.1448839281@sandelman.ca> <565BC4B0.8040502@gmail.com> <25499.1448918662@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565D17A1.1010904@gmail.com> Date: Tue, 1 Dec 2015 16:44:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <25499.1448918662@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "anima@ietf.org" Subject: Re: [Anima] discoverying ACP peers (was Re: comments on current drafts) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 03:44:34 -0000 On 01/12/2015 10:24, Michael Richardson wrote: > > Brian E Carpenter wrote: > >> There are really two scenarios ACP.areyouup = false. > >> > >> 1) before bootstrap. > >> 2) when device is not connected to any other > >> ANIMA connected device. > >> > >> Those are not the same thing. > > > True, but in both cases GRASP will say "Oh, no security here" and > > refuse to do much of anything except discovery. There are definitely > > details to be defined here, of course. > > During the period that bootstrap is occuring, after a bootstrap relay agent > has been discovered, running GRASP on any interface is not, I think > desireable. The reason is mostly concern for some kind of DoS or > initial-configuration vulnerability. (remember: "FIELD"/"SUPPORT" stuff in VMS?) That suggests to me that in addition to a flag saying "ACP is up", we need another one saying "Security boostrap OK". Exactly what we make conditional on that flag is a bit implementation-dependent. > Should bootstrap fail, enabling it again to find a different bootstrap relay > *is* desireable. > > >> And for #2, this condition can persist on a per-interface basis for a > >> long time. > > > Yes, but I assume that a device with multiple interfaces will maintain > > per-interface status and per-adjacency status (see Michael B's > > adjacency table for the ACP). > > Yes, exactly. I'm think that once bootstraped, the bootstrap relay agent ASA > would then want to *respond* on that interface. > > >> We also, in the context of running GRASP insecurely on a particular > >> interface, need to think hard about what GRASP might reveal from a > >> privacy point of view. Some interfaces may *never* be used for the > >> ACP, they could be customer facing, etc. Yet, we need to periodically > >> see if as a result of some cables being re-arranged, there is now a > >> machine that *is* part of the domain. An example here would be where > >> an ISP's switches from using the ISP provided CPE to their own CPE, or > >> back again. > > > Yes. The ACP will have to monitor interfaces and adjacencies > > continuously for that reason, and will thereby reveal its > > existence. GRASP discovery traffic will reveal GRASP's existence. But > > we need to ensure that valuable content is only sent on a secure > > channel. > > This is partly why I think that a multicast IKEv2 INIT might be easier. > > I understand that some people want to hedge their bets with building the ACP > using IKEv2, but we make everything configurable, I'd like to see some clear > use case. > > >> We also need to consider if/how we run on virtual interfaces: for > >> instance VLANs. One might argue that GRASP should only run on > >> physical (untagged) interfaces, but it is not uncommon in access > >> networks for a single fat (containing hundreds of tagged VLANs) pipe > >> to come in a datacenter, and be broken out by an external entity into > >> physical connectors elsewhere, which plug into equipment that should > >> be part of the domain. > >> > >> This is typically when purchasing lit fiber from an incumbent telco > >> for instance. > > > Yes, I don't see how we can restrict it to physical interfaces. > > I believe that we will have to have some documented heuristics: we want ACPs > to come up wherever feasible, but we don't want to annoy ASAs with hundreds > to thousands of virtual interfaces which can never have an ACP. Again, that seems to be an implementation issue. I think it will be GRASP that's annoyed; it should build a single queue of requests for each ASA. > > You will have noticed when configuring your multicast socket, that you don't > have to create a socket per-interface, but can get the interface ifIndex out > along with each packet that you receive. Only with the Advanced Socket API, if I'm not mistaken. Python doesn't have that in a form that works for Python 3.4. I have got a work around for now. Anyway, that shouldn't matter for the design. > So listening to multicasts on > thousands of interfaces doesn't have to be very expensive in terms of program state. > (Except, as it turns out, with GRE interfaces on Linux, which do not return > their ifIndex, which seem to have a bug in this fashion, which I hope to fix) > > As such, we may want to have > interfaces which are in four states: > 0) insecure GRASP announcements > 1) interface being used for bootstrap, suppress > 2) listen for insecure GRASP queries only > 3) ACP up on this interface, skeptically listen. Something like that, which is why I suggested a "Security boostrap OK" flag. Brian > [when the ACP is up, it is likely that there is another interface to listen > to, but one has to continue listening because new devices could show up and > want to bootstrap, or the ACP could fail] > > >> In your context/mind, what is a "bootstrap relay agent"? > > > It's labelled "Proxy" at > > https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-01#page-6 > > Ah, okay! > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Mon Nov 30 20:05:16 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0741A1B7D for ; Mon, 30 Nov 2015 20:05:15 -0800 (PST) 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 x5r6jGN30aNR for ; Mon, 30 Nov 2015 20:05:13 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::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 10B2F1A1A52 for ; Mon, 30 Nov 2015 20:05:13 -0800 (PST) Received: by pacdm15 with SMTP id dm15so207312133pac.3 for ; Mon, 30 Nov 2015 20:05:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=5aApAe0Vj1TlRa48Daf1WS7XfhZC48uuSNw232G0MqA=; b=g4pOKxWfvKkXWQrI2X6y+KJX2/INUco8c9B3S8dYx2FhKYWy4ijZV2VrY0kG67dSpX fxxrT8enbRAZp+68OgXqe0ueCjbE2+mPTypUaUGHt+v1jAOnjPt8BbwMqvWl8DqBONGs EIBXN7vJxm/osMDgvCq75ORJSIgfQnYBeTCX6nK21yDFDXYNauKC4fwVR+RmBdEYvzMt HgzwAwW7uaSf/KIlGecgF6/3JdmpUXR80NAYier4LmNlBjd6SyGZazAQ3Y2ypbQdq7s1 Bu29yUdeAA+kATel2cML3ziqJ7wpQ3m8agsmN5b9mn9f0Y1XALDoFId1NL8ivi/9Zwzl 3cSw== X-Received: by 10.98.74.9 with SMTP id x9mr76612255pfa.139.1448942712571; Mon, 30 Nov 2015 20:05:12 -0800 (PST) Received: from ?IPv6:2406:e007:48f5:1:28cc:dc4c:9703:6781? ([2406:e007:48f5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id sn9sm38161303pac.16.2015.11.30.20.05.09 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 30 Nov 2015 20:05:11 -0800 (PST) To: anima@ietf.org References: <32380.1448833424@sandelman.ca> <565BC11A.9070005@gmail.com> <4994.1448921987@sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <565D1C79.8020808@gmail.com> Date: Tue, 1 Dec 2015 17:05:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4994.1448921987@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] some comments on -- draft-ietf-anima-grasp-01 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 04:05:15 -0000 On 01/12/2015 11:19, Michael Richardson wrote: > > Brian E Carpenter wrote: > >>> 2.1. Requirements for Discovery > >>> 2. When an ASA first starts up, it has no knowledge of the specific > >>> network to which it is attached. Therefore the discovery process > >>> must be able to support any network scenario, assuming only that the > >>> device concerned is bootstrapped from factory condition. > >> > >> I'm thinking that there is more to this: the ASA may assume that the device, > >> having been bootstrapped, now has a secured ACP with the local machine. > > > Yes, you could argue that there's a local sandbox I guess, but is that > > a protocol issue? > > Yes, I suspect that there is something here. > > There is a transitivity of trust that GRASP will have to deal with if the > ASAs do *not* have access to the private key for the device. I think that > SIP did it right, explaining how the SIP proxies interacted, while not saying > too much about how/what they did. I don't expect either the ASAs or GRASP to have access to the private key. Aren't we leaving that in the hands of the ACP? > >> I think that we should also need to think about channel binding mechanisms so > >> that the ASA doesn't have to do all it's own security work, and so that an > >> ASA can potentially put a bit more trust into the source address of a packet. > > > Well, GRASP effectively provides a session layer and the spec says it MUST > > be secured, preferably by the ACP. I'm not clear what more you want. > > Channel binding may involve the two ASA cryptographically connecting the > communication they have at layer "5" with the security provided at layer 3. > It can be as simple as each end asking the layer-3 for the hash of the public > keys used to secure the channel 3, and then sending that in-protocol to establish > that there is no MITM. OK, but for that GRASP is just a carrier. It would have to be the ACP, that created the secure channel, that provides the hash. We still have an unused protocol option called DeviceID - are you saying that we actually need it? > It may be that GRASP will have to *explicitely* support > a trusted MITM because multi-hop GRASP messages will be necessary before > stable addresses are available. I don't see how that would work without a PKI. > >> We also need to discuss how/if an ASA that do wants to do its own security > >> gets access to the validated device identity. The possibility that the device > >> would act as a sub-CA signing each of the ASAs. Another model would have the > >> device enroll each of the ASA into an ASA-type-specific CA. (Finding/creating > >> that ASA-specific-CA being a meta goal.) > > > Right, but given that ASA authorization is out of scope for GRASP, > > what are you asking for? I agree there should be an API giving access > > to the security credentials such as the ID, but shouldn't that be provided > > by the security function itself, not by GRASP? > > When we have seperated security functions from protocols, and assumed some > unspecified API, we have created unbound channels that can be attacked. > - TCP SYN values were divorced from IP end points gave us NAPT. > - lack of TLS ClientCertificates gives us hijacked HTTPS sessions > (one end of not bound to the channel, the other has been trojaned by policy) > - ... > > > However, I agree that we should not ask the ACP to support multicast routing. > > If there was some magic by which the ACP could secure LL multicast, that > > would be wonderful, but I assume not. > > Yes, it could be done. > We can use the enrolled certificates to bring up a multicast key manager like > rfc3830, but I'd like to know why we need it... I'm worrying about the unsolicited (flooding) synchronization that we bolted on. I don't know how to secure it. My understanding is that DTLS+multicast==mess. (Unicast replication, the next point, would fix it.) > > >> I don't think it's worth doing any of these things at the IP layer, I think > >> that there will be grasp daemons running at each vertice of the ACP, and so I > >> think that we should do flooding at the application layer, much like DNCP > >> does for Homenet. > > > Yes and no. Absolutely there needs to be a GRASP relay agent on every > > box that has more than one interface. But do you really want to do > > unicast replication if there are a hundred nodes on the link? > > Quite possibly yes. > 1) most links are not truly multicast the way 10base2 was, but are in fact > star topologies... and: > 2) the switching device at the hub of the star topology is running ANIMA, > and it sees 48 ethernet ports, not one LAN. > > > The thing is that the ACP is supposed to be a SHOULD but the external > > security has to be a MUST. > > > Life would be simpler if the ACP was a MUST but that would be a big change. > > Okay, good to have this conflict clearly stated. > > >> If the designers of GRASP are thinking of using it in some other > >> non-Autonomic situation, then please write a new document that inherits from > >> draft-ietf-anima-grasp for that purpose. > > > That isn't that point. The point is (I thought this was made somewhere in > > the draft, but maybe not) two operators might want to use some autonomic > > capability across the boundary between them, and they will not want > > to merge their ACPs. So that specific autonomic capability would need > > to be protected separately, presumably by a conventional solution > > such as TLS. So we don't want to exclude that by construction; IMHO it > > has no impact on the protocol itself either way. > > ah, okay. > I agree that they don't want to *merge* their ACPs. > I would claim that they want a new ACP to link their two domains, one which > is not yet another "VRF". Let me add a diagram: > http://www.sandelman.ca/SSW/ietf/anima/diagrams/ACP-between-two-ISPs.svg > (also, .dia, and .png if you don't have svg in your browser) > > I've drawn two ISPs, A and B. Each has a NOC and four routers. An ACP > (in purple for ISP A, in green for ISP B) connects each ISPs routers > together. > > A second overlap in ORANGE is a new ACP. I suggest it could be a double > tunnel, using ACP-A's addresses inside ISP-A to connect NOC-A directly to > router A3, which has a interconnect to ISP-B's B2. > (It could also be that ORANGE-ACP uses dataplane addresses) > > The end result is that the appropriate inter-ISP ASAs that need to do things > communicate with each other. I suspect that it isn't just A3/B2 that need to > talk, but rather and ASA on NOC-A and needs to talk to an ASA on NOC-B, but > that it may well need to know something about the Interconnection topology. > > (I'm trying hard not to make this specific to DiffServ...) That would be a fine use case. Yes, I agree that multiple ACPs are not excluded by the laws of physics. Whether there's a real advantage over ad hoc TLS is another question. Thanks Brian From nobody Mon Nov 30 22:11:08 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E081A6FE5; Mon, 30 Nov 2015 22:11:06 -0800 (PST) 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 XniZ19sThiga; Mon, 30 Nov 2015 22:11:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6D21A6FE2; Mon, 30 Nov 2015 22:11:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBA47141; Tue, 01 Dec 2015 06:11:00 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 1 Dec 2015 06:10:57 +0000 Received: from NKGEML506-MBX.china.huawei.com ([169.254.3.25]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 1 Dec 2015 14:10:45 +0800 From: "Liubing (Leo)" To: "Joel M. Halpern" , Brian E Carpenter , Sheng Jiang , "anima@ietf.org" Thread-Topic: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, Thread-Index: AQHRKyRQdyxepWm4J0ybYEf26tHvc560ZusAgAAB9ACAARKPAA== Date: Tue, 1 Dec 2015 06:10:44 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2350B42@nkgeml506-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> <565BCAFA.60807@joelhalpern.com> <565C9D44.1040303@gmail.com> <565C9EE8.3000903@joelhalpern.com> In-Reply-To: <565C9EE8.3000903@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.565D39F4.0117, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.25, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cde6eb59bfcf609c84014b1d635e93ee Archived-At: Cc: "anima-chairs@ietf.org" , Toerless Eckert Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 06:11:06 -0000 Hi Dear all, In general, I think the large scale ISP prefix management is a valid use ca= se of GRASP. So I basically support the draft. But I also think Joel's concern make sense that the current draft seems not= describe the use case in a clear way. My personal comment is: - IIRC, the document structure was based on a suggested "use case template"= at the very beginning of the Anima BoF. The template intended to regular d= ifferent use cases at that time. For now, I think maybe there is no need to= stick to that template any more. It could be more direct to discuss the pr= efix management issues in the Problem Statement. Current texts describes th= e supporting technologies well (e.g. device credential/role, policy intent = etc.), but could be more institutive to the prefix management issue itself. - Section 3/4/5 describes the technology components of the solution well, b= ut It seems it lacks a very clear whole picture of the prefix allocation/pr= ovisioning procedure.=20 So, for me, the problem is mostly description issue rather than technical i= ssue. From a use case perspective, I think it's ok to adopt it, and readabi= lity could be improved after adoption.=20 Best regards, Bing > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Tuesday, December 01, 2015 3:09 AM > To: Brian E Carpenter; Sheng Jiang; anima@ietf.org > Cc: anima-chairs@ietf.org; Toerless Eckert > Subject: Re: [Anima] Confirmation of consensus to adopt > draft-jiang-anima-prefix-management as ANIMA WG document, ends > December 13, 2015, >=20 > I can well believe that there is a valuable demonstration case that could= be > covered by that document. > However, as I read it, the current document is not clear enough to even s= ay > that it is a good starting point on describing that case and its value to= the > group. >=20 > So I would like to se a round of clarity improvement by the authors, afte= r > which it is likely we could adopt the document. >=20 > Yours, > Joel >=20 > On 11/30/15 2:02 PM, Brian E Carpenter wrote: > > Joel, > > > > As I said in my own comment, the use case aspect of the draft > > definitely needs work. It was never intended to be sufficient for the > > general case. Actually, it says that it's limited to ISP networks. It > > probably needs an explicit applicability section with more details on t= hat. > > In particular, is it intended to be used during network creation (and > > would it then use something like RFC 7695) or is it only for prefix > > allocation to customer stubs in an established network? > > > > (If it's used for network creation, there would be some interesting > > questions about bootstrapping that I won't go into here.) > > > > It's also not at all aligned with the current GRASP proposal, and that > > needs to be fixed in the next version. > > > > Its overall role in Anima is really supposed to be a worked example to > > validate the infrastructure components. > > > > Regards > > Brian > > > > > > On 30/11/2015 17:05, Joel M. Halpern wrote: > >> I do not think this document is in shape to be adopted by the working > >> group. It does not clearly state what sort of address prefix handling= it is > attempting to address, and is nowhere near sufficient for the general cas= e. > >> > >> I am sorry that due to the need to chair another working group, I coul= d > not be in the room for the discussion. > >> > >> Yours, > >> Joel M. Halpern > >> > >> On 11/29/15 8:26 PM, Sheng Jiang wrote: > >>> There was clear consensus for adopting > >>> draft-jiang-anima-prefix-management as a ANIMA working group > document in the IETF 94 ANIMA WG meeting, Yokohama. > >>> This message starts a two-week call on confirming the consensus from > the WG meeting. > >>> > >>> Title: Autonomic Prefix Management in Large-scale > Networks > >>> Authors : Jiang, et al. > >>> Filename: draft-jiang-anima-prefix-management > >>> > >>> https://tools.ietf.org/html/draft-jiang-anima-prefix-management > >>> > >>> Please express your support or rejection. If you think this document > >>> should _not_ be adopted, please also explicitly indicate the reasons. > >>> > >>> This adoption call will end on December 13, 2015. > >>> > >>> Regards, > >>> > >>> Sheng + Toerless > >>> _______________________________________________ > >>> Anima mailing list > >>> Anima@ietf.org > >>> https://www.ietf.org/mailman/listinfo/anima > >>> > >> > >> _______________________________________________ > >> Anima mailing list > >> Anima@ietf.org > >> https://www.ietf.org/mailman/listinfo/anima > >> > > >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Mon Nov 30 23:47:52 2015 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DFE1A8894; Mon, 30 Nov 2015 23:47:51 -0800 (PST) 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 fk3g3KHDYHIJ; Mon, 30 Nov 2015 23:47:50 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF071A8893; Mon, 30 Nov 2015 23:47:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1299; q=dns/txt; s=iport; t=1448956069; x=1450165669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=OZtJABjV9ZdmF80CIJ7jD5e0DhmIMuThOYyCFKl+PAs=; b=G4WF1EujtABDnxZwVMDUgDY2QiFPAbYn/Sh41CksFOpUlvFRvdwDgSsH OGoSu2dBFU2qImlV7hKr5MKiWo4ZwGgaS8xHe8WSzqCCnphiP4QXF3liw lG9ppa8rYPDEnp+bIEshHm5Ae1Dp9lfcCJpUHljfqu1gPTvEfdy0SIBY8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQCVT11W/5pdJa1egztTbwa+MAENg?= =?us-ascii?q?WYXCoVuAoE8OBQBAQEBAQEBgQqENAEBAQQBAQE3NAsMBAIBCBEEAQEfBQQHJws?= =?us-ascii?q?UCQgBAQQBDQUIiCYNvBwBAQEBAQEBAQEBAQEBAQEBAQEBAQEUBIZUhH6BQBKHZ?= =?us-ascii?q?wWWVwGFKYgHgWKEQoluiGSDcQEfAQFCgkSBQHKEaoEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,368,1444694400"; d="scan'208";a="213584754" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2015 07:47:48 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tB17lmrD002955 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 07:47:49 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 1 Dec 2015 01:47:48 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.000; Tue, 1 Dec 2015 01:47:48 -0600 From: "Michael Behringer (mbehring)" To: Sheng Jiang , "anima@ietf.org" Thread-Topic: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, Thread-Index: AdErDh0mdYVIx5VPSHyXP1QccUJaDgA/mhqw Date: Tue, 1 Dec 2015 07:47:48 +0000 Message-ID: <4a41735270374155b961ac775b4e5b4c@XCH-RCD-006.cisco.com> References: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B927BC13AB7@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.238.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "anima-chairs@ietf.org" , "Toerless Eckert \(eckert\)" Subject: Re: [Anima] Confirmation of consensus to adopt draft-jiang-anima-prefix-management as ANIMA WG document, ends December 13, 2015, X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 07:47:51 -0000 I support the adoption.=20 Michael > -----Original Message----- > From: Anima [mailto:anima-bounces@ietf.org] On Behalf Of Sheng Jiang > Sent: 30 November 2015 02:26 > To: anima@ietf.org > Cc: anima-chairs@ietf.org; Toerless Eckert (eckert) > Subject: [Anima] Confirmation of consensus to adopt draft-jiang-anima- > prefix-management as ANIMA WG document, ends December 13, 2015, >=20 > There was clear consensus for adopting draft-jiang-anima-prefix- > management as a ANIMA working group document in the IETF 94 ANIMA WG > meeting, Yokohama. > This message starts a two-week call on confirming the consensus from the > WG meeting. >=20 > Title: Autonomic Prefix Management in Large-scale Networks > Authors : Jiang, et al. > Filename: draft-jiang-anima-prefix-management >=20 > https://tools.ietf.org/html/draft-jiang-anima-prefix-management >=20 > Please express your support or rejection. If you think this document shou= ld > _not_ be adopted, please also explicitly indicate the reasons. >=20 > This adoption call will end on December 13, 2015. >=20 > Regards, >=20 > Sheng + Toerless > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima