From nobody Wed Jul 1 08:39:09 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193061A906F for ; Wed, 1 Jul 2015 08:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 pGPvF8ai6BN8 for ; Wed, 1 Jul 2015 08:39:04 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id DC2B61A90E1 for ; Wed, 1 Jul 2015 08:38:51 -0700 (PDT) Received: (qmail 4614 invoked by uid 0); 1 Jul 2015 15:38:48 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy2.mail.unifiedlayer.com with SMTP; 1 Jul 2015 15:38:48 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id n9Xp1q00t2SSUrH019XsMN; Wed, 01 Jul 2015 15:31:56 -0600 X-Authority-Analysis: v=2.1 cv=UNFOQkvy c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=AGkejYDSTmIA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=48vgC7mUAAAA:8 a=NojvYFcnAAAA:8 a=CPnfetgAX7tcl8b5zoEA:9 a=tkKJxfFjhvdEEwf1:21 a=HAHpWqdVs0F_ZZq2:21 a=pILNOxqGKmIA:10 a=cVpdEv2aUKUA:10 a=9uUzcS5Nrb8A:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=83U9S0MeH/s6NfZXvL1nzxB/Pb1XF5xUfQH8B9T/mo0=; b=FWqLfyU+k8NbSlYAq7wPhNLk1Hv5GWJMtM1RY7m9zPAelPQJWm3+nxsbNPP8zkq7WdQwJB1Pc5+RgXefrQT2lew5b5T4jcV55GVM8u/pknanbeqkGWfJLBNuRIt8AC9w; Received: from box313.bluehost.com ([69.89.31.113]:47929 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAK5x-0005ty-T1; Wed, 01 Jul 2015 09:38:42 -0600 Message-ID: <5594097C.70607@labn.net> Date: Wed, 01 Jul 2015 11:38:36 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , 'Jeffrey Haas' References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> In-Reply-To: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , Vishnu Pavan Beeram , "'Alvaro Retana \(aretana\)'" , 'Alia Atlas' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 15:39:07 -0000 > At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Sue, Jeff, Given some recent messages on the list, I thought it best to confirm we're all still on the same page. Based on our past discussions, it's my understanding that the work being done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the foundation for TE support in the I2RS models. I complete agree that there are details on how the different topology models will integrate/mesh still needs to be worked out, and I assumed that this is what you/Sue were referring to above. -- But we will not have two sets of TE topology models. I believe that the authors of the respective drafts are already are working this. (Pavan, my co-chair as well as coauthor of the TEAS yang model, can comment on this.) Please let me know if I missed/miss-understood something. Thanks, Lou (as TEAS WG co-chair) On 6/23/2015 2:19 PM, Susan Hares wrote: > > Netconf Working Group: > > > > The I2RS WG would like to pass you a set of requirements for the I2RS > protocol, and asks that you provide an analysis by IETF 93 on whether > NETCONF or RESTCONF can meet these requirements. We expect that > these requirements may require changes to the either NETCONF or > RESTCONF. > > > > The I2RS architecture document (draft-ietf-i2rs-architecture-09 > ) > provides a high-level overview of the I2RS protocol. The I2RS has > compiled the following documents to provide the additional details on > the requirements for the protocols. > > > > 1) draft-ietf-i2rs-ephemeral-state-00 > > > 2) draft-ietf-i2rs-pub-sub-requirements-02 > > > 3) draft-ietf-i2rs-traceability-03 > > > > > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the > discussion from the 6/10 interim and the top 10 requirements for > I2RS. In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an > set of detailed requirements on how the I2RS WG sees the I2RS protocol > operating. These detailed requirements are to be seen as suggestions > on what type of solution the I2RS WG would like to see, but I2RS WG is > asking the NETCONF WG to provide its best designed protocol. Please > note as part of these detailed requirement the > draft-ietf-i2rs-ephemeral-states-00 contains the idea of using > metadata to record secondary identity. > > > > The I2RS protocol is driven by data-models. The approved data models > for protocol independent services are: > > - draft-ietf-i2rs-rib-data-model-00 > > > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 > (released later this week) > > - Topology model which is a composite of: > > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 > > > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 > > > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 > > > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 > released later this week). > > o Service topology model: > draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > > > > At this time, none of the Topology models utilize Traffic > engineering. It is anticipated that these models will support traffic > engineering. Estimated rates of transfer and timing requirements for > these modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - > under the protocol requirements table. > > > > We hope that NETCONF WG can provide some initial feedback on these > requirements by IETF 93 at the Tuesday I2RS session. I2RS will use > the 6/24 interim at 10:00-11:30am ET to provide a time for any > participate in the I2RS, netconf, or netmod group to ask additional > questions on these requirements. > > > > Sue Hares > > > > Interim time: 10:00-11:30am ET > > Date 6/24/2015 > > Webex: > > https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d0f > > > > agenda: > > > > 10:00 – 10:05 – Bash Agenda > > 10:05 – 10:20- - review of requirements from > > draft-ietf-i2rs-ephemeral-state-00 > > draft-ietf-i2rs-pub-sub-requirements-02 > > draft-ietf-i2rs-traceability-03 > > Timing requirements > > > > 10:20 – 10:30 Review of requirements for mutual authentication, > > and transaction in draft-hares-auth-trans-01 requirements > > > > 10:30- 11:30 Open discussion for I2RS Requirements > > > > Proceedings and slides can be found at: > > http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html > > > > Sue Hares > > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord From nobody Wed Jul 1 12:34:46 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6D1B29F4; Wed, 1 Jul 2015 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 WlLAytzSa0ti; Wed, 1 Jul 2015 12:34:43 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 374FB1AD355; Wed, 1 Jul 2015 12:34:43 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B5AF21E42C; Wed, 1 Jul 2015 15:36:14 -0400 (EDT) Date: Wed, 1 Jul 2015 15:36:14 -0400 From: Jeffrey Haas To: Lou Berger Message-ID: <20150701193614.GB5848@pfrc.org> References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5594097C.70607@labn.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' , "'Alvaro Retana \(aretana\)'" , Vishnu Pavan Beeram , Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:34:44 -0000 Lou, On Wed, Jul 01, 2015 at 11:38:36AM -0400, Lou Berger wrote: > > At this time, none of the Topology models utilize Traffic > engineering. It is anticipated that these models will support traffic > engineering. > > Sue, Jeff, > Given some recent messages on the list, I thought it best to confirm > we're all still on the same page. > > Based on our past discussions, it's my understanding that the work being > done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the > foundation for TE support in the I2RS models. I complete agree that > there are details on how the different topology models will > integrate/mesh still needs to be worked out, and I assumed that this is > what you/Sue were referring to above. -- But we will not have two sets > of TE topology models. I'll admit to not having recently read the teas model. I'll try to correct that soon. That said, we have some interesting headaches to work through for i2rs purposes: - We need a base model to work from. Which group provides the base is unimportant. - Some level of the abstract TE interactions that have i2rs impacts will potentially impose some impact on the models. - The biggest question is interactions with regard to ephemeral state. As you might have noticed, we're having quite the issue trying to shake out ephemeral state issues with netmod/netconf. Until we know what the answer is going to be in yang and the protocols, there's a large unknown as to whether we'll need our own "base model" or not. But just like with everything else in yang, we want to make sure that when there are reusable components, lets do it one place. As I said during today's i2rs interim, we do have to be careful about doing premature refactoring - doubly so as we don't know what the impacts of ephemeral stuff will be on i2rs. (Benoit will hopefully take the above observation as a note that even modeling work is starting to get impacted now and not just language/protocol.) The best I can recommend at this time is lets make sure everyone is paying attention to both drafts, identifying common components and be aware that we may need to reconcile the models via refactoring when the time comes. Plus it gets more eyeballs on both models. > I believe that the authors of the respective drafts are already are > working this. (Pavan, my co-chair as well as coauthor of the TEAS yang > model, can comment on this.) I'm going to largely say, "Don't Panic". We all want to do the right thing IETF-wise. -- Jeff From nobody Wed Jul 1 12:55:12 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF11A88DA for ; Wed, 1 Jul 2015 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 uacR_HKZufV1 for ; Wed, 1 Jul 2015 12:55:08 -0700 (PDT) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 395D81A8877 for ; Wed, 1 Jul 2015 12:54:51 -0700 (PDT) Received: (qmail 24735 invoked by uid 0); 1 Jul 2015 19:54:51 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 1 Jul 2015 19:54:51 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id n7kQ1q00C2SSUrH017kTUh; Wed, 01 Jul 2015 13:44:29 -0600 X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=AGkejYDSTmIA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=ZI-4lMHfUVQ3Q4pe8LIA:9 a=axkuzOC8j6Qsf7DD:21 a=Mrpmenl6cEJZxDNc:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=3RyW9Of3GcGo2/hY1Z0HA5biKsraQv8K8eUQVXAXJcU=; b=AsNhExaC6RNdr+jAVPOL3qw/HXHJ95hFdTzATP6SHgMXoz8xE9nrtQ2AdF/nPhG4Axj3N3um8OYncw0j/8WE95BxmJ9h8jtsFcJK5zi1aK43owurvCEqiFKTJzOQ2Jcx; Received: from box313.bluehost.com ([69.89.31.113]:33860 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAO5l-0008HN-Bi; Wed, 01 Jul 2015 13:54:45 -0600 Message-ID: <5594457F.9040107@labn.net> Date: Wed, 01 Jul 2015 15:54:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jeffrey Haas References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <20150701193614.GB5848@pfrc.org> In-Reply-To: <20150701193614.GB5848@pfrc.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , Vishnu Pavan Beeram , "'Alvaro Retana \(aretana\)'" , 'Alia Atlas' , Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 19:55:09 -0000 Jeff, Thank you for the response. All sounds right. I have a couple of additional points included below that I suspect we agree on. On 7/1/2015 3:36 PM, Jeffrey Haas wrote: ... > The best I can recommend at this time is lets make sure everyone is paying > attention to both drafts, identifying common components and be aware that we > may need to reconcile the models via refactoring when the time comes. Plus > it gets more eyeballs on both models. Agreed. Perhaps we can get a time for the authors of the I2RS and TEAS drafts to sit together in Prague to try to work through some of the details - or at least ensure they are on the same technical page? I talked to Pavan and he's willing to setup this up/coordinate. >> > I believe that the authors of the respective drafts are already are >> > working this. (Pavan, my co-chair as well as coauthor of the TEAS yang >> > model, can comment on this.) > I'm going to largely say, "Don't Panic". We all want to do the right thing > IETF-wise. I think we should ensure that we don't produce two models for the same thing -- this is a "motherhood" statement, so I'd be surprised if there's any disagreement on this point. Thanks, Lou > -- Jeff From nobody Wed Jul 1 15:49:19 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2E51B2C0F; Wed, 1 Jul 2015 15:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 YMrH7Gt7-Dk5; Wed, 1 Jul 2015 15:49:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 467681B2BD2; Wed, 1 Jul 2015 15:49:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Lou Berger'" , "'Jeffrey Haas'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> In-Reply-To: <5594097C.70607@labn.net> Date: Wed, 1 Jul 2015 18:49:09 -0400 Message-ID: <00d801d0b450$250e4560$6f2ad020$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QL4Xs+nnSyjtIA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' , "'Alvaro Retana \(aretana\)'" , 'Vishnu Pavan Beeram' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 22:49:17 -0000 Lou and Jeffrey: On 7/22, I talked with the TEAS TE authors team. They had concerns about how the I2RS was going to integrate the TEAS work. I realized there are two different approaches to the models - and I expressed my hope that we could have aligned/merged models. I chatted with the I2RS topology draft authors, and I found that the authors had not yet begun to work on the TE models. The best plan is to try to get the TEAS authors and the I2RS Topology authors together at IETF 93 and get a plan together for migrating these teams together. I will send a few times out to teams this evening. It would really help I2RS if the TEAS group would meet early in the week (or if the folks are at the hack-athon like I am we may meet Saturday night). We could then try to give NETCONF our best insight on the TE additions. In order to prepare for this TE/Non-TE merge, I2RS WG need to finalize the non-TE models in the topology. Today's interim was target to firm up the Service and T1 topology models, but the T1 topology model will not be ready until IETF 93. My message in June hoped that we would be to the TE models by IETF so that NETCONF would have our entire scope, but we will not be there by the beginning of IETF. I2RS will be following up in August and September with Interims that focus on the TE models in I2RS Topology model. Do you have any other suggestions? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, July 01, 2015 11:39 AM To: Susan Hares; 'Jeffrey Haas' Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'BRUNGARD, DEBORAH A'; Vishnu Pavan Beeram; 'Alvaro Retana (aretana)'; 'Alia Atlas' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) > At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Sue, Jeff, Given some recent messages on the list, I thought it best to confirm we're all still on the same page. Based on our past discussions, it's my understanding that the work being done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the foundation for TE support in the I2RS models. I complete agree that there are details on how the different topology models will integrate/mesh still needs to be worked out, and I assumed that this is what you/Sue were referring to above. -- But we will not have two sets of TE topology models. I believe that the authors of the respective drafts are already are working this. (Pavan, my co-chair as well as coauthor of the TEAS yang model, can comment on this.) Please let me know if I missed/miss-understood something. Thanks, Lou (as TEAS WG co-chair) On 6/23/2015 2:19 PM, Susan Hares wrote: > > Netconf Working Group: > > > > The I2RS WG would like to pass you a set of requirements for the I2RS > protocol, and asks that you provide an analysis by IETF 93 on whether > NETCONF or RESTCONF can meet these requirements. We expect that > these requirements may require changes to the either NETCONF or > RESTCONF. > > > > The I2RS architecture document (draft-ietf-i2rs-architecture-09 > ) > provides a high-level overview of the I2RS protocol. The I2RS has > compiled the following documents to provide the additional details on > the requirements for the protocols. > > > > 1) draft-ietf-i2rs-ephemeral-state-00 > > > 2) draft-ietf-i2rs-pub-sub-requirements-02 > /> > > 3) draft-ietf-i2rs-traceability-03 > > > > > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the > discussion from the 6/10 interim and the top 10 requirements for I2RS. > In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of > detailed requirements on how the I2RS WG sees the I2RS protocol > operating. These detailed requirements are to be seen as suggestions > on what type of solution the I2RS WG would like to see, but I2RS WG is > asking the NETCONF WG to provide its best designed protocol. Please > note as part of these detailed requirement the > draft-ietf-i2rs-ephemeral-states-00 contains the idea of using > metadata to record secondary identity. > > > > The I2RS protocol is driven by data-models. The approved data models > for protocol independent services are: > > - draft-ietf-i2rs-rib-data-model-00 > > > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 > (released later this week) > > - Topology model which is a composite of: > > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 > > > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 > > > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 > logy/> > > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 > released later this week). > > o Service topology model: > draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > > > > At this time, none of the Topology models utilize Traffic engineering. > It is anticipated that these models will support traffic engineering. > Estimated rates of transfer and timing requirements for these modules > are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the > protocol requirements table. > > > > We hope that NETCONF WG can provide some initial feedback on these > requirements by IETF 93 at the Tuesday I2RS session. I2RS will use > the 6/24 interim at 10:00-11:30am ET to provide a time for any > participate in the I2RS, netconf, or netmod group to ask additional > questions on these requirements. > > > > Sue Hares > > > > Interim time: 10:00-11:30am ET > > Date 6/24/2015 > > Webex: > > https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d > 0f > > > > agenda: > > > > 10:00 - 10:05 - Bash Agenda > > 10:05 - 10:20- - review of requirements from > > draft-ietf-i2rs-ephemeral-state-00 > > draft-ietf-i2rs-pub-sub-requirements-02 > > draft-ietf-i2rs-traceability-03 > > Timing requirements > > > > 10:20 - 10:30 Review of requirements for mutual authentication, > > and transaction in draft-hares-auth-trans-01 requirements > > > > 10:30- 11:30 Open discussion for I2RS Requirements > > > > Proceedings and slides can be found at: > > http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.ht > ml > > > > Sue Hares > > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jul 2 10:09:59 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6201A0233 for ; Thu, 2 Jul 2015 10:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 vQlTeYqchHVr for ; Thu, 2 Jul 2015 10:09:57 -0700 (PDT) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 1D4031A0210 for ; Thu, 2 Jul 2015 10:09:57 -0700 (PDT) Received: (qmail 7764 invoked by uid 0); 2 Jul 2015 17:09:56 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 2 Jul 2015 17:09:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id nV2E1q00K2SSUrH01V2HcC; Thu, 02 Jul 2015 11:02:20 -0600 X-Authority-Analysis: v=2.1 cv=ItWNLtPg c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=AGkejYDSTmIA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=DkiAw4pG--BOgwnSZ3UA:9 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6CEqUGc+VZ2aepguyzZzhayYvXVgyuErs9nvsjRJNX0=; b=m9r4kzGmHGy3/OURlWmhVdQDFLBpGThHn9uidiEccW+18VXe3cU6xOT1m5k80c08GwDK4r28IIJDmE41vxm3Mu/pFnbjfPNaimhq1GKXaDBpXyA/A1NgykDHs0VxsDQs; Received: from box313.bluehost.com ([69.89.31.113]:56211 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZAhzh-0002bM-RC; Thu, 02 Jul 2015 11:09:49 -0600 Message-ID: <55957056.60809@labn.net> Date: Thu, 02 Jul 2015 13:09:42 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , 'Jeffrey Haas' References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> In-Reply-To: <00d801d0b450$250e4560$6f2ad020$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Vishnu Pavan Beeram' , "'Alvaro Retana \(aretana\)'" , 'Alia Atlas' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 17:09:58 -0000 Sue, On 7/1/2015 6:49 PM, Susan Hares wrote: > ... In order to prepare for this TE/Non-TE merge, ... > Do you have any other suggestions? It sounds like the authors are working through this. So all that is needed seems to be happening. We should probably announce the time and place where the authors will be meeting in Prague so that others who are interested can show. (I'm assuming Pavan will coordinate the space request with the authors and secretariat.) -- Certianly an brief update in each WG seems appropriate. Not sure this more than someone saying something at the mic. > I2RS will be following up in August and > September with Interims that focus on the TE models in I2RS Topology model. This should work, as long as the interims include the active participants. We're having so many interims nowadays that it seems folks are having trouble balancing day jobs (or sleep if you end up on the wrong end of the time zone mismatch) with meetings... Thanks, Lou From nobody Thu Jul 2 11:45:28 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E781B2D56 for ; Tue, 30 Jun 2015 13:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2uMEAQcXNKR for ; Tue, 30 Jun 2015 13:24:44 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A60F1B2D2C for ; Tue, 30 Jun 2015 13:24:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 101C4240556; Tue, 30 Jun 2015 13:24:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (wsip-72-214-234-138.om.om.cox.net [72.214.234.138]) (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 B5B0B24020E; Tue, 30 Jun 2015 13:24:26 -0700 (PDT) To: Susan Hares , 'Linda Dunbar' , 'Igor Bryskin' , 'Juergen Schoenwaelder' References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <03ef01d0b36c$c98104a0$5c830de0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <5592FAF9.7040501@joelhalpern.com> Date: Tue, 30 Jun 2015 16:24:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <03ef01d0b36c$c98104a0$5c830de0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:26 -0700 Cc: nitin_bahadur@yahoo.com, i2rs@ietf.org, ttkacik@cisco.com, 'Hariharan Ananthakrishnan' , rovarga@cisco.com, alex@cisco.com, "'Jan Medved \(jmedved\)'" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 20:24:51 -0000 Let me be real clear. I know that the topology draft is an adopted I2RS working item, and I do not expect that to change. I am not asking that it change. I think it was a bad fit for our scope, but so be it. I felt I had to say something when someone said "but I2RS architecture looks like X because we have the topology draft." Having the draft does not change the WG agreed architecture. Which you have confirmed in separate email. Yours, Joel On 6/30/15 3:41 PM, Susan Hares wrote: > Joel: > > The use cases have lots of virtual topologies, and I not received any > feedback on these use cases. It would useful for you to comment on which of > these use cases you do not feel is useful. > > > > Joel - it sounds like you are questioning the protocol independent topology > is appropriate for the charter of I2RS. Charter questions are appropriate > only during charter adoption. The charter has been adopted in March 2015. > If you felt you were not heard during this discussion, please send a note to > the chairs and copy the AD. The I2RS chairs need to discuss re-opening > charter issues with the I2RS AD (Alia Atlas). > > The time to discuss the scope of the draft-ietf-i2rs-yang-network-top-01 > draft aligning with the charter was during adoption. I do not perceive that > you are questioning whether this draft aligns with the charter. > > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, June 29, 2015 5:06 PM > To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > You may recall that I have expressed concern about many times about how the > network topology draft fits the I2RS scope. It is still not clear to me > that it is an I2RS item, although it is clearly useful for things talking to > the I2RS Agent. > > Yours, > Joel > > On 6/29/15 5:01 PM, Linda Dunbar wrote: >> Joel, Igor, Juergen, >> >> Thanks for the feedback. Actually I always thought I2RS Agent is within a > single routing engine until reading the "I2RS Topology" draft. >> >> I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good > specification for information exchange between a routing engine and its > client. It reflects one single node's RIBs associated with multiple Routing > Instances supported by the routing engine. >> >> But the "I2RS Topology", which is also a very good specification > describing the network view of topologies (which consists of multiple nodes > and links among them), is more suited for the entity that manages multiple > routing nodes. >> >> RIBs of one routing engine and "topology of multiple routing engines" > definitely represent different perspectives: one is node view, another one > is the network view. >> >> >> In order to make I2RS widely adopted by the industry, it is very important > not to make it too complicated. Routing is not simple to start with, > therefore, it becomes especially more important to keep I2RS specification > simple and to the point. >> >> Therefore, I suggest to have a paragraph in the "network-topo" draft to > describe that this is for the network view, it is for clients who > manage/monitor multiple routing engines. >> >> My two cents. >> >> Linda >> >> -----Original Message----- >> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >> Sent: Monday, June 29, 2015 1:33 PM >> To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder >> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; >> Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan >> Medved (jmedved) >> Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> I agree with Joel, >> >> To answer Linda's question: if I2RS agent manages/represnts multiple > physical devices, the interface between the agent and the devices is out of > scope of I2RS. Note that such interface needs to be standardized only if one > considers a scenario where an I2RS agent controls devices from different > vendors. IMHO this scenario is unlikely, and at least for now it is safe to > assume that said interface is private. >> >> Cheers, >> Igor >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Monday, June 29, 2015 2:01 PM >> To: Linda Dunbar; Juergen Schoenwaelder >> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; >> Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan >> Medved (jmedved) >> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> Juergen is correct that by the I2RS definition an I2RS Agent is part of, > and associated with, a single routing element. >> >> It is true that the routing element may itself be a controller supporting > and interacting with multiple forwarding elements. That is not required, > and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity > is that the relationship between I2RS Clittns and I2rS agents is N:M. That > is, a client may be working with multiple agents, >> and an agent may be communicating with multiple clients. But it is >> still the case that the agent is collocated with the routing system, and > is not in a separate controller from the routing system. >> >> Yours, >> Joel >> >> On 6/29/15 10:46 AM, Linda Dunbar wrote: >>> Juergen, >>> >>> One I2RS agent can interface with multiple routing elements. >>> >>> The network view (which consists of multiple nodes, i.e. topology) has to > be over multiple nodes. Therefore, it is the interface between client and > Agent. Whereas, there are commands to individual routing element. >>> >>> Linda >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Monday, June 29, 2015 3:28 AM >>> To: Linda Dunbar >>> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >>> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan >>> Ananthakrishnan; ttkacik@cisco.com >>> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >>> >>> Linda, >>> >>> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a > routing element. I am not sure your understanding "I2RS Agent is like the > SDN controller" is consistent with the architecture document. >>> >>> /js >>> >>> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>>> Alex, et al, >>>> >>>> The I2RS architecture depicts two types of interfaces: >>>> >>>> - One is the interface between Agent and Client, and >>>> >>>> - another is the interface between Agent and Routing entities. >>>> >>>> >>>> The network model and inventory are more for the interface between Agent > and the Clients, isn't it? One single routing engine doesn't need to know > the overall topology and inventory information of other nodes, even though > some may do. >>>> >>>> >>>> And the /nd:network/nd:node and Termination points are more for the > interface between the Agent and the Forwarding Engine, isn't it? >>>> >>>> IMHO, the information models should be oriented around the I2RS > architecture. I.e. with description on where those information models are > applicable, making it easier to differentiate from other IETF WGs work (such > as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas > I2RS session. >>>> >>>> I2RS Agent is like the SDN controller, which can inform clients about > the topology information, instruct routes to routing engine of multiple > nodes, and retrieve link & termination points status from each of those > nodes. >>>> >>>> The "Service Overlay" in Section 3.4.8 is definitely meant for clients > not towards individual nodes. Mixing them all together make it confusing. >>>> >>>> Cheers, >>>> >>>> Linda Dunbar >>>> >>>> >>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Thu Jul 2 11:45:29 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86441B2DB9 for ; Tue, 30 Jun 2015 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r90kDRot7KxL for ; Tue, 30 Jun 2015 13:40:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112411A1AA1 for ; Tue, 30 Jun 2015 13:40:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A290214F5; Tue, 30 Jun 2015 22:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Az22p55ZItZp; Tue, 30 Jun 2015 22:40:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 30 Jun 2015 22:40:09 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 39C922002B; Tue, 30 Jun 2015 22:40:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZPnPKDO0vt4E; Tue, 30 Jun 2015 22:40:03 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD46520013; Tue, 30 Jun 2015 22:40:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 63D0B34E6C77; Tue, 30 Jun 2015 22:40:06 +0200 (CEST) Date: Tue, 30 Jun 2015 22:40:05 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150630204005.GA6794@elstar.local> Mail-Followup-To: Susan Hares , "'Joel M. Halpern'" , nitin_bahadur@yahoo.com, i2rs@ietf.org, ttkacik@cisco.com, 'Hariharan Ananthakrishnan' , rovarga@cisco.com, alex@cisco.com, 'Igor Bryskin' , 'Linda Dunbar' , "'Jan Medved (jmedved)'" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> <03f101d0b36d$0c635cf0$252a16d0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03f101d0b36d$0c635cf0$252a16d0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: nitin_bahadur@yahoo.com, i2rs@ietf.org, ttkacik@cisco.com, 'Hariharan Ananthakrishnan' , rovarga@cisco.com, alex@cisco.com, 'Igor Bryskin' , 'Linda Dunbar' , "'Jan Medved \(jmedved\)'" , "'Joel M. Halpern'" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 20:40:19 -0000 Sue, I agree with Joel. /js On Tue, Jun 30, 2015 at 03:43:30PM -0400, Susan Hares wrote: > Juergen: > > Please comment on which of the virtual topology use cases in the I2rs use > case requirements document are not appropriate. As the editor, I'd love > comments on the draft. As WG input, this guides the chair's acceptance of > work. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Tuesday, June 30, 2015 1:41 AM > To: Joel M. Halpern > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Igor Bryskin; Linda > Dunbar; Jan Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > I have been in the same boat but some people thought it is really important > to do a generic topology model in I2RS so here we go. > > /js > > On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: > > You may recall that I have expressed concern about many times about > > how the network topology draft fits the I2RS scope. It is still not > > clear to me that it is an I2RS item, although it is clearly useful for > > things talking to the I2RS Agent. > > > > Yours, > > Joel > > > > On 6/29/15 5:01 PM, Linda Dunbar wrote: > > >Joel, Igor, Juergen, > > > > > >Thanks for the feedback. Actually I always thought I2RS Agent is > > >within a single routing engine until reading the "I2RS Topology" draft. > > > > > >I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good > > >specification for information exchange between a routing engine and > > >its client. It reflects one single node's RIBs associated with > > >multiple Routing Instances supported by the routing engine. > > > > > >But the "I2RS Topology", which is also a very good specification > > >describing the network view of topologies (which consists of multiple > > >nodes and links among them), is more suited for the entity that > > >manages multiple routing nodes. > > > > > >RIBs of one routing engine and "topology of multiple routing engines" > > >definitely represent different perspectives: one is node view, > > >another one is the network view. > > > > > > > > >In order to make I2RS widely adopted by the industry, it is very > > >important not to make it too complicated. Routing is not simple to > > >start with, therefore, it becomes especially more important to keep > > >I2RS specification simple and to the point. > > > > > >Therefore, I suggest to have a paragraph in the "network-topo" draft > > >to describe that this is for the network view, it is for clients who > > >manage/monitor multiple routing engines. > > > > > >My two cents. > > > > > >Linda > > > > > >-----Original Message----- > > >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > > >Sent: Monday, June 29, 2015 1:33 PM > > >To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > > >Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; > > >Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan > > >Medved (jmedved) > > >Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > > > > >I agree with Joel, > > > > > >To answer Linda's question: if I2RS agent manages/represnts multiple > > >physical devices, the interface between the agent and the devices is > > >out of scope of I2RS. Note that such interface needs to be > > >standardized only if one considers a scenario where an I2RS agent > > >controls devices from different vendors. IMHO this scenario is > > >unlikely, and at least for now it is safe to assume that said interface > is private. > > > > > >Cheers, > > >Igor > > > > > >-----Original Message----- > > >From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. > > >Halpern > > >Sent: Monday, June 29, 2015 2:01 PM > > >To: Linda Dunbar; Juergen Schoenwaelder > > >Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; > > >Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan > > >Medved (jmedved) > > >Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > > > > >Juergen is correct that by the I2RS definition an I2RS Agent is part > > >of, and associated with, a single routing element. > > > > > >It is true that the routing element may itself be a controller > > >supporting and interacting with multiple forwarding elements. That > > >is not required, and not discussed, by I2RS. As far as I2RS is > > >concerned, the multiplicity is that the relationship between I2RS Clittns > and I2rS agents is N:M. > > >That is, a client may be working with multiple agents, > > >and an agent may be communicating with multiple clients. But it is > > >still the case that the agent is collocated with the routing system, > > >and is not in a separate controller from the routing system. > > > > > >Yours, > > >Joel > > > > > >On 6/29/15 10:46 AM, Linda Dunbar wrote: > > >>Juergen, > > >> > > >>One I2RS agent can interface with multiple routing elements. > > >> > > >>The network view (which consists of multiple nodes, i.e. topology) > > >>has to be over multiple nodes. Therefore, it is the interface > > >>between client and Agent. Whereas, there are commands to individual > routing element. > > >> > > >>Linda > > >>-----Original Message----- > > >>From: Juergen Schoenwaelder > > >>[mailto:j.schoenwaelder@jacobs-university.de] > > >>Sent: Monday, June 29, 2015 3:28 AM > > >>To: Linda Dunbar > > >>Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > > >>rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan > > >>Ananthakrishnan; ttkacik@cisco.com > > >>Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > >> > > >>Linda, > > >> > > >>according to draft-ietf-i2rs-architecture-09, an I2RS agent is part > > >>of a routing element. I am not sure your understanding "I2RS Agent > > >>is like the SDN controller" is consistent with the architecture > document. > > >> > > >>/js > > >> > > >>On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > > >>>Alex, et al, > > >>> > > >>>The I2RS architecture depicts two types of interfaces: > > >>> > > >>>- One is the interface between Agent and Client, and > > >>> > > >>>- another is the interface between Agent and Routing entities. > > >>> > > >>> > > >>>The network model and inventory are more for the interface between > > >>>Agent and the Clients, isn't it? One single routing engine doesn't > > >>>need to know the overall topology and inventory information of > > >>>other nodes, even though some may do. > > >>> > > >>> > > >>>And the /nd:network/nd:node and Termination points are more for the > > >>>interface between the Agent and the Forwarding Engine, isn't it? > > >>> > > >>>IMHO, the information models should be oriented around the I2RS > > >>>architecture. I.e. with description on where those information > > >>>models are applicable, making it easier to differentiate from other > > >>>IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were > > >>>some debates at the Dallas I2RS session. > > >>> > > >>>I2RS Agent is like the SDN controller, which can inform clients > > >>>about the topology information, instruct routes to routing engine > > >>>of multiple nodes, and retrieve link & termination points status > > >>>from each of those nodes. > > >>> > > >>>The "Service Overlay" in Section 3.4.8 is definitely meant for > > >>>clients not towards individual nodes. Mixing them all together make it > confusing. > > >>> > > >>>Cheers, > > >>> > > >>>Linda Dunbar > > >>> > > >>> > > >> > > >>>_______________________________________________ > > >>>i2rs mailing list > > >>>i2rs@ietf.org > > >>>https://www.ietf.org/mailman/listinfo/i2rs > > >> > > >> > > > > > >_______________________________________________ > > >i2rs mailing list > > >i2rs@ietf.org > > >https://www.ietf.org/mailman/listinfo/i2rs > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 11:45:32 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055A21B2AD6; Wed, 1 Jul 2015 02:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPLO1qQ0pzsg; Wed, 1 Jul 2015 02:27:42 -0700 (PDT) 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 300BA1B2AA3; Wed, 1 Jul 2015 02:27:42 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 0B80BDE2F33D9; Wed, 1 Jul 2015 09:27:39 +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 t619RaID028893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Jul 2015 11:27:37 +0200 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.213]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 1 Jul 2015 11:27:36 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: Susan Hares , "'Mahesh Jethanandani'" Thread-Topic: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQHQs3iywoO7BP7k/EicVuTrMAAx6p3Fa4wAgADr2RA= Date: Wed, 1 Jul 2015 09:27:35 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 09:27:44 -0000 --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gU3VzYW4sDQotICAgICAgICAgIFRvcG9sb2d5IG1vZGVsIHdoaWNoIGlzIGEgY29tcG9z aXRlIG9mOg0KbyAgIEdlbmVyaWMgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5n LW5ldHdvcmstdG9wby0wMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vPg0KbyAgIEwzIHRvcG9sb2d5IG1vZGVsOiBkcmFm dC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8+DQpvICAgTDIgdG9wb2xv Z3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDA8aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0 d29yay10b3BvbG9neS8+DQpvICAgTDEgVG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LXpoYW5nLWkycnMt bDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDIgcmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKS4NCm8g ICBTZXJ2aWNlIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2UtdG9wby15 YW5nLW1vZGVsLTAwIChyZWxlYXNlZCBvbiBXZWRuZXNkYXkpDQoNCkF0IHRoaXMgdGltZSwgbm9u ZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVlcmluZy4gIEl0 IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3VwcG9ydCB0cmFmZmljIGVu Z2luZWVyaW5nLg0KDQpSZWFkaW5nIHRoaXMgLCBteSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoZXJl IGlzIGludGVudGlvbiBmb3IgVHJhZmZpYyBFbmdpbmVlcmluZyBwYXJ0IG9mIHRvcG9sb2d5IG1v ZGVsIHRvIGV4cGxvaXQvY29vcmRpbmF0ZSB3aXRoIFRlYXMgLCBhbmQgcGFydGljdWxhcmx5IHdp dGgNCiBkcmFmdC1saXUtdGVhcy15YW5nLXRlLXRvcG8gb3IgdG8gcHJvY2VlZCB3aXRoIGRpc3Rp bmN0IGNvbnRyaWJ1dGlvbnMgaW50ZXJuYWwgdG8gSTJSUy4NCg0KVGhhbmtzDQpTZXJnaW8NCg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206 MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZl cnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg5 MjMwMjU1NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTEzMjQ0Mjc4NzIgNjc2OTg3MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIFN1c2FuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ VG9wb2xvZ3kNCiBtb2RlbCB3aGljaCBpcyBhIGNvbXBvc2l0ZSBvZjo8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5HZW5lcmlj DQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hpdGU7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0wMTwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotMTguMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIy MjtiYWNrZ3JvdW5kOndoaXRlIj5MMw0KIHRvcG9sb2d5IG1vZGVsOjwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7YmFja2dyb3VuZDojRjlGOUY5O3RleHQtZGVj b3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMDwvc3Bhbj48 L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNG OUY5RjkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0xOC4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPkwyDQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMi1u ZXR3b3JrLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Y29sb3I6IzNE MjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWky cnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFj a2dyb3VuZDp3aGl0ZSI+TDENCiBUb3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtemhhbmctaTJycy1sMS10b3BvLXlhbmctbW9kZWwtMDEN CiAoLTAyIHJlbGVhc2VkIGxhdGVyIHRoaXMgd2VlaykuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPlNlcnZpY2UN CiB0b3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ ZHJhZnQtaGFyZXMtaTJycy1zZXJ2aWNlLXRvcG8teWFuZy1tb2RlbC0wMA0KIChyZWxlYXNlZCBv biBXZWRuZXNkYXkpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjM2LjBw dDttYXJnaW4tYm90dG9tOjBjbTttYXJnaW4tbGVmdDozNi4wcHQ7bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkF0IHRoaXMg dGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVl cmluZy4mbmJzcDsgSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGVzZSBtb2RlbHMgd2lsbCBzdXBw b3J0IHRyYWZmaWMgZW5naW5lZXJpbmcuICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVhZGluZyB0 aGlzICwgbXkgcXVlc3Rpb24gaXMgd2hldGhlciB0aGVyZSBpcyBpbnRlbnRpb24gZm9yIFRyYWZm aWMgRW5naW5lZXJpbmcgcGFydCBvZiB0b3BvbG9neSBtb2RlbCB0byBleHBsb2l0L2Nvb3JkaW5h dGUgd2l0aCBUZWFzICwgYW5kIHBhcnRpY3VsYXJseSB3aXRoDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwO2RyYWZ0LWxpdS10ZWFzLXlhbmctdGUtdG9wbyBvciB0byBwcm9jZWVk IHdpdGggZGlzdGluY3QgY29udHJpYnV0aW9ucyBpbnRlcm5hbCB0byBJMlJTLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZXJnaW88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_B9FEE68CE3A78C41A2B3C67549A96F48B75EA34EFR711WXCHMBA05z_-- From nobody Thu Jul 2 11:45:33 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D81A1B95 for ; Wed, 1 Jul 2015 05:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN7_3DRqIZw2 for ; Wed, 1 Jul 2015 05:41:42 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 F114F1A6F7B for ; Wed, 1 Jul 2015 05:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1435754478; bh=Xr0U+tDn5TA+aycjL64zjaLHorITgBkHqQJPZ+Q2M4o=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=xTdxRp2Il8L3U0iVbatVDFEtOSk/TXUTirPU8LvU5IVUWihWxzx3CEn2r32+c5Au6 94DkEU0a3i9lyazk+/4WYgiDOGJve7glFK/gZYx+F1wUwm0GmjQ0l6VlwJ2oEQZ1ze CSyaiJrAcyEDrNkxnhqLcATZm/hmhLJYT9z6nomg= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Nadeau Thomas In-Reply-To: <20150630054124.GA4083@elstar.local> Date: Wed, 1 Jul 2015 08:41:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 47, in=377, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Igor Bryskin , Linda Dunbar , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2015 12:41:45 -0000 I personally think its important to do a generic topology model = as well as provide a layered model. This is something that has and is = implemented and deployed, so it is clearly important and useful. Where = its done is nearly irrelevant just as long as it gets done.=20 =E2=80=94Tom > On Jun 30, 2015:1:41 AM, at 1:41 AM, Juergen Schoenwaelder = wrote: >=20 > I have been in the same boat but some people thought it is really > important to do a generic topology model in I2RS so here we go. >=20 > /js >=20 > On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: >> You may recall that I have expressed concern about many times about = how=20 >> the network topology draft fits the I2RS scope. It is still not = clear=20 >> to me that it is an I2RS item, although it is clearly useful for = things=20 >> talking to the I2RS Agent. >>=20 >> Yours, >> Joel >>=20 >> On 6/29/15 5:01 PM, Linda Dunbar wrote: >>> Joel, Igor, Juergen, >>>=20 >>> Thanks for the feedback. Actually I always thought I2RS Agent is = within a=20 >>> single routing engine until reading the "I2RS Topology" draft. >>>=20 >>> I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good=20 >>> specification for information exchange between a routing engine and = its=20 >>> client. It reflects one single node's RIBs associated with multiple=20= >>> Routing Instances supported by the routing engine. >>>=20 >>> But the "I2RS Topology", which is also a very good specification=20 >>> describing the network view of topologies (which consists of = multiple=20 >>> nodes and links among them), is more suited for the entity that = manages=20 >>> multiple routing nodes. >>>=20 >>> RIBs of one routing engine and "topology of multiple routing = engines"=20 >>> definitely represent different perspectives: one is node view, = another one=20 >>> is the network view. >>>=20 >>>=20 >>> In order to make I2RS widely adopted by the industry, it is very = important=20 >>> not to make it too complicated. Routing is not simple to start with,=20= >>> therefore, it becomes especially more important to keep I2RS = specification=20 >>> simple and to the point. >>>=20 >>> Therefore, I suggest to have a paragraph in the "network-topo" draft = to=20 >>> describe that this is for the network view, it is for clients who=20 >>> manage/monitor multiple routing engines. >>>=20 >>> My two cents. >>>=20 >>> Linda >>>=20 >>> -----Original Message----- >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>> Sent: Monday, June 29, 2015 1:33 PM >>> To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder >>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; = Hariharan=20 >>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved = (jmedved) >>> Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >>>=20 >>> I agree with Joel, >>>=20 >>> To answer Linda's question: if I2RS agent manages/represnts multiple=20= >>> physical devices, the interface between the agent and the devices is = out=20 >>> of scope of I2RS. Note that such interface needs to be standardized = only=20 >>> if one considers a scenario where an I2RS agent controls devices = from=20 >>> different vendors. IMHO this scenario is unlikely, and at least for = now it=20 >>> is safe to assume that said interface is private. >>>=20 >>> Cheers, >>> Igor >>>=20 >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. = Halpern >>> Sent: Monday, June 29, 2015 2:01 PM >>> To: Linda Dunbar; Juergen Schoenwaelder >>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; = Hariharan=20 >>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved = (jmedved) >>> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >>>=20 >>> Juergen is correct that by the I2RS definition an I2RS Agent is part = of,=20 >>> and associated with, a single routing element. >>>=20 >>> It is true that the routing element may itself be a controller = supporting=20 >>> and interacting with multiple forwarding elements. That is not = required,=20 >>> and not discussed, by I2RS. As far as I2RS is concerned, the = multiplicity=20 >>> is that the relationship between I2RS Clittns and I2rS agents is = N:M. =20 >>> That is, a client may be working with multiple agents, >>> and an agent may be communicating with multiple clients. But it is >>> still the case that the agent is collocated with the routing system, = and=20 >>> is not in a separate controller from the routing system. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 6/29/15 10:46 AM, Linda Dunbar wrote: >>>> Juergen, >>>>=20 >>>> One I2RS agent can interface with multiple routing elements. >>>>=20 >>>> The network view (which consists of multiple nodes, i.e. topology) = has to=20 >>>> be over multiple nodes. Therefore, it is the interface between = client and=20 >>>> Agent. Whereas, there are commands to individual routing element. >>>>=20 >>>> Linda >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Monday, June 29, 2015 3:28 AM >>>> To: Linda Dunbar >>>> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >>>> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan = Ananthakrishnan; >>>> ttkacik@cisco.com >>>> Subject: Re: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01 >>>>=20 >>>> Linda, >>>>=20 >>>> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part = of a=20 >>>> routing element. I am not sure your understanding "I2RS Agent is = like the=20 >>>> SDN controller" is consistent with the architecture document. >>>>=20 >>>> /js >>>>=20 >>>> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>>>> Alex, et al, >>>>>=20 >>>>> The I2RS architecture depicts two types of interfaces: >>>>>=20 >>>>> - One is the interface between Agent and Client, and >>>>>=20 >>>>> - another is the interface between Agent and Routing = entities. >>>>>=20 >>>>>=20 >>>>> The network model and inventory are more for the interface between = Agent=20 >>>>> and the Clients, isn't it? One single routing engine doesn't need = to=20 >>>>> know the overall topology and inventory information of other = nodes, even=20 >>>>> though some may do. >>>>>=20 >>>>>=20 >>>>> And the /nd:network/nd:node and Termination points are more for = the=20 >>>>> interface between the Agent and the Forwarding Engine, isn't it? >>>>>=20 >>>>> IMHO, the information models should be oriented around the I2RS=20 >>>>> architecture. I.e. with description on where those information = models=20 >>>>> are applicable, making it easier to differentiate from other IETF = WGs=20 >>>>> work (such as L2VPN, L3VPN, or SFC). I recall there were some = debates at=20 >>>>> the Dallas I2RS session. >>>>>=20 >>>>> I2RS Agent is like the SDN controller, which can inform clients = about=20 >>>>> the topology information, instruct routes to routing engine of = multiple=20 >>>>> nodes, and retrieve link & termination points status from each of = those=20 >>>>> nodes. >>>>>=20 >>>>> The "Service Overlay" in Section 3.4.8 is definitely meant for = clients=20 >>>>> not towards individual nodes. Mixing them all together make it = confusing. >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Linda Dunbar >>>>>=20 >>>>>=20 >>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jul 2 11:45:35 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EABD1B2C7E; Wed, 1 Jul 2015 17:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajmcqUQGwohW; Wed, 1 Jul 2015 17:41:54 -0700 (PDT) Received: from mail-vn0-x22c.google.com (mail-vn0-x22c.google.com [IPv6:2607:f8b0:400c:c0f::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 1BA171B2C9F; Wed, 1 Jul 2015 17:41:52 -0700 (PDT) Received: by vnbf129 with SMTP id f129so9060090vnb.4; Wed, 01 Jul 2015 17:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mMjiODT0NSInRQwJr/B++gfoVh+9A5gkb/Qbcss4jM4=; b=dsPfBWaF6XVqR3Gg1xPY8q1jtQuxFd1Rs035VerH0dOxecQtfRpGxFYv5VWiESlO0n Gz+P+I6sQkomdoChDjGVvSKkomGsxGh0FSRGeAAlepsxBxnQ8rhtKbpOhaXdjPMvEK2A 9COfTQmR+EDb8tcYOJJ1ciddCBpCkOtZkVRJKeynWBeOqgBiGZVmlPacGpcBBdf9mw1m YNRBGqovuI5KKETe66XB1dCW1KMoKgYGJSklScA3tyKHk9X/0uGN9DqHvPnIhD6HcswU OZmYn1acDXyfk52YcLJ1YSuw4/o2ff/ifXjAEYKCKQB5mP7j9oZSk5ldjOsF6AV3BTyJ C3zg== MIME-Version: 1.0 X-Received: by 10.52.32.34 with SMTP id f2mr28501254vdi.11.1435797711282; Wed, 01 Jul 2015 17:41:51 -0700 (PDT) Received: by 10.31.96.80 with HTTP; Wed, 1 Jul 2015 17:41:51 -0700 (PDT) In-Reply-To: <00d801d0b450$250e4560$6f2ad020$@ndzh.com> References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> Date: Wed, 1 Jul 2015 20:41:51 -0400 Message-ID: From: Vishnu Pavan Beeram To: Susan Hares Content-Type: multipart/alternative; boundary=bcaec51d2b808ce8250519d9b42d Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:26 -0700 Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "BRUNGARD, DEBORAH A" , alex@cisco.com, Vishnu Pavan Beeram , Alia Atlas , draft-ietf-teas-yang-te-topo@tools.ietf.com, Jeffrey Haas , "Alvaro Retana \(aretana\)" , Lou Berger Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 00:42:05 -0000 --bcaec51d2b808ce8250519d9b42d Content-Type: text/plain; charset=UTF-8 + Alex + authors Sue, Jeff, The authors of the draft had a meeting today with one of the authors (Alex) of the draft and discussed ways to align the topo models. The consensus so far is that the WILL augment the . There are some issues that need to be worked out (mapping identifiers, termination-points), but those should get resolved in due course of time. I'll sync up with you (Sue) and coordinate a meeting between the authors of the and the authors of the I2RS topo model(s) at the IETF --- hopefully early in the week. Regards, -Pavan On Wed, Jul 1, 2015 at 6:49 PM, Susan Hares wrote: > Lou and Jeffrey: > > On 7/22, I talked with the TEAS TE authors team. They had concerns about > how the I2RS was going to integrate the TEAS work. I realized there are > two > different approaches to the models - and I expressed my hope that we could > have aligned/merged models. I chatted with the I2RS topology draft > authors, > and I found that the authors had not yet begun to work on the TE models. > The best plan is to try to get the TEAS authors and the I2RS Topology > authors together at IETF 93 and get a plan together for migrating these > teams together. > > I will send a few times out to teams this evening. It would really help > I2RS if the TEAS group would meet early in the week (or if the folks are at > the hack-athon like I am we may meet Saturday night). We could then try to > give NETCONF our best insight on the TE additions. > > In order to prepare for this TE/Non-TE merge, I2RS WG need to finalize the > non-TE models in the topology. Today's interim was target to firm up the > Service and T1 topology models, but the T1 topology model will not be ready > until IETF 93. My message in June hoped that we would be to the TE models > by IETF so that NETCONF would have our entire scope, but we will not be > there by the beginning of IETF. I2RS will be following up in August and > September with Interims that focus on the TE models in I2RS Topology model. > > Do you have any other suggestions? > > Sue > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Lou Berger > Sent: Wednesday, July 01, 2015 11:39 AM > To: Susan Hares; 'Jeffrey Haas' > Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'BRUNGARD, DEBORAH A'; Vishnu > Pavan Beeram; 'Alvaro Retana (aretana)'; 'Alia Atlas' > Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and > I2RS > interim (6/24/2015 at 10:00 - 11:30am ET) > > > At this time, none of the Topology models utilize Traffic > engineering. It is anticipated that these models will support traffic > engineering. > > Sue, Jeff, > Given some recent messages on the list, I thought it best to confirm > we're all still on the same page. > > Based on our past discussions, it's my understanding that the work being > done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the > foundation > for TE support in the I2RS models. I complete agree that there are details > on how the different topology models will integrate/mesh still needs to be > worked out, and I assumed that this is what you/Sue were referring to > above. > -- But we will not have two sets of TE topology models. > > I believe that the authors of the respective drafts are already are working > this. (Pavan, my co-chair as well as coauthor of the TEAS yang model, can > comment on this.) > > Please let me know if I missed/miss-understood something. > > Thanks, > Lou > (as TEAS WG co-chair) > On 6/23/2015 2:19 PM, Susan Hares wrote: > > > > Netconf Working Group: > > > > > > > > The I2RS WG would like to pass you a set of requirements for the I2RS > > protocol, and asks that you provide an analysis by IETF 93 on whether > > NETCONF or RESTCONF can meet these requirements. We expect that > > these requirements may require changes to the either NETCONF or > > RESTCONF. > > > > > > > > The I2RS architecture document (draft-ietf-i2rs-architecture-09 > > ) > > provides a high-level overview of the I2RS protocol. The I2RS has > > compiled the following documents to provide the additional details on > > the requirements for the protocols. > > > > > > > > 1) draft-ietf-i2rs-ephemeral-state-00 > > > > > > 2) draft-ietf-i2rs-pub-sub-requirements-02 > > > /> > > > > 3) draft-ietf-i2rs-traceability-03 > > > > > > > > > > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the > > discussion from the 6/10 interim and the top 10 requirements for I2RS. > > In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of > > detailed requirements on how the I2RS WG sees the I2RS protocol > > operating. These detailed requirements are to be seen as suggestions > > on what type of solution the I2RS WG would like to see, but I2RS WG is > > asking the NETCONF WG to provide its best designed protocol. Please > > note as part of these detailed requirement the > > draft-ietf-i2rs-ephemeral-states-00 contains the idea of using > > metadata to record secondary identity. > > > > > > > > The I2RS protocol is driven by data-models. The approved data models > > for protocol independent services are: > > > > - draft-ietf-i2rs-rib-data-model-00 > > > > > > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 > > (released later this week) > > > > - Topology model which is a composite of: > > > > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 > > > > > > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 > > > > > > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 > > > logy/> > > > > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 > > released later this week). > > > > o Service topology model: > > draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > > > > > > > > At this time, none of the Topology models utilize Traffic engineering. > > It is anticipated that these models will support traffic engineering. > > Estimated rates of transfer and timing requirements for these modules > > are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the > > protocol requirements table. > > > > > > > > We hope that NETCONF WG can provide some initial feedback on these > > requirements by IETF 93 at the Tuesday I2RS session. I2RS will use > > the 6/24 interim at 10:00-11:30am ET to provide a time for any > > participate in the I2RS, netconf, or netmod group to ask additional > > questions on these requirements. > > > > > > > > Sue Hares > > > > > > > > Interim time: 10:00-11:30am ET > > > > Date 6/24/2015 > > > > Webex: > > > > https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d > > 0f > > > > > > > > agenda: > > > > > > > > 10:00 - 10:05 - Bash Agenda > > > > 10:05 - 10:20- - review of requirements from > > > > draft-ietf-i2rs-ephemeral-state-00 > > > > draft-ietf-i2rs-pub-sub-requirements-02 > > > > draft-ietf-i2rs-traceability-03 > > > > Timing requirements > > > > > > > > 10:20 - 10:30 Review of requirements for mutual authentication, > > > > and transaction in draft-hares-auth-trans-01 requirements > > > > > > > > 10:30- 11:30 Open discussion for I2RS Requirements > > > > > > > > Proceedings and slides can be found at: > > > > http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.ht > > ml > > > > > > > > Sue Hares > > > > > > > > > > > > > > > > _______________________________________________ > > Rtg-yang-coord mailing list > > Rtg-yang-coord@ietf.org > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --bcaec51d2b808ce8250519d9b42d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+ Alex
+ <te-topo-model> aut= hors

Sue, Jeff,

The authors of the <te-to= po-model> draft had a meeting today with one of the authors (Alex) of th= e <network-topo-model> draft and discussed ways to align the topo mod= els. The consensus so far is that the <te-topo-model> WILL augment th= e <network-topo-model>. There are some issues that need to be worked = out (mapping identifiers, termination-points), but those should get resolve= d in due course of time.

I'll sync up with you (Sue) and coordi= nate a meeting between the authors of the <te-topo-model> and the aut= hors of the I2RS topo model(s) at the IETF --- hopefully early in the week.=

Regards,
-Pavan

On Wed, Jul 1, 2015 at 6:49 PM, S= usan Hares <shares@ndzh.com> wrote:
Lou and Jeffrey:

On 7/22, I talked with the TEAS TE authors team.=C2=A0 They had concerns ab= out
how the I2RS was going to integrate the TEAS work.=C2=A0 I realized there a= re two
different approaches to the models - and I expressed my=C2=A0 hope that we = could
have aligned/merged models.=C2=A0 I chatted with the I2RS topology draft au= thors,
and I found that the authors had not yet begun to work on the TE models. The best plan is to try to get the TEAS authors and the I2RS Topology
authors together at IETF 93 and get a plan together for migrating these
teams together.

I will send a few times out to teams this evening.=C2=A0 =C2=A0It would rea= lly help
I2RS if the TEAS group would meet early in the week (or if the folks are at=
the hack-athon like I am we may meet Saturday night).=C2=A0 We could then t= ry to
give NETCONF our best insight on the TE additions.

=C2=A0In order to prepare for this TE/Non-TE merge, I2RS WG need to finaliz= e the
non-TE models in the topology.=C2=A0 Today's interim was target to firm= up the
Service and T1 topology models, but the T1 topology model will not be ready=
until IETF 93.=C2=A0 My message in June hoped that we would be to the TE mo= dels
by IETF so that NETCONF would have our entire scope, but we will not be
there by the beginning of IETF.=C2=A0 =C2=A0I2RS will be following up in Au= gust and
September with Interims that focus on the TE models in I2RS Topology model.=

Do you have any other suggestions?

Sue


-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Lou Berger
Sent: Wednesday, July 01, 2015 11:39 AM
To: Susan Hares; 'Jeffrey Haas'
Cc: Rtg-yang-coord@ietf.org;= i2rs@ietf.org; 'BRUNGARD, DEBORAH= A'; Vishnu
Pavan Beeram; 'Alvaro Retana (aretana)'; 'Alia Atlas'
Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2R= S
interim (6/24/2015 at 10:00 - 11:30am ET)

> At this time, none of t= he Topology models utilize Traffic
engineering.=C2=A0 It is anticipated that these models will support traffic=
engineering.

Sue, Jeff,
=C2=A0 =C2=A0 Given some recent messages on the list, I thought it best to = confirm
we're all still on the same page.

Based on our past discussions, it's my understanding that the work bein= g
done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the foundatio= n
for TE support in the I2RS models.=C2=A0 I complete agree that there are de= tails
on how the different topology models will integrate/mesh still needs to be<= br> worked out, and I assumed that this is what you/Sue were referring to above= .
-- But we will not have two sets of TE topology models.

I believe that the authors of the respective drafts are already are working=
this.=C2=A0 (Pavan, my co-chair as well as coauthor of the TEAS yang model,= can
comment on this.)

Please let me know if I missed/miss-understood something.

Thanks,
Lou
(as TEAS WG co-chair)
On 6/23/2015 2:19 PM, Susan Hares wrote:
>
> Netconf Working Group:
>
>
>
> The I2RS WG would like to pass you a set of requirements for the I2RS<= br> > protocol, and asks that you provide an analysis by IETF 93 on whether<= br> > NETCONF or RESTCONF can meet these requirements.=C2=A0 =C2=A0We expect= that
> these requirements may require changes to the either NETCONF or
> RESTCONF.
>
>
>
> The I2RS architecture document (draft-ietf-i2rs-architecture-09
> <https://datatracker.ietf.org/= doc/draft-ietf-i2rs-architecture/>)
> provides a high-level overview of the I2RS=C2=A0 protocol.=C2=A0 The I= 2RS has
> compiled the following documents to provide the additional details on<= br> > the requirements for the protocols.
>
>
>
> 1)=C2=A0 =C2=A0 =C2=A0 draft-ietf-i2rs-ephemeral-state-00
> <https://datatracker.ietf.o= rg/doc/draft-ietf-i2rs-ephemeral-state/>
>
> 2)=C2=A0 =C2=A0 =C2=A0 draft-ietf-i2rs-pub-sub-requirements-02
> <https://datatracker.ie= tf.org/doc/draft-ietf-i2rs-pub-sub-requirements
> />
>
> 3)=C2=A0 =C2=A0 =C2=A0 draft-ietf-i2rs-traceability-03
> <https://datatracker.ietf.org/= doc/draft-ietf-i2rs-traceability/>
>
>
>
> The draft-ietf-i2rs-ephemeral-state-00 contains the results of the
> discussion from the 6/10 interim and the top 10 requirements for I2RS.=
> In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of=
> detailed requirements on how the I2RS WG sees the I2RS protocol
> operating.=C2=A0 These detailed requirements are to be seen as suggest= ions
> on what type of solution the I2RS WG would like to see, but I2RS WG is=
> asking the NETCONF WG to provide its best designed protocol.=C2=A0 Ple= ase
> note as part of these detailed requirement the
> draft-ietf-i2rs-ephemeral-states-00 contains the idea of using
> metadata to record secondary identity.
>
>
>
> The I2RS protocol is driven by data-models.=C2=A0 The approved data mo= dels
> for protocol independent services are:
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-ietf-i2rs-rib-data-model-00<= br> > <https://datatracker.ietf.or= g/doc/draft-ietf-i2rs-rib-data-model/>
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filter-Based RIBS:=C2=A0 draft-kin= i-i2rs-fb-rib-data-model.00
> (released later this week)
>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Topology model which is a composit= e of:
>
> o=C2=A0 =C2=A0Generic topology model: draft-ietf-i2rs-yang-network-top= o-01
> <https://datatracker.ietf= .org/doc/draft-ietf-i2rs-yang-network-topo/>
>
> o=C2=A0 =C2=A0L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 > <https://datatracker.ietf.= org/doc/draft-ietf-i2rs-yang-l3-topology/>
>
> o=C2=A0 =C2=A0L2 topology model: draft-ietf-i2rs-yang-l2-network-topol= ogy-00
> <https://datatracker.ie= tf.org/doc/draft-ietf-i2rs-yang-l2-network-topo
> logy/>
>
> o=C2=A0 =C2=A0L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-0= 1 (-02
> released later this week).
>
> o=C2=A0 =C2=A0Service topology model:
> draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) >
>
>
> At this time, none of the Topology models utilize Traffic engineering.=
> It is anticipated that these models will support traffic engineering.<= br> > Estimated rates of transfer and timing requirements for these modules<= br> > are at: http://trac.tools.ietf.org/wg/i2rs/trac/w= iki - under the
> protocol requirements table.
>
>
>
> We hope that NETCONF WG can provide some initial feedback on these
> requirements by IETF 93 at the Tuesday I2RS session.=C2=A0 =C2=A0I2RS = will use
> the 6/24 interim at 10:00-11:30am ET=C2=A0 to provide a time for any > participate in the I2RS, netconf, or netmod group to ask additional > questions on these requirements.
>
>
>
> Sue Hares
>
>
>
> Interim time: 10:00-11:30am ET
>
> Date 6/24/2015
>
> Webex:
>
> https://ietf.webex.com/= ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d
> 0f
>
>
>
> agenda:
>
>
>
> 10:00 - 10:05 - Bash Agenda
>
> 10:05 - 10:20- -=C2=A0 review of requirements from
>
> draft-ietf-i2rs-ephemeral-state-00
>
> draft-ietf-i2rs-pub-sub-requirements-02
>
> draft-ietf-i2rs-traceability-03
>
> Timing requirements
>
>
>
> 10:20 - 10:30=C2=A0 =C2=A0 Review of requirements for mutual authentic= ation,
>
> and transaction in=C2=A0 draft-hares-auth-trans-01 requirements
>
>
>
> 10:30- 11:30=C2=A0 =C2=A0 =C2=A0Open discussion for I2RS Requirements<= br> >
>
>
> Proceedings and slides can be found at:
>
> http://www.ietf.org/proce= edings/interim/2015/06/24/i2rs/proceedings.ht
> ml
>
>
>
> Sue Hares
>
>
>
>
>
>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> Rtg-yang-coord@ietf.org=
> https://www.ietf.org/mailman/listinfo/rtg= -yang-coord


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

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

--bcaec51d2b808ce8250519d9b42d-- From nobody Thu Jul 2 11:45:36 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532F31B2FBC for ; Wed, 1 Jul 2015 23:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wj6AlHW0sqMn for ; Wed, 1 Jul 2015 23:52:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66C41ACEDA for ; Wed, 1 Jul 2015 23:52:05 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0589B174E; Thu, 2 Jul 2015 08:52:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 8wRn5ymOJaiR; Thu, 2 Jul 2015 08:52:00 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 2 Jul 2015 08:51:59 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B70492002B; Thu, 2 Jul 2015 08:52:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qsdKu5cVICX3; Thu, 2 Jul 2015 08:51:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5289B20013; Thu, 2 Jul 2015 08:51:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3EF0834E80DB; Thu, 2 Jul 2015 08:51:58 +0200 (CEST) Date: Thu, 2 Jul 2015 08:51:58 +0200 From: Juergen Schoenwaelder To: Nadeau Thomas Message-ID: <20150702065158.GB10673@elstar.local> Mail-Followup-To: Nadeau Thomas , "Joel M. Halpern" , b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Igor Bryskin , Linda Dunbar , "Jan Medved (jmedved)" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Igor Bryskin , Linda Dunbar , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 06:52:09 -0000 True in principle but then there is apparently also confusion about scope and relationship of the work to what is called an I2RS agent. My proposal back then was to charter a short-lived WG to produce a generic topology model so that this important piece of work is not tied to any other WG with its specific scope. This proposal did not fly but I still believe this would have been the cleanest approach. Anyway, good to read that topology people plan to get together in Prague. Getting the right people to sit together is at the end what makes work move ahead. /js On Wed, Jul 01, 2015 at 08:41:09AM -0400, Nadeau Thomas wrote: > > I personally think its important to do a generic topology model as well as provide a layered model. This is something that has and is implemented and deployed, so it is clearly important and useful. Where its done is nearly irrelevant just as long as it gets done. > > —Tom > > > > On Jun 30, 2015:1:41 AM, at 1:41 AM, Juergen Schoenwaelder wrote: > > > > I have been in the same boat but some people thought it is really > > important to do a generic topology model in I2RS so here we go. > > > > /js > > > > On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: > >> You may recall that I have expressed concern about many times about how > >> the network topology draft fits the I2RS scope. It is still not clear > >> to me that it is an I2RS item, although it is clearly useful for things > >> talking to the I2RS Agent. > >> > >> Yours, > >> Joel > >> > >> On 6/29/15 5:01 PM, Linda Dunbar wrote: > >>> Joel, Igor, Juergen, > >>> > >>> Thanks for the feedback. Actually I always thought I2RS Agent is within a > >>> single routing engine until reading the "I2RS Topology" draft. > >>> > >>> I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good > >>> specification for information exchange between a routing engine and its > >>> client. It reflects one single node's RIBs associated with multiple > >>> Routing Instances supported by the routing engine. > >>> > >>> But the "I2RS Topology", which is also a very good specification > >>> describing the network view of topologies (which consists of multiple > >>> nodes and links among them), is more suited for the entity that manages > >>> multiple routing nodes. > >>> > >>> RIBs of one routing engine and "topology of multiple routing engines" > >>> definitely represent different perspectives: one is node view, another one > >>> is the network view. > >>> > >>> > >>> In order to make I2RS widely adopted by the industry, it is very important > >>> not to make it too complicated. Routing is not simple to start with, > >>> therefore, it becomes especially more important to keep I2RS specification > >>> simple and to the point. > >>> > >>> Therefore, I suggest to have a paragraph in the "network-topo" draft to > >>> describe that this is for the network view, it is for clients who > >>> manage/monitor multiple routing engines. > >>> > >>> My two cents. > >>> > >>> Linda > >>> > >>> -----Original Message----- > >>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >>> Sent: Monday, June 29, 2015 1:33 PM > >>> To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > >>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > >>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > >>> Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > >>> > >>> I agree with Joel, > >>> > >>> To answer Linda's question: if I2RS agent manages/represnts multiple > >>> physical devices, the interface between the agent and the devices is out > >>> of scope of I2RS. Note that such interface needs to be standardized only > >>> if one considers a scenario where an I2RS agent controls devices from > >>> different vendors. IMHO this scenario is unlikely, and at least for now it > >>> is safe to assume that said interface is private. > >>> > >>> Cheers, > >>> Igor > >>> > >>> -----Original Message----- > >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > >>> Sent: Monday, June 29, 2015 2:01 PM > >>> To: Linda Dunbar; Juergen Schoenwaelder > >>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > >>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > >>> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > >>> > >>> Juergen is correct that by the I2RS definition an I2RS Agent is part of, > >>> and associated with, a single routing element. > >>> > >>> It is true that the routing element may itself be a controller supporting > >>> and interacting with multiple forwarding elements. That is not required, > >>> and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity > >>> is that the relationship between I2RS Clittns and I2rS agents is N:M. > >>> That is, a client may be working with multiple agents, > >>> and an agent may be communicating with multiple clients. But it is > >>> still the case that the agent is collocated with the routing system, and > >>> is not in a separate controller from the routing system. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 6/29/15 10:46 AM, Linda Dunbar wrote: > >>>> Juergen, > >>>> > >>>> One I2RS agent can interface with multiple routing elements. > >>>> > >>>> The network view (which consists of multiple nodes, i.e. topology) has to > >>>> be over multiple nodes. Therefore, it is the interface between client and > >>>> Agent. Whereas, there are commands to individual routing element. > >>>> > >>>> Linda > >>>> -----Original Message----- > >>>> From: Juergen Schoenwaelder > >>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>> Sent: Monday, June 29, 2015 3:28 AM > >>>> To: Linda Dunbar > >>>> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > >>>> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; > >>>> ttkacik@cisco.com > >>>> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > >>>> > >>>> Linda, > >>>> > >>>> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a > >>>> routing element. I am not sure your understanding "I2RS Agent is like the > >>>> SDN controller" is consistent with the architecture document. > >>>> > >>>> /js > >>>> > >>>> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > >>>>> Alex, et al, > >>>>> > >>>>> The I2RS architecture depicts two types of interfaces: > >>>>> > >>>>> - One is the interface between Agent and Client, and > >>>>> > >>>>> - another is the interface between Agent and Routing entities. > >>>>> > >>>>> > >>>>> The network model and inventory are more for the interface between Agent > >>>>> and the Clients, isn't it? One single routing engine doesn't need to > >>>>> know the overall topology and inventory information of other nodes, even > >>>>> though some may do. > >>>>> > >>>>> > >>>>> And the /nd:network/nd:node and Termination points are more for the > >>>>> interface between the Agent and the Forwarding Engine, isn't it? > >>>>> > >>>>> IMHO, the information models should be oriented around the I2RS > >>>>> architecture. I.e. with description on where those information models > >>>>> are applicable, making it easier to differentiate from other IETF WGs > >>>>> work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at > >>>>> the Dallas I2RS session. > >>>>> > >>>>> I2RS Agent is like the SDN controller, which can inform clients about > >>>>> the topology information, instruct routes to routing engine of multiple > >>>>> nodes, and retrieve link & termination points status from each of those > >>>>> nodes. > >>>>> > >>>>> The "Service Overlay" in Section 3.4.8 is definitely meant for clients > >>>>> not towards individual nodes. Mixing them all together make it confusing. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Linda Dunbar > >>>>> > >>>>> > >>>> > >>>>> _______________________________________________ > >>>>> i2rs mailing list > >>>>> i2rs@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Jul 2 11:45:39 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F491A1B56 for ; Thu, 2 Jul 2015 05:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlkY5mzf48Lw for ; Thu, 2 Jul 2015 05:55:25 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 DBE241A1B3D for ; Thu, 2 Jul 2015 05:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1435841702; bh=M6K/wQxD7VFn9NuyWBxuOSy+xJuvfLxJ+AsbxSneOIE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=izJJYS6a7jyVy8Y/U0/iRq36Wg1n2TlPbYdLXMQKLsPllH7Z1Xl1Ko+aDyRFFUBqA +nAS49VYF/7QkfRczX5I1cAc6Mrf0q3nnZfbD74sVlAhHgmx2Tz4ek729lleJSADFZ HzoBfp8aOpFbPyLTJahA4B14C+Rjum8qiYaYw+/c= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Nadeau Thomas In-Reply-To: <20150702065158.GB10673@elstar.local> Date: Thu, 2 Jul 2015 08:54:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <43AE77BB-37A9-4D65-ADA1-A7E2AA627ED3@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> <20150702065158.GB10673@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Unknown ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 1, First 48, in=391, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Igor Bryskin , Linda Dunbar , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 12:55:28 -0000 > On Jul 2, 2015:2:51 AM, at 2:51 AM, Juergen Schoenwaelder = wrote: >=20 > True in principle but then there is apparently also confusion about > scope and relationship of the work to what is called an I2RS agent. That is for sure. > My proposal back then was to charter a short-lived WG to produce a > generic topology model so that this important piece of work is not > tied to any other WG with its specific scope. This proposal did not > fly but I still believe this would have been the cleanest approach. I would be all for this at this point. Pruning down the=20 scope of topology to fit into the current I2RS box (which I disagree = with) does not seem to be working out well in terms of the topo work at the IETF. Due to this mismatch, those interested in topology will = find that outside projects such as ODL have progressed topology well beyond=20= what is being discussed in i2rs. For example, multi-layered topology is a reality and there is a functional implementation of this. Maybe the solution is to indeed pull topology out of the i2rs WG and let it = progress independently? > Anyway, good to read that topology people plan to get together in > Prague. Getting the right people to sit together is at the end what > makes work move ahead. For sure.=20 =E2=80=94Tom >=20 > /js >=20 > On Wed, Jul 01, 2015 at 08:41:09AM -0400, Nadeau Thomas wrote: >>=20 >> I personally think its important to do a generic topology model = as well as provide a layered model. This is something that has and is = implemented and deployed, so it is clearly important and useful. Where = its done is nearly irrelevant just as long as it gets done.=20 >>=20 >> =E2=80=94Tom >>=20 >>=20 >>> On Jun 30, 2015:1:41 AM, at 1:41 AM, Juergen Schoenwaelder = wrote: >>>=20 >>> I have been in the same boat but some people thought it is really >>> important to do a generic topology model in I2RS so here we go. >>>=20 >>> /js >>>=20 >>> On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: >>>> You may recall that I have expressed concern about many times about = how=20 >>>> the network topology draft fits the I2RS scope. It is still not = clear=20 >>>> to me that it is an I2RS item, although it is clearly useful for = things=20 >>>> talking to the I2RS Agent. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 6/29/15 5:01 PM, Linda Dunbar wrote: >>>>> Joel, Igor, Juergen, >>>>>=20 >>>>> Thanks for the feedback. Actually I always thought I2RS Agent is = within a=20 >>>>> single routing engine until reading the "I2RS Topology" draft. >>>>>=20 >>>>> I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good=20= >>>>> specification for information exchange between a routing engine = and its=20 >>>>> client. It reflects one single node's RIBs associated with = multiple=20 >>>>> Routing Instances supported by the routing engine. >>>>>=20 >>>>> But the "I2RS Topology", which is also a very good specification=20= >>>>> describing the network view of topologies (which consists of = multiple=20 >>>>> nodes and links among them), is more suited for the entity that = manages=20 >>>>> multiple routing nodes. >>>>>=20 >>>>> RIBs of one routing engine and "topology of multiple routing = engines"=20 >>>>> definitely represent different perspectives: one is node view, = another one=20 >>>>> is the network view. >>>>>=20 >>>>>=20 >>>>> In order to make I2RS widely adopted by the industry, it is very = important=20 >>>>> not to make it too complicated. Routing is not simple to start = with,=20 >>>>> therefore, it becomes especially more important to keep I2RS = specification=20 >>>>> simple and to the point. >>>>>=20 >>>>> Therefore, I suggest to have a paragraph in the "network-topo" = draft to=20 >>>>> describe that this is for the network view, it is for clients who=20= >>>>> manage/monitor multiple routing engines. >>>>>=20 >>>>> My two cents. >>>>>=20 >>>>> Linda >>>>>=20 >>>>> -----Original Message----- >>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>> Sent: Monday, June 29, 2015 1:33 PM >>>>> To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder >>>>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; = Hariharan=20 >>>>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved = (jmedved) >>>>> Subject: RE: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01 >>>>>=20 >>>>> I agree with Joel, >>>>>=20 >>>>> To answer Linda's question: if I2RS agent manages/represnts = multiple=20 >>>>> physical devices, the interface between the agent and the devices = is out=20 >>>>> of scope of I2RS. Note that such interface needs to be = standardized only=20 >>>>> if one considers a scenario where an I2RS agent controls devices = from=20 >>>>> different vendors. IMHO this scenario is unlikely, and at least = for now it=20 >>>>> is safe to assume that said interface is private. >>>>>=20 >>>>> Cheers, >>>>> Igor >>>>>=20 >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. = Halpern >>>>> Sent: Monday, June 29, 2015 2:01 PM >>>>> To: Linda Dunbar; Juergen Schoenwaelder >>>>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; = Hariharan=20 >>>>> Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved = (jmedved) >>>>> Subject: Re: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01 >>>>>=20 >>>>> Juergen is correct that by the I2RS definition an I2RS Agent is = part of,=20 >>>>> and associated with, a single routing element. >>>>>=20 >>>>> It is true that the routing element may itself be a controller = supporting=20 >>>>> and interacting with multiple forwarding elements. That is not = required,=20 >>>>> and not discussed, by I2RS. As far as I2RS is concerned, the = multiplicity=20 >>>>> is that the relationship between I2RS Clittns and I2rS agents is = N:M. =20 >>>>> That is, a client may be working with multiple agents, >>>>> and an agent may be communicating with multiple clients. But it = is >>>>> still the case that the agent is collocated with the routing = system, and=20 >>>>> is not in a separate controller from the routing system. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 6/29/15 10:46 AM, Linda Dunbar wrote: >>>>>> Juergen, >>>>>>=20 >>>>>> One I2RS agent can interface with multiple routing elements. >>>>>>=20 >>>>>> The network view (which consists of multiple nodes, i.e. = topology) has to=20 >>>>>> be over multiple nodes. Therefore, it is the interface between = client and=20 >>>>>> Agent. Whereas, there are commands to individual routing element. >>>>>>=20 >>>>>> Linda >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Monday, June 29, 2015 3:28 AM >>>>>> To: Linda Dunbar >>>>>> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >>>>>> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan = Ananthakrishnan; >>>>>> ttkacik@cisco.com >>>>>> Subject: Re: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01 >>>>>>=20 >>>>>> Linda, >>>>>>=20 >>>>>> according to draft-ietf-i2rs-architecture-09, an I2RS agent is = part of a=20 >>>>>> routing element. I am not sure your understanding "I2RS Agent is = like the=20 >>>>>> SDN controller" is consistent with the architecture document. >>>>>>=20 >>>>>> /js >>>>>>=20 >>>>>> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>>>>>> Alex, et al, >>>>>>>=20 >>>>>>> The I2RS architecture depicts two types of interfaces: >>>>>>>=20 >>>>>>> - One is the interface between Agent and Client, and >>>>>>>=20 >>>>>>> - another is the interface between Agent and Routing = entities. >>>>>>>=20 >>>>>>>=20 >>>>>>> The network model and inventory are more for the interface = between Agent=20 >>>>>>> and the Clients, isn't it? One single routing engine doesn't = need to=20 >>>>>>> know the overall topology and inventory information of other = nodes, even=20 >>>>>>> though some may do. >>>>>>>=20 >>>>>>>=20 >>>>>>> And the /nd:network/nd:node and Termination points are more for = the=20 >>>>>>> interface between the Agent and the Forwarding Engine, isn't it? >>>>>>>=20 >>>>>>> IMHO, the information models should be oriented around the I2RS=20= >>>>>>> architecture. I.e. with description on where those information = models=20 >>>>>>> are applicable, making it easier to differentiate from other = IETF WGs=20 >>>>>>> work (such as L2VPN, L3VPN, or SFC). I recall there were some = debates at=20 >>>>>>> the Dallas I2RS session. >>>>>>>=20 >>>>>>> I2RS Agent is like the SDN controller, which can inform clients = about=20 >>>>>>> the topology information, instruct routes to routing engine of = multiple=20 >>>>>>> nodes, and retrieve link & termination points status from each = of those=20 >>>>>>> nodes. >>>>>>>=20 >>>>>>> The "Service Overlay" in Section 3.4.8 is definitely meant for = clients=20 >>>>>>> not towards individual nodes. Mixing them all together make it = confusing. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Linda Dunbar >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> i2rs mailing list >>>>>>> i2rs@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>=20 >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu Jul 2 11:45:41 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E557A1A86DD for ; Thu, 2 Jul 2015 06:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Ow6C0AtUcqtf for ; Thu, 2 Jul 2015 06:19:54 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D731A7D81 for ; Thu, 2 Jul 2015 06:19:31 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t62DJLUA006621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jul 2015 09:19:21 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 2 Jul 2015 09:19:21 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 2 Jul 2015 09:19:20 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1104.000; Thu, 2 Jul 2015 09:19:20 -0400 From: Igor Bryskin To: Nadeau Thomas , Juergen Schoenwaelder Thread-Topic: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCNQZwAAA0354AABs6xAAAK7y5g///a+ICAAAE0gIAAj+wAgAIHm4CAATDGAIAAZWqAgABUeQA= Date: Thu, 2 Jul 2015 13:19:20 +0000 Message-ID: <35b3edf43f8d44b1be4d73212b0d676c@ATL-SRV-MBX1.advaoptical.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> <20150702065158.GB10673@elstar.local> <43AE77BB-37A9-4D65-ADA1-A7E2AA627ED3@lucidvision.com> In-Reply-To: <43AE77BB-37A9-4D65-ADA1-A7E2AA627ED3@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-02_09:2015-07-02,2015-07-02,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Linda Dunbar , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 13:19:58 -0000 VG9tLA0KDQpJIGhvcGUgeW91IGFyZSBhd2FyZSBvZiB0aGUgd29yayB3ZSBhcmUgZG9pbmcgaW4g dGhlIFRFQVMgd29ya2luZyBncm91cCwgd2hpY2ggZGV2ZWxvcHMgYSBZQU5HIEFic3RyYWN0IFRF IFRvcG9sb2d5IG1vZGVsLCB3aGljaCBkb2VzIHN1cHBvcnQgbXVsdGktbGF5ZXIgVEUgdG9wb2xv Z2llcyAoYm90aCBuYXRpdmUgYW5kIGFic3RyYWN0L2N1c3RvbWl6ZWQsIGJvdGggbGVhcm5lZCBh bmQgY29uZmlndXJhYmxlKSB3aXRoIGxheWVyIHNwZWNpZmljIGF1Z21lbnRhdGlvbnMgaW4gdGhl IHJvYWQgbWFwLiBXZSB3YW50IHRoaXMgbW9kZWwgdG8gYmUgcGFydCBvZiB0aGUgSTJSUyBmYW1p bHksIGJ1dCB3ZSBhbHNvIHdhbnQgdGhlIG1vZGVsIHRvIGJlIHVzZWQgb3V0c2lkZSBvZiBJMlJT LCBmb3IgZXhhbXBsZSwgaW4gdGhlIEFDVE4gY29udGV4dC4NCg0KIFdlIGFyZSBhbHNvIHdvcmtp bmcgb24gYSBtdWx0aS12ZW5kb3IgaW50ZXJvcCBldmVudCBiYXNlZCBvbiB0aGUgbW9kZWwsIHdo aWNoIHdlIGhvcGUgdG8gbWFrZSBoYXBwZW4gd2l0aGluIDIwMTUuDQoNCkNoZWVycywNCklnb3IN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5hZGVhdSBUaG9tYXMgW21haWx0 bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgSnVseSAwMiwgMjAx NSA4OjU1IEFNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQpDYzogSm9lbCBNLiBIYWxwZXJu OyBiIG5pdGluOyBpMnJzQGlldGYub3JnOyB0dGthY2lrQGNpc2NvLmNvbTsgSGFyaWhhcmFuIEFu YW50aGFrcmlzaG5hbjsgcm92YXJnYUBjaXNjby5jb207IGFsZXhAY2lzY28uY29tOyBJZ29yIEJy eXNraW47IExpbmRhIER1bmJhcjsgSmFuIE1lZHZlZCAoam1lZHZlZCkNClN1YmplY3Q6IFJlOiBb aTJyc10gY29tbWVudHMgdG8gZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLTAxDQoN Cg0KPiBPbiBKdWwgMiwgMjAxNToyOjUxIEFNLCBhdCAyOjUxIEFNLCBKdWVyZ2VuIFNjaG9lbndh ZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0K PiBUcnVlIGluIHByaW5jaXBsZSBidXQgdGhlbiB0aGVyZSBpcyBhcHBhcmVudGx5IGFsc28gY29u ZnVzaW9uIGFib3V0IA0KPiBzY29wZSBhbmQgcmVsYXRpb25zaGlwIG9mIHRoZSB3b3JrIHRvIHdo YXQgaXMgY2FsbGVkIGFuIEkyUlMgYWdlbnQuDQoNCglUaGF0IGlzIGZvciBzdXJlLg0KDQo+IE15 IHByb3Bvc2FsIGJhY2sgdGhlbiB3YXMgdG8gY2hhcnRlciBhIHNob3J0LWxpdmVkIFdHIHRvIHBy b2R1Y2UgYSANCj4gZ2VuZXJpYyB0b3BvbG9neSBtb2RlbCBzbyB0aGF0IHRoaXMgaW1wb3J0YW50 IHBpZWNlIG9mIHdvcmsgaXMgbm90IA0KPiB0aWVkIHRvIGFueSBvdGhlciBXRyB3aXRoIGl0cyBz cGVjaWZpYyBzY29wZS4gIFRoaXMgcHJvcG9zYWwgZGlkIG5vdCANCj4gZmx5IGJ1dCBJIHN0aWxs IGJlbGlldmUgdGhpcyB3b3VsZCBoYXZlIGJlZW4gdGhlIGNsZWFuZXN0IGFwcHJvYWNoLg0KDQoJ SSB3b3VsZCBiZSBhbGwgZm9yIHRoaXMgYXQgdGhpcyBwb2ludC4gIFBydW5pbmcgZG93biB0aGUg c2NvcGUgb2YgdG9wb2xvZ3kgdG8gZml0IGludG8gdGhlIGN1cnJlbnQgSTJSUyBib3ggKHdoaWNo IEkgZGlzYWdyZWUgd2l0aCkgZG9lcyBub3Qgc2VlbSB0byBiZSB3b3JraW5nIG91dCB3ZWxsIGlu IHRlcm1zIG9mIHRoZSB0b3BvIHdvcmsgYXQgdGhlIElFVEYuICBEdWUgdG8gdGhpcyBtaXNtYXRj aCwgdGhvc2UgaW50ZXJlc3RlZCBpbiB0b3BvbG9neSB3aWxsIGZpbmQgdGhhdCBvdXRzaWRlIHBy b2plY3RzIHN1Y2ggYXMgT0RMIGhhdmUgcHJvZ3Jlc3NlZCB0b3BvbG9neSB3ZWxsIGJleW9uZCB3 aGF0IGlzIGJlaW5nIGRpc2N1c3NlZCBpbiBpMnJzLiAgRm9yIGV4YW1wbGUsIG11bHRpLWxheWVy ZWQgdG9wb2xvZ3kgaXMgYSByZWFsaXR5IGFuZCB0aGVyZSBpcyBhIGZ1bmN0aW9uYWwgaW1wbGVt ZW50YXRpb24gb2YgdGhpcy4gIE1heWJlIHRoZSBzb2x1dGlvbiBpcyB0byBpbmRlZWQgcHVsbCB0 b3BvbG9neSBvdXQgb2YgdGhlIGkycnMgV0cgYW5kIGxldCBpdCBwcm9ncmVzcyBpbmRlcGVuZGVu dGx5Pw0KDQo+IEFueXdheSwgZ29vZCB0byByZWFkIHRoYXQgdG9wb2xvZ3kgcGVvcGxlIHBsYW4g dG8gZ2V0IHRvZ2V0aGVyIGluIA0KPiBQcmFndWUuIEdldHRpbmcgdGhlIHJpZ2h0IHBlb3BsZSB0 byBzaXQgdG9nZXRoZXIgaXMgYXQgdGhlIGVuZCB3aGF0IA0KPiBtYWtlcyB3b3JrIG1vdmUgYWhl YWQuDQoNCglGb3Igc3VyZS4gDQoNCgnigJRUb20NCg0KDQoNCj4gDQo+IC9qcw0KPiANCj4gT24g V2VkLCBKdWwgMDEsIDIwMTUgYXQgMDg6NDE6MDlBTSAtMDQwMCwgTmFkZWF1IFRob21hcyB3cm90 ZToNCj4+IA0KPj4gCUkgcGVyc29uYWxseSB0aGluayBpdHMgaW1wb3J0YW50IHRvIGRvIGEgZ2Vu ZXJpYyB0b3BvbG9neSBtb2RlbCBhcyB3ZWxsIGFzIHByb3ZpZGUgYSBsYXllcmVkIG1vZGVsLiAg VGhpcyBpcyBzb21ldGhpbmcgdGhhdCBoYXMgYW5kIGlzIGltcGxlbWVudGVkIGFuZCBkZXBsb3ll ZCwgc28gaXQgaXMgY2xlYXJseSBpbXBvcnRhbnQgYW5kIHVzZWZ1bC4gV2hlcmUgaXRzIGRvbmUg aXMgbmVhcmx5IGlycmVsZXZhbnQganVzdCBhcyBsb25nIGFzIGl0IGdldHMgZG9uZS4gDQo+PiAN Cj4+IAnigJRUb20NCj4+IA0KPj4gDQo+Pj4gT24gSnVuIDMwLCAyMDE1OjE6NDEgQU0sIGF0IDE6 NDEgQU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlPiB3cm90ZToNCj4+PiANCj4+PiBJIGhhdmUgYmVlbiBpbiB0aGUgc2FtZSBib2F0 IGJ1dCBzb21lIHBlb3BsZSB0aG91Z2h0IGl0IGlzIHJlYWxseSANCj4+PiBpbXBvcnRhbnQgdG8g ZG8gYSBnZW5lcmljIHRvcG9sb2d5IG1vZGVsIGluIEkyUlMgc28gaGVyZSB3ZSBnby4NCj4+PiAN Cj4+PiAvanMNCj4+PiANCj4+PiBPbiBNb24sIEp1biAyOSwgMjAxNSBhdCAwNTowNjoxN1BNIC0w NDAwLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+Pj4+IFlvdSBtYXkgcmVjYWxsIHRoYXQgSSBo YXZlIGV4cHJlc3NlZCBjb25jZXJuIGFib3V0IG1hbnkgdGltZXMgYWJvdXQgDQo+Pj4+IGhvdyB0 aGUgbmV0d29yayB0b3BvbG9neSBkcmFmdCBmaXRzIHRoZSBJMlJTIHNjb3BlLiAgSXQgaXMgc3Rp bGwgDQo+Pj4+IG5vdCBjbGVhciB0byBtZSB0aGF0IGl0IGlzIGFuIEkyUlMgaXRlbSwgYWx0aG91 Z2ggaXQgaXMgY2xlYXJseSANCj4+Pj4gdXNlZnVsIGZvciB0aGluZ3MgdGFsa2luZyB0byB0aGUg STJSUyBBZ2VudC4NCj4+Pj4gDQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+IA0KPj4+PiBP biA2LzI5LzE1IDU6MDEgUE0sIExpbmRhIER1bmJhciB3cm90ZToNCj4+Pj4+IEpvZWwsIElnb3Is IEp1ZXJnZW4sDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrLiBBY3R1YWxs eSBJIGFsd2F5cyB0aG91Z2h0IEkyUlMgQWdlbnQgaXMgDQo+Pj4+PiB3aXRoaW4gYSBzaW5nbGUg cm91dGluZyBlbmdpbmUgdW50aWwgcmVhZGluZyB0aGUgIkkyUlMgVG9wb2xvZ3kiIGRyYWZ0Lg0K Pj4+Pj4gDQo+Pj4+PiBJIHNlZSBkcmFmdC1pZXRmLWkycnMtcmliLWluZm8tbW9kZWwtMDYgYXMg YSB2ZXJ5IGNsZWFyIGFuZCBnb29kIA0KPj4+Pj4gc3BlY2lmaWNhdGlvbiBmb3IgaW5mb3JtYXRp b24gZXhjaGFuZ2UgYmV0d2VlbiBhIHJvdXRpbmcgZW5naW5lIA0KPj4+Pj4gYW5kIGl0cyBjbGll bnQuIEl0IHJlZmxlY3RzIG9uZSBzaW5nbGUgbm9kZSdzIFJJQnMgYXNzb2NpYXRlZCB3aXRoIA0K Pj4+Pj4gbXVsdGlwbGUgUm91dGluZyBJbnN0YW5jZXMgc3VwcG9ydGVkIGJ5IHRoZSByb3V0aW5n IGVuZ2luZS4NCj4+Pj4+IA0KPj4+Pj4gQnV0IHRoZSAiSTJSUyBUb3BvbG9neSIsIHdoaWNoIGlz IGFsc28gYSB2ZXJ5IGdvb2Qgc3BlY2lmaWNhdGlvbiANCj4+Pj4+IGRlc2NyaWJpbmcgdGhlIG5l dHdvcmsgdmlldyBvZiB0b3BvbG9naWVzICh3aGljaCBjb25zaXN0cyBvZiANCj4+Pj4+IG11bHRp cGxlIG5vZGVzIGFuZCBsaW5rcyBhbW9uZyB0aGVtKSwgaXMgbW9yZSBzdWl0ZWQgZm9yIHRoZSAN Cj4+Pj4+IGVudGl0eSB0aGF0IG1hbmFnZXMgbXVsdGlwbGUgcm91dGluZyBub2Rlcy4NCj4+Pj4+ IA0KPj4+Pj4gUklCcyBvZiBvbmUgcm91dGluZyBlbmdpbmUgYW5kICJ0b3BvbG9neSBvZiBtdWx0 aXBsZSByb3V0aW5nIGVuZ2luZXMiIA0KPj4+Pj4gZGVmaW5pdGVseSByZXByZXNlbnQgZGlmZmVy ZW50IHBlcnNwZWN0aXZlczogb25lIGlzIG5vZGUgdmlldywgDQo+Pj4+PiBhbm90aGVyIG9uZSBp cyB0aGUgbmV0d29yayB2aWV3Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IEluIG9yZGVyIHRvIG1h a2UgSTJSUyB3aWRlbHkgYWRvcHRlZCBieSB0aGUgaW5kdXN0cnksIGl0IGlzIHZlcnkgDQo+Pj4+ PiBpbXBvcnRhbnQgbm90IHRvIG1ha2UgaXQgdG9vIGNvbXBsaWNhdGVkLiBSb3V0aW5nIGlzIG5v dCBzaW1wbGUgdG8gDQo+Pj4+PiBzdGFydCB3aXRoLCB0aGVyZWZvcmUsIGl0IGJlY29tZXMgZXNw ZWNpYWxseSBtb3JlIGltcG9ydGFudCB0byANCj4+Pj4+IGtlZXAgSTJSUyBzcGVjaWZpY2F0aW9u IHNpbXBsZSBhbmQgdG8gdGhlIHBvaW50Lg0KPj4+Pj4gDQo+Pj4+PiBUaGVyZWZvcmUsIEkgc3Vn Z2VzdCB0byBoYXZlIGEgcGFyYWdyYXBoIGluIHRoZSAibmV0d29yay10b3BvIiANCj4+Pj4+IGRy YWZ0IHRvIGRlc2NyaWJlIHRoYXQgdGhpcyBpcyBmb3IgdGhlIG5ldHdvcmsgdmlldywgaXQgaXMg Zm9yIA0KPj4+Pj4gY2xpZW50cyB3aG8gbWFuYWdlL21vbml0b3IgbXVsdGlwbGUgcm91dGluZyBl bmdpbmVzLg0KPj4+Pj4gDQo+Pj4+PiBNeSB0d28gY2VudHMuDQo+Pj4+PiANCj4+Pj4+IExpbmRh DQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBJ Z29yIEJyeXNraW4gW21haWx0bzpJQnJ5c2tpbkBhZHZhb3B0aWNhbC5jb21dDQo+Pj4+PiBTZW50 OiBNb25kYXksIEp1bmUgMjksIDIwMTUgMTozMyBQTQ0KPj4+Pj4gVG86IEpvZWwgTS4gSGFscGVy bjsgTGluZGEgRHVuYmFyOyBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4+Pj4+IENjOiBuaXRpbl9i YWhhZHVyQHlhaG9vLmNvbTsgJ2kycnNAaWV0Zi5vcmcnOyB0dGthY2lrQGNpc2NvLmNvbTsgDQo+ Pj4+PiBIYXJpaGFyYW4gQW5hbnRoYWtyaXNobmFuOyByb3ZhcmdhQGNpc2NvLmNvbTsgYWxleEBj aXNjby5jb207IEphbiANCj4+Pj4+IE1lZHZlZCAoam1lZHZlZCkNCj4+Pj4+IFN1YmplY3Q6IFJF OiBbaTJyc10gY29tbWVudHMgdG8gDQo+Pj4+PiBkcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3Jr LXRvcG8tMDENCj4+Pj4+IA0KPj4+Pj4gSSBhZ3JlZSB3aXRoIEpvZWwsDQo+Pj4+PiANCj4+Pj4+ IFRvIGFuc3dlciBMaW5kYSdzIHF1ZXN0aW9uOiBpZiBJMlJTIGFnZW50IG1hbmFnZXMvcmVwcmVz bnRzIA0KPj4+Pj4gbXVsdGlwbGUgcGh5c2ljYWwgZGV2aWNlcywgdGhlIGludGVyZmFjZSBiZXR3 ZWVuIHRoZSBhZ2VudCBhbmQgdGhlIA0KPj4+Pj4gZGV2aWNlcyBpcyBvdXQgb2Ygc2NvcGUgb2Yg STJSUy4gTm90ZSB0aGF0IHN1Y2ggaW50ZXJmYWNlIG5lZWRzIHRvIA0KPj4+Pj4gYmUgc3RhbmRh cmRpemVkIG9ubHkgaWYgb25lIGNvbnNpZGVycyBhIHNjZW5hcmlvIHdoZXJlIGFuIEkyUlMgDQo+ Pj4+PiBhZ2VudCBjb250cm9scyBkZXZpY2VzIGZyb20gZGlmZmVyZW50IHZlbmRvcnMuIElNSE8g dGhpcyBzY2VuYXJpbyANCj4+Pj4+IGlzIHVubGlrZWx5LCBhbmQgYXQgbGVhc3QgZm9yIG5vdyBp dCBpcyBzYWZlIHRvIGFzc3VtZSB0aGF0IHNhaWQgaW50ZXJmYWNlIGlzIHByaXZhdGUuDQo+Pj4+ PiANCj4+Pj4+IENoZWVycywNCj4+Pj4+IElnb3INCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIA0KPj4+Pj4gSGFscGVybg0KPj4+Pj4gU2VudDog TW9uZGF5LCBKdW5lIDI5LCAyMDE1IDI6MDEgUE0NCj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXI7IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlcg0KPj4+Pj4gQ2M6IG5pdGluX2JhaGFkdXJAeWFob28uY29tOyAn aTJyc0BpZXRmLm9yZyc7IHR0a2FjaWtAY2lzY28uY29tOyANCj4+Pj4+IEhhcmloYXJhbiBBbmFu dGhha3Jpc2huYW47IHJvdmFyZ2FAY2lzY28uY29tOyBhbGV4QGNpc2NvLmNvbTsgSmFuIA0KPj4+ Pj4gTWVkdmVkIChqbWVkdmVkKQ0KPj4+Pj4gU3ViamVjdDogUmU6IFtpMnJzXSBjb21tZW50cyB0 byANCj4+Pj4+IGRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0wMQ0KPj4+Pj4gDQo+ Pj4+PiBKdWVyZ2VuIGlzIGNvcnJlY3QgdGhhdCBieSB0aGUgSTJSUyBkZWZpbml0aW9uIGFuIEky UlMgQWdlbnQgaXMgDQo+Pj4+PiBwYXJ0IG9mLCBhbmQgYXNzb2NpYXRlZCB3aXRoLCBhIHNpbmds ZSByb3V0aW5nIGVsZW1lbnQuDQo+Pj4+PiANCj4+Pj4+IEl0IGlzIHRydWUgdGhhdCB0aGUgcm91 dGluZyBlbGVtZW50IG1heSBpdHNlbGYgYmUgYSBjb250cm9sbGVyIA0KPj4+Pj4gc3VwcG9ydGlu ZyBhbmQgaW50ZXJhY3Rpbmcgd2l0aCBtdWx0aXBsZSBmb3J3YXJkaW5nIGVsZW1lbnRzLiAgDQo+ Pj4+PiBUaGF0IGlzIG5vdCByZXF1aXJlZCwgYW5kIG5vdCBkaXNjdXNzZWQsIGJ5IEkyUlMuICBB cyBmYXIgYXMgSTJSUyANCj4+Pj4+IGlzIGNvbmNlcm5lZCwgdGhlIG11bHRpcGxpY2l0eSBpcyB0 aGF0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBJMlJTIENsaXR0bnMgYW5kIEkyclMgYWdlbnRz IGlzIE46TS4NCj4+Pj4+IFRoYXQgaXMsIGEgY2xpZW50IG1heSBiZSB3b3JraW5nIHdpdGggbXVs dGlwbGUgYWdlbnRzLA0KPj4+Pj4gYW5kIGFuIGFnZW50IG1heSBiZSBjb21tdW5pY2F0aW5nIHdp dGggbXVsdGlwbGUgY2xpZW50cy4gICBCdXQgaXQgaXMNCj4+Pj4+IHN0aWxsIHRoZSBjYXNlIHRo YXQgdGhlIGFnZW50IGlzIGNvbGxvY2F0ZWQgd2l0aCB0aGUgcm91dGluZyANCj4+Pj4+IHN5c3Rl bSwgYW5kIGlzIG5vdCBpbiBhIHNlcGFyYXRlIGNvbnRyb2xsZXIgZnJvbSB0aGUgcm91dGluZyBz eXN0ZW0uDQo+Pj4+PiANCj4+Pj4+IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4gDQo+Pj4+PiBP biA2LzI5LzE1IDEwOjQ2IEFNLCBMaW5kYSBEdW5iYXIgd3JvdGU6DQo+Pj4+Pj4gSnVlcmdlbiwN Cj4+Pj4+PiANCj4+Pj4+PiBPbmUgSTJSUyBhZ2VudCBjYW4gaW50ZXJmYWNlIHdpdGggbXVsdGlw bGUgcm91dGluZyBlbGVtZW50cy4NCj4+Pj4+PiANCj4+Pj4+PiBUaGUgbmV0d29yayB2aWV3ICh3 aGljaCBjb25zaXN0cyBvZiBtdWx0aXBsZSBub2RlcywgaS5lLiANCj4+Pj4+PiB0b3BvbG9neSkg aGFzIHRvIGJlIG92ZXIgbXVsdGlwbGUgbm9kZXMuIFRoZXJlZm9yZSwgaXQgaXMgdGhlIA0KPj4+ Pj4+IGludGVyZmFjZSBiZXR3ZWVuIGNsaWVudCBhbmQgQWdlbnQuIFdoZXJlYXMsIHRoZXJlIGFy ZSBjb21tYW5kcyB0byBpbmRpdmlkdWFsIHJvdXRpbmcgZWxlbWVudC4NCj4+Pj4+PiANCj4+Pj4+ PiBMaW5kYQ0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTog SnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+Pj4+Pj4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGVdDQo+Pj4+Pj4gU2VudDogTW9uZGF5LCBKdW5lIDI5LCAyMDE1IDM6 MjggQU0NCj4+Pj4+PiBUbzogTGluZGEgRHVuYmFyDQo+Pj4+Pj4gQ2M6ICdpMnJzQGlldGYub3Jn JzsgYWxleEBjaXNjby5jb207IEphbiBNZWR2ZWQgKGptZWR2ZWQpOyANCj4+Pj4+PiByb3Zhcmdh QGNpc2NvLmNvbTsgbml0aW5fYmFoYWR1ckB5YWhvby5jb207IEhhcmloYXJhbiANCj4+Pj4+PiBB bmFudGhha3Jpc2huYW47IHR0a2FjaWtAY2lzY28uY29tDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtp MnJzXSBjb21tZW50cyB0byANCj4+Pj4+PiBkcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRv cG8tMDENCj4+Pj4+PiANCj4+Pj4+PiBMaW5kYSwNCj4+Pj4+PiANCj4+Pj4+PiBhY2NvcmRpbmcg dG8gZHJhZnQtaWV0Zi1pMnJzLWFyY2hpdGVjdHVyZS0wOSwgYW4gSTJSUyBhZ2VudCBpcyANCj4+ Pj4+PiBwYXJ0IG9mIGEgcm91dGluZyBlbGVtZW50LiBJIGFtIG5vdCBzdXJlIHlvdXIgdW5kZXJz dGFuZGluZyAiSTJSUyANCj4+Pj4+PiBBZ2VudCBpcyBsaWtlIHRoZSBTRE4gY29udHJvbGxlciIg aXMgY29uc2lzdGVudCB3aXRoIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gL2pzDQo+Pj4+Pj4gDQo+Pj4+Pj4gT24gRnJpLCBKdW4gMjYsIDIwMTUgYXQgMDU6MDM6 MjVQTSArMDAwMCwgTGluZGEgRHVuYmFyIHdyb3RlOg0KPj4+Pj4+PiBBbGV4LCBldCBhbCwNCj4+ Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSBJMlJTIGFyY2hpdGVjdHVyZSBkZXBpY3RzIHR3byB0eXBlcyBv ZiBpbnRlcmZhY2VzOg0KPj4+Pj4+PiANCj4+Pj4+Pj4gLSAgICAgICAgICBPbmUgaXMgdGhlIGlu dGVyZmFjZSBiZXR3ZWVuIEFnZW50IGFuZCBDbGllbnQsIGFuZA0KPj4+Pj4+PiANCj4+Pj4+Pj4g LSAgICAgICAgICBhbm90aGVyIGlzIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBBZ2VudCBhbmQgUm91 dGluZyBlbnRpdGllcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgbmV0d29yayBt b2RlbCBhbmQgaW52ZW50b3J5IGFyZSBtb3JlIGZvciB0aGUgaW50ZXJmYWNlIA0KPj4+Pj4+PiBi ZXR3ZWVuIEFnZW50IGFuZCB0aGUgQ2xpZW50cywgIGlzbid0IGl0PyBPbmUgc2luZ2xlIHJvdXRp bmcgDQo+Pj4+Pj4+IGVuZ2luZSBkb2Vzbid0IG5lZWQgdG8ga25vdyB0aGUgb3ZlcmFsbCB0b3Bv bG9neSBhbmQgaW52ZW50b3J5IA0KPj4+Pj4+PiBpbmZvcm1hdGlvbiBvZiBvdGhlciBub2Rlcywg ZXZlbiB0aG91Z2ggc29tZSBtYXkgZG8uDQo+Pj4+Pj4+IA0KPj4+Pj4+PiANCj4+Pj4+Pj4gQW5k IHRoZSAvbmQ6bmV0d29yay9uZDpub2RlIGFuZCBUZXJtaW5hdGlvbiBwb2ludHMgYXJlIG1vcmUg Zm9yIA0KPj4+Pj4+PiB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIEFnZW50IGFuZCB0aGUgRm9y d2FyZGluZyBFbmdpbmUsIGlzbid0IGl0Pw0KPj4+Pj4+PiANCj4+Pj4+Pj4gSU1ITywgdGhlIGlu Zm9ybWF0aW9uIG1vZGVscyBzaG91bGQgYmUgb3JpZW50ZWQgYXJvdW5kIHRoZSBJMlJTIA0KPj4+ Pj4+PiBhcmNoaXRlY3R1cmUuIEkuZS4gd2l0aCBkZXNjcmlwdGlvbiBvbiB3aGVyZSB0aG9zZSBp bmZvcm1hdGlvbiANCj4+Pj4+Pj4gbW9kZWxzIGFyZSBhcHBsaWNhYmxlLCBtYWtpbmcgaXQgZWFz aWVyIHRvIGRpZmZlcmVudGlhdGUgZnJvbSANCj4+Pj4+Pj4gb3RoZXIgSUVURiBXR3Mgd29yayAo c3VjaCBhcyBMMlZQTiwgTDNWUE4sIG9yIFNGQykuIEkgcmVjYWxsIA0KPj4+Pj4+PiB0aGVyZSB3 ZXJlIHNvbWUgZGViYXRlcyBhdCB0aGUgRGFsbGFzIEkyUlMgc2Vzc2lvbi4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IEkyUlMgQWdlbnQgaXMgbGlrZSB0aGUgU0ROIGNvbnRyb2xsZXIsIHdoaWNoIGNhbiBp bmZvcm0gY2xpZW50cyANCj4+Pj4+Pj4gYWJvdXQgdGhlIHRvcG9sb2d5IGluZm9ybWF0aW9uLCBp bnN0cnVjdCByb3V0ZXMgdG8gcm91dGluZyANCj4+Pj4+Pj4gZW5naW5lIG9mIG11bHRpcGxlIG5v ZGVzLCBhbmQgcmV0cmlldmUgbGluayAmIHRlcm1pbmF0aW9uIHBvaW50cyANCj4+Pj4+Pj4gc3Rh dHVzIGZyb20gZWFjaCBvZiB0aG9zZSBub2Rlcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZSAiU2Vy dmljZSBPdmVybGF5IiBpbiBTZWN0aW9uIDMuNC44IGlzIGRlZmluaXRlbHkgbWVhbnQgZm9yIA0K Pj4+Pj4+PiBjbGllbnRzIG5vdCB0b3dhcmRzIGluZGl2aWR1YWwgbm9kZXMuIE1peGluZyB0aGVt IGFsbCB0b2dldGhlciBtYWtlIGl0IGNvbmZ1c2luZy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IENoZWVy cywNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IExpbmRhIER1bmJhcg0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4+IGkycnMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+IGkycnNAaWV0Zi5vcmcN Cj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQo+Pj4+ Pj4gDQo+Pj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+PiBpMnJzIG1haWxpbmcgbGlzdA0KPj4+Pj4gaTJyc0Bp ZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJz DQo+Pj4+PiANCj4+PiANCj4+PiAtLSANCj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAg ICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4+IFBob25lOiArNDkgNDIxIDIw MCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+ PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLz4NCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+IGkycnMgbWFpbGluZyBsaXN0DQo+Pj4gaTJyc0BpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KPj4gDQo+IA0K PiAtLSANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0 eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEw MyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0K From nobody Thu Jul 2 11:45:42 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B81A0092 for ; Thu, 2 Jul 2015 07:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vBMSHisaSAJ for ; Thu, 2 Jul 2015 07:09:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 DF3251A0091 for ; Thu, 2 Jul 2015 07:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1435846138; bh=cAJNfnoD/h/I53FjIkXkvgBkrjc5RycFfvQGTjZLfss=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=H/LFObo3C8e8tnjHDKHFL9rcAxwIY5FPwH1tCc9fX54cme14tKKLsf/R13j9zyzK+ Y4haaY23Da/EYjOpFyqdsgXxp+MR+sXcU0Tn6D9qBq8hDkxa2V8H7ryayp0a+36Bz1 pcWGypWRITkZksdu/Tf4l7E3VWPsyvZRLfTRFisY= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Nadeau Thomas In-Reply-To: <35b3edf43f8d44b1be4d73212b0d676c@ATL-SRV-MBX1.advaoptical.com> Date: Thu, 2 Jul 2015 09:53:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> <20150630054124.GA4083@elstar.local> <20150702065158.GB10673@elstar.local> <43AE77BB-37A9-4D65-ADA1-A7E2AA627ED3@lucidvision.com> <35b3edf43f8d44b1be4d73212b0d676c@ATL-SRV-MBX1.advaoptical.com> To: Igor Bryskin X-Mailer: Apple Mail (2.2098) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-ShareWhite: 50.255.148.181 X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 48, in=398, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: b nitin , "i2rs@ietf.org" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Juergen Schoenwaelder , Linda Dunbar , "Jan Medved \(jmedved\)" , "Joel M. Halpern" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 14:09:25 -0000 Yes, the question is: how does this work with/collide with what = is going on in i2rs - and more importantly, how do these models work = with the implementations that are out there? =E2=80=94Tom > On Jul 2, 2015:9:19 AM, at 9:19 AM, Igor Bryskin = wrote: >=20 > Tom, >=20 > I hope you are aware of the work we are doing in the TEAS working = group, which develops a YANG Abstract TE Topology model, which does = support multi-layer TE topologies (both native and abstract/customized, = both learned and configurable) with layer specific augmentations in the = road map. We want this model to be part of the I2RS family, but we also = want the model to be used outside of I2RS, for example, in the ACTN = context. >=20 > We are also working on a multi-vendor interop event based on the = model, which we hope to make happen within 2015. >=20 > Cheers, > Igor >=20 > -----Original Message----- > From: Nadeau Thomas [mailto:tnadeau@lucidvision.com]=20 > Sent: Thursday, July 02, 2015 8:55 AM > To: Juergen Schoenwaelder > Cc: Joel M. Halpern; b nitin; i2rs@ietf.org; ttkacik@cisco.com; = Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Igor = Bryskin; Linda Dunbar; Jan Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >=20 >=20 >> On Jul 2, 2015:2:51 AM, at 2:51 AM, Juergen Schoenwaelder = wrote: >>=20 >> True in principle but then there is apparently also confusion about=20= >> scope and relationship of the work to what is called an I2RS agent. >=20 > That is for sure. >=20 >> My proposal back then was to charter a short-lived WG to produce a=20 >> generic topology model so that this important piece of work is not=20 >> tied to any other WG with its specific scope. This proposal did not=20= >> fly but I still believe this would have been the cleanest approach. >=20 > I would be all for this at this point. Pruning down the scope = of topology to fit into the current I2RS box (which I disagree with) = does not seem to be working out well in terms of the topo work at the = IETF. Due to this mismatch, those interested in topology will find that = outside projects such as ODL have progressed topology well beyond what = is being discussed in i2rs. For example, multi-layered topology is a = reality and there is a functional implementation of this. Maybe the = solution is to indeed pull topology out of the i2rs WG and let it = progress independently? >=20 >> Anyway, good to read that topology people plan to get together in=20 >> Prague. Getting the right people to sit together is at the end what=20= >> makes work move ahead. >=20 > For sure.=20 >=20 > =E2=80=94Tom >=20 >=20 >=20 >>=20 >> /js >>=20 >> On Wed, Jul 01, 2015 at 08:41:09AM -0400, Nadeau Thomas wrote: >>>=20 >>> I personally think its important to do a generic topology model = as well as provide a layered model. This is something that has and is = implemented and deployed, so it is clearly important and useful. Where = its done is nearly irrelevant just as long as it gets done.=20 >>>=20 >>> =E2=80=94Tom >>>=20 >>>=20 >>>> On Jun 30, 2015:1:41 AM, at 1:41 AM, Juergen Schoenwaelder = wrote: >>>>=20 >>>> I have been in the same boat but some people thought it is really=20= >>>> important to do a generic topology model in I2RS so here we go. >>>>=20 >>>> /js >>>>=20 >>>> On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: >>>>> You may recall that I have expressed concern about many times = about=20 >>>>> how the network topology draft fits the I2RS scope. It is still=20= >>>>> not clear to me that it is an I2RS item, although it is clearly=20 >>>>> useful for things talking to the I2RS Agent. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 6/29/15 5:01 PM, Linda Dunbar wrote: >>>>>> Joel, Igor, Juergen, >>>>>>=20 >>>>>> Thanks for the feedback. Actually I always thought I2RS Agent is=20= >>>>>> within a single routing engine until reading the "I2RS Topology" = draft. >>>>>>=20 >>>>>> I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good=20= >>>>>> specification for information exchange between a routing engine=20= >>>>>> and its client. It reflects one single node's RIBs associated = with=20 >>>>>> multiple Routing Instances supported by the routing engine. >>>>>>=20 >>>>>> But the "I2RS Topology", which is also a very good specification=20= >>>>>> describing the network view of topologies (which consists of=20 >>>>>> multiple nodes and links among them), is more suited for the=20 >>>>>> entity that manages multiple routing nodes. >>>>>>=20 >>>>>> RIBs of one routing engine and "topology of multiple routing = engines"=20 >>>>>> definitely represent different perspectives: one is node view,=20 >>>>>> another one is the network view. >>>>>>=20 >>>>>>=20 >>>>>> In order to make I2RS widely adopted by the industry, it is very=20= >>>>>> important not to make it too complicated. Routing is not simple = to=20 >>>>>> start with, therefore, it becomes especially more important to=20 >>>>>> keep I2RS specification simple and to the point. >>>>>>=20 >>>>>> Therefore, I suggest to have a paragraph in the "network-topo"=20 >>>>>> draft to describe that this is for the network view, it is for=20 >>>>>> clients who manage/monitor multiple routing engines. >>>>>>=20 >>>>>> My two cents. >>>>>>=20 >>>>>> Linda >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Igor Bryskin [mailto:IBryskin@advaoptical.com] >>>>>> Sent: Monday, June 29, 2015 1:33 PM >>>>>> To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder >>>>>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com;=20= >>>>>> Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan=20= >>>>>> Medved (jmedved) >>>>>> Subject: RE: [i2rs] comments to=20 >>>>>> draft-ietf-i2rs-yang-network-topo-01 >>>>>>=20 >>>>>> I agree with Joel, >>>>>>=20 >>>>>> To answer Linda's question: if I2RS agent manages/represnts=20 >>>>>> multiple physical devices, the interface between the agent and = the=20 >>>>>> devices is out of scope of I2RS. Note that such interface needs = to=20 >>>>>> be standardized only if one considers a scenario where an I2RS=20 >>>>>> agent controls devices from different vendors. IMHO this scenario=20= >>>>>> is unlikely, and at least for now it is safe to assume that said = interface is private. >>>>>>=20 >>>>>> Cheers, >>>>>> Igor >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M.=20 >>>>>> Halpern >>>>>> Sent: Monday, June 29, 2015 2:01 PM >>>>>> To: Linda Dunbar; Juergen Schoenwaelder >>>>>> Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com;=20= >>>>>> Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan=20= >>>>>> Medved (jmedved) >>>>>> Subject: Re: [i2rs] comments to=20 >>>>>> draft-ietf-i2rs-yang-network-topo-01 >>>>>>=20 >>>>>> Juergen is correct that by the I2RS definition an I2RS Agent is=20= >>>>>> part of, and associated with, a single routing element. >>>>>>=20 >>>>>> It is true that the routing element may itself be a controller=20 >>>>>> supporting and interacting with multiple forwarding elements. =20 >>>>>> That is not required, and not discussed, by I2RS. As far as I2RS=20= >>>>>> is concerned, the multiplicity is that the relationship between = I2RS Clittns and I2rS agents is N:M. >>>>>> That is, a client may be working with multiple agents, >>>>>> and an agent may be communicating with multiple clients. But it = is >>>>>> still the case that the agent is collocated with the routing=20 >>>>>> system, and is not in a separate controller from the routing = system. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 6/29/15 10:46 AM, Linda Dunbar wrote: >>>>>>> Juergen, >>>>>>>=20 >>>>>>> One I2RS agent can interface with multiple routing elements. >>>>>>>=20 >>>>>>> The network view (which consists of multiple nodes, i.e.=20 >>>>>>> topology) has to be over multiple nodes. Therefore, it is the=20 >>>>>>> interface between client and Agent. Whereas, there are commands = to individual routing element. >>>>>>>=20 >>>>>>> Linda >>>>>>> -----Original Message----- >>>>>>> From: Juergen Schoenwaelder >>>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>>> Sent: Monday, June 29, 2015 3:28 AM >>>>>>> To: Linda Dunbar >>>>>>> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved);=20 >>>>>>> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan=20 >>>>>>> Ananthakrishnan; ttkacik@cisco.com >>>>>>> Subject: Re: [i2rs] comments to=20 >>>>>>> draft-ietf-i2rs-yang-network-topo-01 >>>>>>>=20 >>>>>>> Linda, >>>>>>>=20 >>>>>>> according to draft-ietf-i2rs-architecture-09, an I2RS agent is=20= >>>>>>> part of a routing element. I am not sure your understanding = "I2RS=20 >>>>>>> Agent is like the SDN controller" is consistent with the = architecture document. >>>>>>>=20 >>>>>>> /js >>>>>>>=20 >>>>>>> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>>>>>>> Alex, et al, >>>>>>>>=20 >>>>>>>> The I2RS architecture depicts two types of interfaces: >>>>>>>>=20 >>>>>>>> - One is the interface between Agent and Client, and >>>>>>>>=20 >>>>>>>> - another is the interface between Agent and Routing = entities. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> The network model and inventory are more for the interface=20 >>>>>>>> between Agent and the Clients, isn't it? One single routing=20 >>>>>>>> engine doesn't need to know the overall topology and inventory=20= >>>>>>>> information of other nodes, even though some may do. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> And the /nd:network/nd:node and Termination points are more for=20= >>>>>>>> the interface between the Agent and the Forwarding Engine, = isn't it? >>>>>>>>=20 >>>>>>>> IMHO, the information models should be oriented around the I2RS=20= >>>>>>>> architecture. I.e. with description on where those information=20= >>>>>>>> models are applicable, making it easier to differentiate from=20= >>>>>>>> other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall=20 >>>>>>>> there were some debates at the Dallas I2RS session. >>>>>>>>=20 >>>>>>>> I2RS Agent is like the SDN controller, which can inform clients=20= >>>>>>>> about the topology information, instruct routes to routing=20 >>>>>>>> engine of multiple nodes, and retrieve link & termination = points=20 >>>>>>>> status from each of those nodes. >>>>>>>>=20 >>>>>>>> The "Service Overlay" in Section 3.4.8 is definitely meant for=20= >>>>>>>> clients not towards individual nodes. Mixing them all together = make it confusing. >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>>=20 >>>>>>>> Linda Dunbar >>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> i2rs mailing list >>>>>>>> i2rs@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>>=20 >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >=20 From nobody Thu Jul 2 11:45:44 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BEA1A0127; Thu, 2 Jul 2015 09:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3XH4sFHAyqe; Thu, 2 Jul 2015 09:56:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98AF91A0167; Thu, 2 Jul 2015 09:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34420; q=dns/txt; s=iport; t=1435856193; x=1437065793; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kD3sq91WBqDB+IJOvgRgftV1EcCv/frAXeFy6Hee0uE=; b=kmZWitoVHCu1zUNsHvQDfNlYoljwYgRawHkmemPUx8gxh6O6o25FBT1w /hj3X/zakOWOBpT16FNOaNElweLwjPKs2lSTSiZZbX0JKbD00xJfDorv9 89xgJSrYjI24m7E65jUuvxeAz74q7NaiFN+1DodZdS0wP1erCLLJBrXVu w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C9BQDubJVV/5hdJa1BEQmCRU1UXwa9BioJgWQBCYV4AhyBMTgUAQEBAQEBAYEKhCIBAQEDAQEBASAKQQsFBwQCAQgRAQMBAQEKFgMEAwICAh8GCxQDBggCBAEJBAUIARKHfwMKCA06tV+QUg2FWgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLSoJNgV0rFhcEBgEGgmIvgRQFk140AYRgglmCSIMeRINQi2GHGhEVggwcFYE9bwGBRYECAQEB X-IronPort-AV: E=Sophos;i="5.15,394,1432598400"; d="scan'208,217";a="165076859" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jul 2015 16:56:29 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t62GuSBe024413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 Jul 2015 16:56:28 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Thu, 2 Jul 2015 11:56:28 -0500 From: "Alexander Clemm (alex)" To: Vishnu Pavan Beeram , Susan Hares Thread-Topic: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQHQtBQWPrNH8lZntEWPqrzeDcBm553Hi/GAgAAffYCAALploA== Date: Thu, 2 Jul 2015 16:56:27 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.143.132] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DBD4C6Axmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 02 Jul 2015 11:45:25 -0700 Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , "BRUNGARD, DEBORAH A" , Vishnu Pavan Beeram , Alia Atlas , "draft-ietf-teas-yang-te-topo@tools.ietf.com" , Jeffrey Haas , "Alvaro Retana \(aretana\)" , Lou Berger Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 16:56:36 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DBD4C6Axmbrcdx05ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBJIGJlbGlldmUgd2UgbWFkZSBhIGxvdCBvZiBwcm9ncmVzcy4gIE1vc3Qgb2YgdXMgd2ls bCBiZSBpbiBQcmFndWUgYW5kIGhhdmluZyBhIG1lZXRpbmcgdGhlcmUgdG8gdHJ5IGFuZCDigJx3 cmFwIHVw4oCdIHRoaW5ncyB3aWxsIGJlIGdvb2QgaWRlYS4NCi0tLSBBbGV4DQoNCkZyb206IFZp c2hudSBQYXZhbiBCZWVyYW0gW21haWx0bzp2aXNobnVwYXZhbkBnbWFpbC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIEp1bHkgMDEsIDIwMTUgNTo0MiBQTQ0KVG86IFN1c2FuIEhhcmVzDQpDYzogTG91 IEJlcmdlcjsgSmVmZnJleSBIYWFzOyBSdGcteWFuZy1jb29yZEBpZXRmLm9yZzsgaTJyc0BpZXRm Lm9yZzsgQlJVTkdBUkQsIERFQk9SQUggQTsgQWxpYSBBdGxhczsgQWx2YXJvIFJldGFuYSAoYXJl dGFuYSk7IFZpc2hudSBQYXZhbiBCZWVyYW07IGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG9A dG9vbHMuaWV0Zi5jb207IEFsZXhhbmRlciBDbGVtbSAoYWxleCkNClN1YmplY3Q6IFJlOiBbaTJy c10gW1J0Zy15YW5nLWNvb3JkXSBSZXF1aXJlbWVudHMgZm9yIEkyUlMgcHJvdG9jb2wgYW5kIEky UlMgaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAwIC0gMTE6MzBhbSBFVCkNCg0KKyBBbGV4DQor IDx0ZS10b3BvLW1vZGVsPiBhdXRob3JzDQpTdWUsIEplZmYsDQpUaGUgYXV0aG9ycyBvZiB0aGUg PHRlLXRvcG8tbW9kZWw+IGRyYWZ0IGhhZCBhIG1lZXRpbmcgdG9kYXkgd2l0aCBvbmUgb2YgdGhl IGF1dGhvcnMgKEFsZXgpIG9mIHRoZSA8bmV0d29yay10b3BvLW1vZGVsPiBkcmFmdCBhbmQgZGlz Y3Vzc2VkIHdheXMgdG8gYWxpZ24gdGhlIHRvcG8gbW9kZWxzLiBUaGUgY29uc2Vuc3VzIHNvIGZh ciBpcyB0aGF0IHRoZSA8dGUtdG9wby1tb2RlbD4gV0lMTCBhdWdtZW50IHRoZSA8bmV0d29yay10 b3BvLW1vZGVsPi4gVGhlcmUgYXJlIHNvbWUgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSB3b3JrZWQg b3V0IChtYXBwaW5nIGlkZW50aWZpZXJzLCB0ZXJtaW5hdGlvbi1wb2ludHMpLCBidXQgdGhvc2Ug c2hvdWxkIGdldCByZXNvbHZlZCBpbiBkdWUgY291cnNlIG9mIHRpbWUuDQoNCkknbGwgc3luYyB1 cCB3aXRoIHlvdSAoU3VlKSBhbmQgY29vcmRpbmF0ZSBhIG1lZXRpbmcgYmV0d2VlbiB0aGUgYXV0 aG9ycyBvZiB0aGUgPHRlLXRvcG8tbW9kZWw+IGFuZCB0aGUgYXV0aG9ycyBvZiB0aGUgSTJSUyB0 b3BvIG1vZGVsKHMpIGF0IHRoZSBJRVRGIC0tLSBob3BlZnVsbHkgZWFybHkgaW4gdGhlIHdlZWsu DQpSZWdhcmRzLA0KLVBhdmFuDQoNCk9uIFdlZCwgSnVsIDEsIDIwMTUgYXQgNjo0OSBQTSwgU3Vz YW4gSGFyZXMgPHNoYXJlc0BuZHpoLmNvbTxtYWlsdG86c2hhcmVzQG5kemguY29tPj4gd3JvdGU6 DQpMb3UgYW5kIEplZmZyZXk6DQoNCk9uIDcvMjIsIEkgdGFsa2VkIHdpdGggdGhlIFRFQVMgVEUg YXV0aG9ycyB0ZWFtLiAgVGhleSBoYWQgY29uY2VybnMgYWJvdXQNCmhvdyB0aGUgSTJSUyB3YXMg Z29pbmcgdG8gaW50ZWdyYXRlIHRoZSBURUFTIHdvcmsuICBJIHJlYWxpemVkIHRoZXJlIGFyZSB0 d28NCmRpZmZlcmVudCBhcHByb2FjaGVzIHRvIHRoZSBtb2RlbHMgLSBhbmQgSSBleHByZXNzZWQg bXkgIGhvcGUgdGhhdCB3ZSBjb3VsZA0KaGF2ZSBhbGlnbmVkL21lcmdlZCBtb2RlbHMuICBJIGNo YXR0ZWQgd2l0aCB0aGUgSTJSUyB0b3BvbG9neSBkcmFmdCBhdXRob3JzLA0KYW5kIEkgZm91bmQg dGhhdCB0aGUgYXV0aG9ycyBoYWQgbm90IHlldCBiZWd1biB0byB3b3JrIG9uIHRoZSBURSBtb2Rl bHMuDQpUaGUgYmVzdCBwbGFuIGlzIHRvIHRyeSB0byBnZXQgdGhlIFRFQVMgYXV0aG9ycyBhbmQg dGhlIEkyUlMgVG9wb2xvZ3kNCmF1dGhvcnMgdG9nZXRoZXIgYXQgSUVURiA5MyBhbmQgZ2V0IGEg cGxhbiB0b2dldGhlciBmb3IgbWlncmF0aW5nIHRoZXNlDQp0ZWFtcyB0b2dldGhlci4NCg0KSSB3 aWxsIHNlbmQgYSBmZXcgdGltZXMgb3V0IHRvIHRlYW1zIHRoaXMgZXZlbmluZy4gICBJdCB3b3Vs ZCByZWFsbHkgaGVscA0KSTJSUyBpZiB0aGUgVEVBUyBncm91cCB3b3VsZCBtZWV0IGVhcmx5IGlu IHRoZSB3ZWVrIChvciBpZiB0aGUgZm9sa3MgYXJlIGF0DQp0aGUgaGFjay1hdGhvbiBsaWtlIEkg YW0gd2UgbWF5IG1lZXQgU2F0dXJkYXkgbmlnaHQpLiAgV2UgY291bGQgdGhlbiB0cnkgdG8NCmdp dmUgTkVUQ09ORiBvdXIgYmVzdCBpbnNpZ2h0IG9uIHRoZSBURSBhZGRpdGlvbnMuDQoNCiBJbiBv cmRlciB0byBwcmVwYXJlIGZvciB0aGlzIFRFL05vbi1URSBtZXJnZSwgSTJSUyBXRyBuZWVkIHRv IGZpbmFsaXplIHRoZQ0Kbm9uLVRFIG1vZGVscyBpbiB0aGUgdG9wb2xvZ3kuICBUb2RheSdzIGlu dGVyaW0gd2FzIHRhcmdldCB0byBmaXJtIHVwIHRoZQ0KU2VydmljZSBhbmQgVDEgdG9wb2xvZ3kg bW9kZWxzLCBidXQgdGhlIFQxIHRvcG9sb2d5IG1vZGVsIHdpbGwgbm90IGJlIHJlYWR5DQp1bnRp bCBJRVRGIDkzLiAgTXkgbWVzc2FnZSBpbiBKdW5lIGhvcGVkIHRoYXQgd2Ugd291bGQgYmUgdG8g dGhlIFRFIG1vZGVscw0KYnkgSUVURiBzbyB0aGF0IE5FVENPTkYgd291bGQgaGF2ZSBvdXIgZW50 aXJlIHNjb3BlLCBidXQgd2Ugd2lsbCBub3QgYmUNCnRoZXJlIGJ5IHRoZSBiZWdpbm5pbmcgb2Yg SUVURi4gICBJMlJTIHdpbGwgYmUgZm9sbG93aW5nIHVwIGluIEF1Z3VzdCBhbmQNClNlcHRlbWJl ciB3aXRoIEludGVyaW1zIHRoYXQgZm9jdXMgb24gdGhlIFRFIG1vZGVscyBpbiBJMlJTIFRvcG9s b2d5IG1vZGVsLg0KDQpEbyB5b3UgaGF2ZSBhbnkgb3RoZXIgc3VnZ2VzdGlvbnM/DQoNClN1ZQ0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpMnJzIFttYWlsdG86aTJycy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgTG91IEJlcmdlcg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDAxLCAyMDE1IDExOjM5IEFNDQpU bzogU3VzYW4gSGFyZXM7ICdKZWZmcmV5IEhhYXMnDQpDYzogUnRnLXlhbmctY29vcmRAaWV0Zi5v cmc8bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnPjsgaTJyc0BpZXRmLm9yZzxtYWlsdG86 aTJyc0BpZXRmLm9yZz47ICdCUlVOR0FSRCwgREVCT1JBSCBBJzsgVmlzaG51DQpQYXZhbiBCZWVy YW07ICdBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSc7ICdBbGlhIEF0bGFzJw0KU3ViamVjdDogUmU6 IFtpMnJzXSBbUnRnLXlhbmctY29vcmRdIFJlcXVpcmVtZW50cyBmb3IgSTJSUyBwcm90b2NvbCBh bmQgSTJSUw0KaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAwIC0gMTE6MzBhbSBFVCkNCj4gQXQg dGhpcyB0aW1lLCBub25lIG9mIHRoZSBUb3BvbG9neSBtb2RlbHMgdXRpbGl6ZSBUcmFmZmljDQpl bmdpbmVlcmluZy4gIEl0IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3Vw cG9ydCB0cmFmZmljDQplbmdpbmVlcmluZy4NCg0KU3VlLCBKZWZmLA0KICAgIEdpdmVuIHNvbWUg cmVjZW50IG1lc3NhZ2VzIG9uIHRoZSBsaXN0LCBJIHRob3VnaHQgaXQgYmVzdCB0byBjb25maXJt DQp3ZSdyZSBhbGwgc3RpbGwgb24gdGhlIHNhbWUgcGFnZS4NCg0KQmFzZWQgb24gb3VyIHBhc3Qg ZGlzY3Vzc2lvbnMsIGl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSB3b3JrIGJlaW5nDQpk b25lIGluIFRFQVMgKHNlZSBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvKSB3aWxsIHNlcnZl IGFzIHRoZSBmb3VuZGF0aW9uDQpmb3IgVEUgc3VwcG9ydCBpbiB0aGUgSTJSUyBtb2RlbHMuICBJ IGNvbXBsZXRlIGFncmVlIHRoYXQgdGhlcmUgYXJlIGRldGFpbHMNCm9uIGhvdyB0aGUgZGlmZmVy ZW50IHRvcG9sb2d5IG1vZGVscyB3aWxsIGludGVncmF0ZS9tZXNoIHN0aWxsIG5lZWRzIHRvIGJl DQp3b3JrZWQgb3V0LCBhbmQgSSBhc3N1bWVkIHRoYXQgdGhpcyBpcyB3aGF0IHlvdS9TdWUgd2Vy ZSByZWZlcnJpbmcgdG8gYWJvdmUuDQotLSBCdXQgd2Ugd2lsbCBub3QgaGF2ZSB0d28gc2V0cyBv ZiBURSB0b3BvbG9neSBtb2RlbHMuDQoNCkkgYmVsaWV2ZSB0aGF0IHRoZSBhdXRob3JzIG9mIHRo ZSByZXNwZWN0aXZlIGRyYWZ0cyBhcmUgYWxyZWFkeSBhcmUgd29ya2luZw0KdGhpcy4gIChQYXZh biwgbXkgY28tY2hhaXIgYXMgd2VsbCBhcyBjb2F1dGhvciBvZiB0aGUgVEVBUyB5YW5nIG1vZGVs LCBjYW4NCmNvbW1lbnQgb24gdGhpcy4pDQoNClBsZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3Nl ZC9taXNzLXVuZGVyc3Rvb2Qgc29tZXRoaW5nLg0KDQpUaGFua3MsDQpMb3UNCihhcyBURUFTIFdH IGNvLWNoYWlyKQ0KT24gNi8yMy8yMDE1IDI6MTkgUE0sIFN1c2FuIEhhcmVzIHdyb3RlOg0KPg0K PiBOZXRjb25mIFdvcmtpbmcgR3JvdXA6DQo+DQo+DQo+DQo+IFRoZSBJMlJTIFdHIHdvdWxkIGxp a2UgdG8gcGFzcyB5b3UgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciB0aGUgSTJSUw0KPiBwcm90 b2NvbCwgYW5kIGFza3MgdGhhdCB5b3UgcHJvdmlkZSBhbiBhbmFseXNpcyBieSBJRVRGIDkzIG9u IHdoZXRoZXINCj4gTkVUQ09ORiBvciBSRVNUQ09ORiBjYW4gbWVldCB0aGVzZSByZXF1aXJlbWVu dHMuICAgV2UgZXhwZWN0IHRoYXQNCj4gdGhlc2UgcmVxdWlyZW1lbnRzIG1heSByZXF1aXJlIGNo YW5nZXMgdG8gdGhlIGVpdGhlciBORVRDT05GIG9yDQo+IFJFU1RDT05GLg0KPg0KPg0KPg0KPiBU aGUgSTJSUyBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1 cmUtMDkNCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJy cy1hcmNoaXRlY3R1cmUvPikNCj4gcHJvdmlkZXMgYSBoaWdoLWxldmVsIG92ZXJ2aWV3IG9mIHRo ZSBJMlJTICBwcm90b2NvbC4gIFRoZSBJMlJTIGhhcw0KPiBjb21waWxlZCB0aGUgZm9sbG93aW5n IGRvY3VtZW50cyB0byBwcm92aWRlIHRoZSBhZGRpdGlvbmFsIGRldGFpbHMgb24NCj4gdGhlIHJl cXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29scy4NCj4NCj4NCj4NCj4gMSkgICAgICBkcmFmdC1p ZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwDQo+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLz4NCj4NCj4gMikgICAgICBk cmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDINCj4gPGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cw0K PiAvPg0KPg0KPiAzKSAgICAgIGRyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHktMDMNCj4gPGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxp dHkvPg0KPg0KPg0KPg0KPiBUaGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBj b250YWlucyB0aGUgcmVzdWx0cyBvZiB0aGUNCj4gZGlzY3Vzc2lvbiBmcm9tIHRoZSA2LzEwIGlu dGVyaW0gYW5kIHRoZSB0b3AgMTAgcmVxdWlyZW1lbnRzIGZvciBJMlJTLg0KPiBJbiBhZGRpdGlv biwgdGhlIGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDAgY29udGFpbnMgYW4gc2V0 IG9mDQo+IGRldGFpbGVkIHJlcXVpcmVtZW50cyBvbiBob3cgdGhlIEkyUlMgV0cgc2VlcyB0aGUg STJSUyBwcm90b2NvbA0KPiBvcGVyYXRpbmcuICBUaGVzZSBkZXRhaWxlZCByZXF1aXJlbWVudHMg YXJlIHRvIGJlIHNlZW4gYXMgc3VnZ2VzdGlvbnMNCj4gb24gd2hhdCB0eXBlIG9mIHNvbHV0aW9u IHRoZSBJMlJTIFdHIHdvdWxkIGxpa2UgdG8gc2VlLCBidXQgSTJSUyBXRyBpcw0KPiBhc2tpbmcg dGhlIE5FVENPTkYgV0cgdG8gcHJvdmlkZSBpdHMgYmVzdCBkZXNpZ25lZCBwcm90b2NvbC4gIFBs ZWFzZQ0KPiBub3RlIGFzIHBhcnQgb2YgdGhlc2UgZGV0YWlsZWQgcmVxdWlyZW1lbnQgdGhlDQo+ IGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGVzLTAwIGNvbnRhaW5zIHRoZSBpZGVhIG9m IHVzaW5nDQo+IG1ldGFkYXRhIHRvIHJlY29yZCBzZWNvbmRhcnkgaWRlbnRpdHkuDQo+DQo+DQo+ DQo+IFRoZSBJMlJTIHByb3RvY29sIGlzIGRyaXZlbiBieSBkYXRhLW1vZGVscy4gIFRoZSBhcHBy b3ZlZCBkYXRhIG1vZGVscw0KPiBmb3IgcHJvdG9jb2wgaW5kZXBlbmRlbnQgc2VydmljZXMgYXJl Og0KPg0KPiAtICAgICAgICAgIGRyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC0wMA0KPiA8 aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRh LW1vZGVsLz4NCj4NCj4gLSAgICAgICAgICBGaWx0ZXItQmFzZWQgUklCUzogIGRyYWZ0LWtpbmkt aTJycy1mYi1yaWItZGF0YS1tb2RlbC4wMA0KPiAocmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKQ0K Pg0KPiAtICAgICAgICAgIFRvcG9sb2d5IG1vZGVsIHdoaWNoIGlzIGEgY29tcG9zaXRlIG9mOg0K Pg0KPiBvICAgR2VuZXJpYyB0b3BvbG9neSBtb2RlbDogZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0 d29yay10b3BvLTAxDQo+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vPg0KPg0KPiBvICAgTDMgdG9wb2xvZ3kgbW9kZWw6 IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTAwDQo+IDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8+DQo+DQo+ IG8gICBMMiB0b3BvbG9neSBtb2RlbDogZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0d29yay10 b3BvbG9neS0wMA0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1pMnJzLXlhbmctbDItbmV0d29yay10b3BvDQo+IGxvZ3kvPg0KPg0KPiBvICAgTDEgVG9wb2xv Z3kgbW9kZWw6IGRyYWZ0LXpoYW5nLWkycnMtbDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDINCj4g cmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKS4NCj4NCj4gbyAgIFNlcnZpY2UgdG9wb2xvZ3kgbW9k ZWw6DQo+IGRyYWZ0LWhhcmVzLWkycnMtc2VydmljZS10b3BvLXlhbmctbW9kZWwtMDAgKHJlbGVh c2VkIG9uIFdlZG5lc2RheSkNCj4NCj4NCj4NCj4gQXQgdGhpcyB0aW1lLCBub25lIG9mIHRoZSBU b3BvbG9neSBtb2RlbHMgdXRpbGl6ZSBUcmFmZmljIGVuZ2luZWVyaW5nLg0KPiBJdCBpcyBhbnRp Y2lwYXRlZCB0aGF0IHRoZXNlIG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZpYyBlbmdpbmVlcmlu Zy4NCj4gRXN0aW1hdGVkIHJhdGVzIG9mIHRyYW5zZmVyIGFuZCB0aW1pbmcgcmVxdWlyZW1lbnRz IGZvciB0aGVzZSBtb2R1bGVzDQo+IGFyZSBhdDogaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvaTJycy90cmFjL3dpa2kgLSB1bmRlciB0aGUNCj4gcHJvdG9jb2wgcmVxdWlyZW1lbnRzIHRh YmxlLg0KPg0KPg0KPg0KPiBXZSBob3BlIHRoYXQgTkVUQ09ORiBXRyBjYW4gcHJvdmlkZSBzb21l IGluaXRpYWwgZmVlZGJhY2sgb24gdGhlc2UNCj4gcmVxdWlyZW1lbnRzIGJ5IElFVEYgOTMgYXQg dGhlIFR1ZXNkYXkgSTJSUyBzZXNzaW9uLiAgIEkyUlMgd2lsbCB1c2UNCj4gdGhlIDYvMjQgaW50 ZXJpbSBhdCAxMDowMC0xMTozMGFtIEVUICB0byBwcm92aWRlIGEgdGltZSBmb3IgYW55DQo+IHBh cnRpY2lwYXRlIGluIHRoZSBJMlJTLCBuZXRjb25mLCBvciBuZXRtb2QgZ3JvdXAgdG8gYXNrIGFk ZGl0aW9uYWwNCj4gcXVlc3Rpb25zIG9uIHRoZXNlIHJlcXVpcmVtZW50cy4NCj4NCj4NCj4NCj4g U3VlIEhhcmVzDQo+DQo+DQo+DQo+IEludGVyaW0gdGltZTogMTA6MDAtMTE6MzBhbSBFVA0KPg0K PiBEYXRlIDYvMjQvMjAxNQ0KPg0KPiBXZWJleDoNCj4NCj4gaHR0cHM6Ly9pZXRmLndlYmV4LmNv bS9pZXRmL2oucGhwP01USUQ9bTQyNjBiZWU3YmU2MWNiMTdiMDAwOGEzYzUyMDY5ZA0KPiAwZg0K Pg0KPg0KPg0KPiBhZ2VuZGE6DQo+DQo+DQo+DQo+IDEwOjAwIC0gMTA6MDUgLSBCYXNoIEFnZW5k YQ0KPg0KPiAxMDowNSAtIDEwOjIwLSAtICByZXZpZXcgb2YgcmVxdWlyZW1lbnRzIGZyb20NCj4N Cj4gZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMA0KPg0KPiBkcmFmdC1pZXRmLWky cnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDINCj4NCj4gZHJhZnQtaWV0Zi1pMnJzLXRyYWNlYWJp bGl0eS0wMw0KPg0KPiBUaW1pbmcgcmVxdWlyZW1lbnRzDQo+DQo+DQo+DQo+IDEwOjIwIC0gMTA6 MzAgICAgUmV2aWV3IG9mIHJlcXVpcmVtZW50cyBmb3IgbXV0dWFsIGF1dGhlbnRpY2F0aW9uLA0K Pg0KPiBhbmQgdHJhbnNhY3Rpb24gaW4gIGRyYWZ0LWhhcmVzLWF1dGgtdHJhbnMtMDEgcmVxdWly ZW1lbnRzDQo+DQo+DQo+DQo+IDEwOjMwLSAxMTozMCAgICAgT3BlbiBkaXNjdXNzaW9uIGZvciBJ MlJTIFJlcXVpcmVtZW50cw0KPg0KPg0KPg0KPiBQcm9jZWVkaW5ncyBhbmQgc2xpZGVzIGNhbiBi ZSBmb3VuZCBhdDoNCj4NCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmlt LzIwMTUvMDYvMjQvaTJycy9wcm9jZWVkaW5ncy5odA0KPiBtbA0KPg0KPg0KPg0KPiBTdWUgSGFy ZXMNCj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gUnRnLXlhbmctY29vcmQgbWFpbGluZyBsaXN0DQo+IFJ0Zy15 YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydGcteWFuZy1jb29yZA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppMnJzIG1haWxp bmcgbGlzdA0KaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycw0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5v cmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnMNCg0K --_000_DBC595ED2346914F9F81D17DD5C32B571DBD4C6Axmbrcdx05ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmltDQoJe21zby1zdHls ZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlll cywgSSBiZWxpZXZlIHdlIG1hZGUgYSBsb3Qgb2YgcHJvZ3Jlc3MuJm5ic3A7IE1vc3Qgb2YgdXMg d2lsbCBiZSBpbiBQcmFndWUgYW5kIGhhdmluZyBhIG1lZXRpbmcgdGhlcmUgdG8gdHJ5IGFuZCDi gJx3cmFwIHVw4oCdIHRoaW5ncyB3aWxsIGJlIGdvb2QgaWRlYS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gVmlzaG51IFBhdmFuIEJlZXJhbSBbbWFpbHRvOnZpc2hudXBhdmFu QGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMDEsIDIwMTUg NTo0MiBQTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXM8YnI+DQo8Yj5DYzo8L2I+IExvdSBC ZXJnZXI7IEplZmZyZXkgSGFhczsgUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0Zi5v cmc7IEJSVU5HQVJELCBERUJPUkFIIEE7IEFsaWEgQXRsYXM7IEFsdmFybyBSZXRhbmEgKGFyZXRh bmEpOyBWaXNobnUgUGF2YW4gQmVlcmFtOyBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvQHRv b2xzLmlldGYuY29tOyBBbGV4YW5kZXIgQ2xlbW0gKGFsZXgpPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbaTJyc10gW1J0Zy15YW5nLWNvb3JkXSBSZXF1aXJlbWVudHMgZm9yIEkyUlMgcHJvdG9j b2wgYW5kIEkyUlMgaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAwIC0gMTE6MzBhbSBFVCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7IEFs ZXg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+JiM0MzsgJmx0O3RlLXRvcG8tbW9kZWwmZ3Q7IGF1 dGhvcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U3VlLCBKZWZmLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PlRoZSBhdXRob3JzIG9mIHRoZSAmbHQ7dGUtdG9wby1tb2RlbCZndDsgZHJhZnQgaGFkIGEgbWVl dGluZyB0b2RheSB3aXRoIG9uZSBvZiB0aGUgYXV0aG9ycyAoQWxleCkgb2YgdGhlICZsdDtuZXR3 b3JrLXRvcG8tbW9kZWwmZ3Q7IGRyYWZ0IGFuZCBkaXNjdXNzZWQgd2F5cyB0byBhbGlnbiB0aGUg dG9wbyBtb2RlbHMuIFRoZSBjb25zZW5zdXMgc28gZmFyIGlzIHRoYXQgdGhlICZsdDt0ZS10b3Bv LW1vZGVsJmd0Ow0KIFdJTEwgYXVnbWVudCB0aGUgJmx0O25ldHdvcmstdG9wby1tb2RlbCZndDsu IFRoZXJlIGFyZSBzb21lIGlzc3VlcyB0aGF0IG5lZWQgdG8gYmUgd29ya2VkIG91dCAobWFwcGlu ZyBpZGVudGlmaWVycywgdGVybWluYXRpb24tcG9pbnRzKSwgYnV0IHRob3NlIHNob3VsZCBnZXQg cmVzb2x2ZWQgaW4gZHVlIGNvdXJzZSBvZiB0aW1lLg0KPGJyPg0KPGJyPg0KSSdsbCBzeW5jIHVw IHdpdGggeW91IChTdWUpIGFuZCBjb29yZGluYXRlIGEgbWVldGluZyBiZXR3ZWVuIHRoZSBhdXRo b3JzIG9mIHRoZSAmbHQ7dGUtdG9wby1tb2RlbCZndDsgYW5kIHRoZSBhdXRob3JzIG9mIHRoZSBJ MlJTIHRvcG8gbW9kZWwocykgYXQgdGhlIElFVEYgLS0tIGhvcGVmdWxseSBlYXJseSBpbiB0aGUg d2Vlay4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi1QYXZhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gV2VkLCBKdWwgMSwgMjAxNSBhdCA2OjQ5IFBNLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNoYXJlc0BuZHpoLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+TG91IGFuZCBKZWZmcmV5Ojxi cj4NCjxicj4NCk9uIDcvMjIsIEkgdGFsa2VkIHdpdGggdGhlIFRFQVMgVEUgYXV0aG9ycyB0ZWFt LiZuYnNwOyBUaGV5IGhhZCBjb25jZXJucyBhYm91dDxicj4NCmhvdyB0aGUgSTJSUyB3YXMgZ29p bmcgdG8gaW50ZWdyYXRlIHRoZSBURUFTIHdvcmsuJm5ic3A7IEkgcmVhbGl6ZWQgdGhlcmUgYXJl IHR3bzxicj4NCmRpZmZlcmVudCBhcHByb2FjaGVzIHRvIHRoZSBtb2RlbHMgLSBhbmQgSSBleHBy ZXNzZWQgbXkmbmJzcDsgaG9wZSB0aGF0IHdlIGNvdWxkPGJyPg0KaGF2ZSBhbGlnbmVkL21lcmdl ZCBtb2RlbHMuJm5ic3A7IEkgY2hhdHRlZCB3aXRoIHRoZSBJMlJTIHRvcG9sb2d5IGRyYWZ0IGF1 dGhvcnMsPGJyPg0KYW5kIEkgZm91bmQgdGhhdCB0aGUgYXV0aG9ycyBoYWQgbm90IHlldCBiZWd1 biB0byB3b3JrIG9uIHRoZSBURSBtb2RlbHMuPGJyPg0KVGhlIGJlc3QgcGxhbiBpcyB0byB0cnkg dG8gZ2V0IHRoZSBURUFTIGF1dGhvcnMgYW5kIHRoZSBJMlJTIFRvcG9sb2d5PGJyPg0KYXV0aG9y cyB0b2dldGhlciBhdCBJRVRGIDkzIGFuZCBnZXQgYSBwbGFuIHRvZ2V0aGVyIGZvciBtaWdyYXRp bmcgdGhlc2U8YnI+DQp0ZWFtcyB0b2dldGhlci48YnI+DQo8YnI+DQpJIHdpbGwgc2VuZCBhIGZl dyB0aW1lcyBvdXQgdG8gdGVhbXMgdGhpcyBldmVuaW5nLiZuYnNwOyAmbmJzcDtJdCB3b3VsZCBy ZWFsbHkgaGVscDxicj4NCkkyUlMgaWYgdGhlIFRFQVMgZ3JvdXAgd291bGQgbWVldCBlYXJseSBp biB0aGUgd2VlayAob3IgaWYgdGhlIGZvbGtzIGFyZSBhdDxicj4NCnRoZSBoYWNrLWF0aG9uIGxp a2UgSSBhbSB3ZSBtYXkgbWVldCBTYXR1cmRheSBuaWdodCkuJm5ic3A7IFdlIGNvdWxkIHRoZW4g dHJ5IHRvPGJyPg0KZ2l2ZSBORVRDT05GIG91ciBiZXN0IGluc2lnaHQgb24gdGhlIFRFIGFkZGl0 aW9ucy48YnI+DQo8YnI+DQombmJzcDtJbiBvcmRlciB0byBwcmVwYXJlIGZvciB0aGlzIFRFL05v bi1URSBtZXJnZSwgSTJSUyBXRyBuZWVkIHRvIGZpbmFsaXplIHRoZTxicj4NCm5vbi1URSBtb2Rl bHMgaW4gdGhlIHRvcG9sb2d5LiZuYnNwOyBUb2RheSdzIGludGVyaW0gd2FzIHRhcmdldCB0byBm aXJtIHVwIHRoZTxicj4NClNlcnZpY2UgYW5kIFQxIHRvcG9sb2d5IG1vZGVscywgYnV0IHRoZSBU MSB0b3BvbG9neSBtb2RlbCB3aWxsIG5vdCBiZSByZWFkeTxicj4NCnVudGlsIElFVEYgOTMuJm5i c3A7IE15IG1lc3NhZ2UgaW4gSnVuZSBob3BlZCB0aGF0IHdlIHdvdWxkIGJlIHRvIHRoZSBURSBt b2RlbHM8YnI+DQpieSBJRVRGIHNvIHRoYXQgTkVUQ09ORiB3b3VsZCBoYXZlIG91ciBlbnRpcmUg c2NvcGUsIGJ1dCB3ZSB3aWxsIG5vdCBiZTxicj4NCnRoZXJlIGJ5IHRoZSBiZWdpbm5pbmcgb2Yg SUVURi4mbmJzcDsgJm5ic3A7STJSUyB3aWxsIGJlIGZvbGxvd2luZyB1cCBpbiBBdWd1c3QgYW5k PGJyPg0KU2VwdGVtYmVyIHdpdGggSW50ZXJpbXMgdGhhdCBmb2N1cyBvbiB0aGUgVEUgbW9kZWxz IGluIEkyUlMgVG9wb2xvZ3kgbW9kZWwuPGJyPg0KPGJyPg0KRG8geW91IGhhdmUgYW55IG90aGVy IHN1Z2dlc3Rpb25zPzxicj4NCjxicj4NClN1ZTxicj4NCjxicj4NCjxicj4NCjxzcGFuIGNsYXNz PSJpbSI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImltIj5Gcm9tOiBpMnJzIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmkycnMtYm91bmNlc0BpZXRm Lm9yZyI+aTJycy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIExvdSBCZXJnZXI8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5TZW50OiBXZWRuZXNkYXksIEp1bHkgMDEsIDIw MTUgMTE6MzkgQU08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5UbzogU3VzYW4gSGFyZXM7 ICdKZWZmcmV5IEhhYXMnPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+Q2M6IDxhIGhyZWY9 Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8 L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+OyAn QlJVTkdBUkQsIERFQk9SQUggQSc7IFZpc2hudTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0i PlBhdmFuIEJlZXJhbTsgJ0FsdmFybyBSZXRhbmEgKGFyZXRhbmEpJzsgJ0FsaWEgQXRsYXMnPC9z cGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+U3ViamVjdDogUmU6IFtpMnJzXSBbUnRnLXlhbmct Y29vcmRdIFJlcXVpcmVtZW50cyBmb3IgSTJSUyBwcm90b2NvbCBhbmQgSTJSUzwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iaW0iPmludGVyaW0gKDYvMjQvMjAxNSBhdCAxMDowMCAtIDExOjMwYW0g RVQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IEF0IHRoaXMgdGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxp emUgVHJhZmZpYzxicj4NCmVuZ2luZWVyaW5nLiZuYnNwOyBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0 IHRoZXNlIG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZpYzxicj4NCmVuZ2luZWVyaW5nLjxicj4N Cjxicj4NClN1ZSwgSmVmZiw8YnI+DQombmJzcDsgJm5ic3A7IEdpdmVuIHNvbWUgcmVjZW50IG1l c3NhZ2VzIG9uIHRoZSBsaXN0LCBJIHRob3VnaHQgaXQgYmVzdCB0byBjb25maXJtPGJyPg0Kd2Un cmUgYWxsIHN0aWxsIG9uIHRoZSBzYW1lIHBhZ2UuPGJyPg0KPGJyPg0KQmFzZWQgb24gb3VyIHBh c3QgZGlzY3Vzc2lvbnMsIGl0J3MgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSB3b3JrIGJlaW5n PGJyPg0KZG9uZSBpbiBURUFTIChzZWUgZHJhZnQtaWV0Zi10ZWFzLXlhbmctdGUtdG9wbykgd2ls bCBzZXJ2ZSBhcyB0aGUgZm91bmRhdGlvbjxicj4NCmZvciBURSBzdXBwb3J0IGluIHRoZSBJMlJT IG1vZGVscy4mbmJzcDsgSSBjb21wbGV0ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkZXRhaWxzPGJy Pg0Kb24gaG93IHRoZSBkaWZmZXJlbnQgdG9wb2xvZ3kgbW9kZWxzIHdpbGwgaW50ZWdyYXRlL21l c2ggc3RpbGwgbmVlZHMgdG8gYmU8YnI+DQp3b3JrZWQgb3V0LCBhbmQgSSBhc3N1bWVkIHRoYXQg dGhpcyBpcyB3aGF0IHlvdS9TdWUgd2VyZSByZWZlcnJpbmcgdG8gYWJvdmUuPGJyPg0KLS0gQnV0 IHdlIHdpbGwgbm90IGhhdmUgdHdvIHNldHMgb2YgVEUgdG9wb2xvZ3kgbW9kZWxzLjxicj4NCjxi cj4NCkkgYmVsaWV2ZSB0aGF0IHRoZSBhdXRob3JzIG9mIHRoZSByZXNwZWN0aXZlIGRyYWZ0cyBh cmUgYWxyZWFkeSBhcmUgd29ya2luZzxicj4NCnRoaXMuJm5ic3A7IChQYXZhbiwgbXkgY28tY2hh aXIgYXMgd2VsbCBhcyBjb2F1dGhvciBvZiB0aGUgVEVBUyB5YW5nIG1vZGVsLCBjYW48YnI+DQpj b21tZW50IG9uIHRoaXMuKTxicj4NCjxicj4NClBsZWFzZSBsZXQgbWUga25vdyBpZiBJIG1pc3Nl ZC9taXNzLXVuZGVyc3Rvb2Qgc29tZXRoaW5nLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpMb3U8 YnI+DQooYXMgVEVBUyBXRyBjby1jaGFpcik8YnI+DQpPbiA2LzIzLzIwMTUgMjoxOSBQTSwgU3Vz YW4gSGFyZXMgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgTmV0Y29uZiBXb3JraW5nIEdyb3Vw Ojxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIEkyUlMgV0cgd291 bGQgbGlrZSB0byBwYXNzIHlvdSBhIHNldCBvZiByZXF1aXJlbWVudHMgZm9yIHRoZSBJMlJTPGJy Pg0KJmd0OyBwcm90b2NvbCwgYW5kIGFza3MgdGhhdCB5b3UgcHJvdmlkZSBhbiBhbmFseXNpcyBi eSBJRVRGIDkzIG9uIHdoZXRoZXI8YnI+DQomZ3Q7IE5FVENPTkYgb3IgUkVTVENPTkYgY2FuIG1l ZXQgdGhlc2UgcmVxdWlyZW1lbnRzLiZuYnNwOyAmbmJzcDtXZSBleHBlY3QgdGhhdDxicj4NCiZn dDsgdGhlc2UgcmVxdWlyZW1lbnRzIG1heSByZXF1aXJlIGNoYW5nZXMgdG8gdGhlIGVpdGhlciBO RVRDT05GIG9yPGJyPg0KJmd0OyBSRVNUQ09ORi48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7IFRoZSBJMlJTIGFyY2hpdGVjdHVyZSBkb2N1bWVudCAoZHJhZnQtaWV0Zi1p MnJzLWFyY2hpdGVjdHVyZS0wOTxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUvIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJz LWFyY2hpdGVjdHVyZS88L2E+Jmd0Oyk8YnI+DQomZ3Q7IHByb3ZpZGVzIGEgaGlnaC1sZXZlbCBv dmVydmlldyBvZiB0aGUgSTJSUyZuYnNwOyBwcm90b2NvbC4mbmJzcDsgVGhlIEkyUlMgaGFzPGJy Pg0KJmd0OyBjb21waWxlZCB0aGUgZm9sbG93aW5nIGRvY3VtZW50cyB0byBwcm92aWRlIHRoZSBh ZGRpdGlvbmFsIGRldGFpbHMgb248YnI+DQomZ3Q7IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBw cm90b2NvbHMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxKSZuYnNw OyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDA8YnI+DQom Z3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvPC9hPiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAyKSZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYt aTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wMjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVp cmVtZW50cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50czwvYT48YnI+DQomZ3Q7IC8mZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgMykmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1pZXRmLWky cnMtdHJhY2VhYmlsaXR5LTAzPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMt dHJhY2VhYmlsaXR5LzwvYT4mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBUaGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBjb250YWlucyB0aGUg cmVzdWx0cyBvZiB0aGU8YnI+DQomZ3Q7IGRpc2N1c3Npb24gZnJvbSB0aGUgNi8xMCBpbnRlcmlt IGFuZCB0aGUgdG9wIDEwIHJlcXVpcmVtZW50cyBmb3IgSTJSUy48YnI+DQomZ3Q7IEluIGFkZGl0 aW9uLCB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBjb250YWlucyBhbiBz ZXQgb2Y8YnI+DQomZ3Q7IGRldGFpbGVkIHJlcXVpcmVtZW50cyBvbiBob3cgdGhlIEkyUlMgV0cg c2VlcyB0aGUgSTJSUyBwcm90b2NvbDxicj4NCiZndDsgb3BlcmF0aW5nLiZuYnNwOyBUaGVzZSBk ZXRhaWxlZCByZXF1aXJlbWVudHMgYXJlIHRvIGJlIHNlZW4gYXMgc3VnZ2VzdGlvbnM8YnI+DQom Z3Q7IG9uIHdoYXQgdHlwZSBvZiBzb2x1dGlvbiB0aGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHNl ZSwgYnV0IEkyUlMgV0cgaXM8YnI+DQomZ3Q7IGFza2luZyB0aGUgTkVUQ09ORiBXRyB0byBwcm92 aWRlIGl0cyBiZXN0IGRlc2lnbmVkIHByb3RvY29sLiZuYnNwOyBQbGVhc2U8YnI+DQomZ3Q7IG5v dGUgYXMgcGFydCBvZiB0aGVzZSBkZXRhaWxlZCByZXF1aXJlbWVudCB0aGU8YnI+DQomZ3Q7IGRy YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGVzLTAwIGNvbnRhaW5zIHRoZSBpZGVhIG9mIHVz aW5nPGJyPg0KJmd0OyBtZXRhZGF0YSB0byByZWNvcmQgc2Vjb25kYXJ5IGlkZW50aXR5Ljxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIEkyUlMgcHJvdG9jb2wgaXMg ZHJpdmVuIGJ5IGRhdGEtbW9kZWxzLiZuYnNwOyBUaGUgYXBwcm92ZWQgZGF0YSBtb2RlbHM8YnI+ DQomZ3Q7IGZvciBwcm90b2NvbCBpbmRlcGVuZGVudCBzZXJ2aWNlcyBhcmU6PGJyPg0KJmd0Ozxi cj4NCiZndDsgLSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtaWV0Zi1p MnJzLXJpYi1kYXRhLW1vZGVsLTAwPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt aTJycy1yaWItZGF0YS1tb2RlbC88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IC0mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpbHRlci1CYXNlZCBSSUJTOiZuYnNwOyBkcmFm dC1raW5pLWkycnMtZmItcmliLWRhdGEtbW9kZWwuMDA8YnI+DQomZ3Q7IChyZWxlYXNlZCBsYXRl ciB0aGlzIHdlZWspPGJyPg0KJmd0Ozxicj4NCiZndDsgLSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgVG9wb2xvZ3kgbW9kZWwgd2hpY2ggaXMgYSBjb21wb3NpdGUgb2Y6PGJyPg0K Jmd0Ozxicj4NCiZndDsgbyZuYnNwOyAmbmJzcDtHZW5lcmljIHRvcG9sb2d5IG1vZGVsOiBkcmFm dC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8tMDE8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3 b3JrLXRvcG8vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLzwvYT4mZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgbyZuYnNwOyAmbmJzcDtMMyB0b3BvbG9neSBtb2RlbDogZHJhZnQtaWV0Zi1pMnJz LXlhbmctbDMtdG9wb2xvZ3ktMDA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS8iIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWkycnMteWFuZy1sMy10b3BvbG9neS88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IG8mbmJz cDsgJm5ic3A7TDIgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdv cmstdG9wb2xvZ3ktMDA8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWky cnMteWFuZy1sMi1uZXR3b3JrLXRvcG88L2E+PGJyPg0KJmd0OyBsb2d5LyZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBvJm5ic3A7ICZuYnNwO0wxIFRvcG9sb2d5IG1vZGVsOiBkcmFmdC16aGFuZy1p MnJzLWwxLXRvcG8teWFuZy1tb2RlbC0wMSAoLTAyPGJyPg0KJmd0OyByZWxlYXNlZCBsYXRlciB0 aGlzIHdlZWspLjxicj4NCiZndDs8YnI+DQomZ3Q7IG8mbmJzcDsgJm5ic3A7U2VydmljZSB0b3Bv bG9neSBtb2RlbDo8YnI+DQomZ3Q7IGRyYWZ0LWhhcmVzLWkycnMtc2VydmljZS10b3BvLXlhbmct bW9kZWwtMDAgKHJlbGVhc2VkIG9uIFdlZG5lc2RheSk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7IEF0IHRoaXMgdGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxz IHV0aWxpemUgVHJhZmZpYyBlbmdpbmVlcmluZy48YnI+DQomZ3Q7IEl0IGlzIGFudGljaXBhdGVk IHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3VwcG9ydCB0cmFmZmljIGVuZ2luZWVyaW5nLjxicj4N CiZndDsgRXN0aW1hdGVkIHJhdGVzIG9mIHRyYW5zZmVyIGFuZCB0aW1pbmcgcmVxdWlyZW1lbnRz IGZvciB0aGVzZSBtb2R1bGVzPGJyPg0KJmd0OyBhcmUgYXQ6IDxhIGhyZWY9Imh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL2kycnMvdHJhYy93aWtpIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw Oi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pMnJzL3RyYWMvd2lraTwvYT4gLSB1bmRlciB0aGU8 YnI+DQomZ3Q7IHByb3RvY29sIHJlcXVpcmVtZW50cyB0YWJsZS48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGhvcGUgdGhhdCBORVRDT05GIFdHIGNhbiBwcm92aWRl IHNvbWUgaW5pdGlhbCBmZWVkYmFjayBvbiB0aGVzZTxicj4NCiZndDsgcmVxdWlyZW1lbnRzIGJ5 IElFVEYgOTMgYXQgdGhlIFR1ZXNkYXkgSTJSUyBzZXNzaW9uLiZuYnNwOyAmbmJzcDtJMlJTIHdp bGwgdXNlPGJyPg0KJmd0OyB0aGUgNi8yNCBpbnRlcmltIGF0IDEwOjAwLTExOjMwYW0gRVQmbmJz cDsgdG8gcHJvdmlkZSBhIHRpbWUgZm9yIGFueTxicj4NCiZndDsgcGFydGljaXBhdGUgaW4gdGhl IEkyUlMsIG5ldGNvbmYsIG9yIG5ldG1vZCBncm91cCB0byBhc2sgYWRkaXRpb25hbDxicj4NCiZn dDsgcXVlc3Rpb25zIG9uIHRoZXNlIHJlcXVpcmVtZW50cy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IFN1ZSBIYXJlczxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgSW50ZXJpbSB0aW1lOiAxMDowMC0xMTozMGFtIEVUPGJyPg0KJmd0Ozxicj4N CiZndDsgRGF0ZSA2LzI0LzIwMTU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZWJleDo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJ RD1tNDI2MGJlZTdiZTYxY2IxN2IwMDA4YTNjNTIwNjlkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNDI2MGJlZTdiZTYxY2IxN2IwMDA4 YTNjNTIwNjlkPC9hPjxicj4NCiZndDsgMGY8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IGFnZW5kYTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IDEwOjAwIC0gMTA6MDUgLSBCYXNoIEFnZW5kYTxicj4NCiZndDs8YnI+DQomZ3Q7IDEwOjA1IC0g MTA6MjAtIC0mbmJzcDsgcmV2aWV3IG9mIHJlcXVpcmVtZW50cyBmcm9tPGJyPg0KJmd0Ozxicj4N CiZndDsgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMDxicj4NCiZndDs8YnI+DQom Z3Q7IGRyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy0wMjxicj4NCiZndDs8YnI+ DQomZ3Q7IGRyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHktMDM8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaW1pbmcgcmVxdWlyZW1lbnRzPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyAxMDoyMCAtIDEwOjMwJm5ic3A7ICZuYnNwOyBSZXZpZXcgb2YgcmVxdWlyZW1lbnRzIGZv ciBtdXR1YWwgYXV0aGVudGljYXRpb24sPGJyPg0KJmd0Ozxicj4NCiZndDsgYW5kIHRyYW5zYWN0 aW9uIGluJm5ic3A7IGRyYWZ0LWhhcmVzLWF1dGgtdHJhbnMtMDEgcmVxdWlyZW1lbnRzPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxMDozMC0gMTE6MzAmbmJzcDsgJm5i c3A7ICZuYnNwO09wZW4gZGlzY3Vzc2lvbiBmb3IgSTJSUyBSZXF1aXJlbWVudHM8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFByb2NlZWRpbmdzIGFuZCBzbGlkZXMgY2Fu IGJlIGZvdW5kIGF0Ojxicj4NCiZndDs8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzA2LzI0L2kycnMvcHJvY2VlZGluZ3MuaHQi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJp bS8yMDE1LzA2LzI0L2kycnMvcHJvY2VlZGluZ3MuaHQ8L2E+PGJyPg0KJmd0OyBtbDxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgU3VlIEhhcmVzPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7IFJ0Zy15YW5nLWNvb3JkIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0i bWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIj5SdGcteWFuZy1jb29yZEBpZXRmLm9yZzwv YT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnRnLXlhbmctY29vcmQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmky cnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmkycnNAaWV0Zi5vcmciPmkycnNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pMnJzPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KaTJycyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DBC595ED2346914F9F81D17DD5C32B571DBD4C6Axmbrcdx05ciscoc_-- From nobody Thu Jul 2 14:04:02 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1801A0266; Thu, 2 Jul 2015 14:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to04q0UljmoK; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) 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 3AD161A038D; Thu, 2 Jul 2015 14:04:00 -0700 (PDT) Received: by pactm7 with SMTP id tm7so45867066pac.2; Thu, 02 Jul 2015 14:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=B2aatS6Q2+3086S98M3ZVrpdLWDlq3Q3nEuxtuWo2a8=; b=MhlecoPhng17aOir3fnn3BYHI2TH/Jibmyn+rd1ygg0/Zpo+kgU1/Zm/BJu+duK/60 fpwabbHI9GQ3Kx4Iet6kzyOXocAbRvF9W8qSf7BYujgcb89gcBfnMg61CjQDPZ78aLdS fsogZnswq8MbjSH9GNQJuAE1CFznUFfRqmLDKl65R8Wt+R91EdP9iv52SWWA574ScD7f EDHxY3gCj3Ixt4z3wJ2XWemxiKMSDJ+h+NSe6Rk5tnBRldpqfnKuzAkfX2AUU7if7msC gGNepSmrSt2S6K+qeECyoq0Y93Js7iHcVTMYmcRCYySFM2nNzB6VVuaSPBaOLgvtE4BK eTeA== X-Received: by 10.66.121.230 with SMTP id ln6mr13230571pab.17.1435871039973; Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Received: from ?IPv6:2001:420:302:1330:7197:4184:582e:ba8f? ([2001:420:302:1330:7197:4184:582e:ba8f]) by mx.google.com with ESMTPSA id mk6sm6691816pab.9.2015.07.02.14.03.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Jul 2015 14:03:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 2 Jul 2015 14:06:00 -0700 Message-Id: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> To: "Eric Voit (evoit)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , NETMOD Working Group , "BRUNGARD, DEBORAH A" , "Alexander Clemm \(alex\)" , Netconf , Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:04:01 -0000 --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) = wrote: >=20 > What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2= =80=9D are met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. =46rom a = personal perspective it would certainly help to have examples of how the = requirements could be met. Cheers. Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

What might be = interesting for a NETCONF speaking slot is an analysis of what = requirements from =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D = are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. 

Susan or somebody from i2rs WG can = decide whether the suggested presentation would help clarify i2rs = requirements to NETCONF. =46rom a personal perspective it would = certainly help to have examples of how the requirements could be = met.

Cheers.

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_5BBBA6F1-E9BC-4EBB-96F5-E6C81B213A59-- From nobody Thu Jul 2 14:06:46 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA01A1A59; Thu, 2 Jul 2015 14:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Skv4ZI2vbl91; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 253CC1A1A78; Thu, 2 Jul 2015 14:06:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" , "'Eric Voit \(evoit\)'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> In-Reply-To: <1AA8FB3B-E17A-4DEC-9F06-1424A0638500@gmail.com> Date: Thu, 2 Jul 2015 17:06:41 -0400 Message-ID: <01d801d0b50a$feeed5f0$fccc81d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D9_01D0B4E9.77DEBC90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCCiG/twIuXbN7nP05VtA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , "'Alexander Clemm \(alex\)'" , 'Netconf' Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2015 21:06:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani Sent: Thursday, July 02, 2015 5:06 PM To: Eric Voit (evoit) Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; = BRUNGARD, DEBORAH A; Alexander Clemm (alex); Netconf; Susan Hares Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS = protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 =20 On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) wrote: =20 What might be interesting for a NETCONF speaking slot is an analysis of = what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D.=20 =20 Susan or somebody from i2rs WG can decide whether the suggested = presentation would help clarify i2rs requirements to NETCONF. From a = personal perspective it would certainly help to have examples of how the = requirements could be met. =20 Cheers. =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_01D9_01D0B4E9.77DEBC90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

I think this would really help show how the requirements can be met. = Let=E2=80=99s plan on Eric doing an analysis of what requirements are = met by =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. =

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mahesh = Jethanandani
Sent: Thursday, July 02, 2015 5:06 = PM
To: Eric Voit (evoit)
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; NETMOD Working Group; BRUNGARD, = DEBORAH A; Alexander Clemm (alex); Netconf; Susan = Hares
Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

 

On Jun 30, 2015, at 3:13 PM, Eric Voit (evoit) <evoit@cisco.com> = wrote:

 

What might be interesting for a NETCONF speaking slot is an analysis = of what requirements from = =E2=80=9Cdraft-ietf-i2rs-pub-sub-requirements=E2=80=9D are met by = =E2=80=9Cdraft-clemm-netconf-yang-push=E2=80=9D. <= /p>

 

Susan or somebody from i2rs WG can decide whether the = suggested presentation would help clarify i2rs requirements to NETCONF. = >From a personal perspective it would certainly help to have examples of = how the requirements could be met.

 

Cheers.

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_01D9_01D0B4E9.77DEBC90-- From nobody Fri Jul 3 11:29:30 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC8A1B2AFB; Thu, 2 Jul 2015 20:47:02 -0700 (PDT) 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 uxnI8QmQojj8; Thu, 2 Jul 2015 20:46:58 -0700 (PDT) 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 77AFA1B2AF5; Thu, 2 Jul 2015 20:46:56 -0700 (PDT) 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 BYH03848; Fri, 03 Jul 2015 03:46:54 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 3 Jul 2015 04:46:52 +0100 Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.3]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Fri, 3 Jul 2015 11:46:46 +0800 From: "Zhangxian (Xian)" To: Susan Hares , Vishnu Pavan Beeram , Lou Berger , "draft-ietf-teas-yang-te-topo@tools.ietf.com" Thread-Topic: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQHQtPdaRDUuJqKhTEyx6qkBpmxcw53JGWEg Date: Fri, 3 Jul 2015 03:46:46 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.104.209] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B471E1803SZXEMA512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 11:29:28 -0700 Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , "BRUNGARD, DEBORAH A" , "alex@cisco.com" , Alia Atlas , Jeffrey Haas , "Alvaro Retana \(aretana\)" Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 03:47:02 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471E1803SZXEMA512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCiAgIEkgd291bGQgZWNobyB3aGF0IExvdSBzYWlkIGluIGFub3RoZXIgZW1haWw6DQoN CuKAnFdlIHNob3VsZCBwcm9iYWJseSBhbm5vdW5jZSB0aGUgdGltZSBhbmQgcGxhY2Ugd2hlcmUg dGhlIGF1dGhvcnMgd2lsbCBiZSBtZWV0aW5nIGluIFByYWd1ZSBzbyB0aGF0IG90aGVycyB3aG8g YXJlIGludGVyZXN0ZWQgY2FuIHNob3cu4oCdDQoNCkkgYW0gZGVmaW5pdGVseSBpbnRlcmVzdGVk Lg0KDQpBbm90aGVyIHN1Z2dlc3Rpb24gaXM6IGNhbiB3ZSB0cnkgdG8gZHJhdyBhIHJlbGF0aW9u c2hpcCBkaWFncmFtIHRvIHNlZSBob3cgdGhlIHRvcG9sb2d5IHJlbGF0ZWQgbW9kZWxzIGZpdHMg dG9nZXRoZXIgKGlycmVzcGVjdGl2ZSBvZiB3aGljaCBXRyBzaG91bGQgd29yayBvbiB3aGF0KT8g SW4gdGhlIDxuZXR3b3JrLXRvcG8tbW9kZWw+IGRyYWZ0LCB0aGVyZSBpcyBhbHJlYWR5IGEgZGlh Z3JhbSB3aGljaCBtaWdodCBiZSBoZWxwZnVsIGFzIGEgc3RhcnRpbmcgcG9pbnQuDQoNClJlZ2Fy ZHMsDQpYaWFuDQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBWaXNobnUgUGF2YW4gQmVlcmFtDQpTZW50OiAyMDE15bm0N+aciDLml6UgODo0 Mg0KVG86IFN1c2FuIEhhcmVzDQpDYzogUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0 Zi5vcmc7IEJSVU5HQVJELCBERUJPUkFIIEE7IGFsZXhAY2lzY28uY29tOyBWaXNobnUgUGF2YW4g QmVlcmFtOyBBbGlhIEF0bGFzOyBkcmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvQHRvb2xzLmll dGYuY29tOyBKZWZmcmV5IEhhYXM7IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBMb3UgQmVyZ2Vy DQpTdWJqZWN0OiBSZTogW2kycnNdIFtSdGcteWFuZy1jb29yZF0gUmVxdWlyZW1lbnRzIGZvciBJ MlJTIHByb3RvY29sIGFuZCBJMlJTIGludGVyaW0gKDYvMjQvMjAxNSBhdCAxMDowMCAtIDExOjMw YW0gRVQpDQoNCisgQWxleA0KKyA8dGUtdG9wby1tb2RlbD4gYXV0aG9ycw0KU3VlLCBKZWZmLA0K VGhlIGF1dGhvcnMgb2YgdGhlIDx0ZS10b3BvLW1vZGVsPiBkcmFmdCBoYWQgYSBtZWV0aW5nIHRv ZGF5IHdpdGggb25lIG9mIHRoZSBhdXRob3JzIChBbGV4KSBvZiB0aGUgPG5ldHdvcmstdG9wby1t b2RlbD4gZHJhZnQgYW5kIGRpc2N1c3NlZCB3YXlzIHRvIGFsaWduIHRoZSB0b3BvIG1vZGVscy4g VGhlIGNvbnNlbnN1cyBzbyBmYXIgaXMgdGhhdCB0aGUgPHRlLXRvcG8tbW9kZWw+IFdJTEwgYXVn bWVudCB0aGUgPG5ldHdvcmstdG9wby1tb2RlbD4uIFRoZXJlIGFyZSBzb21lIGlzc3VlcyB0aGF0 IG5lZWQgdG8gYmUgd29ya2VkIG91dCAobWFwcGluZyBpZGVudGlmaWVycywgdGVybWluYXRpb24t cG9pbnRzKSwgYnV0IHRob3NlIHNob3VsZCBnZXQgcmVzb2x2ZWQgaW4gZHVlIGNvdXJzZSBvZiB0 aW1lLg0KDQpJJ2xsIHN5bmMgdXAgd2l0aCB5b3UgKFN1ZSkgYW5kIGNvb3JkaW5hdGUgYSBtZWV0 aW5nIGJldHdlZW4gdGhlIGF1dGhvcnMgb2YgdGhlIDx0ZS10b3BvLW1vZGVsPiBhbmQgdGhlIGF1 dGhvcnMgb2YgdGhlIEkyUlMgdG9wbyBtb2RlbChzKSBhdCB0aGUgSUVURiAtLS0gaG9wZWZ1bGx5 IGVhcmx5IGluIHRoZSB3ZWVrLg0KUmVnYXJkcywNCi1QYXZhbg0KDQpPbiBXZWQsIEp1bCAxLCAy MDE1IGF0IDY6NDkgUE0sIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJl c0BuZHpoLmNvbT4+IHdyb3RlOg0KTG91IGFuZCBKZWZmcmV5Og0KDQpPbiA3LzIyLCBJIHRhbGtl ZCB3aXRoIHRoZSBURUFTIFRFIGF1dGhvcnMgdGVhbS4gIFRoZXkgaGFkIGNvbmNlcm5zIGFib3V0 DQpob3cgdGhlIEkyUlMgd2FzIGdvaW5nIHRvIGludGVncmF0ZSB0aGUgVEVBUyB3b3JrLiAgSSBy ZWFsaXplZCB0aGVyZSBhcmUgdHdvDQpkaWZmZXJlbnQgYXBwcm9hY2hlcyB0byB0aGUgbW9kZWxz IC0gYW5kIEkgZXhwcmVzc2VkIG15ICBob3BlIHRoYXQgd2UgY291bGQNCmhhdmUgYWxpZ25lZC9t ZXJnZWQgbW9kZWxzLiAgSSBjaGF0dGVkIHdpdGggdGhlIEkyUlMgdG9wb2xvZ3kgZHJhZnQgYXV0 aG9ycywNCmFuZCBJIGZvdW5kIHRoYXQgdGhlIGF1dGhvcnMgaGFkIG5vdCB5ZXQgYmVndW4gdG8g d29yayBvbiB0aGUgVEUgbW9kZWxzLg0KVGhlIGJlc3QgcGxhbiBpcyB0byB0cnkgdG8gZ2V0IHRo ZSBURUFTIGF1dGhvcnMgYW5kIHRoZSBJMlJTIFRvcG9sb2d5DQphdXRob3JzIHRvZ2V0aGVyIGF0 IElFVEYgOTMgYW5kIGdldCBhIHBsYW4gdG9nZXRoZXIgZm9yIG1pZ3JhdGluZyB0aGVzZQ0KdGVh bXMgdG9nZXRoZXIuDQoNCkkgd2lsbCBzZW5kIGEgZmV3IHRpbWVzIG91dCB0byB0ZWFtcyB0aGlz IGV2ZW5pbmcuICAgSXQgd291bGQgcmVhbGx5IGhlbHANCkkyUlMgaWYgdGhlIFRFQVMgZ3JvdXAg d291bGQgbWVldCBlYXJseSBpbiB0aGUgd2VlayAob3IgaWYgdGhlIGZvbGtzIGFyZSBhdA0KdGhl IGhhY2stYXRob24gbGlrZSBJIGFtIHdlIG1heSBtZWV0IFNhdHVyZGF5IG5pZ2h0KS4gIFdlIGNv dWxkIHRoZW4gdHJ5IHRvDQpnaXZlIE5FVENPTkYgb3VyIGJlc3QgaW5zaWdodCBvbiB0aGUgVEUg YWRkaXRpb25zLg0KDQogSW4gb3JkZXIgdG8gcHJlcGFyZSBmb3IgdGhpcyBURS9Ob24tVEUgbWVy Z2UsIEkyUlMgV0cgbmVlZCB0byBmaW5hbGl6ZSB0aGUNCm5vbi1URSBtb2RlbHMgaW4gdGhlIHRv cG9sb2d5LiAgVG9kYXkncyBpbnRlcmltIHdhcyB0YXJnZXQgdG8gZmlybSB1cCB0aGUNClNlcnZp Y2UgYW5kIFQxIHRvcG9sb2d5IG1vZGVscywgYnV0IHRoZSBUMSB0b3BvbG9neSBtb2RlbCB3aWxs IG5vdCBiZSByZWFkeQ0KdW50aWwgSUVURiA5My4gIE15IG1lc3NhZ2UgaW4gSnVuZSBob3BlZCB0 aGF0IHdlIHdvdWxkIGJlIHRvIHRoZSBURSBtb2RlbHMNCmJ5IElFVEYgc28gdGhhdCBORVRDT05G IHdvdWxkIGhhdmUgb3VyIGVudGlyZSBzY29wZSwgYnV0IHdlIHdpbGwgbm90IGJlDQp0aGVyZSBi eSB0aGUgYmVnaW5uaW5nIG9mIElFVEYuICAgSTJSUyB3aWxsIGJlIGZvbGxvd2luZyB1cCBpbiBB dWd1c3QgYW5kDQpTZXB0ZW1iZXIgd2l0aCBJbnRlcmltcyB0aGF0IGZvY3VzIG9uIHRoZSBURSBt b2RlbHMgaW4gSTJSUyBUb3BvbG9neSBtb2RlbC4NCg0KRG8geW91IGhhdmUgYW55IG90aGVyIHN1 Z2dlc3Rpb25zPw0KDQpTdWUNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aTJycyBbbWFpbHRvOmkycnMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86aTJycy1ib3VuY2VzQGll dGYub3JnPl0gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINClNlbnQ6IFdlZG5lc2RheSwgSnVseSAw MSwgMjAxNSAxMTozOSBBTQ0KVG86IFN1c2FuIEhhcmVzOyAnSmVmZnJleSBIYWFzJw0KQ2M6IFJ0 Zy15YW5nLWNvb3JkQGlldGYub3JnPG1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZz47IGky cnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+OyAnQlJVTkdBUkQsIERFQk9SQUggQSc7 IFZpc2hudQ0KUGF2YW4gQmVlcmFtOyAnQWx2YXJvIFJldGFuYSAoYXJldGFuYSknOyAnQWxpYSBB dGxhcycNClN1YmplY3Q6IFJlOiBbaTJyc10gW1J0Zy15YW5nLWNvb3JkXSBSZXF1aXJlbWVudHMg Zm9yIEkyUlMgcHJvdG9jb2wgYW5kIEkyUlMNCmludGVyaW0gKDYvMjQvMjAxNSBhdCAxMDowMCAt IDExOjMwYW0gRVQpDQo+IEF0IHRoaXMgdGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxz IHV0aWxpemUgVHJhZmZpYw0KZW5naW5lZXJpbmcuICBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRo ZXNlIG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZpYw0KZW5naW5lZXJpbmcuDQoNClN1ZSwgSmVm ZiwNCiAgICBHaXZlbiBzb21lIHJlY2VudCBtZXNzYWdlcyBvbiB0aGUgbGlzdCwgSSB0aG91Z2h0 IGl0IGJlc3QgdG8gY29uZmlybQ0Kd2UncmUgYWxsIHN0aWxsIG9uIHRoZSBzYW1lIHBhZ2UuDQoN CkJhc2VkIG9uIG91ciBwYXN0IGRpc2N1c3Npb25zLCBpdCdzIG15IHVuZGVyc3RhbmRpbmcgdGhh dCB0aGUgd29yayBiZWluZw0KZG9uZSBpbiBURUFTIChzZWUgZHJhZnQtaWV0Zi10ZWFzLXlhbmct dGUtdG9wbykgd2lsbCBzZXJ2ZSBhcyB0aGUgZm91bmRhdGlvbg0KZm9yIFRFIHN1cHBvcnQgaW4g dGhlIEkyUlMgbW9kZWxzLiAgSSBjb21wbGV0ZSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBkZXRhaWxz DQpvbiBob3cgdGhlIGRpZmZlcmVudCB0b3BvbG9neSBtb2RlbHMgd2lsbCBpbnRlZ3JhdGUvbWVz aCBzdGlsbCBuZWVkcyB0byBiZQ0Kd29ya2VkIG91dCwgYW5kIEkgYXNzdW1lZCB0aGF0IHRoaXMg aXMgd2hhdCB5b3UvU3VlIHdlcmUgcmVmZXJyaW5nIHRvIGFib3ZlLg0KLS0gQnV0IHdlIHdpbGwg bm90IGhhdmUgdHdvIHNldHMgb2YgVEUgdG9wb2xvZ3kgbW9kZWxzLg0KDQpJIGJlbGlldmUgdGhh dCB0aGUgYXV0aG9ycyBvZiB0aGUgcmVzcGVjdGl2ZSBkcmFmdHMgYXJlIGFscmVhZHkgYXJlIHdv cmtpbmcNCnRoaXMuICAoUGF2YW4sIG15IGNvLWNoYWlyIGFzIHdlbGwgYXMgY29hdXRob3Igb2Yg dGhlIFRFQVMgeWFuZyBtb2RlbCwgY2FuDQpjb21tZW50IG9uIHRoaXMuKQ0KDQpQbGVhc2UgbGV0 IG1lIGtub3cgaWYgSSBtaXNzZWQvbWlzcy11bmRlcnN0b29kIHNvbWV0aGluZy4NCg0KVGhhbmtz LA0KTG91DQooYXMgVEVBUyBXRyBjby1jaGFpcikNCk9uIDYvMjMvMjAxNSAyOjE5IFBNLCBTdXNh biBIYXJlcyB3cm90ZToNCj4NCj4gTmV0Y29uZiBXb3JraW5nIEdyb3VwOg0KPg0KPg0KPg0KPiBU aGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHBhc3MgeW91IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBm b3IgdGhlIEkyUlMNCj4gcHJvdG9jb2wsIGFuZCBhc2tzIHRoYXQgeW91IHByb3ZpZGUgYW4gYW5h bHlzaXMgYnkgSUVURiA5MyBvbiB3aGV0aGVyDQo+IE5FVENPTkYgb3IgUkVTVENPTkYgY2FuIG1l ZXQgdGhlc2UgcmVxdWlyZW1lbnRzLiAgIFdlIGV4cGVjdCB0aGF0DQo+IHRoZXNlIHJlcXVpcmVt ZW50cyBtYXkgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBvcg0KPiBSRVNU Q09ORi4NCj4NCj4NCj4NCj4gVGhlIEkyUlMgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IChkcmFmdC1p ZXRmLWkycnMtYXJjaGl0ZWN0dXJlLTA5DQo+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLz4pDQo+IHByb3ZpZGVzIGEgaGlnaC1s ZXZlbCBvdmVydmlldyBvZiB0aGUgSTJSUyAgcHJvdG9jb2wuICBUaGUgSTJSUyBoYXMNCj4gY29t cGlsZWQgdGhlIGZvbGxvd2luZyBkb2N1bWVudHMgdG8gcHJvdmlkZSB0aGUgYWRkaXRpb25hbCBk ZXRhaWxzIG9uDQo+IHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSBwcm90b2NvbHMuDQo+DQo+DQo+ DQo+IDEpICAgICAgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMA0KPiA8aHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0 ZS8+DQo+DQo+IDIpICAgICAgZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTAy DQo+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHVi LXN1Yi1yZXF1aXJlbWVudHMNCj4gLz4NCj4NCj4gMykgICAgICBkcmFmdC1pZXRmLWkycnMtdHJh Y2VhYmlsaXR5LTAzDQo+IDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLWkycnMtdHJhY2VhYmlsaXR5Lz4NCj4NCj4NCj4NCj4gVGhlIGRyYWZ0LWlldGYtaTJycy1l cGhlbWVyYWwtc3RhdGUtMDAgY29udGFpbnMgdGhlIHJlc3VsdHMgb2YgdGhlDQo+IGRpc2N1c3Np b24gZnJvbSB0aGUgNi8xMCBpbnRlcmltIGFuZCB0aGUgdG9wIDEwIHJlcXVpcmVtZW50cyBmb3Ig STJSUy4NCj4gSW4gYWRkaXRpb24sIHRoZSBkcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRl LTAwIGNvbnRhaW5zIGFuIHNldCBvZg0KPiBkZXRhaWxlZCByZXF1aXJlbWVudHMgb24gaG93IHRo ZSBJMlJTIFdHIHNlZXMgdGhlIEkyUlMgcHJvdG9jb2wNCj4gb3BlcmF0aW5nLiAgVGhlc2UgZGV0 YWlsZWQgcmVxdWlyZW1lbnRzIGFyZSB0byBiZSBzZWVuIGFzIHN1Z2dlc3Rpb25zDQo+IG9uIHdo YXQgdHlwZSBvZiBzb2x1dGlvbiB0aGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHNlZSwgYnV0IEky UlMgV0cgaXMNCj4gYXNraW5nIHRoZSBORVRDT05GIFdHIHRvIHByb3ZpZGUgaXRzIGJlc3QgZGVz aWduZWQgcHJvdG9jb2wuICBQbGVhc2UNCj4gbm90ZSBhcyBwYXJ0IG9mIHRoZXNlIGRldGFpbGVk IHJlcXVpcmVtZW50IHRoZQ0KPiBkcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlcy0wMCBj b250YWlucyB0aGUgaWRlYSBvZiB1c2luZw0KPiBtZXRhZGF0YSB0byByZWNvcmQgc2Vjb25kYXJ5 IGlkZW50aXR5Lg0KPg0KPg0KPg0KPiBUaGUgSTJSUyBwcm90b2NvbCBpcyBkcml2ZW4gYnkgZGF0 YS1tb2RlbHMuICBUaGUgYXBwcm92ZWQgZGF0YSBtb2RlbHMNCj4gZm9yIHByb3RvY29sIGluZGVw ZW5kZW50IHNlcnZpY2VzIGFyZToNCj4NCj4gLSAgICAgICAgICBkcmFmdC1pZXRmLWkycnMtcmli LWRhdGEtbW9kZWwtMDANCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8+DQo+DQo+IC0gICAgICAgICAgRmlsdGVyLUJhc2Vk IFJJQlM6ICBkcmFmdC1raW5pLWkycnMtZmItcmliLWRhdGEtbW9kZWwuMDANCj4gKHJlbGVhc2Vk IGxhdGVyIHRoaXMgd2VlaykNCj4NCj4gLSAgICAgICAgICBUb3BvbG9neSBtb2RlbCB3aGljaCBp cyBhIGNvbXBvc2l0ZSBvZjoNCj4NCj4gbyAgIEdlbmVyaWMgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0 LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9wby0wMQ0KPiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLz4NCj4NCj4gbyAg IEwzIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0wMA0K PiA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmct bDMtdG9wb2xvZ3kvPg0KPg0KPiBvICAgTDIgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJy cy15YW5nLWwyLW5ldHdvcmstdG9wb2xvZ3ktMDANCj4gPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wbw0KPiBsb2d5Lz4N Cj4NCj4gbyAgIEwxIFRvcG9sb2d5IG1vZGVsOiBkcmFmdC16aGFuZy1pMnJzLWwxLXRvcG8teWFu Zy1tb2RlbC0wMSAoLTAyDQo+IHJlbGVhc2VkIGxhdGVyIHRoaXMgd2VlaykuDQo+DQo+IG8gICBT ZXJ2aWNlIHRvcG9sb2d5IG1vZGVsOg0KPiBkcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2UtdG9wby15 YW5nLW1vZGVsLTAwIChyZWxlYXNlZCBvbiBXZWRuZXNkYXkpDQo+DQo+DQo+DQo+IEF0IHRoaXMg dGltZSwgbm9uZSBvZiB0aGUgVG9wb2xvZ3kgbW9kZWxzIHV0aWxpemUgVHJhZmZpYyBlbmdpbmVl cmluZy4NCj4gSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGVzZSBtb2RlbHMgd2lsbCBzdXBwb3J0 IHRyYWZmaWMgZW5naW5lZXJpbmcuDQo+IEVzdGltYXRlZCByYXRlcyBvZiB0cmFuc2ZlciBhbmQg dGltaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlc2UgbW9kdWxlcw0KPiBhcmUgYXQ6IGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2kycnMvdHJhYy93aWtpIC0gdW5kZXIgdGhlDQo+IHByb3Rv Y29sIHJlcXVpcmVtZW50cyB0YWJsZS4NCj4NCj4NCj4NCj4gV2UgaG9wZSB0aGF0IE5FVENPTkYg V0cgY2FuIHByb3ZpZGUgc29tZSBpbml0aWFsIGZlZWRiYWNrIG9uIHRoZXNlDQo+IHJlcXVpcmVt ZW50cyBieSBJRVRGIDkzIGF0IHRoZSBUdWVzZGF5IEkyUlMgc2Vzc2lvbi4gICBJMlJTIHdpbGwg dXNlDQo+IHRoZSA2LzI0IGludGVyaW0gYXQgMTA6MDAtMTE6MzBhbSBFVCAgdG8gcHJvdmlkZSBh IHRpbWUgZm9yIGFueQ0KPiBwYXJ0aWNpcGF0ZSBpbiB0aGUgSTJSUywgbmV0Y29uZiwgb3IgbmV0 bW9kIGdyb3VwIHRvIGFzayBhZGRpdGlvbmFsDQo+IHF1ZXN0aW9ucyBvbiB0aGVzZSByZXF1aXJl bWVudHMuDQo+DQo+DQo+DQo+IFN1ZSBIYXJlcw0KPg0KPg0KPg0KPiBJbnRlcmltIHRpbWU6IDEw OjAwLTExOjMwYW0gRVQNCj4NCj4gRGF0ZSA2LzI0LzIwMTUNCj4NCj4gV2ViZXg6DQo+DQo+IGh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MjYwYmVlN2JlNjFjYjE3YjAw MDhhM2M1MjA2OWQNCj4gMGYNCj4NCj4NCj4NCj4gYWdlbmRhOg0KPg0KPg0KPg0KPiAxMDowMCAt IDEwOjA1IC0gQmFzaCBBZ2VuZGENCj4NCj4gMTA6MDUgLSAxMDoyMC0gLSAgcmV2aWV3IG9mIHJl cXVpcmVtZW50cyBmcm9tDQo+DQo+IGRyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDAN Cj4NCj4gZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTAyDQo+DQo+IGRyYWZ0 LWlldGYtaTJycy10cmFjZWFiaWxpdHktMDMNCj4NCj4gVGltaW5nIHJlcXVpcmVtZW50cw0KPg0K Pg0KPg0KPiAxMDoyMCAtIDEwOjMwICAgIFJldmlldyBvZiByZXF1aXJlbWVudHMgZm9yIG11dHVh bCBhdXRoZW50aWNhdGlvbiwNCj4NCj4gYW5kIHRyYW5zYWN0aW9uIGluICBkcmFmdC1oYXJlcy1h dXRoLXRyYW5zLTAxIHJlcXVpcmVtZW50cw0KPg0KPg0KPg0KPiAxMDozMC0gMTE6MzAgICAgIE9w ZW4gZGlzY3Vzc2lvbiBmb3IgSTJSUyBSZXF1aXJlbWVudHMNCj4NCj4NCj4NCj4gUHJvY2VlZGlu Z3MgYW5kIHNsaWRlcyBjYW4gYmUgZm91bmQgYXQ6DQo+DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1LzA2LzI0L2kycnMvcHJvY2VlZGluZ3MuaHQNCj4gbWwN Cj4NCj4NCj4NCj4gU3VlIEhhcmVzDQo+DQo+DQo+DQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJ0Zy15YW5nLWNvb3JkIG1h aWxpbmcgbGlzdA0KPiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRnLXlhbmctY29v cmRAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRn LXlhbmctY29vcmQNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaTJycyBtYWlsaW5nIGxpc3QNCmkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmkycnMgbWFpbGlu ZyBsaXN0DQppMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471E1803SZXEMA512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmltDQoJe21zby1zdHlsZS1uYW1lOmltO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpI LUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBJIHdvdWxkIGVjaG8gd2hhdCBMb3Ugc2FpZCBpbiBhbm90 aGVyIGVtYWlsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPldlIHNob3VsZCBwcm9iYWJseSBhbm5vdW5jZSB0aGUgdGltZSBh bmQgcGxhY2Ugd2hlcmUgdGhlIGF1dGhvcnMgd2lsbCBiZSBtZWV0aW5nIGluIFByYWd1ZSBzbyB0 aGF0IG90aGVycyB3aG8gYXJlIGludGVyZXN0ZWQNCiBjYW4gc2hvdy7igJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkkgYW0gZGVmaW5pdGVseSBpbnRlcmVzdGVkLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6NS4yNXB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFub3RoZXIg c3VnZ2VzdGlvbiBpczogY2FuIHdlIHRyeSB0byBkcmF3IGEgcmVsYXRpb25zaGlwIGRpYWdyYW0g dG8gc2VlIGhvdyB0aGUgdG9wb2xvZ3kgcmVsYXRlZCBtb2RlbHMgZml0cyB0b2dldGhlcg0KIChp cnJlc3BlY3RpdmUgb2Ygd2hpY2ggV0cgc2hvdWxkIHdvcmsgb24gd2hhdCk/IEluIHRoZSAmbHQ7 bmV0d29yay10b3BvLW1vZGVsJmd0OyBkcmFmdCwgdGhlcmUgaXMgYWxyZWFkeSBhIGRpYWdyYW0g d2hpY2ggbWlnaHQgYmUgaGVscGZ1bCBhcyBhIHN0YXJ0aW5nIHBvaW50Lg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPGJyPg0KWGlhbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaTJycyBbbWFpbHRvOmkycnMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VmlzaG51IFBhdmFuIEJlZXJh bTxicj4NCjxiPlNlbnQ6PC9iPiAyMDE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij43 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7mnIg8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCiA4OjQyPGJyPg0KPGI+VG86PC9iPiBTdXNhbiBIYXJlczxicj4NCjxiPkNjOjwv Yj4gUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7IEJSVU5HQVJELCBERUJP UkFIIEE7IGFsZXhAY2lzY28uY29tOyBWaXNobnUgUGF2YW4gQmVlcmFtOyBBbGlhIEF0bGFzOyBk cmFmdC1pZXRmLXRlYXMteWFuZy10ZS10b3BvQHRvb2xzLmlldGYuY29tOyBKZWZmcmV5IEhhYXM7 IEFsdmFybyBSZXRhbmEgKGFyZXRhbmEpOyBMb3UgQmVyZ2VyPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbaTJyc10gW1J0Zy15YW5nLWNvb3JkXSBSZXF1aXJlbWVudHMgZm9yIEkyUlMgcHJvdG9j b2wgYW5kIEkyUlMgaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAwIC0gMTE6MzBhbSBFVCk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsgQWxleDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiYjNDM7ICZs dDt0ZS10b3BvLW1vZGVsJmd0OyBhdXRob3JzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+U3VlLCBKZWZmLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGF1dGhvcnMgb2YgdGhlICZsdDt0ZS10b3BvLW1vZGVsJmd0 OyBkcmFmdCBoYWQgYSBtZWV0aW5nIHRvZGF5IHdpdGggb25lIG9mIHRoZSBhdXRob3JzIChBbGV4 KSBvZiB0aGUgJmx0O25ldHdvcmstdG9wby1tb2RlbCZndDsgZHJhZnQgYW5kIGRpc2N1c3NlZCB3 YXlzIHRvIGFsaWduIHRoZSB0b3BvIG1vZGVscy4gVGhlIGNvbnNlbnN1cyBzbw0KIGZhciBpcyB0 aGF0IHRoZSAmbHQ7dGUtdG9wby1tb2RlbCZndDsgV0lMTCBhdWdtZW50IHRoZSAmbHQ7bmV0d29y ay10b3BvLW1vZGVsJmd0Oy4gVGhlcmUgYXJlIHNvbWUgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSB3 b3JrZWQgb3V0IChtYXBwaW5nIGlkZW50aWZpZXJzLCB0ZXJtaW5hdGlvbi1wb2ludHMpLCBidXQg dGhvc2Ugc2hvdWxkIGdldCByZXNvbHZlZCBpbiBkdWUgY291cnNlIG9mIHRpbWUuDQo8YnI+DQo8 YnI+DQpJJ2xsIHN5bmMgdXAgd2l0aCB5b3UgKFN1ZSkgYW5kIGNvb3JkaW5hdGUgYSBtZWV0aW5n IGJldHdlZW4gdGhlIGF1dGhvcnMgb2YgdGhlICZsdDt0ZS10b3BvLW1vZGVsJmd0OyBhbmQgdGhl IGF1dGhvcnMgb2YgdGhlIEkyUlMgdG9wbyBtb2RlbChzKSBhdCB0aGUgSUVURiAtLS0gaG9wZWZ1 bGx5IGVhcmx5IGluIHRoZSB3ZWVrLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPi1QYXZhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk9uIFdlZCwgSnVsIDEsIDIwMTUgYXQgNjo0OSBQTSwgU3VzYW4gSGFyZXMgJmx0 OzxhIGhyZWY9Im1haWx0bzpzaGFyZXNAbmR6aC5jb20iIHRhcmdldD0iX2JsYW5rIj5zaGFyZXNA bmR6aC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Mb3UgYW5kIEplZmZyZXk6PGJyPg0KPGJyPg0KT24gNy8yMiwgSSB0YWxrZWQgd2l0aCB0aGUg VEVBUyBURSBhdXRob3JzIHRlYW0uJm5ic3A7IFRoZXkgaGFkIGNvbmNlcm5zIGFib3V0PGJyPg0K aG93IHRoZSBJMlJTIHdhcyBnb2luZyB0byBpbnRlZ3JhdGUgdGhlIFRFQVMgd29yay4mbmJzcDsg SSByZWFsaXplZCB0aGVyZSBhcmUgdHdvPGJyPg0KZGlmZmVyZW50IGFwcHJvYWNoZXMgdG8gdGhl IG1vZGVscyAtIGFuZCBJIGV4cHJlc3NlZCBteSZuYnNwOyBob3BlIHRoYXQgd2UgY291bGQ8YnI+ DQpoYXZlIGFsaWduZWQvbWVyZ2VkIG1vZGVscy4mbmJzcDsgSSBjaGF0dGVkIHdpdGggdGhlIEky UlMgdG9wb2xvZ3kgZHJhZnQgYXV0aG9ycyw8YnI+DQphbmQgSSBmb3VuZCB0aGF0IHRoZSBhdXRo b3JzIGhhZCBub3QgeWV0IGJlZ3VuIHRvIHdvcmsgb24gdGhlIFRFIG1vZGVscy48YnI+DQpUaGUg YmVzdCBwbGFuIGlzIHRvIHRyeSB0byBnZXQgdGhlIFRFQVMgYXV0aG9ycyBhbmQgdGhlIEkyUlMg VG9wb2xvZ3k8YnI+DQphdXRob3JzIHRvZ2V0aGVyIGF0IElFVEYgOTMgYW5kIGdldCBhIHBsYW4g dG9nZXRoZXIgZm9yIG1pZ3JhdGluZyB0aGVzZTxicj4NCnRlYW1zIHRvZ2V0aGVyLjxicj4NCjxi cj4NCkkgd2lsbCBzZW5kIGEgZmV3IHRpbWVzIG91dCB0byB0ZWFtcyB0aGlzIGV2ZW5pbmcuJm5i c3A7ICZuYnNwO0l0IHdvdWxkIHJlYWxseSBoZWxwPGJyPg0KSTJSUyBpZiB0aGUgVEVBUyBncm91 cCB3b3VsZCBtZWV0IGVhcmx5IGluIHRoZSB3ZWVrIChvciBpZiB0aGUgZm9sa3MgYXJlIGF0PGJy Pg0KdGhlIGhhY2stYXRob24gbGlrZSBJIGFtIHdlIG1heSBtZWV0IFNhdHVyZGF5IG5pZ2h0KS4m bmJzcDsgV2UgY291bGQgdGhlbiB0cnkgdG88YnI+DQpnaXZlIE5FVENPTkYgb3VyIGJlc3QgaW5z aWdodCBvbiB0aGUgVEUgYWRkaXRpb25zLjxicj4NCjxicj4NCiZuYnNwO0luIG9yZGVyIHRvIHBy ZXBhcmUgZm9yIHRoaXMgVEUvTm9uLVRFIG1lcmdlLCBJMlJTIFdHIG5lZWQgdG8gZmluYWxpemUg dGhlPGJyPg0Kbm9uLVRFIG1vZGVscyBpbiB0aGUgdG9wb2xvZ3kuJm5ic3A7IFRvZGF5J3MgaW50 ZXJpbSB3YXMgdGFyZ2V0IHRvIGZpcm0gdXAgdGhlPGJyPg0KU2VydmljZSBhbmQgVDEgdG9wb2xv Z3kgbW9kZWxzLCBidXQgdGhlIFQxIHRvcG9sb2d5IG1vZGVsIHdpbGwgbm90IGJlIHJlYWR5PGJy Pg0KdW50aWwgSUVURiA5My4mbmJzcDsgTXkgbWVzc2FnZSBpbiBKdW5lIGhvcGVkIHRoYXQgd2Ug d291bGQgYmUgdG8gdGhlIFRFIG1vZGVsczxicj4NCmJ5IElFVEYgc28gdGhhdCBORVRDT05GIHdv dWxkIGhhdmUgb3VyIGVudGlyZSBzY29wZSwgYnV0IHdlIHdpbGwgbm90IGJlPGJyPg0KdGhlcmUg YnkgdGhlIGJlZ2lubmluZyBvZiBJRVRGLiZuYnNwOyAmbmJzcDtJMlJTIHdpbGwgYmUgZm9sbG93 aW5nIHVwIGluIEF1Z3VzdCBhbmQ8YnI+DQpTZXB0ZW1iZXIgd2l0aCBJbnRlcmltcyB0aGF0IGZv Y3VzIG9uIHRoZSBURSBtb2RlbHMgaW4gSTJSUyBUb3BvbG9neSBtb2RlbC48YnI+DQo8YnI+DQpE byB5b3UgaGF2ZSBhbnkgb3RoZXIgc3VnZ2VzdGlvbnM/PGJyPg0KPGJyPg0KU3VlPGJyPg0KPGJy Pg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IGkycnMgW21haWx0bzo8YSBocmVmPSJtYWls dG86aTJycy1ib3VuY2VzQGlldGYub3JnIj5pMnJzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC ZWhhbGYgT2YgTG91IEJlcmdlcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPlNlbnQ6IFdl ZG5lc2RheSwgSnVseSAwMSwgMjAxNSAxMTozOSBBTTwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0i aW0iPlRvOiBTdXNhbiBIYXJlczsgJ0plZmZyZXkgSGFhcyc8L3NwYW4+PGJyPg0KPHNwYW4gY2xh c3M9ImltIj5DYzogPGEgaHJlZj0ibWFpbHRvOlJ0Zy15YW5nLWNvb3JkQGlldGYub3JnIj5SdGct eWFuZy1jb29yZEBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+ aTJyc0BpZXRmLm9yZzwvYT47ICdCUlVOR0FSRCwgREVCT1JBSCBBJzsgVmlzaG51PC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJpbSI+UGF2YW4gQmVlcmFtOyAnQWx2YXJvIFJldGFuYSAoYXJldGFu YSknOyAnQWxpYSBBdGxhcyc8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImltIj5TdWJqZWN0OiBS ZTogW2kycnNdIFtSdGcteWFuZy1jb29yZF0gUmVxdWlyZW1lbnRzIGZvciBJMlJTIHByb3RvY29s IGFuZCBJMlJTPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJpbSI+aW50ZXJpbSAoNi8yNC8yMDE1 IGF0IDEwOjAwIC0gMTE6MzBhbSBFVCk8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBB dCB0aGlzIHRpbWUsIG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRyYWZmaWM8 YnI+DQplbmdpbmVlcmluZy4mbmJzcDsgSXQgaXMgYW50aWNpcGF0ZWQgdGhhdCB0aGVzZSBtb2Rl bHMgd2lsbCBzdXBwb3J0IHRyYWZmaWM8YnI+DQplbmdpbmVlcmluZy48YnI+DQo8YnI+DQpTdWUs IEplZmYsPGJyPg0KJm5ic3A7ICZuYnNwOyBHaXZlbiBzb21lIHJlY2VudCBtZXNzYWdlcyBvbiB0 aGUgbGlzdCwgSSB0aG91Z2h0IGl0IGJlc3QgdG8gY29uZmlybTxicj4NCndlJ3JlIGFsbCBzdGls bCBvbiB0aGUgc2FtZSBwYWdlLjxicj4NCjxicj4NCkJhc2VkIG9uIG91ciBwYXN0IGRpc2N1c3Np b25zLCBpdCdzIG15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUgd29yayBiZWluZzxicj4NCmRvbmUg aW4gVEVBUyAoc2VlIGRyYWZ0LWlldGYtdGVhcy15YW5nLXRlLXRvcG8pIHdpbGwgc2VydmUgYXMg dGhlIGZvdW5kYXRpb248YnI+DQpmb3IgVEUgc3VwcG9ydCBpbiB0aGUgSTJSUyBtb2RlbHMuJm5i c3A7IEkgY29tcGxldGUgYWdyZWUgdGhhdCB0aGVyZSBhcmUgZGV0YWlsczxicj4NCm9uIGhvdyB0 aGUgZGlmZmVyZW50IHRvcG9sb2d5IG1vZGVscyB3aWxsIGludGVncmF0ZS9tZXNoIHN0aWxsIG5l ZWRzIHRvIGJlPGJyPg0Kd29ya2VkIG91dCwgYW5kIEkgYXNzdW1lZCB0aGF0IHRoaXMgaXMgd2hh dCB5b3UvU3VlIHdlcmUgcmVmZXJyaW5nIHRvIGFib3ZlLjxicj4NCi0tIEJ1dCB3ZSB3aWxsIG5v dCBoYXZlIHR3byBzZXRzIG9mIFRFIHRvcG9sb2d5IG1vZGVscy48YnI+DQo8YnI+DQpJIGJlbGll dmUgdGhhdCB0aGUgYXV0aG9ycyBvZiB0aGUgcmVzcGVjdGl2ZSBkcmFmdHMgYXJlIGFscmVhZHkg YXJlIHdvcmtpbmc8YnI+DQp0aGlzLiZuYnNwOyAoUGF2YW4sIG15IGNvLWNoYWlyIGFzIHdlbGwg YXMgY29hdXRob3Igb2YgdGhlIFRFQVMgeWFuZyBtb2RlbCwgY2FuPGJyPg0KY29tbWVudCBvbiB0 aGlzLik8YnI+DQo8YnI+DQpQbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBtaXNzZWQvbWlzcy11bmRl cnN0b29kIHNvbWV0aGluZy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KTG91PGJyPg0KKGFzIFRF QVMgV0cgY28tY2hhaXIpPGJyPg0KT24gNi8yMy8yMDE1IDI6MTkgUE0sIFN1c2FuIEhhcmVzIHdy b3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IE5ldGNvbmYgV29ya2luZyBHcm91cDo8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJMlJTIFdHIHdvdWxkIGxpa2UgdG8g cGFzcyB5b3UgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIGZvciB0aGUgSTJSUzxicj4NCiZndDsgcHJv dG9jb2wsIGFuZCBhc2tzIHRoYXQgeW91IHByb3ZpZGUgYW4gYW5hbHlzaXMgYnkgSUVURiA5MyBv biB3aGV0aGVyPGJyPg0KJmd0OyBORVRDT05GIG9yIFJFU1RDT05GIGNhbiBtZWV0IHRoZXNlIHJl cXVpcmVtZW50cy4mbmJzcDsgJm5ic3A7V2UgZXhwZWN0IHRoYXQ8YnI+DQomZ3Q7IHRoZXNlIHJl cXVpcmVtZW50cyBtYXkgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBvcjxi cj4NCiZndDsgUkVTVENPTkYuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBUaGUgSTJSUyBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKGRyYWZ0LWlldGYtaTJycy1hcmNoaXRl Y3R1cmUtMDk8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1 cmUvPC9hPiZndDspPGJyPg0KJmd0OyBwcm92aWRlcyBhIGhpZ2gtbGV2ZWwgb3ZlcnZpZXcgb2Yg dGhlIEkyUlMmbmJzcDsgcHJvdG9jb2wuJm5ic3A7IFRoZSBJMlJTIGhhczxicj4NCiZndDsgY29t cGlsZWQgdGhlIGZvbGxvd2luZyBkb2N1bWVudHMgdG8gcHJvdmlkZSB0aGUgYWRkaXRpb25hbCBk ZXRhaWxzIG9uPGJyPg0KJmd0OyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgcHJvdG9jb2xzLjxi cj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMSkmbmJzcDsgJm5ic3A7ICZu YnNwOyBkcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwPGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVw aGVtZXJhbC1zdGF0ZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLzwvYT4mZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgMikmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1pZXRmLWkycnMtcHViLXN1 Yi1yZXF1aXJlbWVudHMtMDI8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm LWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHM8L2E+PGJyPg0KJmd0OyAvJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7IDMpJm5ic3A7ICZuYnNwOyAmbmJzcDsgZHJhZnQtaWV0Zi1pMnJzLXRyYWNlYWJp bGl0eS0wMzxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHkvIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXRyYWNlYWJpbGl0 eS88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIGRy YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDAgY29udGFpbnMgdGhlIHJlc3VsdHMgb2Yg dGhlPGJyPg0KJmd0OyBkaXNjdXNzaW9uIGZyb20gdGhlIDYvMTAgaW50ZXJpbSBhbmQgdGhlIHRv cCAxMCByZXF1aXJlbWVudHMgZm9yIEkyUlMuPGJyPg0KJmd0OyBJbiBhZGRpdGlvbiwgdGhlIGRy YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDAgY29udGFpbnMgYW4gc2V0IG9mPGJyPg0K Jmd0OyBkZXRhaWxlZCByZXF1aXJlbWVudHMgb24gaG93IHRoZSBJMlJTIFdHIHNlZXMgdGhlIEky UlMgcHJvdG9jb2w8YnI+DQomZ3Q7IG9wZXJhdGluZy4mbmJzcDsgVGhlc2UgZGV0YWlsZWQgcmVx dWlyZW1lbnRzIGFyZSB0byBiZSBzZWVuIGFzIHN1Z2dlc3Rpb25zPGJyPg0KJmd0OyBvbiB3aGF0 IHR5cGUgb2Ygc29sdXRpb24gdGhlIEkyUlMgV0cgd291bGQgbGlrZSB0byBzZWUsIGJ1dCBJMlJT IFdHIGlzPGJyPg0KJmd0OyBhc2tpbmcgdGhlIE5FVENPTkYgV0cgdG8gcHJvdmlkZSBpdHMgYmVz dCBkZXNpZ25lZCBwcm90b2NvbC4mbmJzcDsgUGxlYXNlPGJyPg0KJmd0OyBub3RlIGFzIHBhcnQg b2YgdGhlc2UgZGV0YWlsZWQgcmVxdWlyZW1lbnQgdGhlPGJyPg0KJmd0OyBkcmFmdC1pZXRmLWky cnMtZXBoZW1lcmFsLXN0YXRlcy0wMCBjb250YWlucyB0aGUgaWRlYSBvZiB1c2luZzxicj4NCiZn dDsgbWV0YWRhdGEgdG8gcmVjb3JkIHNlY29uZGFyeSBpZGVudGl0eS48YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSBJMlJTIHByb3RvY29sIGlzIGRyaXZlbiBieSBk YXRhLW1vZGVscy4mbmJzcDsgVGhlIGFwcHJvdmVkIGRhdGEgbW9kZWxzPGJyPg0KJmd0OyBmb3Ig cHJvdG9jb2wgaW5kZXBlbmRlbnQgc2VydmljZXMgYXJlOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWlldGYtaTJycy1yaWItZGF0 YS1tb2RlbC0wMDxicj4NCiZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1yaWItZGF0YS1tb2RlbC8iIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcmliLWRh dGEtbW9kZWwvPC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBGaWx0ZXItQmFzZWQgUklCUzombmJzcDsgZHJhZnQta2luaS1pMnJz LWZiLXJpYi1kYXRhLW1vZGVsLjAwPGJyPg0KJmd0OyAocmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVr KTxicj4NCiZndDs8YnI+DQomZ3Q7IC0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRvcG9sb2d5IG1vZGVsIHdoaWNoIGlzIGEgY29tcG9zaXRlIG9mOjxicj4NCiZndDs8YnI+DQom Z3Q7IG8mbmJzcDsgJm5ic3A7R2VuZXJpYyB0b3BvbG9neSBtb2RlbDogZHJhZnQtaWV0Zi1pMnJz LXlhbmctbmV0d29yay10b3BvLTAxPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaTJycy15YW5nLW5ldHdvcmstdG9wby88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IG8m bmJzcDsgJm5ic3A7TDMgdG9wb2xvZ3kgbW9kZWw6IGRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRv cG9sb2d5LTAwPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3kvIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmct bDMtdG9wb2xvZ3kvPC9hPiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBvJm5ic3A7ICZuYnNwO0wy IHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5 LTAwPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDItbmV0d29yay10b3BvIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDIt bmV0d29yay10b3BvPC9hPjxicj4NCiZndDsgbG9neS8mZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg byZuYnNwOyAmbmJzcDtMMSBUb3BvbG9neSBtb2RlbDogZHJhZnQtemhhbmctaTJycy1sMS10b3Bv LXlhbmctbW9kZWwtMDEgKC0wMjxicj4NCiZndDsgcmVsZWFzZWQgbGF0ZXIgdGhpcyB3ZWVrKS48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBvJm5ic3A7ICZuYnNwO1NlcnZpY2UgdG9wb2xvZ3kgbW9kZWw6 PGJyPg0KJmd0OyBkcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2UtdG9wby15YW5nLW1vZGVsLTAwIChy ZWxlYXNlZCBvbiBXZWRuZXNkYXkpPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0OyBBdCB0aGlzIHRpbWUsIG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRy YWZmaWMgZW5naW5lZXJpbmcuPGJyPg0KJmd0OyBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRoZXNl IG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZpYyBlbmdpbmVlcmluZy48YnI+DQomZ3Q7IEVzdGlt YXRlZCByYXRlcyBvZiB0cmFuc2ZlciBhbmQgdGltaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlc2Ug bW9kdWxlczxicj4NCiZndDsgYXJlIGF0OiA8YSBocmVmPSJodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy93Zy9pMnJzL3RyYWMvd2lraSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvd2cvaTJycy90cmFjL3dpa2k8L2E+IC0gdW5kZXIgdGhlPGJyPg0KJmd0OyBw cm90b2NvbCByZXF1aXJlbWVudHMgdGFibGUuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBXZSBob3BlIHRoYXQgTkVUQ09ORiBXRyBjYW4gcHJvdmlkZSBzb21lIGluaXRp YWwgZmVlZGJhY2sgb24gdGhlc2U8YnI+DQomZ3Q7IHJlcXVpcmVtZW50cyBieSBJRVRGIDkzIGF0 IHRoZSBUdWVzZGF5IEkyUlMgc2Vzc2lvbi4mbmJzcDsgJm5ic3A7STJSUyB3aWxsIHVzZTxicj4N CiZndDsgdGhlIDYvMjQgaW50ZXJpbSBhdCAxMDowMC0xMTozMGFtIEVUJm5ic3A7IHRvIHByb3Zp ZGUgYSB0aW1lIGZvciBhbnk8YnI+DQomZ3Q7IHBhcnRpY2lwYXRlIGluIHRoZSBJMlJTLCBuZXRj b25mLCBvciBuZXRtb2QgZ3JvdXAgdG8gYXNrIGFkZGl0aW9uYWw8YnI+DQomZ3Q7IHF1ZXN0aW9u cyBvbiB0aGVzZSByZXF1aXJlbWVudHMuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0OyBTdWUgSGFyZXM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IEludGVyaW0gdGltZTogMTA6MDAtMTE6MzBhbSBFVDxicj4NCiZndDs8YnI+DQomZ3Q7IERhdGUg Ni8yNC8yMDE1PGJyPg0KJmd0Ozxicj4NCiZndDsgV2ViZXg6PGJyPg0KJmd0Ozxicj4NCiZndDsg PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQyNjBiZWU3 YmU2MWNiMTdiMDAwOGEzYzUyMDY5ZCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bTQyNjBiZWU3YmU2MWNiMTdiMDAwOGEzYzUyMDY5ZDwv YT48YnI+DQomZ3Q7IDBmPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBh Z2VuZGE6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxMDowMCAtIDEw OjA1IC0gQmFzaCBBZ2VuZGE8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxMDowNSAtIDEwOjIwLSAtJm5i c3A7IHJldmlldyBvZiByZXF1aXJlbWVudHMgZnJvbTxicj4NCiZndDs8YnI+DQomZ3Q7IGRyYWZ0 LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFmdC1p ZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMtMDI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFm dC1pZXRmLWkycnMtdHJhY2VhYmlsaXR5LTAzPGJyPg0KJmd0Ozxicj4NCiZndDsgVGltaW5nIHJl cXVpcmVtZW50czxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMTA6MjAg LSAxMDozMCZuYnNwOyAmbmJzcDsgUmV2aWV3IG9mIHJlcXVpcmVtZW50cyBmb3IgbXV0dWFsIGF1 dGhlbnRpY2F0aW9uLDxicj4NCiZndDs8YnI+DQomZ3Q7IGFuZCB0cmFuc2FjdGlvbiBpbiZuYnNw OyBkcmFmdC1oYXJlcy1hdXRoLXRyYW5zLTAxIHJlcXVpcmVtZW50czxicj4NCiZndDs8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgMTA6MzAtIDExOjMwJm5ic3A7ICZuYnNwOyAmbmJzcDtP cGVuIGRpc2N1c3Npb24gZm9yIEkyUlMgUmVxdWlyZW1lbnRzPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBQcm9jZWVkaW5ncyBhbmQgc2xpZGVzIGNhbiBiZSBmb3VuZCBh dDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3Byb2Nl ZWRpbmdzL2ludGVyaW0vMjAxNS8wNi8yNC9pMnJzL3Byb2NlZWRpbmdzLmh0IiB0YXJnZXQ9Il9i bGFuayI+DQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzL2ludGVyaW0vMjAxNS8wNi8y NC9pMnJzL3Byb2NlZWRpbmdzLmh0PC9hPjxicj4NCiZndDsgbWw8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFN1ZSBIYXJlczxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBS dGcteWFuZy1jb29yZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpSdGct eWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmctY29vcmRAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Zy15YW5n LWNvb3JkIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J0Zy15YW5nLWNvb3JkPC9hPjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPmkycnMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmkycnNA aWV0Zi5vcmciPmkycnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaTJycyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ky cnM8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C636AF2FA540124E9B9ACB5A6BECCE6B471E1803SZXEMA512MBSchi_-- From nobody Fri Jul 3 11:38:15 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B1D1A1B13; Fri, 3 Jul 2015 11:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 RJC0UcDjopOA; Fri, 3 Jul 2015 11:35:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 ED17B1A1ADC; Fri, 3 Jul 2015 11:35:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Zhangxian \(Xian\)'" , "'Vishnu Pavan Beeram'" , "'Lou Berger'" , References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> In-Reply-To: Date: Fri, 3 Jul 2015 14:35:22 -0400 Message-ID: <011c01d0b5bf$06055c60$12101520$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011D_01D0B59D.7EF91390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QL4Xs+nAlcpWbYBg5KlhQJWWMN7nP4FLMA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 11:38:13 -0700 Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , alex@cisco.com, 'Alia Atlas' , 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 18:35:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011D_01D0B59D.7EF91390 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Xian: =20 The time will be 6:00pm-7:00pm (18:00-19:00) on Sunday 7/19/2015 in = Prague. =20 =20 I=E2=80=99m also trying to lock down a conference call at 11:00am-12:00 = ET (8:00am-12:00pm PT, 23:00-23:59 Beijing) on 7/8 for the TEAS authors = and the topology authors. By this time I will have reviewed the TEAS = and I2RS drafts submitted, and I will have questions for the authors.=20 =20 Please let me know if you can attend these two meetings. =20 Sue=20 =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Zhangxian (Xian) Sent: Thursday, July 02, 2015 11:47 PM To: Susan Hares; Vishnu Pavan Beeram; Lou Berger; = draft-ietf-teas-yang-te-topo@tools.ietf.com Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; = alex@cisco.com; Alia Atlas; Jeffrey Haas; Alvaro Retana (aretana) Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and = I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Hi,=20 =20 I would echo what Lou said in another email: =20 =E2=80=9CWe should probably announce the time and place where the = authors will be meeting in Prague so that others who are interested can = show.=E2=80=9D =20 I am definitely interested.=20 =20 Another suggestion is: can we try to draw a relationship diagram to see = how the topology related models fits together (irrespective of which WG = should work on what)? In the draft, there is = already a diagram which might be helpful as a starting point.=20 =20 Regards, Xian =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Vishnu Pavan = Beeram Sent: 2015=E5=B9=B47=E6=9C=882=E6=97=A5 8:42 To: Susan Hares Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; = alex@cisco.com; Vishnu Pavan Beeram; Alia Atlas; = draft-ietf-teas-yang-te-topo@tools.ietf.com; Jeffrey Haas; Alvaro Retana = (aretana); Lou Berger Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and = I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 + Alex + authors Sue, Jeff, The authors of the draft had a meeting today with one of = the authors (Alex) of the draft and discussed ways = to align the topo models. The consensus so far is that the = WILL augment the . There are some = issues that need to be worked out (mapping identifiers, = termination-points), but those should get resolved in due course of = time.=20 I'll sync up with you (Sue) and coordinate a meeting between the authors = of the and the authors of the I2RS topo model(s) at the = IETF --- hopefully early in the week.=20 Regards, -Pavan =20 On Wed, Jul 1, 2015 at 6:49 PM, Susan Hares wrote: Lou and Jeffrey: On 7/22, I talked with the TEAS TE authors team. They had concerns = about how the I2RS was going to integrate the TEAS work. I realized there are = two different approaches to the models - and I expressed my hope that we = could have aligned/merged models. I chatted with the I2RS topology draft = authors, and I found that the authors had not yet begun to work on the TE models. The best plan is to try to get the TEAS authors and the I2RS Topology authors together at IETF 93 and get a plan together for migrating these teams together. I will send a few times out to teams this evening. It would really = help I2RS if the TEAS group would meet early in the week (or if the folks are = at the hack-athon like I am we may meet Saturday night). We could then try = to give NETCONF our best insight on the TE additions. In order to prepare for this TE/Non-TE merge, I2RS WG need to finalize = the non-TE models in the topology. Today's interim was target to firm up = the Service and T1 topology models, but the T1 topology model will not be = ready until IETF 93. My message in June hoped that we would be to the TE = models by IETF so that NETCONF would have our entire scope, but we will not be there by the beginning of IETF. I2RS will be following up in August = and September with Interims that focus on the TE models in I2RS Topology = model. Do you have any other suggestions? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, July 01, 2015 11:39 AM To: Susan Hares; 'Jeffrey Haas' Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'BRUNGARD, DEBORAH A'; = Vishnu Pavan Beeram; 'Alvaro Retana (aretana)'; 'Alia Atlas' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and = I2RS interim (6/24/2015 at 10:00 - 11:30am ET) > At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Sue, Jeff, Given some recent messages on the list, I thought it best to confirm we're all still on the same page. Based on our past discussions, it's my understanding that the work being done in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the = foundation for TE support in the I2RS models. I complete agree that there are = details on how the different topology models will integrate/mesh still needs to = be worked out, and I assumed that this is what you/Sue were referring to = above. -- But we will not have two sets of TE topology models. I believe that the authors of the respective drafts are already are = working this. (Pavan, my co-chair as well as coauthor of the TEAS yang model, = can comment on this.) Please let me know if I missed/miss-understood something. Thanks, Lou (as TEAS WG co-chair) On 6/23/2015 2:19 PM, Susan Hares wrote: > > Netconf Working Group: > > > > The I2RS WG would like to pass you a set of requirements for the I2RS > protocol, and asks that you provide an analysis by IETF 93 on whether > NETCONF or RESTCONF can meet these requirements. We expect that > these requirements may require changes to the either NETCONF or > RESTCONF. > > > > The I2RS architecture document (draft-ietf-i2rs-architecture-09 > ) > provides a high-level overview of the I2RS protocol. The I2RS has > compiled the following documents to provide the additional details on > the requirements for the protocols. > > > > 1) draft-ietf-i2rs-ephemeral-state-00 > > > 2) draft-ietf-i2rs-pub-sub-requirements-02 > /> > > 3) draft-ietf-i2rs-traceability-03 > > > > > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the > discussion from the 6/10 interim and the top 10 requirements for I2RS. > In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of > detailed requirements on how the I2RS WG sees the I2RS protocol > operating. These detailed requirements are to be seen as suggestions > on what type of solution the I2RS WG would like to see, but I2RS WG is > asking the NETCONF WG to provide its best designed protocol. Please > note as part of these detailed requirement the > draft-ietf-i2rs-ephemeral-states-00 contains the idea of using > metadata to record secondary identity. > > > > The I2RS protocol is driven by data-models. The approved data models > for protocol independent services are: > > - draft-ietf-i2rs-rib-data-model-00 > > > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 > (released later this week) > > - Topology model which is a composite of: > > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 > > > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 > > > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 > logy/> > > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 > released later this week). > > o Service topology model: > draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > > > > At this time, none of the Topology models utilize Traffic engineering. > It is anticipated that these models will support traffic engineering. > Estimated rates of transfer and timing requirements for these modules > are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the > protocol requirements table. > > > > We hope that NETCONF WG can provide some initial feedback on these > requirements by IETF 93 at the Tuesday I2RS session. I2RS will use > the 6/24 interim at 10:00-11:30am ET to provide a time for any > participate in the I2RS, netconf, or netmod group to ask additional > questions on these requirements. > > > > Sue Hares > > > > Interim time: 10:00-11:30am ET > > Date 6/24/2015 > > Webex: > > = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d > 0f > > > > agenda: > > > > 10:00 - 10:05 - Bash Agenda > > 10:05 - 10:20- - review of requirements from > > draft-ietf-i2rs-ephemeral-state-00 > > draft-ietf-i2rs-pub-sub-requirements-02 > > draft-ietf-i2rs-traceability-03 > > Timing requirements > > > > 10:20 - 10:30 Review of requirements for mutual authentication, > > and transaction in draft-hares-auth-trans-01 requirements > > > > 10:30- 11:30 Open discussion for I2RS Requirements > > > > Proceedings and slides can be found at: > > http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.ht > ml > > > > Sue Hares > > > > > > > > _______________________________________________ > Rtg-yang-coord mailing list > Rtg-yang-coord@ietf.org > https://www.ietf.org/mailman/listinfo/rtg-yang-coord _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_011D_01D0B59D.7EF91390 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Xian:

 

The time will be 6:00pm-7:00pm (18:00-19:00) on Sunday 7/19/2015 in = Prague. =C2=A0

 

I=E2=80=99m also trying to lock down a conference call at = 11:00am-12:00 ET (8:00am-12:00pm PT, 23:00-23:59 Beijing) on 7/8 for the = TEAS authors and the topology authors. =C2=A0By this time I will have = reviewed the TEAS and I2RS drafts submitted, and I will have questions = for the authors.

 

Please let me know if you can attend these two = meetings.

 

Sue

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Zhangxian = (Xian)
Sent: Thursday, July 02, 2015 11:47 PM
To: = Susan Hares; Vishnu Pavan Beeram; Lou Berger; = draft-ietf-teas-yang-te-topo@tools.ietf.com
Cc: = Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; = alex@cisco.com; Alia Atlas; Jeffrey Haas; Alvaro Retana = (aretana)
Subject: Re: [i2rs] [Rtg-yang-coord] Requirements = for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Hi,

 

   I would echo what Lou said in = another email:

 

=E2=80=9CWe should probably announce the = time and place where the authors will be meeting in Prague so that = others who are interested can show.=E2=80=9D

 

I am definitely interested. =

 

Another suggestion is: can we try to draw = a relationship diagram to see how the topology related models fits = together (irrespective of which WG should work on what)? In the = <network-topo-model> draft, there is already a diagram which might = be helpful as a starting point.

 

Regards,
Xian

 

From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Vishnu Pavan Beeram
Sent: 2015=E5=B9=B47=E6=9C=882=E6=97=A5 8:42
To: Susan Hares
Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; alex@cisco.com; Vishnu Pavan Beeram; = Alia Atlas; draft-ietf-te= as-yang-te-topo@tools.ietf.com; Jeffrey Haas; Alvaro Retana = (aretana); Lou Berger
Subject: Re: [i2rs] [Rtg-yang-coord] = Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - = 11:30am ET)

 

+ = Alex

+ <te-topo-model> = authors

Sue, = Jeff,

The authors of the = <te-topo-model> draft had a meeting today with one of the authors = (Alex) of the <network-topo-model> draft and discussed ways to = align the topo models. The consensus so far is that the = <te-topo-model> WILL augment the <network-topo-model>. There = are some issues that need to be worked out (mapping identifiers, = termination-points), but those should get resolved in due course of = time.

I'll sync up with you (Sue) and coordinate a meeting = between the authors of the <te-topo-model> and the authors of the = I2RS topo model(s) at the IETF --- hopefully early in the week. =

Regards,

=

-Pavan

 

On Wed, Jul = 1, 2015 at 6:49 PM, Susan Hares <shares@ndzh.com> wrote:

Lou and Jeffrey:

On 7/22, I = talked with the TEAS TE authors team.  They had concerns = about
how the I2RS was going to integrate the TEAS work.  I = realized there are two
different approaches to the models - and I = expressed my  hope that we could
have aligned/merged = models.  I chatted with the I2RS topology draft authors,
and I = found that the authors had not yet begun to work on the TE = models.
The best plan is to try to get the TEAS authors and the I2RS = Topology
authors together at IETF 93 and get a plan together for = migrating these
teams together.

I will send a few times out to = teams this evening.   It would really help
I2RS if the TEAS = group would meet early in the week (or if the folks are at
the = hack-athon like I am we may meet Saturday night).  We could then = try to
give NETCONF our best insight on the TE = additions.

 In order to prepare for this TE/Non-TE merge, = I2RS WG need to finalize the
non-TE models in the topology.  = Today's interim was target to firm up the
Service and T1 topology = models, but the T1 topology model will not be ready
until IETF = 93.  My message in June hoped that we would be to the TE = models
by IETF so that NETCONF would have our entire scope, but we = will not be
there by the beginning of IETF.   I2RS will be = following up in August and
September with Interims that focus on the = TE models in I2RS Topology model.

Do you have any other = suggestions?

Sue


-----Original = Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Lou Berger
Sent: Wednesday, July = 01, 2015 11:39 AM
To: Susan Hares; 'Jeffrey = Haas'
Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'BRUNGARD, DEBORAH A'; = Vishnu
Pavan Beeram; 'Alvaro Retana = (aretana)'; 'Alia Atlas'
Subject: Re: [i2rs] = [Rtg-yang-coord] Requirements for I2RS protocol and I2RS
interim (6/24/2015 at 10:00 - 11:30am = ET)

> At this time, none of the = Topology models utilize Traffic
engineering.  It is anticipated = that these models will support traffic
engineering.

Sue, = Jeff,
    Given some recent messages on the list, I thought = it best to confirm
we're all still on the same page.

Based on = our past discussions, it's my understanding that the work being
done = in TEAS (see draft-ietf-teas-yang-te-topo) will serve as the = foundation
for TE support in the I2RS models.  I complete agree = that there are details
on how the different topology models will = integrate/mesh still needs to be
worked out, and I assumed that this = is what you/Sue were referring to above.
-- But we will not have two = sets of TE topology models.

I believe that the authors of the = respective drafts are already are working
this.  (Pavan, my = co-chair as well as coauthor of the TEAS yang model, can
comment on = this.)

Please let me know if I missed/miss-understood = something.

Thanks,
Lou
(as TEAS WG co-chair)
On = 6/23/2015 2:19 PM, Susan Hares wrote:
>
> Netconf Working = Group:
>
>
>
> The I2RS WG would like to pass = you a set of requirements for the I2RS
> protocol, and asks that = you provide an analysis by IETF 93 on whether
> NETCONF or = RESTCONF can meet these requirements.   We expect that
> = these requirements may require changes to the either NETCONF or
> = RESTCONF.
>
>
>
> The I2RS architecture document = (draft-ietf-i2rs-architecture-09
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-archit= ecture/>)
> provides a high-level overview of the = I2RS  protocol.  The I2RS has
> compiled the following = documents to provide the additional details on
> the requirements = for the protocols.
>
>
>
> 1)    =   draft-ietf-i2rs-ephemeral-state-00
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-epheme= ral-state/>
>
> 2)      = draft-ietf-i2rs-pub-sub-requirements-02
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-su= b-requirements
> />
>
> 3)      = draft-ietf-i2rs-traceability-03
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-tracea= bility/>
>
>
>
> The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the
> = discussion from the 6/10 interim and the top 10 requirements for = I2RS.
> In addition, the draft-ietf-i2rs-ephemeral-state-00 = contains an set of
> detailed requirements on how the I2RS WG sees = the I2RS protocol
> operating.  These detailed requirements = are to be seen as suggestions
> on what type of solution the I2RS = WG would like to see, but I2RS WG is
> asking the NETCONF WG to = provide its best designed protocol.  Please
> note as part of = these detailed requirement the
> = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using
> = metadata to record secondary identity.
>
>
>
> = The I2RS protocol is driven by data-models.  The approved data = models
> for protocol independent services are:
>
> = -          = draft-ietf-i2rs-rib-data-model-00
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-da= ta-model/>
>
> -          = Filter-Based RIBS:  draft-kini-i2rs-fb-rib-data-model.00
> = (released later this week)
>
> -        =   Topology model which is a composite of:
>
> o  =  Generic topology model: = draft-ietf-i2rs-yang-network-topo-01
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-n= etwork-topo/>
>
> o   L3 topology model: = draft-ietf-i2rs-yang-l3-topology-00
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l= 3-topology/>
>
> o   L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00
> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l= 2-network-topo
> logy/>
>
> o   L1 = Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02
> = released later this week).
>
> o   Service = topology model:
> draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday)
>
>
>
> At this time, = none of the Topology models utilize Traffic engineering.
> It is = anticipated that these models will support traffic engineering.
> = Estimated rates of transfer and timing requirements for these = modules
> are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - = under the
> protocol requirements = table.
>
>
>
> We hope that NETCONF WG can = provide some initial feedback on these
> requirements by IETF 93 = at the Tuesday I2RS session.   I2RS will use
> the 6/24 = interim at 10:00-11:30am ET  to provide a time for any
> = participate in the I2RS, netconf, or netmod group to ask = additional
> questions on these = requirements.
>
>
>
> Sue = Hares
>
>
>
> Interim time: 10:00-11:30am = ET
>
> Date 6/24/2015
>
> Webex:
>
> = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61c= b17b0008a3c52069d
> 0f
>
>
>
> = agenda:
>
>
>
> 10:00 - 10:05 - Bash = Agenda
>
> 10:05 - 10:20- -  review of requirements = from
>
> draft-ietf-i2rs-ephemeral-state-00
>
> = draft-ietf-i2rs-pub-sub-requirements-02
>
> = draft-ietf-i2rs-traceability-03
>
> Timing = requirements
>
>
>
> 10:20 - 10:30    = Review of requirements for mutual authentication,
>
> and = transaction in  draft-hares-auth-trans-01 = requirements
>
>
>
> 10:30- 11:30    =  Open discussion for I2RS = Requirements
>
>
>
> Proceedings and slides can = be found at:
>
> http://www.ietf.org/proceedings/interim/2015/06/24/i2rs= /proceedings.ht
> ml
>
>
>
> Sue = Hares
>
>
>
>
>
>
>
> = _______________________________________________
> Rtg-yang-coord = mailing list
> Rtg-yang-coord@ietf.org
&g= t; https://www.ietf.org/mailman/listinfo/rtg-yang-coord


_______________________________________________

 

------=_NextPart_000_011D_01D0B59D.7EF91390-- From nobody Fri Jul 3 12:39:29 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143291A7005; Fri, 3 Jul 2015 12:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 qd_brI25Worl; Fri, 3 Jul 2015 12:39:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 DAC061A7000; Fri, 3 Jul 2015 12:39:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'BELOTTI, SERGIO \(SERGIO\)'" , "'Mahesh Jethanandani'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: Date: Fri, 3 Jul 2015 15:39:23 -0400 Message-ID: <01c801d0b5c7$f7058d80$e510a880$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C9_01D0B5A6.6FF65E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLAkJXomwCOt7Bop0On+6Q Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Netconf' , 'NETMOD Working Group' Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 19:39:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Sergio:=20 =20 Just in case you missed in the rest of the email threads:=20 =20 Yes =E2=80=93 I2RS plans to coordinate the topology model with the TEAS = Topology model. The work began with the authors last week, and will = continue in a discussion of the TEAS And Topology authors next week = (7/8) in a conference call, and at IETF on Sunday (7/19 from 6-7pm).=20 =20 The I2RS WG will provide an update on the merging of these two models. = If you are a TEAS author, please let me know. If you wish to help on = an I2RS Topology model, the I2RS working group would appreciate your = review of any model.=20 =20 I am personally working on the service layer model.=20 =20 Sue Hares=20 From: BELOTTI, SERGIO (SERGIO) = [mailto:sergio.belotti@alcatel-lucent.com]=20 Sent: Wednesday, July 01, 2015 5:28 AM To: Susan Hares; 'Mahesh Jethanandani' Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'NETMOD Working Group'; = 'Netconf'; 'BRUNGARD, DEBORAH A' Subject: RE: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol = and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Hello Susan, - Topology model which is a composite of: o Generic topology model: = = draft-ietf-i2rs-yang-network-topo-01=20 o L3 topology model: = = draft-ietf-i2rs-yang-l3-topology-00=20 o L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00=20 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday) =20 At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. =20 =20 Reading this , my question is whether there is intention for Traffic = Engineering part of topology model to exploit/coordinate with Teas , and = particularly with=20 draft-liu-teas-yang-te-topo or to proceed with distinct contributions = internal to I2RS. =20 Thanks Sergio =20 ------=_NextPart_000_01C9_01D0B5A6.6FF65E80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Sergio:

 

Just in case you missed in the rest of the email threads: =

 

Yes =E2=80=93 I2RS plans to coordinate the topology model with the = TEAS Topology model.=C2=A0 The work began with the authors last week, = and will continue in a discussion of the TEAS And Topology authors next = week (7/8) =C2=A0in a conference call, and at IETF on Sunday (7/19 from = 6-7pm).

 

The I2RS WG will provide an update on the merging of these two = models.=C2=A0 If you are a TEAS author, please let me know. = =C2=A0=C2=A0If you wish to help on an I2RS Topology model, the I2RS = working group would appreciate your review of any model. =

 

I am personally working on the service layer model. =

 

Sue Hares

From:= = BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-lucent.com] =
Sent: Wednesday, July 01, 2015 5:28 AM
To: Susan = Hares; 'Mahesh Jethanandani'
Cc: Rtg-yang-coord@ietf.org; = i2rs@ietf.org; 'NETMOD Working Group'; 'Netconf'; 'BRUNGARD, DEBORAH = A'
Subject: RE: [Rtg-yang-coord] [netmod] Requirements for = I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Hello Susan,

-        = ;  Topology model which is a composite = of:=

o   Generic topology model: draft-ietf-i2rs-yang-network-topo-01 =

o   L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 =

o   L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 =

o   L1 Topology model: draft-zhang= -i2rs-l1-topo-yang-model-01 (-02 released later this week). 

o   Service topology model: draft-hares= -i2rs-service-topo-yang-model-00 (released on = Wednesday)

 =

At this = time, none of the Topology models utilize Traffic engineering.  It = is anticipated that these models will support traffic engineering. =  

 

Reading this , my question is whether there is = intention for Traffic Engineering part of topology model to = exploit/coordinate with Teas , and particularly with =

 draft-liu-teas-yang-te-topo or to proceed = with distinct contributions internal to I2RS.

 

Thanks

Sergio

 

------=_NextPart_000_01C9_01D0B5A6.6FF65E80-- From nobody Fri Jul 3 13:52:16 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB4C1A7D83 for ; Fri, 3 Jul 2015 12:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 WJnOxz2Fe_VU for ; Fri, 3 Jul 2015 12:49:17 -0700 (PDT) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id E68681A7113 for ; Fri, 3 Jul 2015 12:49:16 -0700 (PDT) Received: (qmail 2898 invoked by uid 0); 3 Jul 2015 19:49:15 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy5.mail.unifiedlayer.com with SMTP; 3 Jul 2015 19:49:15 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id nveo1q00P2SSUrH01verYh; Fri, 03 Jul 2015 13:38:54 -0600 X-Authority-Analysis: v=2.1 cv=ALgDonD0 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=wU2YTnxGAAAA:8 a=cNaOj0WVAAAA:8 a=AGkejYDSTmIA:10 a=N659UExz7-8A:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=zOBTXjUuO1YA:10 a=k0E8tIfyBo0Nto1-jTgA:9 a=pILNOxqGKmIA:10 a=Am4pkuz53W8A:10 a=VvYRpQ6nluYA:10 a=lsHcWZlcHswA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=tKywBpBLQIqnAYMqLrl8Bc4mOOj68wTPd12vBM2Jr7Y=; b=O8Y36lYE25lXst/YR9OeAC1i7YCfBaKiP+ABWrfUhIEtdkRF71ZP2rNCxywxXj5J+766c3icxhT2uzVAF44o2mXmUcnxuGa+y3nc7ct1YusTzAjRmr3ocwC7nbtBhsNQ; Received: from box313.bluehost.com ([69.89.31.113]:59060 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZB6xR-0001VC-LG; Fri, 03 Jul 2015 13:49:09 -0600 Message-ID: <5596E72D.9070900@labn.net> Date: Fri, 03 Jul 2015 15:49:01 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , "'Zhangxian (Xian)'" , 'Vishnu Pavan Beeram' , draft-ietf-teas-yang-te-topo@tools.ietf.com References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> <011c01d0b5bf$06055c60$12101520$@ndzh.com> In-Reply-To: <011c01d0b5bf$06055c60$12101520$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 13:52:15 -0700 Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , alex@cisco.com, 'Alia Atlas' , 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 19:49:17 -0000 Sue, On 7/3/2015 2:35 PM, Susan Hares wrote: > By this time I will have reviewed the TEAS and I2RS drafts submitted, > and I will have questions for the authors. It might be helpful to have this discussion on list so others who are on the call can follow/participate. Thanks, Lou From nobody Fri Jul 3 13:52:44 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16B731A87C9; Fri, 3 Jul 2015 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 f00UDHQMwIXS; Fri, 3 Jul 2015 13:49:09 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 BEFBD1A87C4; Fri, 3 Jul 2015 13:49:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Lou Berger'" , "'Zhangxian \(Xian\)'" , "'Vishnu Pavan Beeram'" , References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <5594097C.70607@labn.net> <00d801d0b450$250e4560$6f2ad020$@ndzh.com> <011c01d0b5bf$06055c60$12101520$@ndzh.com> <5596E72D.9070900@labn.net> In-Reply-To: <5596E72D.9070900@labn.net> Date: Fri, 3 Jul 2015 16:49:00 -0400 Message-ID: <024101d0b5d1$b0f4cd10$12de6730$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QL4Xs+nAlcpWbYBg5KlhQJWWMN7Ae0Cs00ByK1qFpzgfjKg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 03 Jul 2015 13:52:42 -0700 Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "'BRUNGARD, DEBORAH A'" , alex@cisco.com, 'Alia Atlas' , 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 20:49:10 -0000 Lou: This webex (7/8) is to help inform the I2RS chair so that prior to kicking off the mail list discussion. Sue -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, July 03, 2015 3:49 PM To: Susan Hares; 'Zhangxian (Xian)'; 'Vishnu Pavan Beeram'; draft-ietf-teas-yang-te-topo@tools.ietf.com Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; 'BRUNGARD, DEBORAH A'; alex@cisco.com; 'Alia Atlas'; 'Jeffrey Haas'; 'Alvaro Retana (aretana)' Subject: Re: [i2rs] [Rtg-yang-coord] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Sue, On 7/3/2015 2:35 PM, Susan Hares wrote: > By this time I will have reviewed the TEAS and I2RS drafts submitted, > and I will have questions for the authors. It might be helpful to have this discussion on list so others who are on the call can follow/participate. Thanks, Lou From nobody Fri Jul 3 20:25:51 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB95F1B3363; Fri, 3 Jul 2015 20:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.56 X-Spam-Level: X-Spam-Status: No, score=-100.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zp2KKKPY7pUY; Fri, 3 Jul 2015 20:25:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7361B3361; Fri, 3 Jul 2015 20:25:43 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id DE20FD00E992E; Sat, 4 Jul 2015 11:25:39 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id DB07F49F44691; Sat, 4 Jul 2015 11:25:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t643PZDt039528; Sat, 4 Jul 2015 11:25:35 +0800 (GMT-8) (envelope-from dai.xianxian@zte.com.cn) In-Reply-To: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org, jhaas@juniper.net, shares@ndzh.com MIME-Version: 1.0 X-KeepSent: 5744358B:3CEE4C66-48257E78:0011EC09; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: dai.xianxian@zte.com.cn Date: Sat, 4 Jul 2015 11:25:29 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-04 11:25:31, Serialize complete at 2015-07-04 11:25:31 Content-Type: multipart/alternative; boundary="=_alternative 0012D25448257E78_=" X-MAIL: mse01.zte.com.cn t643PZDt039528 Archived-At: Cc: i2rs@ietf.org, akatlas@gmail.com, i2rs , i-d-announce@ietf.org Subject: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2015 03:25:49 -0000 This is a multipart message in MIME format. --=_alternative 0012D25448257E78_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGVsbG8gSi4gSGFhcyBhbmQgUy4gSGFyZXMsDQoNCkkgaGF2ZSBzb21lIGRvdWJ0IGFib3V0ICJk cmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwIi4NCg0KMS5DaGFwdGVyIDYgUmVxdWly ZW1lbnRzIHJlZ2FyZGluZyBJZGVudGl0eSwgU2Vjb25kYXJ5LUlkZW50aXR5IGFuZCANClByaW9y aXR5DQoNCkkyUlMgcGVybWl0cyBSUEMgb3BlcmF0aW9uIHRvIGNhcnJ5IHByaW9yaXR5IGFuZCBh IHNlY29uZGFyeSBpZGVudGl0eSBhcyANCmF0dHJpYnV0ZSBwYXJhbWV0ZXJzLg0KSW4gdGhpcyBk cmFmdCwgaXQgZGVzY3JpYmVzIHRoYXQgIlRoaXMgc2Vjb25kYXJ5IGlkZW50aXR5IG1ldGEtZGF0 YSBNVVNUIA0KYmUgcmVhZC1vbmx5LiBvcGVyYXRpb25zIGF0dGVtcHRpbmcgdG8gYWx0ZXIgaXQg TVVTVCBiZSBzaWxlbnRseSBpZ25vcmVkLiANCiINClNpbmNlIGlkZW50aXR5IGF0dHJpYnV0ZSBj YW5ub3QgYmUgY2hhbmdlZCB1bnRpbCB0aGUgc2Vzc2lvbiB0ZXJtaW5hdGVzLCANCndoeSBkb24n dCB3ZSBwZXJtaXQgY2xpZW50IHRvIHNlbmQgaGVsbG8gbWVzc2FnZSB3aXRoIHN1Y2ggaW5mb3Mg ZHVyaW5nDQogc2Vzc2lvbiBlc3RhYmxpc2htZW50Lg0KIGUuZywNCiAgICA8aGVsbG8geG1sbnM9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgIDxjYXBhYmls aXRpZXM+DQogICAgICAgPGNhcGFiaWxpdHk+DQogICAgICAgICB1cm46aWV0ZjpwYXJhbXM6bmV0 Y29uZjpiYXNlOjEuMA0KICAgICAgIDwvY2FwYWJpbGl0eT4NCiAgICAgICA8Y2FwYWJpbGl0eT4N CiANCnVybjppZXRmOnBhcmFtczppMnJzOmNhcGFiaWxpdHk6aTJyczoxLjA/c2Vjb25kYXJ5LWlk ZW50aXR5PXVzZXIxJnByaW9yaXR5PTEwDQogICAgICAgPC9jYXBhYmlsaXR5Pg0KICAgICA8L2Nh cGFiaWxpdGllcz4NCiAgIDwvaGVsbG8+DQpJdCBtZWFucyBpbiB0aGlzIHNlc3Npb24sIHRoZSBz ZWNvbmRhcnktaWRlbnRpdHkgaXMgbmFtZWQgInVzZXIxIiwgdGhlIA0KZGVmYXVsdCBwcmlvcml0 eSBpcyAxMCANCg0KdGhlbixpZiB0aGUgc2Vzc2lvbiB3YW50cyB0byBjaGFuZ2UgaXRzIHByaW9y aXR5IHdoaWxlIFJQQyBvcGVyYXRpb24sYXMgDQpmb2xsb3dzDQogICAgIDxmb28geG1sbnM6aTJy cz0iaHR0cHM6Ly9pZXRmLmV4YW1wbGUuY29tL2kycnMiIA0KaTJyczppMnJzLXByaW9yaXR5PSI0 NyI+DQogICAgICAgICAgLi4uDQogICAgPC9mb28+IA0KSXQgbWVhbnMgbm93IGluIHRoaXMgc2Vz c2lvbiwgdGhlIHNlY29uZGFyeS1pZGVudGl0eSBpcyBuYW1lZCAidXNlcjEiLCB0aGUgDQpwcmlv cml0eSBpcyA0NyANCg0KZnVydGhlcm1vcmUsIHdlIGNhbiBkZWZpbmUgPHNldC1pMnJzLXByaW9y aXR5PiB0byBjaGFuZ2UgY3VycmVudCBzZXNzaW9uJ3MgDQpwcmlvcml0eSxzdWNoIGFzDQogICAg PHNldC1pMnJzLXByaW9yaXR5IA0KeG1sbnM6aTJycz0idXJuOmlldGY6cGFyYW1zOmkycnM6Y2Fw YWJpbGl0eTppMnJzOjEuMCI+DQogICAgICAgIDxwcmlvcml0eT4yMDwvcHJpb3JpdHk+DQogICAg PC9zZXQtaTJycy1wcmlvcml0eT4NCiANCg0KMi5JbiB0aGlzIGRyYWZ0LCBQcmlvcml0eSBpcyBk ZWZpbmVkIGFzIGEgbnVtZXJpYyB2YWx1ZSxob3cgYWJvdXQgaXRzIA0KcmFuZ2Ugc3RhdGVtZW50 cz8gSXMgImkycnMtcHJpb3JpdHkgPSAyNTUiIGlzIHRoZSBoaWdoZXN0Pw0KDQozLmNvbmZpZyBl cGhlbWVyYWwNCkluIHRoaXMgZHJhZnQsVGhlIFlBTkcgImNvbmZpZyIga2V5d29yZCBpcyBleHRl bmRlZCxsaWtlICJjb25maWcgDQp0cnVlL2ZhbHNlL2VwaGVtZXJhbCIgLGFuZCB0aGUgYmFzaWMg bmV0Y29uZiBvcGVyYXRpb24gc2hvdWxkIGJlIGV4dGVuZGVkLA0KbGlrZSAiZ2V0LWNvbmZpZyIg ImVkaXQtY29uZmlnIiBhbmQgc28gb24uDQp3aHkgZG9uJ3Qgd2UgZGVmaW5lIGEgbmV3IGtpbmQg b2Ygb3BlcmF0aW9ucyxsaWtlICJnZXQtaTJycyIgImVkaXQtaTJycyI/IA0KVGFrZSBkZWZpbml0 aW9uIG9mICJnZXQtaTJycyIgZm9yIGV4YW1wbGUuDQogICAgICAgIHJwYyBnZXQtaTJycyB7DQog ICAgICAgIGRlc2NyaXB0aW9uICJUaGlzIG9wZXJhdGlvbiBjYW4gYmUgdXNlZCB0byBnZXQgZGF0 YSBmcm9tIGkycnMgDQpkYXRhIjsNCiAgICAgICAgaW5wdXQgew0KICAgICAgICAgICAgICAgIGxl YWYgcHJpdmF0ZSB7DQogICAgICAgICAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbiAiSWYgdGhl IHZhbHVlIGlzIHRydWUsIGl0IG1lYW5zIG9ubHkgDQpkYXRhIG93bmVkIGJ5IA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgc2FtZSBpZGVudGl0eSB3aWxsIGJl IA0KcmV0cmlldmVkLiBPdGhlcndpc2UsIGFsbCBpMnJzIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBkYXRhIHdpbGwgYmUgcmV0dXJuZWQuIjsNCiAgICAgICAgICAg ICAgICAgICAgICAgIHR5cGUgYm9vbGVhbjsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRlZmF1 bHQgZmFsc2U7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIGFueXhtbCBmaWx0 ZXIgew0KICAgICAgICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgIlN1YnRyZWUgZmlsdGVyIHRvIHVzZS4iOw0KICAgICAgICAgICAgICAgIH0N CiAgICAgICAgfQ0KIA0KICAgICAgICBvdXRwdXQgew0KICAgICAgICAgICAgICAgIGFueXhtbCBk YXRhIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAg ICAgICAgICAgICAgICJDb3B5IG9mIHRoZSBpMnJzIGRhdGEgdGhhdCBtYXRjaGVkDQogICAgICAg ICAgICAgICAgICAgICAgICAgICB0aGUgZmlsdGVyIGNyaXRlcmlhIChpZiBhbnkpLiAgQW4gZW1w dHkgZGF0YSANCmNvbnRhaW5lcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgaW5kaWNhdGVz IHRoYXQgdGhlIHJlcXVlc3QgZGlkIG5vdCBwcm9kdWNlIGFueSANCnJlc3VsdHMuIjsNCiAgICAg ICAgICAgICAgICB9DQogICAgICAgIH0NCiAgICB9DQpJZiBpdCBpcyBmZWFzaWJsZSwgaSBjYW4g ZGVmaW5lIG90aGVycy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIA0Kt6K8/sjLOiAgImkycnMiIDxpMnJzLWJvdW5jZXNAaWV0Zi5vcmc+DQoyMDE1LzA2LzI0 IDAwOjUyDQoNCsrVvP7Iyw0KPGktZC1hbm5vdW5jZUBpZXRmLm9yZz4sIA0Ks63LzQ0KaTJyc0Bp ZXRmLm9yZw0K1vfM4g0KW2kycnNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaTJycy1lcGhlbWVy YWwtc3RhdGUtMDAudHh0DQoNCg0KDQoNCg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyANCmRpcmVjdG9yaWVzLg0K IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEludGVyZmFjZSB0byB0aGUgUm91dGlu ZyBTeXN0ZW0gV29ya2luZyANCkdyb3VwIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAg ICAgICAgICA6IEkyUlMgRXBoZW1lcmFsIFN0YXRlIFJlcXVpcmVtZW50cw0KICAgICAgICBBdXRo b3JzICAgICAgICAgOiBKZWZmIEhhYXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgU3VzYW4g SGFyZXMNCiAgICAgICAgICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1pMnJz LWVwaGVtZXJhbC1zdGF0ZS0wMC50eHQNCiAgICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAg IDogMTMNCiAgICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNS0wNi0yMw0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgY292ZXJzIHJlcXVlc3RzIHRvIHRoZSBuZXRtb2Qg YW5kIG5ldGNvbmYgV29ya2luZw0KICAgR3JvdXBzIGZvciBmdW5jdGlvbmFsaXR5IHRvIHN1cHBv cnQgdGhlIGVwaGVtZXJhbCBzdGF0ZSByZXF1aXJlbWVudHMNCiAgIHRvIGltcGxlbWVudCB0aGUg STJSUyBhcmNoaXRlY3R1cmUuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2 ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgDQpzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaTJycyBtYWlsaW5n IGxpc3QNCmkycnNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaTJycw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21p dHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRl bmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBh cmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlv biwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVz IGltbWVkaWF0ZWx5Lg0K --=_alternative 0012D25448257E78_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIEouIEhhYXMgYW5kIFMuIEhhcmVz LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZl IHNvbWUgZG91YnQgYWJvdXQgJnF1b3Q7ZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0w MCZxdW90Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PjEuQ2hhcHRlciA2IFJlcXVpcmVtZW50cyByZWdhcmRpbmcgSWRlbnRpdHksDQpTZWNvbmRhcnkt SWRlbnRpdHkgYW5kIFByaW9yaXR5PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5JMlJTIHBlcm1pdHMgUlBDIG9wZXJhdGlvbiB0byBjYXJyeQ0KcHJpb3Jp dHkgYW5kIGEgc2Vjb25kYXJ5IGlkZW50aXR5IGFzIGF0dHJpYnV0ZSBwYXJhbWV0ZXJzLjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gdGhpcyBkcmFmdCwgaXQg ZGVzY3JpYmVzIHRoYXQgJnF1b3Q7VGhpcw0Kc2Vjb25kYXJ5IGlkZW50aXR5IG1ldGEtZGF0YSBN VVNUIGJlIHJlYWQtb25seS4gb3BlcmF0aW9ucyBhdHRlbXB0aW5nIHRvDQphbHRlciBpdCBNVVNU IGJlIHNpbGVudGx5IGlnbm9yZWQuICZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+U2luY2UgaWRlbnRpdHkgYXR0cmlidXRlIGNhbm5vdCBiZSBjaGFuZ2Vk DQp1bnRpbCB0aGUgc2Vzc2lvbiB0ZXJtaW5hdGVzLCB3aHkgZG9uJ3Qgd2UgcGVybWl0IGNsaWVu dCB0byBzZW5kIGhlbGxvDQptZXNzYWdlIHdpdGggc3VjaCBpbmZvcyBkdXJpbmc8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO3Nlc3Npb24gZXN0YWJsaXNo bWVudC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO2Uu Zyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJmx0O2hlbGxvIHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpi YXNlOjEuMCZxdW90OyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2NhcGFiaWxpdGllcyZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZsdDtjYXBhYmlsaXR5Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3VybjppZXRmOnBhcmFtczpu ZXRjb25mOmJhc2U6MS4wPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L2NhcGFiaWxpdHkmZ3Q7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7Y2FwYWJpbGl0eSZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1cm46aWV0ZjpwYXJh bXM6aTJyczpjYXBhYmlsaXR5OmkycnM6MS4wP3NlY29uZGFyeS1pZGVudGl0eT11c2VyMSZhbXA7 cHJpb3JpdHk9MTA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsvY2FwYWJpbGl0eSZndDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9j YXBhYmlsaXRpZXMmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7Jmx0Oy9oZWxsbyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkl0IG1lYW5zIGluIHRoaXMgc2Vzc2lvbiwgdGhlIHNlY29uZGFyeS1p ZGVudGl0eQ0KaXMgbmFtZWQgJnF1b3Q7dXNlcjEmcXVvdDssIHRoZSBkZWZhdWx0IHByaW9yaXR5 IGlzIDEwICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+dGhlbixpZiB0aGUgc2Vzc2lvbiB3YW50cyB0byBjaGFuZ2UNCml0cyBwcmlvcml0eSB3 aGlsZSBSUEMgb3BlcmF0aW9uLGFzIGZvbGxvd3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O2ZvbyB4bWxuczppMnJzPSZx dW90OzwvZm9udD48YSBocmVmPWh0dHBzOi8vaWV0Zi5leGFtcGxlLmNvbS9pMnJzPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwczovL2lldGYuZXhhbXBsZS5jb20vaTJyczwvZm9u dD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90Ow0KaTJyczppMnJzLXBy aW9yaXR5PSZxdW90OzQ3JnF1b3Q7Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJmx0Oy9m b28mZ3Q7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SXQgbWVhbnMgbm93IGluIHRoaXMgc2Vzc2lvbiwgdGhlIHNlY29uZGFyeS1pZGVudGl0eQ0KaXMg bmFtZWQgJnF1b3Q7dXNlcjEmcXVvdDssIHRoZSBwcmlvcml0eSBpcyA0NyAmbmJzcDs8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmZ1cnRoZXJtb3JlLCB3 ZSBjYW4gZGVmaW5lICZsdDtzZXQtaTJycy1wcmlvcml0eSZndDsNCnRvIGNoYW5nZSBjdXJyZW50 IHNlc3Npb24ncyBwcmlvcml0eSxzdWNoIGFzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZsdDtzZXQtaTJycy1wcmlvcml0eQ0KeG1sbnM6 aTJycz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6aTJyczpjYXBhYmlsaXR5OmkycnM6MS4wJnF1b3Q7 Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZsdDtwcmlvcml0eSZndDsyMCZsdDsvcHJpb3JpdHkmZ3Q7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZs dDsvc2V0LWkycnMtcHJpb3JpdHkmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Mi5JbiB0aGlzIGRyYWZ0LCBQcmlvcml0eSBpcyBkZWZpbmVkDQph cyBhIG51bWVyaWMgdmFsdWUsaG93IGFib3V0IGl0cyByYW5nZSBzdGF0ZW1lbnRzPyBJcyAmcXVv dDtpMnJzLXByaW9yaXR5DQo9IDI1NSZxdW90OyBpcyB0aGUgaGlnaGVzdD88L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuY29uZmlnIGVwaGVtZXJhbDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gdGhpcyBkcmFmdCxU aGUgWUFORyAmcXVvdDtjb25maWcmcXVvdDsNCmtleXdvcmQgaXMgZXh0ZW5kZWQsbGlrZSAmcXVv dDtjb25maWcgdHJ1ZS9mYWxzZS9lcGhlbWVyYWwmcXVvdDsgLGFuZCB0aGUNCmJhc2ljIG5ldGNv bmYgb3BlcmF0aW9uIHNob3VsZCBiZSBleHRlbmRlZCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPmxpa2UgJnF1b3Q7Z2V0LWNvbmZpZyZxdW90OyAmcXVvdDtlZGl0 LWNvbmZpZyZxdW90Ow0KYW5kIHNvIG9uLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+d2h5IGRvbid0IHdlIGRlZmluZSBhIG5ldyBraW5kIG9mIG9wZXJhdGlvbnMs bGlrZQ0KJnF1b3Q7Z2V0LWkycnMmcXVvdDsgJnF1b3Q7ZWRpdC1pMnJzJnF1b3Q7PyA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRha2UgZGVmaW5pdGlvbiBvZiAm cXVvdDtnZXQtaTJycyZxdW90Ow0KZm9yIGV4YW1wbGUuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcnBjDQpnZXQt aTJycyB7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KZGVzY3JpcHRpb24gJnF1b3Q7VGhp cyBvcGVyYXRpb24gY2FuIGJlIHVzZWQgdG8gZ2V0IGRhdGEgZnJvbSBpMnJzDQpkYXRhJnF1b3Q7 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmlucHV0IHs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbGVhZiBwcml2YXRlIHs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpkZXNjcmlwdGlvbiAmcXVvdDtJZiB0aGUgdmFsdWUg aXMgdHJ1ZSwgaXQgbWVhbnMgb25seSBkYXRhIG93bmVkDQpieSA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDt0aGUgc2FtZSBpZGVudGl0eSB3aWxsIGJlIHJldHJpZXZlZC4gT3Ro ZXJ3aXNlLCBhbGwgaTJycyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDtkYXRh IHdpbGwgYmUgcmV0dXJuZWQuJnF1b3Q7OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCnR5 cGUgYm9vbGVhbjs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpkZWZhdWx0IGZhbHNlOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGFueXhtbCBmaWx0ZXIgezwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmRlc2NyaXB0aW9u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZxdW90O1N1YnRyZWUgZmlsdGVy IHRvIHVzZS4mcXVvdDs7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IH08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQp9PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0Kb3V0cHV0 IHs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgYW55eG1sIGRhdGEgezwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCmRlc2NyaXB0aW9u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZxdW90O0NvcHkgb2YgdGhlIGky cnMgZGF0YSB0aGF0IG1hdGNoZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7dGhlIGZpbHRlciBjcml0ZXJpYSAoaWYgYW55KS4gJm5ic3A7QW4gZW1wdHkgZGF0YSBj b250YWluZXI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7aW5kaWNh dGVzIHRoYXQgdGhlIHJlcXVlc3QgZGlkIG5vdCBwcm9kdWNlIGFueSByZXN1bHRzLiZxdW90Ozs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCn08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgfTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+SWYgaXQgaXMgZmVhc2libGUsIGkgY2FuIGRlZmluZSBvdGhl cnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwOyZx dW90O2kycnMmcXVvdDsgJmx0O2kycnMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxNS8wNi8yNCAwMDo1MjwvZm9udD4NCjx0 ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbHQ7aS1kLWFu bm91bmNlQGlldGYub3JnJmd0OywgPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pMnJzQGlldGYub3JnPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5baTJyc10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1pMnJzLWVwaGVt ZXJhbC1zdGF0ZS0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJs ZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy48YnI+DQogVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSW50ZXJmYWNlIHRvIHRoZSBSb3V0aW5nIFN5 c3RlbSBXb3JraW5nDQpHcm91cCBvZiB0aGUgSUVURi48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7VGl0bGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6 DQpJMlJTIEVwaGVtZXJhbCBTdGF0ZSBSZXF1aXJlbWVudHM8YnI+DQogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7QXV0aG9ycyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBKZWZmDQpI YWFzPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtTdXNhbiBIYXJlczxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQpGaWxlbmFtZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6IGRyYWZ0LWlldGYtaTJy cy1lcGhlbWVyYWwtc3RhdGUtMDAudHh0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhZ2VzICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiAxMzxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpEYXRlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7OiAyMDE1LTA2LTIzPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZu YnNwOyBUaGlzIGRvY3VtZW50IGNvdmVycyByZXF1ZXN0cyB0byB0aGUgbmV0bW9kIGFuZCBuZXRj b25mIFdvcmtpbmc8YnI+DQogJm5ic3A7IEdyb3VwcyBmb3IgZnVuY3Rpb25hbGl0eSB0byBzdXBw b3J0IHRoZSBlcGhlbWVyYWwgc3RhdGUgcmVxdWlyZW1lbnRzPGJyPg0KICZuYnNwOyB0byBpbXBs ZW1lbnQgdGhlIEkyUlMgYXJjaGl0ZWN0dXJlLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRh dGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjwvZm9udD48L3R0 PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJy cy1lcGhlbWVyYWwtc3RhdGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvPC9mb250PjwvdHQ+ PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPGJyPg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUtMDAiPjx0 dD48Zm9udCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaTJy cy1lcGhlbWVyYWwtc3RhdGUtMDA8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48YnI+DQo8 YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6PGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy8iPjx0dD48Zm9udCBzaXplPTI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmkycnMgbWFpbGlu ZyBsaXN0PGJyPg0KaTJyc0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPjx0dD48Zm9udCBzaXplPTI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzPC9mb250PjwvdHQ+PC9hPjx0 dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQoNCjxicj48cHJlPjxmb250 IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5z bWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGlu dGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91 IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0 aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoNCjxicj48cHJlPjxmb250IGNv bG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0 dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVu ZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFy ZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9u LCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMg aW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 0012D25448257E78_=-- From nobody Mon Jul 6 06:54:07 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC741A87CE; Mon, 6 Jul 2015 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id plidVD77ZCg6; Mon, 6 Jul 2015 06:54:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 213941A87D7; Mon, 6 Jul 2015 06:53:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706135359.13216.48896.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 06:53:59 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l2-network-topology-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:54:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : A YANG Data Model for Layer-2 Network Topologies Authors : Jie Dong Xiugang Wei Filename : draft-ietf-i2rs-yang-l2-network-topology-01.txt Pages : 19 Date : 2015-07-06 Abstract: This document defines a YANG data model for Layer 2 network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l2-network-topology-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l2-network-topology-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 13 15:33:00 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516DF1A1B59; Wed, 8 Jul 2015 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 dYivpbQ_Qax2; Wed, 8 Jul 2015 10:21:18 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 EAC0D1A1B56; Wed, 8 Jul 2015 10:21:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.203.226; From: "Susan Hares" To: , Date: Wed, 8 Jul 2015 13:21:08 -0400 Message-ID: <00c301d0b9a2$7b01cb20$71056160$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C4_01D0B980.F3F02B20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC5ocN3mMUaARFOS3ulnbMwg3hixg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Mon, 13 Jul 2015 15:32:58 -0700 Cc: "'Zhangxian \(Xian\)'" , db3546@att.com, 'Alia Atlas' , 'Jeffrey Haas' , 'Benoit Claise' , "'Alvaro Retana \(aretana\)'" , 'Lou Berger' , 'Fatai Zhang' Subject: [i2rs] I2RS Topology discussion with TEAS TE topology authors X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 17:21:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C4_01D0B980.F3F02B20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all: The I2RS Topology will be meeting with the TEAS authors on Monday night at 20:00 (the last session ends at 19:40) to discuss coordination of Yang Topology modules for TEAS TE and I2RS Ephemeral state models. Room location will be announced later this week. We welcome all authors and interested participants. This is an in-depth session side-bar meeting. I will send a list of drafts for those wishing to join our discussion. The authors will also send a github locations for the modules. Sue Hares ------=_NextPart_000_00C4_01D0B980.F3F02B20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = all:

 

The I2RS Topology will be meeting with the TEAS = authors on Monday night at 20:00 (the last session ends at 19:40) to = discuss coordination of Yang Topology modules for TEAS TE and I2RS = Ephemeral state models.

 

Room = location will be announced later this week.  We welcome all authors = and interested participants.  This is an in-depth session side-bar = meeting. I will send a list of drafts for those wishing to join our = discussion.  The authors will also send a github locations for the = modules.

 

Sue Hares

------=_NextPart_000_00C4_01D0B980.F3F02B20-- From nobody Mon Jul 13 15:45:05 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7291A86E8; Mon, 13 Jul 2015 15:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.222 X-Spam-Level: X-Spam-Status: No, score=0.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, SPF_HELO_PASS=-0.001, 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 4I6-_bUSkwzl; Mon, 13 Jul 2015 15:45:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DF1DF1A86F6; Mon, 13 Jul 2015 15:45:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 79DD21E436; Mon, 13 Jul 2015 18:46:52 -0400 (EDT) Date: Mon, 13 Jul 2015 18:46:52 -0400 From: Jeffrey Haas To: dai.xianxian@zte.com.cn Message-ID: <20150713224652.GB5779@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, jhaas@juniper.net, internet-drafts@ietf.org, akatlas@gmail.com, i2rs , i-d-announce@ietf.org, shares@ndzh.com Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:45:04 -0000 On Sat, Jul 04, 2015 at 11:25:29AM +0800, dai.xianxian@zte.com.cn wrote: > I have some doubt about "draft-ietf-i2rs-ephemeral-state-00". > > 1.Chapter 6 Requirements regarding Identity, Secondary-Identity and > Priority > > I2RS permits RPC operation to carry priority and a secondary identity as > attribute parameters. > In this draft, it describes that "This secondary identity meta-data MUST > be read-only. operations attempting to alter it MUST be silently ignored. > " > Since identity attribute cannot be changed until the session terminates, > why don't we permit client to send hello message with such infos during > session establishment. > e.g, > > > > urn:ietf:params:netconf:base:1.0 > > > > urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10 > > > > It means in this session, the secondary-identity is named "user1", the > default priority is 10 This would be an acceptable means of encoding the secondary-identity. Does anyone working on a netconf implementation have any opinions about this form vs. what is in the draft? Note that the priority MUST not be user-supplied. It should be derived from the credentials. Letting the user set the priority may be inappropriate security. > then,if the session wants to change its priority while RPC operation,as > follows > i2rs:i2rs-priority="47"> > ... > > It means now in this session, the secondary-identity is named "user1", the > priority is 47 > > furthermore, we can define to change current session's > priority,such as > xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0"> > 20 > I believe having the priority set per-session likely matches our use case. In the event a different priority is expected, the user would use a different session with different credentials. > 2.In this draft, Priority is defined as a numeric value,how about its > range statements? Is "i2rs-priority = 255" is the highest? At the moment, I think we're a bit early on this specific detail. Once we have further clarification from the netconf working group, we can clarify this point. > 3.config ephemeral > In this draft,The YANG "config" keyword is extended,like "config > true/false/ephemeral" ,and the basic netconf operation should be extended, > like "get-config" "edit-config" and so on. > why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? There has been some level of feedback from the netmod/netconf Working Group participants that this might be the way to go. Consider the prior proposal draft-bjorklund-netmod-operational. The specific details of this will resolve once the underlying concepts of how we'll represent the ephemeral configuration state have been better defined. The proposals in the current draft are merely discussion points to try to start a conversation as to what the mechanism could look like. We're looking forward to that discussion within netconf. -- Jeff From nobody Mon Jul 13 15:58:33 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF331A8716 for ; Mon, 13 Jul 2015 15:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.178 X-Spam-Level: X-Spam-Status: No, score=-0.178 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nup3CGG4qto5 for ; Mon, 13 Jul 2015 15:58:31 -0700 (PDT) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 BCD4E1A871A for ; Mon, 13 Jul 2015 15:58:24 -0700 (PDT) Received: by laem6 with SMTP id m6so19400021lae.0 for ; Mon, 13 Jul 2015 15:58:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6Cr8Ox3qRzzzS7poFrnUHfMPrm7y28ek6+8W1evirBE=; b=DCySI8x2n8az4oTpgcA9kfO6HfO/HAyP3FAX8wpv2XTP8z0voI1X778c+bH1HLRS9W THbDN6o+BEvz8WF0AEY+o4LbxqKsgl17CrVBAq1EPbxuEaLuHWb6be5z7MNHB6mToLwp BwvTbh9DVx+NvdZJ8BSCEheUVFHkg99vlf6kCp5keklMg9ee6P9JLqMmnVrW61QVLLCe unpHjghHB2K2JVEk7Kl+tkm8i2Th67LTa4yMUp/iMJCwpIaGAOkZSs7wpByGb8tNwkHm wWkMLgrjfGIcRbpAeWvSplCtoXog6rtXbe5aCF07N00jsJxKuosX5+7EpyXxCwqgVP/d MDZg== X-Gm-Message-State: ALoCoQmbK3MRU6IP97CyEcaruwBMtIzYvG9w4uRcgFH0iejNhdOlwXaMt4sbUl7+Z+TUKyUPvDAY MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr34286841lbc.82.1436828303005; Mon, 13 Jul 2015 15:58:23 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 13 Jul 2015 15:58:22 -0700 (PDT) In-Reply-To: <20150713224652.GB5779@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> Date: Mon, 13 Jul 2015 15:58:22 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1134dcc89ab4b7051ac9a820 Archived-At: Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , internet-drafts@ietf.org, Alia Atlas , i2rs , i-d-announce@ietf.org, Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 22:58:33 -0000 --001a1134dcc89ab4b7051ac9a820 Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas wrote: > On Sat, Jul 04, 2015 at 11:25:29AM +0800, dai.xianxian@zte.com.cn wrote: > > I have some doubt about "draft-ietf-i2rs-ephemeral-state-00". > > > > 1.Chapter 6 Requirements regarding Identity, Secondary-Identity and > > Priority > > > > I2RS permits RPC operation to carry priority and a secondary identity as > > attribute parameters. > > In this draft, it describes that "This secondary identity meta-data MUST > > be read-only. operations attempting to alter it MUST be silently ignored. > > " > > Since identity attribute cannot be changed until the session terminates, > > why don't we permit client to send hello message with such infos during > > session establishment. > > e.g, > > > > > > > > urn:ietf:params:netconf:base:1.0 > > > > > > > > > urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10 > > > > > > > > It means in this session, the secondary-identity is named "user1", the > > default priority is 10 > > This would be an acceptable means of encoding the secondary-identity. Does > anyone working on a netconf implementation have any opinions about this > form > vs. what is in the draft? > > Note that the priority MUST not be user-supplied. It should be derived > from > the credentials. Letting the user set the priority may be inappropriate > security. > > This approach would mean that the I2RS client acting as a broker would need a different session for each secondary client. It seems more useful to allow the client to use 1 session, and just require that each edit be from a specific secondary identity. (e.g., add a secondary-identity parameter to the edit operation). The proposed solution of an XML attribute allows every node in an edit to be from a different secondary identity. > then,if the session wants to change its priority while RPC operation,as > > follows > > > i2rs:i2rs-priority="47"> > > ... > > > > It means now in this session, the secondary-identity is named "user1", > the > > priority is 47 > > > > furthermore, we can define to change current > session's > > priority,such as > > > xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0"> > > 20 > > > > I believe having the priority set per-session likely matches our use case. > In the event a different priority is expected, the user would use a > different session with different credentials. > I thought the client priority is configured in advance by the administrator. It makes no sense to have each client state their own priority. This is useless for resolving conflicts between clients. > > > 2.In this draft, Priority is defined as a numeric value,how about its > > range statements? Is "i2rs-priority = 255" is the highest? > > At the moment, I think we're a bit early on this specific detail. Once we > have further clarification from the netconf working group, we can clarify > this point. > IMO, priority 0 is the highest, and can only be used by the system itself. Priority 1 is the next highest. > > > 3.config ephemeral > > In this draft,The YANG "config" keyword is extended,like "config > > true/false/ephemeral" ,and the basic netconf operation should be > extended, > > like "get-config" "edit-config" and so on. > > why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? > > There has been some level of feedback from the netmod/netconf Working Group > participants that this might be the way to go. Consider the prior > proposal draft-bjorklund-netmod-operational. > > The specific details of this will resolve once the underlying concepts of > how we'll represent the ephemeral configuration state have been better > defined. The proposals in the current draft are merely discussion points > to > try to start a conversation as to what the mechanism could look like. > > We're looking forward to that discussion within netconf. > > -- Jeff > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a1134dcc89ab4b7051ac9a820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
On Sat, Jul 04, 2015 at 11:25:= 29AM +0800, dai.xianxian@zte.com= .cn wrote:
> I have some doubt about "draft-ietf-i2rs-ephemeral-state-00"= .
>
> 1.Chapter 6 Requirements regarding Identity, Secondary-Identity and > Priority
>
> I2RS permits RPC operation to carry priority and a secondary identity = as
> attribute parameters.
> In this draft, it describes that "This secondary identity meta-da= ta MUST
> be read-only. operations attempting to alter it MUST be silently ignor= ed.
> "
> Since identity attribute cannot be changed until the session terminate= s,
> why don't we permit client to send hello message with such infos d= uring
>=C2=A0 session establishment.
>=C2=A0 e.g,
>=C2=A0 =C2=A0 =C2=A0<hello xmlns=3D"urn:ietf:params:xml:ns:netc= onf:base:1.0">
>=C2=A0 =C2=A0 =C2=A0 <capabilities>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <capability>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 urn:ietf:params:netconf:base:1.0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </capability>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <capability>
>
> urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=3Duser1&am= p;priority=3D10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </capability>
>=C2=A0 =C2=A0 =C2=A0 </capabilities>
>=C2=A0 =C2=A0 </hello>
> It means in this session, the secondary-identity is named "user1&= quot;, the
> default priority is 10

This would be an acceptable means of encoding the secondary-identity.=C2=A0= Does
anyone working on a netconf implementation have any opinions about this for= m
vs. what is in the draft?

Note that the priority MUST not be user-supplied.=C2=A0 It should be derive= d from
the credentials.=C2=A0 Letting the user set the priority may be inappropria= te
security.




This app= roach would mean that the I2RS client acting as a broker
would ne= ed a different session for each secondary client.
It seems more u= seful to allow the client to use 1 session,
and just require that= each edit be from a specific secondary identity.

= (e.g., add a secondary-identity parameter to the edit operation).
The proposed solution of an XML attribute allows every node
in a= n edit to be from a different secondary identity.

=
> then,if the session wants to change its priority while RPC operation,a= s
> follows
>=C2=A0 =C2=A0 =C2=A0 <foo xmlns:i2rs=3D"https://ietf.exampl= e.com/i2rs"
> i2rs:i2rs-priority=3D"47">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0</foo>
> It means now in this session, the secondary-identity is named "us= er1", the
> priority is 47
>
> furthermore, we can define <set-i2rs-priority> to change current= session's
> priority,such as
>=C2=A0 =C2=A0 =C2=A0<set-i2rs-priority
> xmlns:i2rs=3D"urn:ietf:params:i2rs:capability:i2rs:1.0"><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<priority>20</priority> >=C2=A0 =C2=A0 =C2=A0</set-i2rs-priority>

I believe having the priority set per-session likely matches our use case.<= br> In the event a different priority is expected, the user would use a
different session with different credentials.

I thought the client priority is configured in advance by the
<= div>administrator.=C2=A0 It makes no sense to have each client
st= ate their own priority.=C2=A0 This is useless for resolving conflicts
=
between clients.



=C2=A0

> 2.In this draft, Priority is defined as a numeric value,how about its<= br> > range statements? Is "i2rs-priority =3D 255" is the highest?=

At the moment, I think we're a bit early on this specific detail.=C2=A0= Once we
have further clarification from the netconf working group, we can clarify this point.

IMO, priority 0 is the high= est, and can only be used
by the system itself.=C2=A0 Priority 1 = is the next highest.

=C2=A0

> 3.config ephemeral
> In this draft,The YANG "config" keyword is extended,like &qu= ot;config
> true/false/ephemeral" ,and the basic netconf operation should be = extended,
> like "get-config" "edit-config" and so on.
> why don't we define a new kind of operations,like "get-i2rs&q= uot; "edit-i2rs"?

There has been some level of feedback from the netmod/netconf Working Group=
participants that this might be the way to go.=C2=A0 Consider the prior
proposal draft-bjorklund-netmod-operational.

The specific details of this will resolve once the underlying concepts of how we'll represent the ephemeral configuration state have been better<= br> defined.=C2=A0 The proposals in the current draft are merely discussion poi= nts to
try to start a conversation as to what the mechanism could look like.

We're looking forward to that discussion within netconf.

-- Jeff


Andy
= =C2=A0

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

--001a1134dcc89ab4b7051ac9a820-- From nobody Mon Jul 13 16:08:07 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B991A872C; Mon, 13 Jul 2015 16:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 pGc9SyJaoFzH; Mon, 13 Jul 2015 16:08:03 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 405E41A872B; Mon, 13 Jul 2015 16:08:03 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id D7C8F1E436; Mon, 13 Jul 2015 19:09:52 -0400 (EDT) Date: Mon, 13 Jul 2015 19:09:52 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20150713230952.GI13783@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , internet-drafts@ietf.org, Alia Atlas , i2rs , i-d-announce@ietf.org, Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:08:04 -0000 Andy, On Mon, Jul 13, 2015 at 03:58:22PM -0700, Andy Bierman wrote: > On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas wrote: > > Note that the priority MUST not be user-supplied. It should be derived > > from > > the credentials. Letting the user set the priority may be inappropriate > > security. > > This approach would mean that the I2RS client acting as a broker > would need a different session for each secondary client. > It seems more useful to allow the client to use 1 session, > and just require that each edit be from a specific secondary identity. > > (e.g., add a secondary-identity parameter to the edit operation). > The proposed solution of an XML attribute allows every node > in an edit to be from a different secondary identity. I don't object to moving secondary-identity into something that may be able to vary on a per-edit transaction. I had started to write that priority is associated with their client and that edits are likely done on behalf of a given secondary-id. Then I had a realization prompted by the proxy use case: In order to carry through the appropriate priority, it would be necessary to similarly carry through the primary identity in order to have that identity/priority association. This seems a bit contrary to the idea of a proxy operating as "root". Joel/Alia, would you please comment how you intended the multi-headed control case to operate with regard to associated identity and priority? > > I believe having the priority set per-session likely matches our use case. > > In the event a different priority is expected, the user would use a > > different session with different credentials. > > > > I thought the client priority is configured in advance by the > administrator. It makes no sense to have each client > state their own priority. This is useless for resolving conflicts > between clients. Priority associated to client identity is what is intended. > IMO, priority 0 is the highest, and can only be used > by the system itself. Priority 1 is the next highest. This is probably reasonable. It also means you've already tripped into the usual descriptive issue of lower is better; better is not higher. :-) -- Jeff From nobody Mon Jul 13 16:32:56 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60B1A8791; Mon, 13 Jul 2015 16:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=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 PI4SqbYOgArU; Mon, 13 Jul 2015 16:32:54 -0700 (PDT) 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 628A81A878E; Mon, 13 Jul 2015 16:32:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id ED2411C0234; Mon, 13 Jul 2015 16:32:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 79EF81C00F7; Mon, 13 Jul 2015 16:32:52 -0700 (PDT) To: Jeffrey Haas , dai.xianxian@zte.com.cn References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A44A68.6020208@joelhalpern.com> Date: Mon, 13 Jul 2015 19:31:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150713224652.GB5779@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, jhaas@juniper.net, internet-drafts@ietf.org, akatlas@gmail.com, i2rs , i-d-announce@ietf.org, shares@ndzh.com Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:32:55 -0000 Secondary identity can (and in fact is expected to) change during the session an I2RS client has with an I2RS Agent. Specifically, if the client is acting as a broker, it will need to associated different operations with different secondary identities. Priority is, as I understand it, per session. I tend to think of priority as coming from AAA, not from the Client, but that is something we can discuss. Yours, Joel On 7/13/15 6:46 PM, Jeffrey Haas wrote: > On Sat, Jul 04, 2015 at 11:25:29AM +0800, dai.xianxian@zte.com.cn wrote: >> I have some doubt about "draft-ietf-i2rs-ephemeral-state-00". >> >> 1.Chapter 6 Requirements regarding Identity, Secondary-Identity and >> Priority >> >> I2RS permits RPC operation to carry priority and a secondary identity as >> attribute parameters. >> In this draft, it describes that "This secondary identity meta-data MUST >> be read-only. operations attempting to alter it MUST be silently ignored. >> " >> Since identity attribute cannot be changed until the session terminates, >> why don't we permit client to send hello message with such infos during >> session establishment. >> e.g, >> >> >> >> urn:ietf:params:netconf:base:1.0 >> >> >> >> urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10 >> >> >> >> It means in this session, the secondary-identity is named "user1", the >> default priority is 10 > > This would be an acceptable means of encoding the secondary-identity. Does > anyone working on a netconf implementation have any opinions about this form > vs. what is in the draft? > > Note that the priority MUST not be user-supplied. It should be derived from > the credentials. Letting the user set the priority may be inappropriate > security. > >> then,if the session wants to change its priority while RPC operation,as >> follows >> > i2rs:i2rs-priority="47"> >> ... >> >> It means now in this session, the secondary-identity is named "user1", the >> priority is 47 >> >> furthermore, we can define to change current session's >> priority,such as >> > xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0"> >> 20 >> > > I believe having the priority set per-session likely matches our use case. > In the event a different priority is expected, the user would use a > different session with different credentials. > >> 2.In this draft, Priority is defined as a numeric value,how about its >> range statements? Is "i2rs-priority = 255" is the highest? > > At the moment, I think we're a bit early on this specific detail. Once we > have further clarification from the netconf working group, we can clarify > this point. > >> 3.config ephemeral >> In this draft,The YANG "config" keyword is extended,like "config >> true/false/ephemeral" ,and the basic netconf operation should be extended, >> like "get-config" "edit-config" and so on. >> why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? > > There has been some level of feedback from the netmod/netconf Working Group > participants that this might be the way to go. Consider the prior > proposal draft-bjorklund-netmod-operational. > > The specific details of this will resolve once the underlying concepts of > how we'll represent the ephemeral configuration state have been better > defined. The proposals in the current draft are merely discussion points to > try to start a conversation as to what the mechanism could look like. > > We're looking forward to that discussion within netconf. > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jul 13 16:38:34 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE31A87B9 for ; Mon, 13 Jul 2015 16:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, J_CHICKENPOX_84=0.6, J_CHICKENPOX_92=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 P-Es3SgTCmfZ for ; Mon, 13 Jul 2015 16:38:31 -0700 (PDT) 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 740A81A87B8 for ; Mon, 13 Jul 2015 16:38:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 601701C0234; Mon, 13 Jul 2015 16:38:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 A902E1C00F7; Mon, 13 Jul 2015 16:38:30 -0700 (PDT) From: Joel Halpern To: Jeffrey Haas References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> Message-ID: <55A44BB9.2070900@joelhalpern.com> Date: Mon, 13 Jul 2015 19:37:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150713224652.GB5779@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:38:32 -0000 Secondary identity can (and in fact is expected to) change during the session an I2RS client has with an I2RS Agent. Specifically, if the client is acting as a broker, it will need to associated different operations with different secondary identities. Priority is, as I understand it, per session. I tend to think of priority as coming from AAA, not from the Client, but that is something we can discuss. Yours, Joel On 7/13/15 6:46 PM, Jeffrey Haas wrote: > On Sat, Jul 04, 2015 at 11:25:29AM +0800, dai.xianxian@zte.com.cn wrote: >> I have some doubt about "draft-ietf-i2rs-ephemeral-state-00". >> >> 1.Chapter 6 Requirements regarding Identity, Secondary-Identity and >> Priority >> >> I2RS permits RPC operation to carry priority and a secondary identity as >> attribute parameters. >> In this draft, it describes that "This secondary identity meta-data MUST >> be read-only. operations attempting to alter it MUST be silently ignored. >> " >> Since identity attribute cannot be changed until the session terminates, >> why don't we permit client to send hello message with such infos during >> session establishment. >> e.g, >> >> >> >> urn:ietf:params:netconf:base:1.0 >> >> >> >> urn:ietf:params:i2rs:capability:i2rs:1.0?secondary-identity=user1&priority=10 >> >> >> >> It means in this session, the secondary-identity is named "user1", the >> default priority is 10 > > This would be an acceptable means of encoding the secondary-identity. Does > anyone working on a netconf implementation have any opinions about this form > vs. what is in the draft? > > Note that the priority MUST not be user-supplied. It should be derived from > the credentials. Letting the user set the priority may be inappropriate > security. > >> then,if the session wants to change its priority while RPC operation,as >> follows >> > i2rs:i2rs-priority="47"> >> ... >> >> It means now in this session, the secondary-identity is named "user1", the >> priority is 47 >> >> furthermore, we can define to change current session's >> priority,such as >> > xmlns:i2rs="urn:ietf:params:i2rs:capability:i2rs:1.0"> >> 20 >> > > I believe having the priority set per-session likely matches our use case. > In the event a different priority is expected, the user would use a > different session with different credentials. > >> 2.In this draft, Priority is defined as a numeric value,how about its >> range statements? Is "i2rs-priority = 255" is the highest? > > At the moment, I think we're a bit early on this specific detail. Once we > have further clarification from the netconf working group, we can clarify > this point. > >> 3.config ephemeral >> In this draft,The YANG "config" keyword is extended,like "config >> true/false/ephemeral" ,and the basic netconf operation should be extended, >> like "get-config" "edit-config" and so on. >> why don't we define a new kind of operations,like "get-i2rs" "edit-i2rs"? > > There has been some level of feedback from the netmod/netconf Working Group > participants that this might be the way to go. Consider the prior > proposal draft-bjorklund-netmod-operational. > > The specific details of this will resolve once the underlying concepts of > how we'll represent the ephemeral configuration state have been better > defined. The proposals in the current draft are merely discussion points to > try to start a conversation as to what the mechanism could look like. > > We're looking forward to that discussion within netconf. > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jul 13 16:38:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00D41A87C2 for ; Mon, 13 Jul 2015 16:38:43 -0700 (PDT) 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 xQhJAt-RINzp for ; Mon, 13 Jul 2015 16:38:39 -0700 (PDT) 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 287671A87C1 for ; Mon, 13 Jul 2015 16:38:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 0180E1C04C8; Mon, 13 Jul 2015 16:38:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 780D01C0234; Mon, 13 Jul 2015 16:38:38 -0700 (PDT) From: Joel Halpern To: Jeffrey Haas References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> Message-ID: <55A44BC1.9070007@joelhalpern.com> Date: Mon, 13 Jul 2015 19:37:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150713230952.GI13783@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:38:44 -0000 To amplify my previous reply on priority, priority is associated with the I2RS Client. it does not change even if the client is acting on behalf of multiple secondary identities. (If the use case requires that variability, use multiple primary identities, with separate sessions.) Thus, the conflict error behavior is determined by the clients, not by what they are doing or the secondary identities they are working on behalf of. The WG considered (and I hope still considers) this acceptable on the basis that it is an error case anyway, and all we are doing is creating predictable behavior for the rror handling, not "correct" behavior. Yours, Joel On 7/13/15 7:09 PM, Jeffrey Haas wrote: > Andy, > > On Mon, Jul 13, 2015 at 03:58:22PM -0700, Andy Bierman wrote: >> On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas wrote: >>> Note that the priority MUST not be user-supplied. It should be derived >>> from >>> the credentials. Letting the user set the priority may be inappropriate >>> security. >> >> This approach would mean that the I2RS client acting as a broker >> would need a different session for each secondary client. >> It seems more useful to allow the client to use 1 session, >> and just require that each edit be from a specific secondary identity. >> >> (e.g., add a secondary-identity parameter to the edit operation). >> The proposed solution of an XML attribute allows every node >> in an edit to be from a different secondary identity. > > I don't object to moving secondary-identity into something that may be able > to vary on a per-edit transaction. > > I had started to write that priority is associated with their client and > that edits are likely done on behalf of a given secondary-id. Then I had a > realization prompted by the proxy use case: In order to carry through the > appropriate priority, it would be necessary to similarly carry through the > primary identity in order to have that identity/priority association. This > seems a bit contrary to the idea of a proxy operating as "root". > > Joel/Alia, would you please comment how you intended the multi-headed > control case to operate with regard to associated identity and priority? > >>> I believe having the priority set per-session likely matches our use case. >>> In the event a different priority is expected, the user would use a >>> different session with different credentials. >>> >> >> I thought the client priority is configured in advance by the >> administrator. It makes no sense to have each client >> state their own priority. This is useless for resolving conflicts >> between clients. > > Priority associated to client identity is what is intended. > >> IMO, priority 0 is the highest, and can only be used >> by the system itself. Priority 1 is the next highest. > > This is probably reasonable. It also means you've already tripped into the > usual descriptive issue of lower is better; better is not higher. :-) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jul 13 17:02:25 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345CC1A87D1 for ; Mon, 13 Jul 2015 17:02:24 -0700 (PDT) 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 q0HyVqM2I9H5 for ; Mon, 13 Jul 2015 17:02:22 -0700 (PDT) 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 D02F81A87D0 for ; Mon, 13 Jul 2015 17:02:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BAD951C04C8; Mon, 13 Jul 2015 17:02:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 DF9F71C038B; Mon, 13 Jul 2015 17:02:21 -0700 (PDT) To: Jeffrey Haas References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A45151.9060709@joelhalpern.com> Date: Mon, 13 Jul 2015 20:01:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150713234843.GK13783@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 00:02:24 -0000 In line toi make sure we keep context. Yours, Joel On 7/13/15 7:48 PM, Jeffrey Haas wrote: > Joel, > > On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: >> To amplify my previous reply on priority, priority is associated >> with the I2RS Client. it does not change even if the client is >> acting on behalf of multiple secondary identities. (If the use case >> requires that variability, use multiple primary identities, with >> separate sessions.) > > To attempt to reduce this to an example: > Basis case: Multiple clients speaking directly to an agent. Clients have > distinct priorities. Priority causes config to tie-break appropriately > among the various client interactions. Yes. > > Proxy case: Agent is against as "root" from a proxy, potentially with the > a single priority. As long as the proxy maintains the tie-breaking as if it > had implemented the agent operations, it's okay that the resultant nodes may > have the same priority associated with them? Having the client keep track of what it has modified, and noticing if there are direct conflicts among the applications it supports is indeed a way to handle it. Note that a client acting on behalf of multiple applications needs to make sure it keeps track of what it has done, and on whose behalf, for lots of reasons. > > Gloss: We still haven't concluded our discussion as to whether the nodes are > decorated as "owned by an identity" or "have a priority". From other discussions, I had assumed nodes had to be decorated with the owned-by identity. In the case of error, when a given clients entry is removed due to a higher priority client pre-empting it, the original client is to be notified of the error. If you don't have the owner decoration, that is impossible. Having said that, I was not expecting I2RS to give that owner or priority information back in any request, so I had always considered it an internal implementation matter how the associations were stored. Returning such information in response to a get is a nice-to-have, but is not to the best of my knowledge an I2RS requirement. > > Note that the gloss has an interesting impact. If nodes are expected to get > their priority via identity, this makes things very messy if you don't > maintain multiple identities to have distinct priorities in the proxy case. I am not sure where the complications comes from. The priority comes from the client that performed that operation. That identity needs to be available (as noted above). Secondary identities are recorded for traceability. Again, whether they are actually with the node, or only in the log, is not something on which I2RS has expressed a requirement. The requirement is that the information be provided in the request, and be logged. There is a good argument for requiring that the secondary identity be returned with any error notifications, so as to make the broker clients job more tractable. But I don't think we said that anywhere. > > -- Jeff > From nobody Mon Jul 13 17:37:17 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763211A8898 for ; Mon, 13 Jul 2015 17:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 5bGLmi3_rHdo for ; Mon, 13 Jul 2015 17:37:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 7FD191A885B for ; Mon, 13 Jul 2015 17:37:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.34; From: "Susan Hares" To: Date: Mon, 13 Jul 2015 20:37:10 -0400 Message-ID: <00c101d0bdcd$38ee6fc0$aacb4f40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C2_01D0BDAB.B1DCCFC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC9zPB6Pty6gDT7ScuAqYgI1cyzrg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Mahesh Jethanandani' , "'Ersue, Mehmet \(Nokia - DE/Munich\)'" , "'Benoit Claise \(bclaise\)'" , 'Alia Atlas' Subject: [i2rs] Warning - you may experience delays in responses from your I2RS co-chair X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 00:37:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C2_01D0BDAB.B1DCCFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS creative WG group: You may experience delays in email from this I2RS co-chair (fortunately Jeff Haas seems to be caught up with email.) this week. Unfortunately, this week I have required PhD exams on Wednesday and Thursday. I am cramming for the exams. Sue Hares ------=_NextPart_000_00C2_01D0BDAB.B1DCCFC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS = creative WG group:

 

You may = experience delays in email from this I2RS co-chair (fortunately Jeff = Haas seems to be caught up with email.) this week.   = Unfortunately, this week I have required PhD exams on Wednesday and = Thursday.   I am cramming for the exams.

 

Sue Hares =

------=_NextPart_000_00C2_01D0BDAB.B1DCCFC0-- From nobody Mon Jul 13 18:04:20 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370FB1A0025 for ; Mon, 13 Jul 2015 18:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 VU2JT_my18VD for ; Mon, 13 Jul 2015 18:04:17 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (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 01ED31A0024 for ; Mon, 13 Jul 2015 18:04:16 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so132071186lbb.3 for ; Mon, 13 Jul 2015 18:04:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ashAzX6WhdaLJQK9kuZkYEIwb5dlwSRZa5np7AkV4rc=; b=OwUtRYWDZE2nYrEmR8zFg7amvwFOE289PpH/dbEsa+9IWVQjaXoSloCBdmjB26XO6n mAMmR+HIwCadE97jUfngLFl4kGCJkMpq/mdOnDHd7GJgzB/qGeFryF9eoV+00yUOp9Ms UQTGMdJeaBSflykuZdyrZS899s0fzYWzRXo+pzQOuCU4i7chJEQP+U98gmn/SybUaviH pyGmpUjmsv/DGiDDh7zeZIzE388K88daXbuF+aZy35tEAFjgelw5yTrOYpADsinAKYpJ FSWAm15x0RJ/hcY36lPKZn9mu8WUUVRZAKPPNP4gtY1kPWvzwTvtktFHJC9COfuIPyx0 ipSQ== X-Gm-Message-State: ALoCoQlsliRo/P7zrbJpunJ6ax3uvuqWi9pbRgxWBE7LasfLdIisyibQoLw584o95GX9y8dP/al+ MIME-Version: 1.0 X-Received: by 10.112.85.3 with SMTP id d3mr18105627lbz.33.1436835855261; Mon, 13 Jul 2015 18:04:15 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 13 Jul 2015 18:04:15 -0700 (PDT) In-Reply-To: <20150713234843.GK13783@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> Date: Mon, 13 Jul 2015 18:04:15 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1134946cc0f859051acb6aff Archived-At: Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , Alia Atlas , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 01:04:19 -0000 --001a1134946cc0f859051acb6aff Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas wrote: > Joel, > > On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: > > To amplify my previous reply on priority, priority is associated > > with the I2RS Client. it does not change even if the client is > > acting on behalf of multiple secondary identities. (If the use case > > requires that variability, use multiple primary identities, with > > separate sessions.) > > To attempt to reduce this to an example: > Basis case: Multiple clients speaking directly to an agent. Clients have > distinct priorities. Priority causes config to tie-break appropriately > among the various client interactions. > > Proxy case: Agent is against as "root" from a proxy, potentially with the > a single priority. As long as the proxy maintains the tie-breaking as if > it > had implemented the agent operations, it's okay that the resultant nodes > may > have the same priority associated with them? > > Gloss: We still haven't concluded our discussion as to whether the nodes > are > decorated as "owned by an identity" or "have a priority". > > Note that the gloss has an interesting impact. If nodes are expected to > get > their priority via identity, this makes things very messy if you don't > maintain multiple identities to have distinct priorities in the proxy case. > > OK -- it is becoming clearer now -- in order to support a broker, the priority is saved with the node, not the client. The operator configured priority is really the "best allowed". Let's say lower priorities are better, and client A is assigned the value 10. That means client A is allowed to use priorities 10 .. 255. Each edit from client A can have a priority that is associated with the secondary client. ... app27 42 An error is returned if is 9 or lower in this example. IMO this is better than requiring client A to open a session as a different user name for each priority value needed. -- Jeff > Andy --001a1134946cc0f859051acb6aff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Joel,

On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
> To amplify my previous reply on priority, priority is associated
> with the I2RS Client.=C2=A0 it does not change even if the client is > acting on behalf of multiple secondary identities.=C2=A0 (If the use c= ase
> requires that variability, use multiple primary identities, with
> separate sessions.)

To attempt to reduce this to an example:
Basis case: Multiple clients speaking directly to an agent.=C2=A0 Clients h= ave
distinct priorities.=C2=A0 Priority causes config to tie-break appropriatel= y
among the various client interactions.

Proxy case: Agent is against as "root" from a proxy, potentially = with the
a single priority.=C2=A0 As long as the proxy maintains the tie-breaking as= if it
had implemented the agent operations, it's okay that the resultant node= s may
have the same priority associated with them?

Gloss: We still haven't concluded our discussion as to whether the node= s are
decorated as "owned by an identity" or "have a priority"= ;.

Note that the gloss has an interesting impact.=C2=A0 If nodes are expected = to get
their priority via identity, this makes things very messy if you don't<= br> maintain multiple identities to have distinct priorities in the proxy case.=



OK -- it is becoming cl= earer now -- in order to support a broker, the
priority is saved = with the node, not the client.

The operator config= ured priority is really the "best allowed".
Let's s= ay lower priorities are better, and client A is assigned the
valu= e 10.=C2=A0 That means client A is allowed to use priorities 10 .. 255.

Each edit from client A can have a priority that is a= ssociated with
the secondary client.

=C2= =A0 =C2=A0<rpc>
=C2=A0 =C2=A0 =C2=A0 <edit-config>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<target><ephemeral />= </target>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<config> = =C2=A0... </config>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<s= econdary-identity>app27</secondary-identity>
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<priority>42</priority>
=C2= =A0 =C2=A0 =C2=A0 </edit-config>
=C2=A0 =C2=A0</rpc><= /div>

An error is returned if <priority> is 9 or l= ower in this example.

IMO this is better than requ= iring client A to open a session as a
different user name for eac= h priority value needed.



=
-- Jeff


Andy

--001a1134946cc0f859051acb6aff-- From nobody Mon Jul 13 18:43:50 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 888D91A88D0 for ; Mon, 13 Jul 2015 18:43:48 -0700 (PDT) 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 TK-06xvDVCdP for ; Mon, 13 Jul 2015 18:43:47 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7261A88CF for ; Mon, 13 Jul 2015 18:43:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4AFC9240C4A; Mon, 13 Jul 2015 18:43:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 B2837240470; Mon, 13 Jul 2015 18:43:46 -0700 (PDT) To: Andy Bierman References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A46915.3050702@joelhalpern.com> Date: Mon, 13 Jul 2015 21:42:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 01:43:48 -0000 The flexibility Jeff has described, and you have commented upon, is permitted but not required by (what I understand of) the agreements of the WG. If it can be easily done, it seems like a nice thing to do. Yours, Joel On 7/13/15 9:04 PM, Andy Bierman wrote: > > > On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas > wrote: > > Joel, > > On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: > > To amplify my previous reply on priority, priority is associated > > with the I2RS Client. it does not change even if the client is > > acting on behalf of multiple secondary identities. (If the use case > > requires that variability, use multiple primary identities, with > > separate sessions.) > > To attempt to reduce this to an example: > Basis case: Multiple clients speaking directly to an agent. Clients > have > distinct priorities. Priority causes config to tie-break appropriately > among the various client interactions. > > Proxy case: Agent is against as "root" from a proxy, potentially > with the > a single priority. As long as the proxy maintains the tie-breaking > as if it > had implemented the agent operations, it's okay that the resultant > nodes may > have the same priority associated with them? > > Gloss: We still haven't concluded our discussion as to whether the > nodes are > decorated as "owned by an identity" or "have a priority". > > Note that the gloss has an interesting impact. If nodes are > expected to get > their priority via identity, this makes things very messy if you don't > maintain multiple identities to have distinct priorities in the > proxy case. > > > > OK -- it is becoming clearer now -- in order to support a broker, the > priority is saved with the node, not the client. > > The operator configured priority is really the "best allowed". > Let's say lower priorities are better, and client A is assigned the > value 10. That means client A is allowed to use priorities 10 .. 255. > > Each edit from client A can have a priority that is associated with > the secondary client. > > > > > ... > app27 > 42 > > > > An error is returned if is 9 or lower in this example. > > IMO this is better than requiring client A to open a session as a > different user name for each priority value needed. > > > > -- Jeff > > > > Andy > From nobody Mon Jul 13 19:07:49 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 521D51A8912 for ; Mon, 13 Jul 2015 19:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yNSRpWjUUZRA for ; Mon, 13 Jul 2015 19:07:46 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (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 D867C1A8868 for ; Mon, 13 Jul 2015 19:07:45 -0700 (PDT) Received: by laem6 with SMTP id m6so21918756lae.0 for ; Mon, 13 Jul 2015 19:07:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Kk6Wx/CXiZcZZsaSKPzElniSsSYyaJ86AugbBjsmaww=; b=lVVN35FPIMR/w8jk7SsS4USlGfj48g71YrdnLkLsmh4RUKezWUpLH9AQ4riJriRtqK VevQcFp5BbpQt+eQPz2Zeld5IGItrm8x6rtWy7Yin8HLnrLyaVrZbLCkrbIKu6E8u2yv g8dVfZEI9ZHQjq0PTPxorPUNKm4EfGtAHrV8z8QmhU00PkoZcok+uSiHKudvuo0tSfI/ Zgjips4DN/3dSzJ0AksBO+VGdbiWFiqKpUXojq0gJ+4LMkwAT31hPNUBR80cpXJ090iA lJOCMvtCfst92dTXrM83A2v5vO4OcQdXgqUggCkIkcJ5fPYPhGIKSwlv4lK3YcUV2H33 FSCQ== X-Gm-Message-State: ALoCoQnIzNbp6GKCgXu+kxsmTCS18vgDyBL47YzVUqV7MDGFAW021725C8PZAhQED9hsFg06n6fR MIME-Version: 1.0 X-Received: by 10.152.225.164 with SMTP id rl4mr20020813lac.38.1436839664169; Mon, 13 Jul 2015 19:07:44 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 13 Jul 2015 19:07:44 -0700 (PDT) In-Reply-To: <55A46915.3050702@joelhalpern.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A46915.3050702@joelhalpern.com> Date: Mon, 13 Jul 2015 19:07:44 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11349aa6c84c76051acc4d4a Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:07:48 -0000 --001a11349aa6c84c76051acc4d4a Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern wrote: > The flexibility Jeff has described, and you have commented upon, is > permitted but not required by (what I understand of) the agreements of the > WG. If it can be easily done, it seems like a nice thing to do. > > It means the priority, client-ID, and 2nd-id all need to be saved per subtree. What happens if a client priority mapping is deleted or does not exist? Does that client just get the worst possible priority or is it an error or is all data deleted for that client? What if the server is aware a client id was removed completely? Does that matter for existing data for that client? Yours, > Joel > > Andy > On 7/13/15 9:04 PM, Andy Bierman wrote: > >> >> >> On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas > > wrote: >> >> Joel, >> >> On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: >> > To amplify my previous reply on priority, priority is associated >> > with the I2RS Client. it does not change even if the client is >> > acting on behalf of multiple secondary identities. (If the use >> case >> > requires that variability, use multiple primary identities, with >> > separate sessions.) >> >> To attempt to reduce this to an example: >> Basis case: Multiple clients speaking directly to an agent. Clients >> have >> distinct priorities. Priority causes config to tie-break >> appropriately >> among the various client interactions. >> >> Proxy case: Agent is against as "root" from a proxy, potentially >> with the >> a single priority. As long as the proxy maintains the tie-breaking >> as if it >> had implemented the agent operations, it's okay that the resultant >> nodes may >> have the same priority associated with them? >> >> Gloss: We still haven't concluded our discussion as to whether the >> nodes are >> decorated as "owned by an identity" or "have a priority". >> >> Note that the gloss has an interesting impact. If nodes are >> expected to get >> their priority via identity, this makes things very messy if you don't >> maintain multiple identities to have distinct priorities in the >> proxy case. >> >> >> >> OK -- it is becoming clearer now -- in order to support a broker, the >> priority is saved with the node, not the client. >> >> The operator configured priority is really the "best allowed". >> Let's say lower priorities are better, and client A is assigned the >> value 10. That means client A is allowed to use priorities 10 .. 255. >> >> Each edit from client A can have a priority that is associated with >> the secondary client. >> >> >> >> >> ... >> app27 >> 42 >> >> >> >> An error is returned if is 9 or lower in this example. >> >> IMO this is better than requiring client A to open a session as a >> different user name for each priority value needed. >> >> >> >> -- Jeff >> >> >> >> Andy >> >> --001a11349aa6c84c76051acc4d4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
The flexibility J= eff has described, and you have commented upon, is permitted but not requir= ed by (what I understand of) the agreements of the WG.=C2=A0 If it can be e= asily done, it seems like a nice thing to do.


It means the priority, client-ID, and = 2nd-id all need to be saved per subtree.

What happ= ens if a client priority mapping is deleted or does not exist?
Do= es that client just get the worst possible priority or is it an error
=
or is all data deleted for that client?

What = if the server is aware a client id was removed completely?
Does t= hat matter for existing data for that client?

Yours,
Joel



Andy
=C2=A0
On 7/13/15 9:04 PM, Andy Bierman wrote:


On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas <jhaas@pfrc.org
<mailto:jhaas@pfrc.o= rg>> wrote:

=C2=A0 =C2=A0 Joel,

=C2=A0 =C2=A0 On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wro= te:
=C2=A0 =C2=A0 =C2=A0> To amplify my previous reply on priority, priority= is associated
=C2=A0 =C2=A0 =C2=A0> with the I2RS Client.=C2=A0 it does not change eve= n if the client is
=C2=A0 =C2=A0 =C2=A0> acting on behalf of multiple secondary identities.= =C2=A0 (If the use case
=C2=A0 =C2=A0 =C2=A0> requires that variability, use multiple primary id= entities, with
=C2=A0 =C2=A0 =C2=A0> separate sessions.)

=C2=A0 =C2=A0 To attempt to reduce this to an example:
=C2=A0 =C2=A0 Basis case: Multiple clients speaking directly to an agent.= =C2=A0 Clients
=C2=A0 =C2=A0 have
=C2=A0 =C2=A0 distinct priorities.=C2=A0 Priority causes config to tie-brea= k appropriately
=C2=A0 =C2=A0 among the various client interactions.

=C2=A0 =C2=A0 Proxy case: Agent is against as "root" from a proxy= , potentially
=C2=A0 =C2=A0 with the
=C2=A0 =C2=A0 a single priority.=C2=A0 As long as the proxy maintains the t= ie-breaking
=C2=A0 =C2=A0 as if it
=C2=A0 =C2=A0 had implemented the agent operations, it's okay that the = resultant
=C2=A0 =C2=A0 nodes may
=C2=A0 =C2=A0 have the same priority associated with them?

=C2=A0 =C2=A0 Gloss: We still haven't concluded our discussion as to wh= ether the
=C2=A0 =C2=A0 nodes are
=C2=A0 =C2=A0 decorated as "owned by an identity" or "have a= priority".

=C2=A0 =C2=A0 Note that the gloss has an interesting impact.=C2=A0 If nodes= are
=C2=A0 =C2=A0 expected to get
=C2=A0 =C2=A0 their priority via identity, this makes things very messy if = you don't
=C2=A0 =C2=A0 maintain multiple identities to have distinct priorities in t= he
=C2=A0 =C2=A0 proxy case.



OK -- it is becoming clearer now -- in order to support a broker, the
priority is saved with the node, not the client.

The operator configured priority is really the "best allowed". Let's say lower priorities are better, and client A is assigned the
value 10.=C2=A0 That means client A is allowed to use priorities 10 .. 255.=

Each edit from client A can have a priority that is associated with
the secondary client.

=C2=A0 =C2=A0 <rpc>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<edit-config>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <target><ephemeral /></ta= rget>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <config>=C2=A0 ... </config>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <secondary-identity>app27</seco= ndary-identity>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <priority>42</priority>
=C2=A0 =C2=A0 =C2=A0 =C2=A0</edit-config>
=C2=A0 =C2=A0 </rpc>

An error is returned if <priority> is 9 or lower in this example.

IMO this is better than requiring client A to open a session as a
different user name for each priority value needed.



=C2=A0 =C2=A0 -- Jeff



Andy


--001a11349aa6c84c76051acc4d4a-- From nobody Mon Jul 13 19:15:58 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2787B1A8946 for ; Mon, 13 Jul 2015 19:15:58 -0700 (PDT) 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 EyvElqrEyeyk for ; Mon, 13 Jul 2015 19:15:57 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB6A1A8944 for ; Mon, 13 Jul 2015 19:15:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id F0E492412BB; Mon, 13 Jul 2015 19:15:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 961CD2402F5; Mon, 13 Jul 2015 19:15:56 -0700 (PDT) To: Andy Bierman References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A46915.3050702@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <55A470A0.3010808@joelhalpern.com> Date: Mon, 13 Jul 2015 22:14:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:15:58 -0000 Andy, I am not following your comments. Questions in line below. Joel On 7/13/15 10:07 PM, Andy Bierman wrote: > > > On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern > wrote: > > The flexibility Jeff has described, and you have commented upon, is > permitted but not required by (what I understand of) the agreements > of the WG. If it can be easily done, it seems like a nice thing to do. > > > It means the priority, client-ID, and 2nd-id all need to be saved per > subtree. per subtree? The client-ID needs to be saved with the changed node. The secondary ID ought to be saved there, but is not required. If we want to support variable priority, then we would need to record the priority. Otherwise, recording the priority is an implementation acceleration, as it is determinable from the client ID. > > What happens if a client priority mapping is deleted or does not exist? > Does that client just get the worst possible priority or is it an error > or is all data deleted for that client? What happens if the client permissions are missing from the AAA? I would expect the client to get no permissions. Similarly, if the client priority is missing, the client would get the worst possible priority. If we support variable, per-request, priority (limited by the AAA result) then we need to pick a behavior for when the client omits the value. I don't care if he gets the worst priority or the best priority he is permitted (but if we want to support this we should be explicit.) > > What if the server is aware a client id was removed completely? > Does that matter for existing data for that client? If the client ID is no longer valid, and if the Agent (not sure what the server would be) knows that, then the client would no longer be permitted to perform new operations. I suppose we should write down whether, in ushc an event, the clients existing operations are removed or the client retains the ability to remove them. I am inclined to say that they should be removed, since the client may not currently have an active session, and presumably woudl fail any new attempt to authenticate. This seems to be something we should spell out. > > Yours, > Joel > > > > Andy > From nobody Mon Jul 13 19:26:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5349B1A8958 for ; Mon, 13 Jul 2015 19:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 f7K5Hxzesflw for ; Mon, 13 Jul 2015 19:26:43 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 0E8751A8972 for ; Mon, 13 Jul 2015 19:26:43 -0700 (PDT) Received: by lahh5 with SMTP id h5so29344916lah.2 for ; Mon, 13 Jul 2015 19:26:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NmWylCzcIT037Bi5/MqGFXkpVEsWrUPLz0fCZ8hM1Nc=; b=SoO+m7rnzquq8PutJjUBHgD43UNtJCjrN2YzmN7/X6qu2ln0tcXWALSPNIXiw1bxan a/WF1W7PBh4/OtnbkTrdQqPn5NkRSsIwmr5HUesls2ibed1rT1cEHqrrMr8pyz11DstW Rn96CuOgiIxQ0OpQOAHilg2ZIQk0CuuGM0yde5j4MVUXfXPFjG2KNiVMSHndDOpnwsZS 0dUsR64CkMhJNTUNwlgbytPCxn8/12xz1OqmuSPhzugOPXu+SmrV2aFscW1E8YU2WDZm A3lbOTJEiTFdKUFAYK821N6NHjfnNjs6IwaMH/v7n7fU0V5YkT1PAv57/uGty+V0NjPT 9fbQ== X-Gm-Message-State: ALoCoQkdo4ZfCTxIMm9JG3ITP0Bo5jXp2P0kQeyNCd36zElBMVLUt063huW2Du8THadcyDB2VehO MIME-Version: 1.0 X-Received: by 10.152.225.164 with SMTP id rl4mr20077663lac.38.1436840801609; Mon, 13 Jul 2015 19:26:41 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 13 Jul 2015 19:26:41 -0700 (PDT) In-Reply-To: <55A470A0.3010808@joelhalpern.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A46915.3050702@joelhalpern.com> <55A470A0.3010808@joelhalpern.com> Date: Mon, 13 Jul 2015 19:26:41 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11349aa694345b051acc91cd Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:26:46 -0000 --001a11349aa694345b051acc91cd Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern wrote: > Andy, I am not following your comments. Questions in line below. > Joel > > On 7/13/15 10:07 PM, Andy Bierman wrote: > >> >> >> On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern > > wrote: >> >> The flexibility Jeff has described, and you have commented upon, is >> permitted but not required by (what I understand of) the agreements >> of the WG. If it can be easily done, it seems like a nice thing to >> do. >> >> >> It means the priority, client-ID, and 2nd-id all need to be saved per >> subtree. >> > > per subtree? The client-ID needs to be saved with the changed node. The > secondary ID ought to be saved there, but is not required. If we want to > support variable priority, then we would need to record the priority. > Otherwise, recording the priority is an implementation acceleration, as it > is determinable from the client ID. > If the client creates a list entry then the priority applies to the list node and its descendants -- that's what I mean by subtree, Is the 2nd-id sticky? If /foo is created with 2nd=app21 and it is updated later with a new value, but no 2nd is provided, is the old 2nd reported (as per traceability requirements doc?) Or is the 2nd forgotten by the server as soon as it is logged? So the update edit would have no 2nd-id (as the request specified)? >> What happens if a client priority mapping is deleted or does not exist? >> Does that client just get the worst possible priority or is it an error >> or is all data deleted for that client? >> > > What happens if the client permissions are missing from the AAA? I would > expect the client to get no permissions. Similarly, if the client priority > is missing, the client would get the worst possible priority. > > Getting worst priority seems correct > If we support variable, per-request, priority (limited by the AAA result) > then we need to pick a behavior for when the client omits the value. I > don't care if he gets the worst priority or the best priority he is > permitted (but if we want to support this we should be explicit.) > >> >> What if the server is aware a client id was removed completely? >> Does that matter for existing data for that client? >> > > If the client ID is no longer valid, and if the Agent (not sure what the > server would be) knows that, then the client would no longer be permitted > to perform new operations. I suppose we should write down whether, in ushc > an event, the clients existing operations are removed or the client retains > the ability to remove them. I am inclined to say that they should be > removed, since the client may not currently have an active session, and > presumably woudl fail any new attempt to authenticate. This seems to be > something we should spell out. > > > >> Yours, >> Joel >> >> >> >> Andy >> >> Andy --001a11349aa694345b051acc91cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
Andy, I am not fo= llowing your comments.=C2=A0 Questions in line below.
Joel

On 7/13/15 10:07 PM, Andy Bierman wrote:


On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern <jmh@joelhalpern.com
<mailto:jmh@joe= lhalpern.com>> wrote:

=C2=A0 =C2=A0 The flexibility Jeff has described, and you have commented up= on, is
=C2=A0 =C2=A0 permitted but not required by (what I understand of) the agre= ements
=C2=A0 =C2=A0 of the WG.=C2=A0 If it can be easily done, it seems like a ni= ce thing to do.


It means the priority, client-ID, and 2nd-id all need to be saved per
subtree.

per subtree?=C2=A0 The client-ID needs to be saved with the changed node. T= he secondary ID ought to be saved there, but is not required.=C2=A0 If we w= ant to support variable priority, then we would need to record the priority= .=C2=A0 Otherwise, recording the priority is an implementation acceleration= , as it is determinable from the client ID.

=
If the client creates a list entry then the priority applies to the li= st node
and its descendants -- that's what I mean by subtree,=

Is the 2nd-id sticky?

If= /foo is created with 2nd=3Dapp21 and it is updated later
with a = new value, but no 2nd is provided, is the old 2nd
reported (as pe= r traceability requirements doc?)=C2=A0

Or is the = 2nd forgotten by the server as soon as it is logged?
So the updat= e edit would have no 2nd-id (as the request specified)?




What happens if a client priority mapping is deleted or does not exist?
Does that client just get the worst possible priority or is it an error
or is all data deleted for that client?

What happens if the client permissions are missing from the AAA?=C2=A0 I wo= uld expect the client to get no permissions.=C2=A0 Similarly, if the client= priority is missing, the client would get the worst possible priority.


Getting worst priority seems correct

=C2=A0
If we support variable, per-request, priority (limited by the AAA result) t= hen we need to pick a behavior for when the client omits the value.=C2=A0 I= don't care if he gets the worst priority or the best priority he is pe= rmitted (but if we want to support this we should be explicit.)

What if the server is aware a client id was removed completely?
Does that matter for existing data for that client?

If the client ID is no longer valid, and if the Agent (not sure what the se= rver would be) knows that, then the client would no longer be permitted to = perform new operations.=C2=A0 I suppose we should write down whether, in us= hc an event, the clients existing operations are removed or the client reta= ins the ability to remove them.=C2=A0 I am inclined to say that they should= be removed, since the client may not currently have an active session, and= presumably woudl fail any new attempt to authenticate.=C2=A0 This seems to= be something we should spell out.



=C2=A0 =C2=A0 Yours,
=C2=A0 =C2=A0 Joel



Andy




Andy

--001a11349aa694345b051acc91cd-- From nobody Mon Jul 13 19:32:30 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEB51A8990 for ; Mon, 13 Jul 2015 19:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, 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 hhzarkIwJ1K6 for ; Mon, 13 Jul 2015 19:32:27 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BED41A898D for ; Mon, 13 Jul 2015 19:32:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2C440245BB5; Mon, 13 Jul 2015 19:32:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 AA543240470; Mon, 13 Jul 2015 19:32:26 -0700 (PDT) To: Andy Bierman References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A46915.3050702@joelhalpern.com> <55A470A0.3010808@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <55A4747C.7040702@joelhalpern.com> Date: Mon, 13 Jul 2015 22:31:24 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:32:28 -0000 A few more comments below. Mostly, I think I understand you. Thanks, Joel On 7/13/15 10:26 PM, Andy Bierman wrote: > > > On Mon, Jul 13, 2015 at 7:14 PM, Joel M. Halpern > wrote: > > Andy, I am not following your comments. Questions in line below. > Joel > > On 7/13/15 10:07 PM, Andy Bierman wrote: > > > > On Mon, Jul 13, 2015 at 6:42 PM, Joel M. Halpern > > >> wrote: > > The flexibility Jeff has described, and you have commented > upon, is > permitted but not required by (what I understand of) the > agreements > of the WG. If it can be easily done, it seems like a nice > thing to do. > > > It means the priority, client-ID, and 2nd-id all need to be > saved per > subtree. > > > per subtree? The client-ID needs to be saved with the changed node. > The secondary ID ought to be saved there, but is not required. If > we want to support variable priority, then we would need to record > the priority. Otherwise, recording the priority is an > implementation acceleration, as it is determinable from the client ID. > > > If the client creates a list entry then the priority applies to the list > node > and its descendants -- that's what I mean by subtree, Okay. > > Is the 2nd-id sticky? > > If /foo is created with 2nd=app21 and it is updated later > with a new value, but no 2nd is provided, is the old 2nd > reported (as per traceability requirements doc?) > > Or is the 2nd forgotten by the server as soon as it is logged? > So the update edit would have no 2nd-id (as the request specified)? 2nd ID is,as far as I can tell, per-operation. If the Client does not send a second ID with a specific operation, then the Agent will presume that there is no second ID. So the early second ID (which was logged when the operation was performed) will be removed. And will therefore not be included if a later error message is generate. That is what the client has indicated by not including a secondary ID on the operation. From nobody Tue Jul 14 10:56:50 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582631AD0A2 for ; Tue, 14 Jul 2015 10:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 joxKyfPX74xj for ; Tue, 14 Jul 2015 10:56:48 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 08D201AD0D2 for ; Tue, 14 Jul 2015 10:56:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CECE01E36B; Tue, 14 Jul 2015 13:57:51 -0400 (EDT) Date: Tue, 14 Jul 2015 13:57:51 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20150714175751.GD16705@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A45151.9060709@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:56:49 -0000 Joel, On Mon, Jul 13, 2015 at 08:01:21PM -0400, Joel M. Halpern wrote: > On 7/13/15 7:48 PM, Jeffrey Haas wrote: > >Gloss: We still haven't concluded our discussion as to whether the nodes are > >decorated as "owned by an identity" or "have a priority". > > From other discussions, I had assumed nodes had to be decorated with > the owned-by identity. In the case of error, when a given clients > entry is removed due to a higher priority client pre-empting it, the > original client is to be notified of the error. If you don't have > the owner decoration, that is impossible. Having said that, I was > not expecting I2RS to give that owner or priority information back > in any request, so I had always considered it an internal > implementation matter how the associations were stored. Returning > such information in response to a get is a nice-to-have, but is not > to the best of my knowledge an I2RS requirement. > >Note that the gloss has an interesting impact. If nodes are expected to get > >their priority via identity, this makes things very messy if you don't > >maintain multiple identities to have distinct priorities in the proxy case. > > I am not sure where the complications comes from. The priority > comes from the client that performed that operation. That identity > needs to be available (as noted above). Secondary identities are > recorded for traceability. Again, whether they are actually with > the node, or only in the log, is not something on which I2RS has > expressed a requirement. The requirement is that the information be > provided in the request, and be logged. User A has priority 10 User B has priority 20 (20 is better than 10 for discussion) Per-discussion, owner is the meta data that nodes are decorated with for priority resolution. If user A writes state foo to an agent directly, foo is owned by A. If user B writes state bar to an agent directly, bar is owned by B. foo and bar have priorities 10 and 20 respectively as a consequence of the priority system mapping clients to priority. Proxy example: A and B write above to some proxy, which needs to carry it to some second system. Ignore secondary-identity as that is noise for this example. In order for the remote system to have foo with priority 10 and bar with priority 20, since priority is tied to client we will either: 1. Require two distinct client IDs to allow the proxied system to store something with appropriate tie-breaking. 2. Require the distributing agent to resolve the tie-breakers and simply install the results itself. You seem to believe that 2 is what will happen. However, for multi-headed control, there may be more than one agent proxying to the remote system. This means that to enforce priority, the priority needs to carry through to that remote system. That also means that multiple users are required, even if they are not A and B above - perhaps root10 and root20. -- Jeff From nobody Tue Jul 14 10:59:40 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423B41AD0C1 for ; Tue, 14 Jul 2015 10:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 NVs8zvlepPWP for ; Tue, 14 Jul 2015 10:59:38 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 919F41AD0C0 for ; Tue, 14 Jul 2015 10:59:38 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 676AE1E36B; Tue, 14 Jul 2015 14:01:29 -0400 (EDT) Date: Tue, 14 Jul 2015 14:01:29 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20150714180129.GE16705@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , Alia Atlas , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 17:59:39 -0000 Andy, On Mon, Jul 13, 2015 at 06:04:15PM -0700, Andy Bierman wrote: > OK -- it is becoming clearer now -- in order to support a broker, the > priority is saved with the node, not the client. FWIW, I think this is likely the case. However, the architecture authors seem to disagree. > The operator configured priority is really the "best allowed". > Let's say lower priorities are better, and client A is assigned the > value 10. That means client A is allowed to use priorities 10 .. 255. The implication from the architecture seems to be that a client gets one priority. This is the point for Alia/Joel to chime in if they disagree with my interpretation. > Each edit from client A can have a priority that is associated with > the secondary client. > > > > > ... > app27 > 42 > > I don't believe the expected behavior is that priority is carried as a protocol parameter. FWIW, I think this may be useful in the case of a proxy (as above), but presents interesting security issues since the secondary identity isn't part of the authentication system. -- Jeff From nobody Tue Jul 14 11:23:19 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD261B29A9 for ; Tue, 14 Jul 2015 11:23:17 -0700 (PDT) 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 PC23_f_nAGPz for ; Tue, 14 Jul 2015 11:23:15 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC591B29D4 for ; Tue, 14 Jul 2015 11:23:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 9861024076F; Tue, 14 Jul 2015 11:23:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 E85FD240470; Tue, 14 Jul 2015 11:23:06 -0700 (PDT) To: Jeffrey Haas References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A55349.8090107@joelhalpern.com> Date: Tue, 14 Jul 2015 14:22:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150714175751.GD16705@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:23:17 -0000 The architecture does not have a proxy. It only has Clients, who may be acting on behalf of applications. Those applications are not consider, by the I2RS system, to be I2RS Clients. Secondary identity is not a full proxy mode. secondary identities are not authenticated. They do not have priorities. They are included in the architecture to ease attribution. So no, if A and B are applications, working through a common I2RS client, then their operations are handled by the client. The requirements only call for the client priority to be assigned to those operations. As a nice-to-have, allowing clients to specify different priorities for different operations is acceptable. But it is not necessary. Remember that even with different priorities, such collisions are considered errors. Priority is for giving predictable results. It is not expected to give the "right" results in terms of application intention. Yours, Joel On 7/14/15 1:57 PM, Jeffrey Haas wrote: > Joel, > > On Mon, Jul 13, 2015 at 08:01:21PM -0400, Joel M. Halpern wrote: >> On 7/13/15 7:48 PM, Jeffrey Haas wrote: >>> Gloss: We still haven't concluded our discussion as to whether the nodes are >>> decorated as "owned by an identity" or "have a priority". >> >> From other discussions, I had assumed nodes had to be decorated with >> the owned-by identity. In the case of error, when a given clients >> entry is removed due to a higher priority client pre-empting it, the >> original client is to be notified of the error. If you don't have >> the owner decoration, that is impossible. Having said that, I was >> not expecting I2RS to give that owner or priority information back >> in any request, so I had always considered it an internal >> implementation matter how the associations were stored. Returning >> such information in response to a get is a nice-to-have, but is not >> to the best of my knowledge an I2RS requirement. > > >>> Note that the gloss has an interesting impact. If nodes are expected to get >>> their priority via identity, this makes things very messy if you don't >>> maintain multiple identities to have distinct priorities in the proxy case. >> >> I am not sure where the complications comes from. The priority >> comes from the client that performed that operation. That identity >> needs to be available (as noted above). Secondary identities are >> recorded for traceability. Again, whether they are actually with >> the node, or only in the log, is not something on which I2RS has >> expressed a requirement. The requirement is that the information be >> provided in the request, and be logged. > > User A has priority 10 > User B has priority 20 > (20 is better than 10 for discussion) > Per-discussion, owner is the meta data that nodes are decorated with for > priority resolution. > > If user A writes state foo to an agent directly, foo is owned by A. > If user B writes state bar to an agent directly, bar is owned by B. > > foo and bar have priorities 10 and 20 respectively as a consequence of the > priority system mapping clients to priority. > > Proxy example: > A and B write above to some proxy, which needs to carry it to some second > system. > Ignore secondary-identity as that is noise for this example. > > In order for the remote system to have foo with priority 10 and bar with > priority 20, since priority is tied to client we will either: > > 1. Require two distinct client IDs to allow the proxied system to store > something with appropriate tie-breaking. > 2. Require the distributing agent to resolve the tie-breakers and simply > install the results itself. > > You seem to believe that 2 is what will happen. > > However, for multi-headed control, there may be more than one agent proxying > to the remote system. This means that to enforce priority, the priority > needs to carry through to that remote system. That also means that multiple > users are required, even if they are not A and B above - perhaps root10 and > root20. > > -- Jeff > From nobody Tue Jul 14 11:38:03 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032051B2A1B for ; Tue, 14 Jul 2015 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 5QbXvyuiEG0l for ; Tue, 14 Jul 2015 11:38:01 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8FD1B2A12 for ; Tue, 14 Jul 2015 11:38:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 084A01E36C; Tue, 14 Jul 2015 14:39:52 -0400 (EDT) Date: Tue, 14 Jul 2015 14:39:51 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20150714183951.GL16705@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A55349.8090107@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:38:02 -0000 Joel, On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: > The architecture does not have a proxy. It only has Clients, who > may be acting on behalf of applications. Those applications are not > consider, by the I2RS system, to be I2RS Clients. > > Secondary identity is not a full proxy mode. secondary identities > are not authenticated. They do not have priorities. They are > included in the architecture to ease attribution. It is understood that secondary-identity is only a traceability detail. > So no, if A and B are applications, working through a common I2RS > client, then their operations are handled by the client. The > requirements only call for the client priority to be assigned to > those operations. Given the above, I think it is fair to say that proxies are completely out of scope. While this simplifies things, I'm not sure it's the best thing long-term. > As a nice-to-have, allowing clients to specify different priorities > for different operations is acceptable. But it is not necessary. As a nice-to-have, I don't believe the architecture clearly explains such an ability to alter priority. Please work with Alia to update the architecture document to clarify this if you believe this property is important. -- Jeff From nobody Tue Jul 14 11:45:01 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A121A802E for ; Tue, 14 Jul 2015 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7naj1KCcKEA6 for ; Tue, 14 Jul 2015 11:44:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A1B1AD2EE for ; Tue, 14 Jul 2015 11:44:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9CED727; Tue, 14 Jul 2015 20:44:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RqkJ6BMDR3-e; Tue, 14 Jul 2015 20:44:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 14 Jul 2015 20:44:55 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C477320033; Tue, 14 Jul 2015 20:44:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ATS_YTy2Pzlc; Tue, 14 Jul 2015 20:45:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A677920031; Tue, 14 Jul 2015 20:44:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B8A283540B64; Tue, 14 Jul 2015 20:44:54 +0200 (CEST) Date: Tue, 14 Jul 2015 20:44:54 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20150714184454.GB3102@elstar.local> Mail-Followup-To: "Joel M. Halpern" , Jeffrey Haas , "i2rs@ietf.org" References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A55349.8090107@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:45:01 -0000 On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: > As a nice-to-have, allowing clients to specify different priorities for > different operations is acceptable. But it is not necessary. Hm. I thought I understood that the priority is known by the server and that the authenticated username of the client is used to lookup the client's priority. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 14 11:53:01 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54D51B2A2A for ; Tue, 14 Jul 2015 11:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 8sBkI_eghrQk for ; Tue, 14 Jul 2015 11:52:58 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (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 9875D1ACEE1 for ; Tue, 14 Jul 2015 11:52:57 -0700 (PDT) Received: by lbbzr7 with SMTP id zr7so11646531lbb.1 for ; Tue, 14 Jul 2015 11:52:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cwa89zi77M6h4IEOHwOhU4moLdIRWL1E1uZc9PBVScU=; b=IKnM64lnzSaZEHHTxtXXHx8UAYK7ucummAGoF/XTEEr4nYDUGQwRWUJg2rSDWtEIKT pXK6CAIAwUfxt/jIh7m+9xp2uNlOTrZ8vZJMVo3RdyDD8nPot2u/QvJIM9egOHagcsoX 759c9h+cquXhfGvh/gPr6vRF/6PNUHLOXrA6Rn4JR2TY1HmUxyPrwoIIYNcBdmbYepfq LHSBenyffgYK19IIQ1TrXGmxmMzJa/34egrh6C/PMs+OZ3gI5xfHy3815xYknO5z+wZs f5nuMi1R0VHSUAflg/dHUw8vz22aW+eBzav2a1Ix4SIp8haEHkQBO36YPN3J5esCP6Ai ttkQ== X-Gm-Message-State: ALoCoQm165B57OKSU6fqlKDDpPwqiYss4qLDxcCYbxvAO7LJuOTPt7QSRdEkwD5CyVq1Kc6M54JR MIME-Version: 1.0 X-Received: by 10.152.225.164 with SMTP id rl4mr101554lac.38.1436899976077; Tue, 14 Jul 2015 11:52:56 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Jul 2015 11:52:55 -0700 (PDT) In-Reply-To: <20150714183951.GL16705@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> <20150714183951.GL16705@pfrc.org> Date: Tue, 14 Jul 2015 11:52:55 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11349aa6a6fcfe051ada581e Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:53:00 -0000 --001a11349aa6a6fcfe051ada581e Content-Type: text/plain; charset=UTF-8 On Tue, Jul 14, 2015 at 11:39 AM, Jeffrey Haas wrote: > Joel, > > On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: > > The architecture does not have a proxy. It only has Clients, who > > may be acting on behalf of applications. Those applications are not > > consider, by the I2RS system, to be I2RS Clients. > > > > Secondary identity is not a full proxy mode. secondary identities > > are not authenticated. They do not have priorities. They are > > included in the architecture to ease attribution. > > It is understood that secondary-identity is only a traceability detail. > > > So no, if A and B are applications, working through a common I2RS > > client, then their operations are handled by the client. The > > requirements only call for the client priority to be assigned to > > those operations. > > Given the above, I think it is fair to say that proxies are completely out > of scope. While this simplifies things, I'm not sure it's the best thing > long-term. > > The entire northbound API from the client is out of scope. The secondary identity is just decoration in the standard. In reality, a broker might be the only client, so its priority is worthless for resolving conflicts. The applications using the broker are the ones needing priority to resolve conflicts. I can imagine "data-specific controllers" meaning if an app for vendor X want to write a particular set of data structures, it goes through the client designed to provide a simplified (proprietary) API for this purpose. Since this is all out of scope I suppose it doesn't matter, but some types of brokers won't work very well. > As a nice-to-have, allowing clients to specify different priorities > > for different operations is acceptable. But it is not necessary. > > As a nice-to-have, I don't believe the architecture clearly explains such > an > ability to alter priority. Please work with Alia to update the > architecture > document to clarify this if you believe this property is important. > > -- Jeff > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11349aa6a6fcfe051ada581e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Joel,

On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote:
> The architecture does not have a proxy.=C2=A0 It only has Clients, who=
> may be acting on behalf of applications.=C2=A0 Those applications are = not
> consider, by the I2RS system, to be I2RS Clients.
>
> Secondary identity is not a full proxy mode.=C2=A0 secondary identitie= s
> are not authenticated.=C2=A0 They do not have priorities.=C2=A0 They a= re
> included in the architecture to ease attribution.

It is understood that secondary-identity is only a traceability detail.

> So no, if A and B are applications, working through a common I2RS
> client, then their operations are handled by the client.=C2=A0 The
> requirements only call for the client priority to be assigned to
> those operations.

Given the above, I think it is fair to say that proxies are completely out<= br> of scope.=C2=A0 While this simplifies things, I'm not sure it's the= best thing
long-term.


The entire northbound API from the cli= ent is out of scope.
The secondary identity is just decoration in= the standard.

In reality, a broker might be the o= nly client, so its priority
is worthless for resolving conflicts.= =C2=A0 The applications using
the broker are the ones needing pri= ority to resolve conflicts.

I can imagine "da= ta-specific controllers" meaning if an app
for vendor X want= to write a particular set of data structures,
it goes through th= e client designed to provide a simplified
(proprietary) API for t= his purpose.

Since this is all out of scope I supp= ose it doesn't matter,
but some types of brokers won't wo= rk very well.





> As a nice-to-have, allowing clients to specify different priorities > for different operations is acceptable.=C2=A0 But it is not necessary.=

As a nice-to-have, I don't believe the architecture clearly explains su= ch an
ability to alter priority.=C2=A0 Please work with Alia to update the archit= ecture
document to clarify this if you believe this property is important.

-- Jeff



Andy
=C2=A0
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--001a11349aa6a6fcfe051ada581e-- From nobody Tue Jul 14 11:54:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C38E1B2A73 for ; Tue, 14 Jul 2015 11:53:55 -0700 (PDT) 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 yibDYaB5wucx for ; Tue, 14 Jul 2015 11:53:54 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D64A1B2A74 for ; Tue, 14 Jul 2015 11:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DBD2D251FF9; Tue, 14 Jul 2015 11:53:53 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 80EB8251FC9; Tue, 14 Jul 2015 11:53:53 -0700 (PDT) To: Jeffrey Haas References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> <20150714183951.GL16705@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A55A80.6000708@joelhalpern.com> Date: Tue, 14 Jul 2015 14:52:48 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150714183951.GL16705@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 18:53:55 -0000 In line for emphasis. Joel On 7/14/15 2:39 PM, Jeffrey Haas wrote: > Joel, > > On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: ... >> As a nice-to-have, allowing clients to specify different priorities >> for different operations is acceptable. But it is not necessary. > > As a nice-to-have, I don't believe the architecture clearly explains such an > ability to alter priority. Please work with Alia to update the architecture > document to clarify this if you believe this property is important. I don't consider the property of variable priorities important. You raised it in your description. As far as I am concerned, the description Juergen sent to the list (priority is derived by AAA from the client identity) meets the requirements. I am very concerned that as I2RS expresses its requirements, we need to be clear which things are requirements, and which things people ahve thought of since (such as variable priority) but are not WG requirements. > > -- Jeff > From nobody Tue Jul 14 12:06:07 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9F1B2A81 for ; Tue, 14 Jul 2015 12:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, 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 NGeVpQm8GkI6 for ; Tue, 14 Jul 2015 12:06:04 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D10E71B2A80 for ; Tue, 14 Jul 2015 12:06:03 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t6EJ61GL016165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Jul 2015 15:06:01 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 14 Jul 2015 15:06:00 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 14 Jul 2015 15:06:00 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1104.000; Tue, 14 Jul 2015 15:06:00 -0400 From: Igor Bryskin To: Jeffrey Haas , "Joel M. Halpern" Thread-Topic: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt Thread-Index: AQHQtgkkoLK4eWa0RkyXf7B5KXM/r53aUpoAgAADNwCAAAM2AP//y6s5gAFvfYCAAAbAgIAABPyA//++G2A= Date: Tue, 14 Jul 2015 19:05:59 +0000 Message-ID: <835788acc87344d9908434386600b6c0@ATL-SRV-MBX1.advaoptical.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> <20150714183951.GL16705@pfrc.org> In-Reply-To: <20150714183951.GL16705@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-07-14_09:2015-07-14,2015-07-14,1970-01-01 signatures=0 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 19:06:05 -0000 Jeff, Joel, All I think declaring proxy out of I2RS architecture scope is a good thing. No= t only this would simplify thing for I2RSs, FWIW it would allow for a singl= e I3RS client to support arbitrary hierarchies of applications. Igor -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Tuesday, July 14, 2015 2:40 PM To: Joel M. Halpern Cc: i2rs@ietf.org Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00"./= / I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt Joel, On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: > The architecture does not have a proxy. It only has Clients, who > may be acting on behalf of applications. Those applications are not > consider, by the I2RS system, to be I2RS Clients. >=20 > Secondary identity is not a full proxy mode. secondary identities > are not authenticated. They do not have priorities. They are > included in the architecture to ease attribution. It is understood that secondary-identity is only a traceability detail. > So no, if A and B are applications, working through a common I2RS > client, then their operations are handled by the client. The > requirements only call for the client priority to be assigned to > those operations. Given the above, I think it is fair to say that proxies are completely out of scope. While this simplifies things, I'm not sure it's the best thing long-term. > As a nice-to-have, allowing clients to specify different priorities > for different operations is acceptable. But it is not necessary. As a nice-to-have, I don't believe the architecture clearly explains such a= n ability to alter priority. Please work with Alia to update the architectur= e document to clarify this if you believe this property is important. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jul 14 12:08:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F09B1B2AA5 for ; Tue, 14 Jul 2015 12:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 ukRJvPvMff6K for ; Tue, 14 Jul 2015 12:08:43 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (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 141821B2A93 for ; Tue, 14 Jul 2015 12:08:02 -0700 (PDT) Received: by lagw2 with SMTP id w2so11673622lag.3 for ; Tue, 14 Jul 2015 12:08:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wax+j77rej6wUyajOqXeXU13w+iBOHtm4Rh23XlseIo=; b=dqvndIvHjHpTsoSNtW6xFE992IOdqb1E/Z2+4atSOyhX/vQjvv83N1VPtZo88mDUlJ 7VvO8Ww7mD57EY4e7zkFTFSpMl20a9tt9BC2o8xTdAV0QWaHUSMm05oRX/hI6m18WYHM DCB5hHmMBQTRndI6YjcR6qL3EOle16j8Iw/DhjKxBbogF0OuWbw4dLp3QxDCcmoWLU2C FibjoWi64EdMoUifn6WUEJCfMU+a6hrZej623d0jLZZm7oGIJIgyTFG+/hqwJV7mJrEz OnvuM74Edk3B3Ov5trFgPE9uMNBoRztyLgJdNP8cpJGXW7cqjBvN82QXfSiUIDcMqrYi eRtA== X-Gm-Message-State: ALoCoQlOUVtyMBgv89Q/blY4c6w6lspk9ta8+5vKYEQczGmec1LfqP7BxelrhhggKwbsU8YTn9e5 MIME-Version: 1.0 X-Received: by 10.152.116.39 with SMTP id jt7mr144109lab.82.1436900880629; Tue, 14 Jul 2015 12:08:00 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 14 Jul 2015 12:08:00 -0700 (PDT) In-Reply-To: References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> <55A45151.9060709@joelhalpern.com> <20150714175751.GD16705@pfrc.org> <55A55349.8090107@joelhalpern.com> <20150714183951.GL16705@pfrc.org> Date: Tue, 14 Jul 2015 12:08:00 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c36592915afd051ada8edf Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 19:08:45 -0000 --001a11c36592915afd051ada8edf Content-Type: text/plain; charset=UTF-8 On Tue, Jul 14, 2015 at 11:52 AM, Andy Bierman wrote: > > > On Tue, Jul 14, 2015 at 11:39 AM, Jeffrey Haas wrote: > >> Joel, >> >> On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote: >> > The architecture does not have a proxy. It only has Clients, who >> > may be acting on behalf of applications. Those applications are not >> > consider, by the I2RS system, to be I2RS Clients. >> > >> > Secondary identity is not a full proxy mode. secondary identities >> > are not authenticated. They do not have priorities. They are >> > included in the architecture to ease attribution. >> >> It is understood that secondary-identity is only a traceability detail. >> >> > So no, if A and B are applications, working through a common I2RS >> > client, then their operations are handled by the client. The >> > requirements only call for the client priority to be assigned to >> > those operations. >> >> Given the above, I think it is fair to say that proxies are completely out >> of scope. While this simplifies things, I'm not sure it's the best thing >> long-term. >> >> > The entire northbound API from the client is out of scope. > The secondary identity is just decoration in the standard. > > In reality, a broker might be the only client, so its priority > is worthless for resolving conflicts. The applications using > the broker are the ones needing priority to resolve conflicts. > > I can imagine "data-specific controllers" meaning if an app > for vendor X want to write a particular set of data structures, > it goes through the client designed to provide a simplified > (proprietary) API for this purpose. > > Since this is all out of scope I suppose it doesn't matter, > but some types of brokers won't work very well. > > Actually, if there is only 1 client then priority is irrelevant and the broker will resolve all collisions. If a broker is not the only client then its priority is set to the best needed by all the apps using the broker. Probably best to just wait and see if a standard broker is ever needed. I suspect proprietary systems will just add extra parameters and get around the standard, no matter what WG decision is getting in the way. Andy > > > > > As a nice-to-have, allowing clients to specify different priorities >> > for different operations is acceptable. But it is not necessary. >> >> As a nice-to-have, I don't believe the architecture clearly explains such >> an >> ability to alter priority. Please work with Alia to update the >> architecture >> document to clarify this if you believe this property is important. >> >> -- Jeff >> >> > > Andy > > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > --001a11c36592915afd051ada8edf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 14, 2015 at 11:52 AM, Andy Bierman <andy@yumaworks.com> wrote:

=

On Tue, Jul 14, 2= 015 at 11:39 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Joel,

On Tue, Jul 14, 2015 at 02:22:01PM -0400, Joel M. Halpern wrote:
> The architecture does not have a proxy.=C2=A0 It only has Clients, who=
> may be acting on behalf of applications.=C2=A0 Those applications are = not
> consider, by the I2RS system, to be I2RS Clients.
>
> Secondary identity is not a full proxy mode.=C2=A0 secondary identitie= s
> are not authenticated.=C2=A0 They do not have priorities.=C2=A0 They a= re
> included in the architecture to ease attribution.

It is understood that secondary-identity is only a traceability detail.

> So no, if A and B are applications, working through a common I2RS
> client, then their operations are handled by the client.=C2=A0 The
> requirements only call for the client priority to be assigned to
> those operations.

Given the above, I think it is fair to say that proxies are completely out<= br> of scope.=C2=A0 While this simplifies things, I'm not sure it's the= best thing
long-term.


The entire northbound API from the cli= ent is out of scope.
The secondary identity is just decoration in= the standard.

In reality, a broker might be the o= nly client, so its priority
is worthless for resolving conflicts.= =C2=A0 The applications using
the broker are the ones needing pri= ority to resolve conflicts.

I can imagine "da= ta-specific controllers" meaning if an app
for vendor X want= to write a particular set of data structures,
it goes through th= e client designed to provide a simplified
(proprietary) API for t= his purpose.

Since this is all out of scope I supp= ose it doesn't matter,
but some types of brokers won't wo= rk very well.


<= /div>

Actually, if there is only 1 client then priority = is irrelevant and
the broker will resolve all collisions.=C2=A0 I= f a broker is not the only client
then its priority is set to the= best needed by all the apps using
the broker.

Probably best to just wait and see if a standard broker is ever need= ed.
I suspect proprietary systems will just add extra parameters<= /div>
and get around the standard, no matter what WG decision is
<= div>getting in the way.



<= div>Andy


=




> As a nice-to-have, allowing clients to specify different priorities > for different operations is acceptable.=C2=A0 But it is not necessary.=

As a nice-to-have, I don't believe the architecture clearly explains su= ch an
ability to alter priority.=C2=A0 Please work with Alia to update the archit= ecture
document to clarify this if you believe this property is important.

-- Jeff



Andy
=C2=A0
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


--001a11c36592915afd051ada8edf-- From nobody Sat Jul 18 15:01:18 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064E21A017E for ; Sat, 18 Jul 2015 15:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 2h8S242A2uyC for ; Sat, 18 Jul 2015 15:01:15 -0700 (PDT) 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 BAA3C1A0107 for ; Sat, 18 Jul 2015 15:01:14 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYX46963; Sat, 18 Jul 2015 22:01:13 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 18 Jul 2015 23:01:12 +0100 Received: from DFWEML702-CHM.china.huawei.com ([10.193.5.72]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Sat, 18 Jul 2015 15:01:04 -0700 From: Linda Dunbar To: "'i2rs@ietf.org'" , Susan Hares , "jhaas@juniper.net" Thread-Topic: multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state Thread-Index: AQHQwaU9HuAloP1M20KLFQfoTKupJQ== Date: Sat, 18 Jul 2015 22:01:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657CDFA09@dfweml702-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.84.188] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657CDFA09dfweml702chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 22:01:18 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657CDFA09dfweml702chm_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sue and Jeff, There have been many postings/comments to draft-ietf-i2rs-ephemeral-state-0= 0, I went through many, but not all. In case my comments have been addresse= d by previous postings that I missed, I am really sorry for wasting your ti= me. I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is= about the =93multi-headed control of a I2RS agent=94. IMHO, the =93I2RS-ephemeral-state=94 should be addressed separately from = =93multi-headed control=94, because for networks that only use single contr= oller, they don=92t have to deal with the complicated scheme of multiple co= ntrollers, but they do need to conform to the =93ephemeral-state=94 via I2R= S interface. =93I2RS-ephemeral-state=94 should be simply: - all commands from I2RS interface are ephemeral, i.e. they do not sustain = restart, and all configuration from I2RS interface are voided (or removed) = when the connection to the I2RS agent is lost. The Multi-headed control scheme described in the draft can also be applied = to persistent configuration. draft-ietf-i2rs-ephemeral-state-00 introduced a new =93ephemeral-config=94 = to NETCONF, does it mean that if I2RS client uses regular =93config=94 inst= ead of =93ephemeral-config=94, the configuration becomes persistent? It s= houldn=92t, in my opinion. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657CDFA09dfweml702chm_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

Sue and Jeff,

 

There = have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I w= ent through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wastin= g your time.

 =

 

I find= the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about= the =93multi-headed control of a I2RS agent=94.

&= nbsp;

IMHO, = the =93I2RS-ephemeral-state=94 should be addressed separately from =93multi= -headed control=94, because for networks that only use single controller, they don=92t have to deal with the complicated scheme of multiple controll= ers, but they do need to conform to the =93ephemeral-state=94 via I2RS inte= rface.

&= nbsp;

=93I2R= S-ephemeral-state=94 should be simply:

- all = commands from I2RS interface are ephemeral, i.e. they do not sustain restar= t, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost. =

&= nbsp;

&= nbsp;

The Mu= lti-headed control scheme described in the draft can also be applied to per= sistent configuration.

&= nbsp;

&= nbsp;

draft-= ietf-i2rs-ephemeral-state-00 introduced a new =93ephemeral-config=94 to NET= CONF, does it mean that if I2RS client uses regular =93config=94 instead of  =93ephemeral-config=94, the configuration becomes persistent?&nbs= p; It shouldn=92t, in my opinion.

&= nbsp;

&= nbsp;

Linda = Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657CDFA09dfweml702chm_-- From nobody Sat Jul 18 19:55:13 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5341A1B89 for ; Sat, 18 Jul 2015 19:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BVJ3BTtWSuJb for ; Sat, 18 Jul 2015 19:55:09 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (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 0F67E1A1B81 for ; Sat, 18 Jul 2015 19:55:09 -0700 (PDT) Received: by lahh5 with SMTP id h5so79532683lah.2 for ; Sat, 18 Jul 2015 19:55:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9lagIE1925h3hEi9ix8Fp9yuxN7V8mLbh4fKSN7Kfk8=; b=O76o/IbdOhoT6lwjoNYfMSaq6qEUeBonjobrkrspbTqZsgBjo7DWZiGJGUFegNCUmi Y77Mn55++6pBtc6NvSEy6PSnu1uflLnw3SSAStXP3sQwJHIlgik4iWoWuHsQxuwu4LH5 DYiv2wR5wn86Xpzos8JDAv9dLJM3m0AVyq81tPY7DzPr22ktQbJ16Ymljl9CdUhmh2ln 5dbfA9GRdJZLRuSRNswB8Q+9PH89EbQhcFPfm+32OKt1Aex+WCe54cf8xEWVaF9PaNqE 1jMUuRZ8RBU+snPzxePFqBDjFUmnvUdMLCL6yaVxbRimEQDqobps467ELBYV++qdI4ZL uQWQ== X-Gm-Message-State: ALoCoQmhSfiv2yxobUbY8K3yjuL052FXc8eaVUqzAEzqMn7b9SjMtB/Amycjg7hV78sQhlIio/HR MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr21431294laa.33.1437274507464; Sat, 18 Jul 2015 19:55:07 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sat, 18 Jul 2015 19:55:07 -0700 (PDT) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657CDFA09@dfweml702-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657CDFA09@dfweml702-chm> Date: Sat, 18 Jul 2015 19:55:07 -0700 Message-ID: From: Andy Bierman To: Linda Dunbar Content-Type: multipart/alternative; boundary=001a11c27cf0766b79051b318c15 Archived-At: Cc: "jhaas@juniper.net" , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 02:55:11 -0000 --001a11c27cf0766b79051b318c15 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, very interesting comments... I agree these are requirements that could apply to more than I2RS. The first-one-wins (via client priority) details could apply to configuration as well as ephemeral state, and I wonder if NETCONF should be changed to support it. I don't agree that a lost connection caused all the state for that client to disappear. In NETCONF, it is generally only the edits in progress that are tossed. Since I2RS will not use a candidate config, these multi-PDU edits should not be possible in I2RS. I agree that the "access" procedures for ephemeral state can be separated from "multi-head" procedures, but they are somewhat coupled. I think the arch. doc mentioned parameters sent with an edit to ask for a notification if the edit is rejected because higher priority data already exists (notify me when my edit might work). It seems multi-head control is mandatory to support. Andy On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar wrote: > > > Sue and Jeff, > > > > There have been many postings/comments to > draft-ietf-i2rs-ephemeral-state-00, I went through many, but not all. In > case my comments have been addressed by previous postings that I missed, = I > am really sorry for wasting your time. > > > > > > I find the majority of the content in draft-ietf-i2rs-ephemeral-state-00 > is about the =E2=80=9Cmulti-headed control of a I2RS agent=E2=80=9D. > > > > IMHO, the =E2=80=9CI2RS-ephemeral-state=E2=80=9D should be addressed sepa= rately from > =E2=80=9Cmulti-headed control=E2=80=9D, because for networks that only us= e single > controller, they don=E2=80=99t have to deal with the complicated scheme o= f multiple > controllers, but they do need to conform to the =E2=80=9Cephemeral-state= =E2=80=9D via I2RS > interface. > > > > =E2=80=9CI2RS-ephemeral-state=E2=80=9D should be simply: > > - all commands from I2RS interface are ephemeral, i.e. they do not sustai= n > restart, and all configuration from I2RS interface are voided (or removed= ) > when the connection to the I2RS agent is lost. > > > > > > The Multi-headed control scheme described in the draft can also be applie= d > to persistent configuration. > > > > > > draft-ietf-i2rs-ephemeral-state-00 introduced a new =E2=80=9Cephemeral-co= nfig=E2=80=9D to > NETCONF, does it mean that if I2RS client uses regular =E2=80=9Cconfig=E2= =80=9D instead of > =E2=80=9Cephemeral-config=E2=80=9D, the configuration becomes persistent= ? It shouldn=E2=80=99t, > in my opinion. > > > > > > Linda Dunbar > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --001a11c27cf0766b79051b318c15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

very interesting comments...
<= div>
I agree these are requirements that could apply to more = than I2RS.
The first-one-wins (via client priority) details could= apply to configuration
as well as ephemeral state, and I wonder = if NETCONF
should be changed to support it.

<= div>I don't agree that a lost connection caused all the state for that = client
to disappear.=C2=A0 In NETCONF, it is generally only the e= dits in progress
that are tossed.=C2=A0 Since I2RS will not use a= candidate config,
these multi-PDU edits should not be possible i= n I2RS.

I agree that the "access" proced= ures for ephemeral state can
be separated from "multi-head&q= uot; procedures, but they are somewhat
coupled. I think the arch.= doc mentioned parameters sent with an
edit to ask for a notifica= tion if the edit is rejected because higher
priority data already= exists (notify me when my edit might work).
It seems multi-head = control is mandatory to support.


An= dy



<= br>
On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar= <linda.dunbar@huawei.com> wrote:

=C2=A0

Sue and Jeff,

=C2=A0

There = have been many postings/comments to draft-ietf-i2rs-ephemeral-state-00, I w= ent through many, but not all. In case my comments have been addressed by previous postings that I missed, I am really sorry for wastin= g your time.

=C2=A0=

=C2=A0

I find= the majority of the content in draft-ietf-i2rs-ephemeral-state-00 is about= the =E2=80=9Cmulti-headed control of a I2RS agent=E2=80=9D.<= /span>

=C2=A0

IMHO, = the =E2=80=9CI2RS-ephemeral-state=E2=80=9D should be addressed separately f= rom =E2=80=9Cmulti-headed control=E2=80=9D, because for networks that only = use single controller, they don=E2=80=99t have to deal with the complicated scheme of multiple co= ntrollers, but they do need to conform to the =E2=80=9Cephemeral-state=E2= =80=9D via I2RS interface.

=C2=A0

=E2=80= =9CI2RS-ephemeral-state=E2=80=9D should be simply:

- all = commands from I2RS interface are ephemeral, i.e. they do not sustain restar= t, and all configuration from I2RS interface are voided (or removed) when the connection to the I2RS agent is lost.

=C2=A0

=C2=A0

The Mu= lti-headed control scheme described in the draft can also be applied to per= sistent configuration.

=C2=A0

=C2=A0

draft-= ietf-i2rs-ephemeral-state-00 introduced a new =E2=80=9Cephemeral-config=E2= =80=9D to NETCONF, does it mean that if I2RS client uses regular =E2=80=9Cc= onfig=E2=80=9D instead of =C2=A0=E2=80=9Cephemeral-config=E2=80=9D, the configuration becomes per= sistent?=C2=A0 It shouldn=E2=80=99t, in my opinion. =

=C2=A0

=C2=A0

Linda = Dunbar

=C2=A0


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


--001a11c27cf0766b79051b318c15-- From nobody Sun Jul 19 00:22:43 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5A31A0AF8 for ; Sun, 19 Jul 2015 00:22:42 -0700 (PDT) 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 QeC1436MM4OW for ; Sun, 19 Jul 2015 00:22:40 -0700 (PDT) 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 761671A0AC8 for ; Sun, 19 Jul 2015 00:22:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 5D5EE1D26B4; Sun, 19 Jul 2015 00:22:40 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [80.95.104.60]) (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 43A6A1C028F; Sun, 19 Jul 2015 00:22:39 -0700 (PDT) To: Andy Bierman , Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F657CDFA09@dfweml702-chm> From: "Joel M. Halpern" Message-ID: <55AB5039.3030301@joelhalpern.com> Date: Sun, 19 Jul 2015 03:22:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "jhaas@juniper.net" , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] multi-headed control of I2RS agent v.s. i2rs-Ephemeral-state X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 07:22:42 -0000 Thanks Andy. I had missed that line in Linda's email. I agree with Andy. As I understand the WG agreements, ephemeral state has nothing to do with the presence or absence of a connection to the I2RS client which provided the state. The ephemeral aspect is strictly about whether the state survives reboot of the device with the I2RS Agent (there is some ambiguity / flexibility about the case where the I2RS Agent reboots without the device itself rebooting, which we should be clear about.) While the document title may be narrower than its scope (often the case with IETF documents) it is important that we get protocol mechanisms which deal with the priority as well as the ephemeral aspects. I see no benefit in having two separate documents to discuss them. Yours, Joel On 7/18/15 10:55 PM, Andy Bierman wrote: > Hi, > > very interesting comments... > > I agree these are requirements that could apply to more than I2RS. > The first-one-wins (via client priority) details could apply to > configuration > as well as ephemeral state, and I wonder if NETCONF > should be changed to support it. > > I don't agree that a lost connection caused all the state for that client > to disappear. In NETCONF, it is generally only the edits in progress > that are tossed. Since I2RS will not use a candidate config, > these multi-PDU edits should not be possible in I2RS. > > I agree that the "access" procedures for ephemeral state can > be separated from "multi-head" procedures, but they are somewhat > coupled. I think the arch. doc mentioned parameters sent with an > edit to ask for a notification if the edit is rejected because higher > priority data already exists (notify me when my edit might work). > It seems multi-head control is mandatory to support. > > > Andy > > > > > On Sat, Jul 18, 2015 at 3:01 PM, Linda Dunbar > wrote: > > __ __ > > Sue and Jeff, ____ > > __ __ > > There have been many postings/comments to > draft-ietf-i2rs-ephemeral-state-00, I went through many, but not > all. In case my comments have been addressed by previous postings > that I missed, I am really sorry for wasting your time. ____ > > ____ > > __ __ > > I find the majority of the content in > draft-ietf-i2rs-ephemeral-state-00 is about the “multi-headed > control of a I2RS agent”.____ > > __ __ > > IMHO, the “I2RS-ephemeral-state” should be addressed separately from > “multi-headed control”, because for networks that only use single > controller, they don’t have to deal with the complicated scheme of > multiple controllers, but they do need to conform to the > “ephemeral-state” via I2RS interface. ____ > > __ __ > > “I2RS-ephemeral-state” should be simply:____ > > - all commands from I2RS interface are ephemeral, i.e. they do not > sustain restart, and all configuration from I2RS interface are > voided (or removed) when the connection to the I2RS agent is lost. ____ > > __ __ > > __ __ > > The Multi-headed control scheme described in the draft can also be > applied to persistent configuration. ____ > > __ __ > > __ __ > > draft-ietf-i2rs-ephemeral-state-00 introduced a new > “ephemeral-config” to NETCONF, does it mean that if I2RS client uses > regular “config” instead of “ephemeral-config”, the configuration > becomes persistent? It shouldn’t, in my opinion. ____ > > __ __ > > __ __ > > Linda Dunbar____ > > __ __ > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jul 20 07:44:12 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB781A89B9; Mon, 20 Jul 2015 07:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 Rf1JB0hFqfdV; Mon, 20 Jul 2015 07:44:09 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 837221A8998; Mon, 20 Jul 2015 07:44:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=31.133.162.2; From: "Susan Hares" To: , , References: In-Reply-To: Date: Mon, 20 Jul 2015 10:44:06 -0400 Message-ID: <002901d0c2fa$88f6e9c0$9ae4bd40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+IBQ4UGchZLEYWb2vYGsiDeGPsZ6JsR0w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'Joel M. Halpern'" , 'Alia Atlas' Subject: [i2rs] FW: I2RS/TEAS Topology Discussion X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 14:44:10 -0000 Here's the location for the I2RS/TEAS topology Discussion. Location: Berlin/Brussels Time: 20:00 - 21:00 See you there! Sue Hares From nobody Mon Jul 20 08:05:27 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B4A1A87B2; Mon, 13 Jul 2015 16:35:45 -0700 (PDT) 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 4kuaGAHxxilR; Mon, 13 Jul 2015 16:35:43 -0700 (PDT) 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 AB2021A87AD; Mon, 13 Jul 2015 16:35:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 9992D1C0234; Mon, 13 Jul 2015 16:35:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [65.216.245.2]) (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 1C43D1C00F7; Mon, 13 Jul 2015 16:35:42 -0700 (PDT) To: Jeffrey Haas , Andy Bierman References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> From: "Joel M. Halpern" Message-ID: <55A44B12.10201@joelhalpern.com> Date: Mon, 13 Jul 2015 19:34:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150713230952.GI13783@pfrc.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 08:05:26 -0700 Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , internet-drafts@ietf.org, Alia Atlas , i2rs , i-d-announce@ietf.org, Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:35:45 -0000 To amplify my previous reply on priority, priority is associated with the I2RS Client. it does not change even if the client is acting on behalf of multiple secondary identities. (If the use case requires that variability, use multiple primary identities, with separate sessions.) Thus, the conflict error behavior is determined by the clients, not by what they are doing or the secondary identities they are working on behalf of. The WG considered (and I hope still considers) this acceptable on the basis that it is an error case anyway, and all we are doing is creating predictable behavior for the rror handling, not "correct" behavior. Yours, Joel On 7/13/15 7:09 PM, Jeffrey Haas wrote: > Andy, > > On Mon, Jul 13, 2015 at 03:58:22PM -0700, Andy Bierman wrote: >> On Mon, Jul 13, 2015 at 3:46 PM, Jeffrey Haas wrote: >>> Note that the priority MUST not be user-supplied. It should be derived >>> from >>> the credentials. Letting the user set the priority may be inappropriate >>> security. >> >> This approach would mean that the I2RS client acting as a broker >> would need a different session for each secondary client. >> It seems more useful to allow the client to use 1 session, >> and just require that each edit be from a specific secondary identity. >> >> (e.g., add a secondary-identity parameter to the edit operation). >> The proposed solution of an XML attribute allows every node >> in an edit to be from a different secondary identity. > > I don't object to moving secondary-identity into something that may be able > to vary on a per-edit transaction. > > I had started to write that priority is associated with their client and > that edits are likely done on behalf of a given secondary-id. Then I had a > realization prompted by the proxy use case: In order to carry through the > appropriate priority, it would be necessary to similarly carry through the > primary identity in order to have that identity/priority association. This > seems a bit contrary to the idea of a proxy operating as "root". > > Joel/Alia, would you please comment how you intended the multi-headed > control case to operate with regard to associated identity and priority? > >>> I believe having the priority set per-session likely matches our use case. >>> In the event a different priority is expected, the user would use a >>> different session with different credentials. >>> >> >> I thought the client priority is configured in advance by the >> administrator. It makes no sense to have each client >> state their own priority. This is useless for resolving conflicts >> between clients. > > Priority associated to client identity is what is intended. > >> IMO, priority 0 is the highest, and can only be used >> by the system itself. Priority 1 is the next highest. > > This is probably reasonable. It also means you've already tripped into the > usual descriptive issue of lower is better; better is not higher. :-) > > -- Jeff > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Jul 20 08:05:28 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81BA1A87C8; Mon, 13 Jul 2015 16:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, 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 p-f-P7nI2uZg; Mon, 13 Jul 2015 16:46:54 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E1B401A87C7; Mon, 13 Jul 2015 16:46:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 74DD91E436; Mon, 13 Jul 2015 19:48:43 -0400 (EDT) Date: Mon, 13 Jul 2015 19:48:43 -0400 From: Jeffrey Haas To: "Joel M. Halpern" Message-ID: <20150713234843.GK13783@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A44B12.10201@joelhalpern.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 08:05:26 -0700 Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , internet-drafts@ietf.org, Andy Bierman , Alia Atlas , i2rs , i-d-announce@ietf.org, Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:46:54 -0000 Joel, On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: > To amplify my previous reply on priority, priority is associated > with the I2RS Client. it does not change even if the client is > acting on behalf of multiple secondary identities. (If the use case > requires that variability, use multiple primary identities, with > separate sessions.) To attempt to reduce this to an example: Basis case: Multiple clients speaking directly to an agent. Clients have distinct priorities. Priority causes config to tie-break appropriately among the various client interactions. Proxy case: Agent is against as "root" from a proxy, potentially with the a single priority. As long as the proxy maintains the tie-breaking as if it had implemented the agent operations, it's okay that the resultant nodes may have the same priority associated with them? Gloss: We still haven't concluded our discussion as to whether the nodes are decorated as "owned by an identity" or "have a priority". Note that the gloss has an interesting impact. If nodes are expected to get their priority via identity, this makes things very messy if you don't maintain multiple identities to have distinct priorities in the proxy case. -- Jeff From nobody Mon Jul 20 08:05:30 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11E11A87EA for ; Mon, 13 Jul 2015 16:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 ksOsZEkNwhva for ; Mon, 13 Jul 2015 16:54:46 -0700 (PDT) Received: from mail-la0-f45.google.com (mail-la0-f45.google.com [209.85.215.45]) (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 A0C801A87D2 for ; Mon, 13 Jul 2015 16:54:45 -0700 (PDT) Received: by lagw2 with SMTP id w2so25716634lag.3 for ; Mon, 13 Jul 2015 16:54:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PmF3SBO5aKC4ZSoXQInjERfXjfOfBbmwSAUv9WoTT10=; b=b7HOUMPih6YV8rl3QwuWAB70q1TuaND6a8DnHQZ2ebWTpvN7UwYvE7I0kyHwy0TpSe 6ON4yi85dY2RfFVd5ZehPWI+Lw5sBAtdjbWiO4r0AL9k5KjBCbw4mMQ6euU98x90rWAF VaKmVl9Wh+zVUx9ie4mGYwHrzO+RX3MNNNX1bX0nGec4U3qPatlcY3oERKrKe/jG1TVG 9OgZpjlt5QKzrW8j9/paQLDHHh425lp6kpkwjVhZedmyFuw1+lP28XtlQqCjkqHfNuMM mVVkaPgP25SUhV1BX5ZK32tuv92XowXJr8m78NdAfBmGnRhNRVlFZyA37e2y4rGeJwp8 TCwQ== X-Gm-Message-State: ALoCoQnbEmxDJr5z9+ReUOfgFQT4xOiaA80eaYSowbSwdPd+5T8IOm9Wv3mOh79cQ4rK6i902vHr MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr34456567lbc.82.1436831684128; Mon, 13 Jul 2015 16:54:44 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Mon, 13 Jul 2015 16:54:44 -0700 (PDT) In-Reply-To: <20150713234843.GK13783@pfrc.org> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> Date: Mon, 13 Jul 2015 16:54:44 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a1134dcc82289c3051aca723b Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 08:05:26 -0700 Cc: "i2rs@ietf.org" , dai.xianxian@zte.com.cn, Jeff Haas , internet-drafts@ietf.org, Alia Atlas , i2rs , i-d-announce@ietf.org, "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 23:54:47 -0000 --001a1134dcc82289c3051aca723b Content-Type: text/plain; charset=UTF-8 On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas wrote: > Joel, > > On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote: > > To amplify my previous reply on priority, priority is associated > > with the I2RS Client. it does not change even if the client is > > acting on behalf of multiple secondary identities. (If the use case > > requires that variability, use multiple primary identities, with > > separate sessions.) > > To attempt to reduce this to an example: > Basis case: Multiple clients speaking directly to an agent. Clients have > distinct priorities. Priority causes config to tie-break appropriately > among the various client interactions. > > Proxy case: Agent is against as "root" from a proxy, potentially with the > a single priority. As long as the proxy maintains the tie-breaking as if > it > had implemented the agent operations, it's okay that the resultant nodes > may > have the same priority associated with them? > > Gloss: We still haven't concluded our discussion as to whether the nodes > are > decorated as "owned by an identity" or "have a priority". > > Note that the gloss has an interesting impact. If nodes are expected to > get > their priority via identity, this makes things very messy if you don't > maintain multiple identities to have distinct priorities in the proxy case. > > But the secondary identity is just extra meta-data to be stored by the agent. If there is a priority associated with each secondary client then that becomes the client-id. The design does not directly support different priorities per broker. The broker needs to pretend to be different clients, and each session will have a different client-id and priority. This is non-optimal but not broken. -- Jeff > Andy --001a1134dcc82289c3051aca723b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 13, 2015 at 4:48 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Joel,

On Mon, Jul 13, 2015 at 07:34:42PM -0400, Joel M. Halpern wrote:
> To amplify my previous reply on priority, priority is associated
> with the I2RS Client.=C2=A0 it does not change even if the client is > acting on behalf of multiple secondary identities.=C2=A0 (If the use c= ase
> requires that variability, use multiple primary identities, with
> separate sessions.)

To attempt to reduce this to an example:
Basis case: Multiple clients speaking directly to an agent.=C2=A0 Clients h= ave
distinct priorities.=C2=A0 Priority causes config to tie-break appropriatel= y
among the various client interactions.

Proxy case: Agent is against as "root" from a proxy, potentially = with the
a single priority.=C2=A0 As long as the proxy maintains the tie-breaking as= if it
had implemented the agent operations, it's okay that the resultant node= s may
have the same priority associated with them?

Gloss: We still haven't concluded our discussion as to whether the node= s are
decorated as "owned by an identity" or "have a priority"= ;.

Note that the gloss has an interesting impact.=C2=A0 If nodes are expected = to get
their priority via identity, this makes things very messy if you don't<= br> maintain multiple identities to have distinct priorities in the proxy case.=


But the secondary identity is just ext= ra meta-data to be stored by
the agent.=C2=A0 If there is a prior= ity associated with each secondary client
then that becomes the c= lient-id.=C2=A0

The design does not directly suppo= rt different priorities per broker.
The broker needs to pretend t= o be different clients, and each session
will have a different cl= ient-id and priority.=C2=A0 This is non-optimal but not broken.
<= br>



-- Jeff

Andy
=C2=A0

--001a1134dcc82289c3051aca723b-- From nobody Mon Jul 20 15:19:18 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA52E1A877E for ; Mon, 20 Jul 2015 15:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09YMsevTEtnB for ; Mon, 20 Jul 2015 15:19:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE651A877B for ; Mon, 20 Jul 2015 15:19:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7712B14DC for ; Tue, 21 Jul 2015 00:19:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id YfqmqPtbuJCL for ; Tue, 21 Jul 2015 00:19:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 21 Jul 2015 00:19:12 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1DCB420039 for ; Tue, 21 Jul 2015 00:19:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qoplujcEpzEj; Tue, 21 Jul 2015 00:19:12 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1FCC420036; Tue, 21 Jul 2015 00:19:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 55A113545494; Tue, 21 Jul 2015 00:19:10 +0200 (CEST) Date: Tue, 21 Jul 2015 00:19:10 +0200 From: Juergen Schoenwaelder To: i2rs@ietf.org Message-ID: <20150720221910.GA17835@elstar.local> Mail-Followup-To: i2rs@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 22:19:17 -0000 Hi, I looked at this document from the perspective of NETCONF/RESTCONF and here are some comments I wrote down while reading the document: a) I assume the following two requirements are simply a bit badly worded but not harmful: o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a client, MUST confirm that the client has a valid identity. o SEC-REQ-04: The client, upon receiving an I2RS message from an agent, MUST confirm the I2RS agent's identity. b) The point here is that for protocols that use a secure transport, authentication typically takes place when a secure transport is established and not when I2RS messages are received. o SEC-REQ-08: Each Identity is associated with one secondary identity during a particular read/write sequence, but the secondary identity may vary during the time a connection between the I2RS client and I2RS agent is active. The variance of the secondary identity allows the I2rs client to be associated with multiple applications and pass along an identifier for these applications in the secondary identifier. Not really a security requirement I would say. Not sure it needs to stay in the security requirements document. c) This part of SEC-REQ-10 is somewhat unclear: [...] In addition, the key management mechanisms need to be able to update the keys before they have lost sufficient security strengths, without breaking the connection between the agents and clients. It is unclear which keys are meant. Security protocols usually have keys to authenticate communicating parties, they typically generate a session master key and they usually derive the currently used encryption key from the session master key and they usually perform automated rekeying. If this refers to authentication keys, then key updates usually do not impact existing sessions. d) It remains unclear what that following means in practice: SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement mechanisms that mitigate DoS attacks e) I find it kind of surprising that the security requirements document allows for non-secure channels. This should be checked with the security directorate. f) Section 2.4.1 seems to be a misplaced protocol requirement - this is pretty much unrelated to security from what I can tell. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jul 20 15:21:19 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785471A87E2 for ; Mon, 20 Jul 2015 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvAu8B_QC5My for ; Mon, 20 Jul 2015 15:21:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ACEC1A87DB for ; Mon, 20 Jul 2015 15:21:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 4D24714DC for ; Tue, 21 Jul 2015 00:21:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VvTIncyiqr_4 for ; Tue, 21 Jul 2015 00:21:05 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Tue, 21 Jul 2015 00:21:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36CF420037 for ; Tue, 21 Jul 2015 00:21:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id uTyazpC0J0z0; Tue, 21 Jul 2015 00:21:05 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9672920036; Tue, 21 Jul 2015 00:21:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8AB6935454C0; Tue, 21 Jul 2015 00:21:04 +0200 (CEST) Date: Tue, 21 Jul 2015 00:21:04 +0200 From: Juergen Schoenwaelder To: i2rs@ietf.org Message-ID: <20150720222104.GB17835@elstar.local> Mail-Followup-To: i2rs@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: Subject: [i2rs] review of draft-mglt-i2rs-security-environment-reqs-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 22:21:13 -0000 Hi, I looked at this document from the perspective of NETCONF/RESTCONF and here are some comments I wrote down while reading the document: a) The abstract says: Environment security requirements are independent of the protocol used for I2RS. Hence, there should be no requirements for NETCONF. But lets see... REQ 3: The I2RS Agent validates data to ensure injecting the information will not create a deadlock with any other system, nor will it create a routing loop, nor will it cause the control plane to fail to converge. This is not implementable. How should an I2RS Agent determine this? This would require that every I2RS Agent has a global view on the network and the routing state in all network elements. b) There are a number of AAA requirements, some are difficult to understand and it remains unclear why they are not already covered in the authentication document. Overall, I am a bit confused which problem this document tries to solve. There are a few bits of implementation advice, perhaps this document could be the beginning of an implementation guidelines document. c) The discussion of communication requirements between an I2RS Client and its Applications seems a bit out of scope since I understand this is not something I2RS actively works on. The I2RS architecture document says: The details of how applications communicate with a remote client is out of scope for I2RS. Similarly, the authentication requirements document says: Please note the security of the application to I2RS client connection is outside of the I2RS protocol or I2RS interface. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 21 01:35:23 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4302D1B2A89 for ; Tue, 21 Jul 2015 01:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] 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 yuv2CHEUihIq for ; Tue, 21 Jul 2015 01:35:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 34C541B2A88 for ; Tue, 21 Jul 2015 01:35:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.137.141; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , References: <20150720221910.GA17835@elstar.local> In-Reply-To: <20150720221910.GA17835@elstar.local> Date: Tue, 21 Jul 2015 04:35:05 -0400 Message-ID: <000001d0c390$262106f0$726314d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKWlr5U47tWceDoeLqGTaPNdTl9bJxZzYmw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Benoit Claise \(bclaise\)'" , 'Alia Atlas' Subject: Re: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:35:21 -0000 Juergen: Thank you for your review. In order to make progress on this review, would you kindly tell me: a) Why you did not make any comment on REQ 01 and REQ 02? Did you consider these to not have any relationship to the NETCONF/RESTCONF? SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least one unique identifier that uniquely identifies each party. o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for mutual identification of the I2RS client and I2RS agent. b) On SEC-REQ-03 and SEC-REQ-04, if you feel these are badly worded - can you suggest new text or a refinement? c) On SEC-REQ-05, SEC-REQ-06, SEC-REQ-07 why you did not make any comment? Did you consider these outside the NETCONF? SEC-REQ-05: Identity distribution and the loading of these identities into I2RS agent and I2RS Client SHOULD occur outside the I2RS protocol. o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF or private) will distribute or load identities so that the I2RS client/agent has these identities prior to the I2RS protocol establishing a connection between I2RS client and I2RS agent. o SEC-REQ-07: Each Identity MUST be linked to one priority d) On SEC-REQ-08: Can you explain why you do not feel this is a security requirement? e) On SEC-REQ-09: Did you accept this requirement? SEC-REQ-09: The data security of the I2RS protocol MUST be able to support transfer of the data over a secure transport and optionally be able to support a non-security transport. A security transport is defined to have the qualities of confidentiality, has message integrity, prevents replay attack, and supports end-to-end integrity of the I2RS client-agent session. On SEC-REQ-10: There are many ways to key between two entities. These include pre-shared keys and master-key. Is there better language you wish to suggest? Would you like an list of these key algorithms. What specifically are you stating regarding the key? On SEC-REQ-11, can you tell me if you considered or review this requirement? On SEC-REQ-12, can you tell me why you felt the requirement to have a protocol that mitigated DDoS attacks was not a valuable requirement? Does NETCONF not provide DDoS attacks? Is there a reason why you felt this requirement was not useful? On SEC-REQ-13, SEC-REQ-14, SEQ-REQ-15, SEC-REQ-16, SEC-REQ-18, SEQ-REQ-19, SEC-REQ-20, Can you tell me if as a NETCONF Expert - what your review is? On the allowing of an insecure connection, one of the requirements which I inherited from my previous chairs - was the requirement for an insecure connection for some transport. Would you be willing to share your wisdom as a past NETCONF advisor why the past chairs felt they should allow this insecure connection. Section 2.4.1 was insert to address Andy Bierman's concerns regarding the architecture document. The SEC-REQ-17 for this section was removed so that we could engage in a more substantive discussion. So, can you provide any more details to your comments other than "this is a mistake. Thank you again for your review of this document. I look forward to learning more about your thoughts regarding the security requirements for the I2RS protocol. If you did not review other sections of this document and if you do not have time to review the other sections of this document (see above), can you recommend someone else to review these sections. Any wording would aid me in providing this document. I will revise the document and do a WG adoption call. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Monday, July 20, 2015 6:19 PM To: i2rs@ietf.org Subject: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt Hi, I looked at this document from the perspective of NETCONF/RESTCONF and here are some comments I wrote down while reading the document: a) I assume the following two requirements are simply a bit badly worded but not harmful: o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a client, MUST confirm that the client has a valid identity. o SEC-REQ-04: The client, upon receiving an I2RS message from an agent, MUST confirm the I2RS agent's identity. b) The point here is that for protocols that use a secure transport, authentication typically takes place when a secure transport is established and not when I2RS messages are received. o SEC-REQ-08: Each Identity is associated with one secondary identity during a particular read/write sequence, but the secondary identity may vary during the time a connection between the I2RS client and I2RS agent is active. The variance of the secondary identity allows the I2rs client to be associated with multiple applications and pass along an identifier for these applications in the secondary identifier. Not really a security requirement I would say. Not sure it needs to stay in the security requirements document. c) This part of SEC-REQ-10 is somewhat unclear: [...] In addition, the key management mechanisms need to be able to update the keys before they have lost sufficient security strengths, without breaking the connection between the agents and clients. It is unclear which keys are meant. Security protocols usually have keys to authenticate communicating parties, they typically generate a session master key and they usually derive the currently used encryption key from the session master key and they usually perform automated rekeying. If this refers to authentication keys, then key updates usually do not impact existing sessions. d) It remains unclear what that following means in practice: SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement mechanisms that mitigate DoS attacks e) I find it kind of surprising that the security requirements document allows for non-secure channels. This should be checked with the security directorate. f) Section 2.4.1 seems to be a misplaced protocol requirement - this is pretty much unrelated to security from what I can tell. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jul 21 02:53:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347CF1B2CB8 for ; Tue, 21 Jul 2015 02:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryTsfYC6BUuZ for ; Tue, 21 Jul 2015 02:53:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277381B2CD0 for ; Tue, 21 Jul 2015 02:53:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 71F57103F; Tue, 21 Jul 2015 11:53:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dKh2ln4D0Xmt; Tue, 21 Jul 2015 11:53:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 21 Jul 2015 11:53:37 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3A762003D; Tue, 21 Jul 2015 11:53:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hx0bQet3abbs; Tue, 21 Jul 2015 11:53:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD9A220037; Tue, 21 Jul 2015 11:53:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BF1803545948; Tue, 21 Jul 2015 11:53:34 +0200 (CEST) Date: Tue, 21 Jul 2015 11:53:34 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150721095334.GA19005@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Alia Atlas' , "'Benoit Claise (bclaise)'" References: <20150720221910.GA17835@elstar.local> <000001d0c390$262106f0$726314d0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001d0c390$262106f0$726314d0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "'Benoit Claise \(bclaise\)'" , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:53:45 -0000 On Tue, Jul 21, 2015 at 04:35:05AM -0400, Susan Hares wrote: > Juergen: > > Thank you for your review. In order to make progress on this review, would > you kindly tell me: > > a) Why you did not make any comment on REQ 01 and REQ 02? Did you consider > these to not have any relationship to the NETCONF/RESTCONF? > > SEC-REQ-01: All I2RS clients and I2RS agents MUST have at least > one unique identifier that uniquely identifies each party. > o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for > mutual identification of the I2RS client and I2RS agent. I believe NETCONF/RESTCONF cover these two so I did not comment. I only commented on things where I found the document unclear. > b) On SEC-REQ-03 and SEC-REQ-04, if you feel these are badly worded - can > you suggest new text or a refinement? I happy leave this to I2RS people. > c) On SEC-REQ-05, SEC-REQ-06, SEC-REQ-07 why you did not make any comment? > Did you consider these outside the NETCONF? > > SEC-REQ-05: Identity distribution and the loading of these > identities into I2RS agent and I2RS Client SHOULD occur outside > the I2RS protocol. > o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF > or private) will distribute or load identities so that the I2RS > client/agent has these identities prior to the I2RS protocol > establishing a connection between I2RS client and I2RS agent. > > o SEC-REQ-07: Each Identity MUST be linked to one priority I do not consider them critical to address, see above. > d) On SEC-REQ-08: Can you explain why you do not feel this is a security > requirement? I think it is up to you to explain to me or the WG why you think this is a security requirement. > e) On SEC-REQ-09: Did you accept this requirement? > > SEC-REQ-09: The data security of the I2RS protocol MUST be able to > support transfer of the data over a secure transport and optionally > be able to support a non-security transport. A security transport is > defined to have the qualities of confidentiality, has message > integrity, prevents replay attack, and supports end-to-end integrity > of the I2RS client-agent session. I am not accepting anything. NETCONF and RESTCONF always work over a secure transport. I do question that running I2RS over an unsecure transport will fly high in the security area but up to you to figure this out. > On SEC-REQ-10: There are many ways to key between two entities. These > include pre-shared keys and master-key. Is there better language you wish > to suggest? Would you like an list of these key algorithms. What > specifically are you stating regarding the key? I said 'key' is ambiguous. I like you to clarify what you mean with SEC-REQ-10. > On SEC-REQ-11, can you tell me if you considered or review this requirement? I read the whole document. I don't see a problem with this except that I have a hard time to believe a non-secure transport will fly. > On SEC-REQ-12, can you tell me why you felt the requirement to have a > protocol that mitigated DDoS attacks was not a valuable requirement? Does > NETCONF not provide DDoS attacks? Is there a reason why you felt this > requirement was not useful? I have no clue how you measure whether a protocol has DDoS protection. RESTCONF, for example, is running over HTTP. What is HTTP's DDoS protection? NETCONF runs over SSH. What is SSHs DDoS protection? The point is that DDoS protection must happen way before NETCONF / RESTCONF interactions start. > On SEC-REQ-13, SEC-REQ-14, SEQ-REQ-15, SEC-REQ-16, SEC-REQ-18, SEQ-REQ-19, > SEC-REQ-20, > Can you tell me if as a NETCONF Expert - what your review is? Again, NETCONF and RESTCONF always run over a secure transport and hence the requirements are met. Having these requirements for a non-secure transport seems odd to me (because addressing them would turn the non-secure transport into a secure transport) but this is I2RS business to work out. > On the allowing of an insecure connection, one of the requirements which I > inherited from my previous chairs - was the requirement for an insecure > connection for some transport. Would you be willing to share your wisdom > as a past NETCONF advisor why the past chairs felt they should allow this > insecure connection. I can't provide the reasoning. > Section 2.4.1 was insert to address Andy Bierman's concerns regarding the > architecture document. The SEC-REQ-17 for this section was removed so that > we could engage in a more substantive discussion. So, can you provide any > more details to your comments other than "this is a mistake. I said I fail to see why this belongs into the security requirements document. > Thank you again for your review of this document. I look forward to > learning more about your thoughts regarding the security requirements for > the I2RS protocol. If you did not review other sections of this document > and if you do not have time to review the other sections of this document > (see above), can you recommend someone else to review these sections. > > Any wording would aid me in providing this document. I will revise the > document and do a WG adoption call. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Monday, July 20, 2015 6:19 PM > To: i2rs@ietf.org > Subject: [i2rs] review of draft-hares-i2rs-auth-trans-04.txt > > Hi, > > I looked at this document from the perspective of NETCONF/RESTCONF and here > are some comments I wrote down while reading the document: > > a) I assume the following two requirements are simply a bit badly > worded but not harmful: > > o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a > client, MUST confirm that the client has a valid identity. > > o SEC-REQ-04: The client, upon receiving an I2RS message from an > agent, MUST confirm the I2RS agent's identity. > > b) The point here is that for protocols that use a secure transport, > authentication typically takes place when a secure transport is > established and not when I2RS messages are received. > > o SEC-REQ-08: Each Identity is associated with one secondary > identity during a particular read/write sequence, but the > secondary identity may vary during the time a connection between > the I2RS client and I2RS agent is active. The variance of the > secondary identity allows the I2rs client to be associated with > multiple applications and pass along an identifier for these > applications in the secondary identifier. > > Not really a security requirement I would say. Not sure it needs to > stay in the security requirements document. > > c) This part of SEC-REQ-10 is somewhat unclear: > > [...] In addition, the key management > mechanisms need to be able to update the keys before they have lost > sufficient security strengths, without breaking the connection > between the agents and clients. > > It is unclear which keys are meant. Security protocols usually have > keys to authenticate communicating parties, they typically generate > a session master key and they usually derive the currently used > encryption key from the session master key and they usually perform > automated rekeying. If this refers to authentication keys, then key > updates usually do not impact existing sessions. > > d) It remains unclear what that following means in practice: > > SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement > mechanisms that mitigate DoS attacks > > e) I find it kind of surprising that the security requirements > document allows for non-secure channels. This should be checked > with the security directorate. > > f) Section 2.4.1 seems to be a misplaced protocol requirement - this > is pretty much unrelated to security from what I can tell. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jul 22 04:57:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39AE1B29E5; Wed, 22 Jul 2015 04:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 XvWdyWOy8wT3; Wed, 22 Jul 2015 04:56:55 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (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 88CDE1B3054; Wed, 22 Jul 2015 04:55:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.178.184; From: "Susan Hares" To: Date: Wed, 22 Jul 2015 07:54:56 -0400 Message-ID: <00b501d0c475$3b8d7b50$b2a871f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01D0C453.B47C5080" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdDEdOlQJMGPPUEfQqaMneREQFbH1Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] draft-ietf-teas-yang-te-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:57:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B6_01D0C453.B47C5080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you for defining the terms native TE-Topology and customized TE-Topology in your draft. Do you think the native topology and customized topology definitions could be adapted to normal (non-TE topologies)? Sue ------=_NextPart_000_00B6_01D0C453.B47C5080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you = for defining the terms native TE-Topology and customized TE-Topology in = your draft.   Do you think the native topology and customized = topology definitions could be adapted to normal (non-TE topologies)? =

 

Sue

------=_NextPart_000_00B6_01D0C453.B47C5080-- From nobody Thu Jul 23 04:15:13 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D551A8A07 for ; Thu, 23 Jul 2015 04:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 4Z3m7qqaT0N7 for ; Thu, 23 Jul 2015 04:15:10 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B53D1A854B for ; Thu, 23 Jul 2015 04:15:09 -0700 (PDT) X-AuditID: c1b4fb2d-f79176d00000321c-14-55b0ccbc293c Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.24.12828.CBCC0B55; Thu, 23 Jul 2015 13:15:08 +0200 (CEST) Received: from ESESSMB101.ericsson.se ([169.254.1.16]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 13:15:07 +0200 From: Amit Dass To: "i2rs@ietf.org" Thread-Topic: mVPN in Service Topology Model Thread-Index: AdDFOMo/izKCF7AQQgWVIqoBTI2Yhg== Date: Thu, 23 Jul 2015 11:15:07 +0000 Message-ID: <2A8B18CA4F90D7498B8F58E7073CAB340EE5B3AA@ESESSMB101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_2A8B18CA4F90D7498B8F58E7073CAB340EE5B3AAESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje6eMxtCDfrXiFqsm/GBxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQt7FrMWPBavaJv8nbWB8a9IFyMHh4SAicS5y/ZdjJxAppjE hXvr2boYuTiEBI4ySpy7toARwlnMKLFk9noWkCo2AQ2Jtcu3gtkiAsoSB3/2soLYwgLqEhPf LGAFGSoioCPR9D0MokRP4vnPecwgNouAqsT9rqdgNq+Ar0T7vDOMIDYj0OLvp9YwgdjMAuIS t57MZ4I4SEBiyZ7zzBC2qMTLx/9YIWwlibWHt7OArGIWyJdYtNgUYqSgxMmZT1gmMArNQjJp FkLVLCRVECU6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG0eLU4uLcdCNjvdSizOTi4vw8 vbzUkk2MwGg4uOW37g7G1a8dDzEKcDAq8fA+aNoQKsSaWFZcmXuIUZqDRUmcd8bmvFAhgfTE ktTs1NSC1KL4otKc1OJDjEwcnFINjMkPBZUXHrD5sGOHVZDpTpEXai4vm9Ifdm16wdynFL6M UTLpX5H4qoB9wgIH1eJPKvjtuLgnYu2zq+ylcUlzXHv/ctmmLLmWOrl0omzjrvM7Qg25EmxK //9j+2uX26J2ZtOZ8tkBtX0MYtEhp6/0ycSe22qzJ+q2VP5OjoAP37/H6ft9cMy1UWIpzkg0 1GIuKk4EAN1D+15nAgAA Archived-At: Subject: [i2rs] mVPN in Service Topology Model X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:15:11 -0000 --_000_2A8B18CA4F90D7498B8F58E7073CAB340EE5B3AAESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, One question I have on the Service Topology model is that if we plan to cov= er mVPN under the L3 topology or it's a separate use case? BR/AMit --_000_2A8B18CA4F90D7498B8F58E7073CAB340EE5B3AAESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

 

One question I have on the Service Topology model= is that if we plan to cover mVPN under the L3 topology or it's a separate = use case?

 

 

BR/AMit

 

--_000_2A8B18CA4F90D7498B8F58E7073CAB340EE5B3AAESESSMB101erics_-- From nobody Fri Jul 24 02:06:13 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255AA1B2BE7; Tue, 21 Jul 2015 02:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TQzAOfcJWGTb; Tue, 21 Jul 2015 02:35:18 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (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 3C91B1A89E0; Tue, 21 Jul 2015 02:35:18 -0700 (PDT) Received: from dhcp-8833.meeting.ietf.org ([31.133.136.51]:59397 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1ZHTx5-0002FH-7D; Tue, 21 Jul 2015 09:35:09 +0000 From: "Russ White" To: "'Andy Bierman'" , "'Jeffrey Haas'" References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <20150713224652.GB5779@pfrc.org> <20150713230952.GI13783@pfrc.org> <55A44B12.10201@joelhalpern.com> <20150713234843.GK13783@pfrc.org> In-Reply-To: Date: Tue, 21 Jul 2015 05:34:16 -0400 Message-ID: <03cc01d0c398$87f4ff50$97defdf0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQCQIeJoLHKQ7oAYGCGjY2QIv20pQwNLDm62AgtPHvEBh1wz+wJSZctmAodrX98BVhkhJAEZ0mfan/WwyUA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 02:06:11 -0700 Cc: i2rs@ietf.org, dai.xianxian@zte.com.cn, 'Jeff Haas' , internet-drafts@ietf.org, 'Alia Atlas' , 'i2rs' , i-d-announce@ietf.org, "'Joel M. Halpern'" , 'Susan Hares' Subject: Re: [i2rs] some doubt about "draft-ietf-i2rs-ephemeral-state-00".// I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:35:23 -0000 =20 > The design does not directly support different priorities per broker. > The broker needs to pretend to be different clients, and each session = will > have a different client-id and priority. This is non-optimal but not = broken. And it's much simpler to implement. It would leave proxies out of scope = while allowing those who want to implement proxies a way to do so. In = short -- this seems like a good solution. Russ