From nobody Mon Feb 2 08:22: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 7E28E1A86DE for ; Fri, 23 Jan 2015 10:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.75 X-Spam-Level: X-Spam-Status: No, score=0.75 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qC_kcwIl4HyY for ; Fri, 23 Jan 2015 10:20:21 -0800 (PST) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E641A914F for ; Fri, 23 Jan 2015 10:20:19 -0800 (PST) Received: by mail-pd0-f173.google.com with SMTP id fp1so9947373pdb.4 for ; Fri, 23 Jan 2015 10:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/OU5hyQivJabC3rSSF0R+09roGI5/9YpQFHSX7UhZX0=; b=QEM2eHEhdqcF0J+fWnP1U4l7U07Pi5uO4XsTtbXAqEwHiF+j+/aa0DiIWRxjg/36Vj HznipG6mRUWGwIs4oDM5tGkwR/cI1NAi6g/OcpJI2e9wMsStfU8aLZqwU2UymGNffqnr HxM9w0G/x99OQ4AnqLzTWrqWlxzCZ3r4aQtieFEM2wzDdDzwSlxTMBZGVk5p2aiDLa3m K6YJb1xccB9Vw/8oSSibOJCKH140lAIq88108CDBb/u9f+CK5yQT+UNvP6YC6XIwprX1 gc6laRWG/E9ffBtJTewB+BxG54pBQiBwRT74Bf7qhy+zbCa5ZImkNyH9KPop8AbvWhA6 X5Cg== MIME-Version: 1.0 X-Received: by 10.66.235.200 with SMTP id uo8mr13288501pac.108.1422037218633; Fri, 23 Jan 2015 10:20:18 -0800 (PST) Received: by 10.70.80.73 with HTTP; Fri, 23 Jan 2015 10:20:18 -0800 (PST) In-Reply-To: References: Date: Fri, 23 Jan 2015 10:20:18 -0800 Message-ID: From: Amitava Biswas To: undisclosed-recipients:; Content-Type: multipart/alternative; boundary=001a1136d022462e29050d55d713 Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 08:22:22 -0800 Subject: [i2rs] Fwd: Cal for papers: IEEE Workshops on SDN, NFV, under NetSoft 2015, London, 13-17 Apr. 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, 23 Jan 2015 18:20:23 -0000 --001a1136d022462e29050d55d713 Content-Type: text/plain; charset=UTF-8 Hi All, This is a 2nd call for papers for IEEE Workshops on SDN, NFV under NetSoft 2015 IEEE conference, in London, UK, on 13-17 Apr. The submission deadline for all workshops are Jan 31, 2015. Details are below. CALL FOR PAPERS ================================================================= IEEE NetSoft 2015 Workshops 1st IEEE Conference on Network Softwarization April 13-17, 2015 - London, UK http://sites.ieee.org/netsoft/workshop/ Workshop Paper Submission Deadline: January 31, 2015 ================================================================= NetSoft 2015 will be the first of a series of annual events established as part of the IEEE Software-Defined Networks initiative of the IEEE Future Directions Committee in order to build an IEEE-wide community in this area across multiple IEEE societies and councils (http://sdn.ieee.org/about.html). Software-Defined Networking (SDN), Network Function Virtualization (NFV), and Software-Defined Clouds could be seen as different expressions of an overall transformation trend, which is deeply impacting and Telecom and IT industries. This trend is also transforming several other Industries, in using "softwarization" to optimize costs and processes and in bringing new values in infrastructures. In particular, SDN, NFV and network programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure management. NetSoft 2015 will feature 3 workshops, aiming at bringing together researchers and practitioners to discuss issues, current state and future trends in SDN and NFV related areas on manageability, security and 5G. NetSoft 2015 workshops will be held on April 13 and April 17, 2015. All workshops are currently accepting submissions of original/position/work-in-progress/experience papers at respective links as below. Submissions must be in IEEE 2-column style with a length limitation of 6 pages (including title, abstract, all figures, tables, and references). Submission instructions, important dates and further details are available on the workshops websites as below. Accepted and presented papers will be published in the workshop proceedings and submitted to IEEE Xplore. -IEEE MISSION 2015 IEEE Workshop on Management Issues in SDN, SDI and NFV Website: http://sites.ieee.org/netsoft/workshop/mission/ Submission: http://edas.info/19315 Organizers: Kashinath Basu, Oxford Brookes University, UK; Chen Liu, Microsoft, US -IEEE Soft5G 2015 IEEE Workshop on Software Defined 5G Networks Website: http://www.fokus.fraunhofer.de/go/Soft5G_Workshop_2014 Submission: http://edas.info/N19311 Organizers: Thomas Magedanz, TU Berlin/Fraunhofer Institute FOKUS, Germany; Roberto Riggio, CREATE-NET, Italy -IEEE SEC-SDN 2015 IEEE Workshop on Security issues in SDN Website: http://sites.ieee.org/netsoft/workshop/sec-sdn/ Submission: https://edas.info/19419 Organizers: Olivier Festor, Telecom-Nancy, France; Radu State, SnT, Luxembourg Important dates: Paper Submission: January 31, 2015 Notification of Acceptance: February 28, 2015 Camera Ready Papers: March 13, 2015 We are looking forward to your paper submission as well as you participation at the NetSoft 2015 workshops in April 2015. NETSOFT WORKSHOP CO-CHAIRS Amitava Biswas, Cisco Systems, US Noura Limam, University of Waterloo, Canada NETSOFT GENERAL CO-CHAIRS Prosper Chemouil, Orange Labs, France George Pavlou, University College London,UK IEEE SDN Initiative Chair Antonio Manzalini, Telecom Italia, Italy --001a1136d022462e29050d55d713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= Hi All,

This is a 2nd call for papers for IEEE Workshops on SD= N, NFV under NetSoft 2015 IEEE conference, in London, UK, on 13-17 Apr.
=
The submission deadline for all workshops are Jan 31, 2015. Details a= re below.

CALL FOR PAPERS
=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 IEEE NetS= oft 2015 Workshops
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0 1st IEEE Conference on Net= work Softwarization
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 April 13-17, = 2015 - London, UK
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0
=C2=A0=C2=A0= =C2=A0 =C2=A0=C2=A0=C2=A0 http://sites.ieee.org/netsoft/workshop/
=C2=A0<= br>=C2=A0=C2=A0=C2=A0 Workshop Paper Submission Deadline:=C2=A0January 31, = 2015
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

NetSoft 2015= will be the first of a series of annual events established as part of the = IEEE Software-Defined Networks initiative of the IEEE Future Directions Com= mittee in order to build an IEEE-wide community in this area across multipl= e IEEE societies and councils (http://sdn.ieee.org/about.html). Software-Defined Netw= orking (SDN), Network Function Virtualization (NFV), and Software-Defined C= louds could be seen as different expressions of an overall transformation t= rend, which is deeply impacting and Telecom and IT industries. This trend i= s also transforming several other Industries, in using "softwarization= " to optimize costs and processes
and in bringing new values in in= frastructures. In particular, SDN, NFV and network programmability are crea= ting the conditions to reinvent network and cloud
architectures, accele= rate service deployment and facilitate infrastructure management.

N= etSoft 2015 will feature 3 workshops, aiming at bringing together researche= rs and practitioners to discuss issues, current state and future trends in = SDN and NFV related areas on manageability, security and 5G.

NetSoft= 2015 workshops will be held on April 13 and April 17, 2015. All workshops = are currently accepting submissions of original/position/work-in-progress/e= xperience
papers at respective links as below. Submissions must be in I= EEE 2-column style with a length limitation of 6 pages (including title, ab= stract, all figures, tables, and references). Submission instructions, impo= rtant dates and further details are available on the workshops websites as = below.

Accepted and presented papers will be published in the worksh= op proceedings and submitted to IEEE Xplore.

-IEEE MISSION 2015
= =C2=A0IEEE Workshop on Management Issues in SDN, SDI and NFV
=C2=A0Websi= te:=C2=A0http://sites.ieee.org/netsoft/workshop/mission/
=C2=A0Su= bmission: http://edas.= info/19315
=C2=A0Organizers: =C2=A0=C2=A0=C2=A0 Kashinath Basu, Oxfo= rd Brookes University, UK; Chen Liu, Microsoft, US

-IEEE Soft5G 2015=
=C2=A0IEEE Workshop on Software Defined 5G Networks
=C2=A0Website:= =C2=A0http://www.fokus.fraunhofer.de/go/Soft5G_Workshop_2014<= br>=C2=A0Submission: = http://edas.info/N19311
=C2=A0Organizers: =C2=A0=C2=A0=C2=A0 Thomas = Magedanz, TU Berlin/Fraunhofer Institute FOKUS, Germany;=C2=A0=C2=A0=C2=A0 = Roberto Riggio, CREATE-NET, Italy

-IEEE SEC-SDN 2015
=C2=A0IEEE W= orkshop on Security issues in SDN
=C2=A0Website:=C2=A0http://sites.ie= ee.org/netsoft/workshop/sec-sdn/
=C2=A0Submission: https://edas.info/19419
=C2=A0O= rganizers: =C2=A0=C2=A0=C2=A0 Olivier Festor, Telecom-Nancy, France; Radu S= tate, SnT, Luxembourg

Important dates:=C2=A0
Paper Submission: J= anuary 31, 2015
Notification of Acceptance: February 28, 2015
Camera= Ready Papers: March 13, 2015

We are looking forward to your paper s= ubmission as well as you participation at the NetSoft 2015 workshops in Apr= il 2015.

NETSOFT WORKSHOP CO-CHAIRS
Amitava Biswas, Cisco Systems= , US
Noura Limam, University of Waterloo, Canada

NETSOFT GENERAL= CO-CHAIRS
Prosper Chemouil, Orange Labs,
France George Pavlou, Uni= versity College London,UK

IEEE SDN Initiative Chair
Antonio Manz= alini, Telecom Italia, Italy=C2=A0

--001a1136d022462e29050d55d713-- From nobody Mon Feb 2 08:22: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 8EC651A1B18 for ; Thu, 29 Jan 2015 15:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33xrm-tRNPme for ; Thu, 29 Jan 2015 15:35:09 -0800 (PST) Received: from sjmda16.webex.com (sjmda16.webex.com [64.68.124.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4A51A8893 for ; Thu, 29 Jan 2015 15:35:09 -0800 (PST) Received: from jva2tc117.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-6.webex.com [64.68.121.241]) by sjmda16.webex.com (Postfix) with ESMTP id 84259A054F for ; Thu, 29 Jan 2015 23:35:09 +0000 (GMT) Received: from jva2tc117.webex.com (localhost [127.0.0.1]) by jva2tc117.webex.com (Postfix) with ESMTP id 35A559FB3D for ; Thu, 29 Jan 2015 23:35:09 +0000 (GMT) Date: Thu, 29 Jan 2015 23:35:09 +0000 (GMT) From: I2RS Working Group To: i2rs@ietf.org Message-ID: <52238249.34515.1422574509206.JavaMail.nobody@jva2tc117.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_34513_1002631319.1422574509205" X-Priority: 3 Importance: normal Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 08:22:22 -0800 Subject: [i2rs] WebEx meeting invitation: I2RS interim Meeting X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: i2rs-chairs@tools.ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 23:35:11 -0000 ------=_Part_34513_1002631319.1422574509205 Content-Type: multipart/Alternative; boundary="----=_Part_34514_2067884071.1422574509205" ------=_Part_34514_2067884071.1422574509205 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKSTJSUyBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKCkkyUlMgaW50ZXJpbSBNZWV0aW5nClRodXJzZGF5LCBGZWJydWFyeSA1LCAy MDE1CjEwOjAwIGFtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQtMDU6 MDApICB8ICAxIGhyIDMwIG1pbgoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tNTRkMTE1N2M2ZGFkYWY5NmNlZDlkMTI3NjU1MmNiNzEK TWVldGluZyBudW1iZXI6IDY0OSA3MzcgMTI4Ck1lZXRpbmcgcGFzc3dvcmQ6IHN1ZWFpZHNqZWZm CgoNCkpPSU4gQlkgUEhPTkUNCjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJl ciAoVVMvQ2FuYWRhKSAKMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2Fu YWRhKQpBY2Nlc3MgY29kZTogNjQ5IDczNyAxMjgKClRvbGwtZnJlZSBkaWFsaW5nIHJlc3RyaWN0 aW9uczogCmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRm DQoNCgpBZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2FsZW5kYXI6Cmh0dHBzOi8vaWV0Zi53ZWJl eC5jb20vaWV0Zi9qLnBocD9NVElEPW05Yjk1NzYyMWM5MTY1YjNkYzViOWQ0MTY2ZjVjMWFlOA0K DQoKQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6Cmh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9tYwoKCklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRo YXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24g c2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNj b3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3Ug YXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBj b25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUg aG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi4K ------=_Part_34514_2067884071.1422574509205 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBJMlJT IFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPkkyUlMgaW50ZXJpbSBNZWV0aW5nPC9iPgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQkJPHRyIHN0eWxlPSJtYXJnaW46MHB4Ij4KCQkJCQkJCQk8dGQ+ VGh1cnNkYXksIEZlYnJ1YXJ5IDUsIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4KCQkJ CQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjEwOjAwIGFtJm5ic3A7Jm5i c3A7fCZuYnNwOyZuYnNwO0Vhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0wNTow MCkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBociAzMCBtaW4KCQkJCQkJCQk8L3RkPgoJCQkJ CQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0OiAy MHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+CgkJ CQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJCQkJ CQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZweCI+ CgkJCQkJCQkJCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElE PW01NGQxMTU3YzZkYWRhZjk2Y2VkOWQxMjc2NTUyY2I3MSIKCQkJCQkJCQkJCXN0eWxlPSJ0ZXh0 LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJCQkJ CTxiPkpvaW4gV2ViRXggbWVldGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+CgkJ CQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1dG87 IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJ CQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGluZyBu dW1iZXI6CgkJCQkJCQkJPC90ZD4KCQkJCQkJCQk8dGQ+NjQ5IDczNyAxMjgKCQkJCQkJCQk8L3Rk PgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmctcmln aHQ6IDVweDsiPk1lZXRpbmcgcGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+c3VlYWlkc2plZmY8 L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCgoKCQoKCTx0YWJsZT48dHIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjIwcHgiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90 cj48L3RhYmxlPjx0YWJsZT48dHI+PHRkIHN0eWxlPSJmb250LXNpemU6MTZweCI+PGI+Sm9pbiBi eSBwaG9uZTwvYj48L3RkPjwvdHI+PHRyIHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGI+MS04Nzct NjY4LTQ0OTM8L2I+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9DYW5hZGEpPC90 ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEtNjUwLTQ3OS0zMjA4PC9iPiZu YnNwO0NhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSk8L3RkPjwvdHI+PHRyIHN0eWxlPSJt YXJnaW46MHB4Ij48dGQ+QWNjZXNzIGNvZGU6Jm5ic3A7NjQ5IDczNyAxMjg8L3RkPjwvdHI+PHRy IHN0eWxlPSJtYXJnaW46MHB4Ij48dGQ+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRm L3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGYiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtm b250LXNpemU6MTNweDtjb2xvcjojMDBBRkY5OyI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rp b25zPC9hPjwvdGQ+PC90cj48L3RhYmxlPgoKCQkJCQk8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhl aWdodDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJs ZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjEzcHgiPjxhIGhyZWY9Imh0dHBzOi8v aWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW05Yjk1NzYyMWM5MTY1YjNkYzViOWQ0MTY2 ZjVjMWFlOCIgc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lO2NvbG9yOiMwMEFGRjk7IGZvbnQt c2l6ZToxM3B4Ij5BZGQgdGhpcyBtZWV0aW5nPC9hPiB0byB5b3VyIGNhbGVuZGFyLjwvdGQ+PC90 cj48L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBweDsiPjx0ZCBzdHls ZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgo8dGFibGU+CiAgICA8dHI+ CiAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTNweDtmb250LWZhbWlseTogQXJpYWw7Y29s b3I6ICM2NjY2NjY7Ij4KICAgICAgICBDYW4ndCBqb2luIHRoZSBtZWV0aW5nPwogICAgIAk8YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiIHN0eWxlPSJ0ZXh0LWRlY29yYXRp b246bm9uZTtmb250LXNpemU6MTNweDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjojMDBBRkY5O2Zv bnQtY29sb3I6IzAwQUZGOTsiPgogICAgICAgIAlDb250YWN0IHN1cHBvcnQuPC9hPgoJCTwvdGQ+ CiAgICA8L3RyPgo8L3RhYmxlPgo8dGFibGU+PHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMTBweDsi Pjx0ZCBzdHlsZT0iaGVpZ2h0OjEwcHgiPiZuYnNwOzwvdGQ+PC90cj48L3RhYmxlPgoJCQkJCQk8 dGFibGU+CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTJweDtjb2xv cjogI0EwQTBBMDsiPgoJCQkJCQkJCQlJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0 IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNl bnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292 ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwgeW91IGF1 dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBub3QgY29u c2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhlIGhv c3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uPC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwv dGFibGU+CgkJCQk8L3RkPgoJCQk8L3RyPgoJCTwvdGFibGU+Cgk8L3RkPgogICA8L3RyPgo8L3Rh YmxlPgoKPC9ib2R5Pg== ------=_Part_34514_2067884071.1422574509205-- ------=_Part_34513_1002631319.1422574509205 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86aTJyc0BpZXRmLm9yZwpPUkdBTklaRVI7Q049Ikky UlMgV29ya2luZyBHcm91cCI6TUFJTFRPOmkycnMtY2hhaXJzQHRvb2xzLmlldGYub3JnCkRUU1RB UlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDIwNVQxMDAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVy biBUaW1lIjoyMDE1MDIwNVQxMTMwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MQpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4w NDU2NjgwLTMyMTY4MTc0Ny1TVT1pZXRmCkRUU1RBTVA6MjAxNTAyMDVUMTUwMDAwWgpERVNDUklQ VElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW01NGQxMTU3YzZkYWRhZjk2Y2VkOWQxMjc2NTUyY2I3MVxuTWVldGluZyBu dW1iZXI6IDY0OSA3MzcgMTI4XG5NZWV0aW5nIHBhc3N3b3JkOiBzdWVhaWRzamVmZlxuXG5cbkpP SU4gQlkgUEhPTkVcbjEtODc3LTY2OC00NDkzIENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMv Q2FuYWRhKSBcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlc bkFjY2VzcyBjb2RlOiA2NDkgNzM3IDEyOFxuXG5Ub2xsLWZyZWUgZGlhbGluZyByZXN0cmljdGlv bnM6IFxuaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVlX3Jlc3RyaWN0aW9ucy5wZGZc blxuXG5cbkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOlxuaHR0 cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jXG5cblxuSU1QT1JUQU5UIE5PVElDRTogUGxlYXNl IG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZv cm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5 IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Np b24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3Ug ZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3 aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLlxuClgtQUxULURFU0M7Rk1U VFlQRT10ZXh0L2h0bWw6CTxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+IDxG T05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj4JCTxhCQkJCQlocmVmPSJodHRwczovL2lldGYud2Vi ZXguY29tL2lldGYvai5waHA/TVRJRD1tNTRkMTE1N2M2ZGFkYWY5NmNlZDlkMTI3NjU1MmNiNzEi PjxGT05UIFNJWkU9IjMiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJBcmlhbCI+Sm9pbiBXZWJFeCBt ZWV0aW5nPC9GT05UPjwvYT4JCQk8dGFibGU+CQkJCTx0cj4JCQkJCTx0ZD4JCQkJCQk8Rk9OVCBT SVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPk1lZXRpbmcgbnVtYmVyOjwvRk9O VD4JCQkJCTwvdGQ+CQkJCQk8dGQ+CQkJCQkJPEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj42NDkgNzM3IDEyODwvRk9OVD4JCQkJCTwvdGQ+CQkJCTwvdHI+CQkJPC90 YWJsZT4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIi ICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPnN1ZWFpZHNqZWZmPC9GT05UPjwvdGQ+PC90 cj48L3RhYmxlPgkJPC9GT05UPjxGT05UIFNJWkU9IjEiIEZBQ0U9IkFSSUFMIj4mbmJzcDs8QlI+ Jm5ic3A7PEJSPjwvRk9OVD48Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+PEZPTlQgU0laRT0i MyIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5Kb2luIGJ5IHBob25lPC9GT05UPiZuYnNw OyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48c3Ryb25n PjEtODc3LTY2OC00NDkzPC9zdHJvbmc+Jm5ic3A7Q2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChV Uy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYi IEZBQ0U9ImFyaWFsIj48c3Ryb25nPjEtNjUwLTQ3OS0zMjA4PC9zdHJvbmc+Jm5ic3A7Q2FsbC1p biB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTwvRk9OVD4mbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIi IENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+QWNjZXNzIGNvZGU6IDY0OSA3MzcgMTI4PC9G T05UPiZuYnNwOyA8QlI+PGEgaHJlZj0iaHR0cDovL3d3dy53ZWJleC5jb20vcGRmL3RvbGxmcmVl X3Jlc3RyaWN0aW9ucy5wZGYiPjxGT05UIFNJWkU9IjEiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJh cmlhbCI+VG9sbC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zPC9GT05UPjwvYT4gJm5ic3A7IDxC Uj48L0ZPTlQ+PEJSPjxCUj4JJm5ic3A7PEJSPgk8Rk9OVCBTSVpFPSIxIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPgkJCQlDYW4ndCBqb2luIHRoZSBtZWV0aW5nPzwvRk9OVD4JPGEgaHJl Zj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj4JPEZPTlQgU0laRT0iMSIgQ09MT1I9 IiMwMEFGRjkiIEZBQ0U9IkFyaWFsIj5Db250YWN0IHN1cHBvcnQuPC9GT05UPjwvYT4JJm5ic3A7 PEJSPiZuYnNwOzxCUj48Rk9OVCBDT0xPUj0iI0EwQTBBMCIgc2l6ZT0iMSIgRkFDRT0iYXJpYWwi PklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFs bG93cyBhdWRpbyBhbmQgb3RoZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24g dG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0 ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRv IHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVk LCBkaXNjdXNzIHlvdXIgY29uY2VybnMgd2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUg c2Vzc2lvbi48L0ZPTlQ+PC9GT05UPgpTVU1NQVJZOkkyUlMgaW50ZXJpbSBNZWV0aW5nClBSSU9S SVRZOjUKQ0xBU1M6UFVCTElDCkJFR0lOOlZBTEFSTQpUUklHR0VSOi1QVDVNCkFDVElPTjpESVNQ TEFZCkRFU0NSSVBUSU9OOlJlbWluZGVyCkVORDpWQUxBUk0KRU5EOlZFVkVOVApFTkQ6VkNBTEVO REFSCg== ------=_Part_34513_1002631319.1422574509205-- From nobody Mon Feb 2 08:22: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 1A3CA1A1B18 for ; Thu, 29 Jan 2015 15:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.91 X-Spam-Level: X-Spam-Status: No, score=-8.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bgs4L18kGIp for ; Thu, 29 Jan 2015 15:37:16 -0800 (PST) Received: from sjmda11.webex.com (sjmda11.webex.com [64.68.124.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDB31A1AB8 for ; Thu, 29 Jan 2015 15:37:16 -0800 (PST) Received: from jva2tc117.webex.com (sjc02-wxp00-lbace03-core-vl120-np10b-6.webex.com [64.68.121.241]) by sjmda11.webex.com (Postfix) with ESMTP id 68B47C066A for ; Thu, 29 Jan 2015 23:37:16 +0000 (GMT) Received: from jva2tc117.webex.com (localhost [127.0.0.1]) by jva2tc117.webex.com (Postfix) with ESMTP id 176339FB3D for ; Thu, 29 Jan 2015 23:37:16 +0000 (GMT) Date: Thu, 29 Jan 2015 23:37:16 +0000 (GMT) From: I2RS Working Group To: i2rs@ietf.org Message-ID: <220928411.34533.1422574636077.JavaMail.nobody@jva2tc117.webex.com> MIME-Version: 1.0 Content-Type: multipart/Mixed; boundary="----=_Part_34531_1420400432.1422574636076" X-Priority: 3 Importance: normal Archived-At: X-Mailman-Approved-At: Mon, 02 Feb 2015 08:22:22 -0800 Subject: [i2rs] WebEx meeting invitation: I2RS Interim 2/19/2015 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: i2rs-chairs@tools.ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jan 2015 23:37:18 -0000 ------=_Part_34531_1420400432.1422574636076 Content-Type: multipart/Alternative; boundary="----=_Part_34532_1241840572.1422574636076" ------=_Part_34532_1241840572.1422574636076 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: base64 CkhlbGxvLAoKSTJSUyBXb3JraW5nIEdyb3VwIGludml0ZXMgeW91IHRvIGpvaW4gdGhpcyBXZWJF eCBtZWV0aW5nLgoKCkkyUlMgSW50ZXJpbSAyLzE5LzIwMTUKVGh1cnNkYXksIEZlYnJ1YXJ5IDE5 LCAyMDE1CjEwOjAwIGFtICB8ICBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUgKE5ldyBZb3JrLCBHTVQt MDU6MDApICB8ICAxIGhyIDMwIG1pbgoKCkpPSU4gV0VCRVggTUVFVElORwpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tZjQ2MmMzMWMwNDI5NDU2MTY2NDM2Y2I4MDYyNWIw MjkKTWVldGluZyBudW1iZXI6IDY0NiAwMTEgMDE5Ck1lZXRpbmcgcGFzc3dvcmQ6IHlhbmdpc2Z1 bm5vdwoKDQpKT0lOIEJZIFBIT05FDQoxLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBu dW1iZXIgKFVTL0NhbmFkYSkgCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVT L0NhbmFkYSkKQWNjZXNzIGNvZGU6IDY0NiAwMTEgMDE5CgpUb2xsLWZyZWUgZGlhbGluZyByZXN0 cmljdGlvbnM6IApodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZyZWVfcmVzdHJpY3Rpb25z LnBkZg0KDQoKQWRkIHRoaXMgbWVldGluZyB0byB5b3VyIGNhbGVuZGFyOgpodHRwczovL2lldGYu d2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMjUwMzdiYjE3MDlkMWNkNDg2MjhkNjBiZDdjOWEz ZmENCg0KCkNhbid0IGpvaW4gdGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOgpodHRw czovL2lldGYud2ViZXguY29tL2lldGYvbWMKCgpJTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90 ZSB0aGF0IHRoaXMgV2ViRXggc2VydmljZSBhbGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0 aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUg ZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBCeSBqb2luaW5nIHRoaXMgc2Vzc2lvbiwg eW91IGF1dG9tYXRpY2FsbHkgY29uc2VudCB0byBzdWNoIHJlY29yZGluZ3MuIElmIHlvdSBkbyBu b3QgY29uc2VudCB0byBiZWluZyByZWNvcmRlZCwgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGgg dGhlIGhvc3Qgb3IgZG8gbm90IGpvaW4gdGhlIHNlc3Npb24uCg== ------=_Part_34532_1241840572.1422574636076 Content-Type: text/html;charset=UTF-8 Content-Transfer-Encoding: base64 PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lk dGgsIGluaXRpYWwtc2NhbGU9MSIgLz48Ym9keT48c3R5bGUgdHlwZT0idGV4dC9jc3MiPgpkaXYs cCx0ZCxzcGFuIHt3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d29yZC1icmVhazogbm9ybWFsO30KCnRh YmxlIHtib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBib3JkZXI6IDA7Ym9yZGVyLXNwYWNpbmc6 IDA7Ym9yZGVyLWNvbG9yOiB3aGl0ZTsgd2lkdGg6MTAwJSFpbXBvcnRhbnQ7d2lkdGg6NTI1cHg7 IG1heC13aWR0aDo1MjVweCFpbXBvcnRhbnQ7IG1pbi13aWR0aDogMjc5cHghaW1wb3J0YW50O30K dHIge2xpbmUtaGVpZ2h0OiAyMHB4O30KCnRkLGEge2ZvbnQtc2l6ZTogMTVweDtmb250LWZhbWls eTogQXJpYWw7Y29sb3I6ICM2NjY2NjY7cGFkZGluZzowO30KPC9zdHlsZT4KCjx0YWJsZSBzdHls ZT0icGFkZGluZzowOyBtYXJnaW46MCIgd2lkdGg9IjEwMCUiIGFsaWduPSJsZWZ0Ij4KICAgPHRy PgogICAgICA8dGQgc3R5bGU9InBhZGRpbmctdG9wOjVweDsiPgogICAgICAgIDx0YWJsZSBzdHls ZT0id2lkdGg6IDUyNXB4O21hcmdpbi1sZWZ0OjVweCIgYWxpZ249ImxlZnQiPgoJCQk8dHI+CgkJ CQk8dGQgdmFsaWduPSJ0b3AiPgoKPHRhYmxlPgogICAgICAgPHRyPgogICAgICAgICAgPHRkIHN0 eWxlPSJmb250LXNpemU6IDE1cHg7Zm9udC1mYW1pbHk6IEFyaWFsO2NvbG9yOiM0RDRENEQiPgog ICAgICAgICAgICAgSGVsbG8sCiAgICAgICAgICA8L3RkPgogICAgICAgPC90cj4KICAgICAgIDx0 cj4KICAgICAgICAgICA8dGQgc3R5bGU9ImZvbnQtc2l6ZTogMTVweDtmb250LWZhbWlseTogQXJp YWw7Y29sb3I6IzRENEQ0RDtwYWRkaW5nLXRvcDoxMHB4OyI+CiAgICAgICAgICAgICAgICBJMlJT IFdvcmtpbmcgR3JvdXAgaW52aXRlcyB5b3UgdG8gam9pbiB0aGlzIFdlYkV4IG1lZXRpbmcuCiAg ICAgICAgICAgICAgICAJICAgICAgICAgICA8L3RkPgogICAgICA8L3RyPgo8L3RhYmxlPgoKCgoK PHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoy MHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJCQkJPHRhYmxlICB3aWR0aD0iMTAwJSI+ CgkJCQkJCQk8dHI+CgkJCQkJCQkJPHRkIHN0eWxlPSJmb250LXNpemU6MTZweDsgY29sb3I6IzRE NEQ0RCI+CgkJCQkJCQkJCTxiPkkyUlMgSW50ZXJpbSAyLzE5LzIwMTU8L2I+CgkJCQkJCQkJPC90 ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCQk8dHIgc3R5bGU9Im1hcmdpbjowcHgiPgoJCQkJCQkJCTx0 ZD5UaHVyc2RheSwgRmVicnVhcnkgMTksIDIwMTUKCQkJCQkJCQk8L3RkPgoJCQkJCQkJPC90cj4K CQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+CgkJCQkJCQkJPHRkPjEwOjAwIGFtJm5ic3A7 Jm5ic3A7fCZuYnNwOyZuYnNwO0Vhc3Rlcm4gU3RhbmRhcmQgVGltZSAoTmV3IFlvcmssIEdNVC0w NTowMCkmbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7MSBociAzMCBtaW4KCQkJCQkJCQk8L3RkPgoJ CQkJCQkJPC90cj4KCQkJCQkJPC90YWJsZT4KCjx0YWJsZT48dHIgc3R5bGU9ImxpbmUtaGVpZ2h0 OiAyMHB4OyI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwvdGFibGU+ CgkJCQkJCTx0YWJsZSBzdHlsZT0id2lkdGg6YXV0bzsgd2lkdGg6YXV0byFpbXBvcnRhbnQiPgoJ CQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iY29sb3I6IzAwQUZGOTtmb250LXNpemU6MTZw eCI+CgkJCQkJCQkJCTxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9N VElEPW1mNDYyYzMxYzA0Mjk0NTYxNjY0MzZjYjgwNjI1YjAyOSIKCQkJCQkJCQkJCXN0eWxlPSJ0 ZXh0LWRlY29yYXRpb246bm9uZTtmb250LXNpemU6MTZweDtjb2xvcjojMDBBRkY5Ij4KCQkJCQkJ CQkJCTxiPkpvaW4gV2ViRXggbWVldGluZzwvYj4KCQkJCQkJCQkJPC9hPgoJCQkJCQkJCTwvdGQ+ CgkJCQkJCQk8L3RyPgoJCQkJCQk8L3RhYmxlPgoJCQkJCQk8dGFibGUgc3R5bGU9IndpZHRoOmF1 dG87IHdpZHRoOmF1dG8haW1wb3J0YW50Ij4KCQkJCQkJCTx0ciBzdHlsZT0ibWFyZ2luOjBweCI+ CgkJCQkJCQkJPHRkIHN0eWxlPSJwYWRkaW5nLXJpZ2h0OiA1cHg7Ij4KCQkJCQkJCQkJTWVldGlu ZyBudW1iZXI6CgkJCQkJCQkJPC90ZD4KCQkJCQkJCQk8dGQ+NjQ2IDAxMSAwMTkKCQkJCQkJCQk8 L3RkPgoJCQkJCQkJPC90cj4KCQkJCQkJCTx0cj4KCQkJCQkJCQk8dGQgc3R5bGU9InBhZGRpbmct cmlnaHQ6IDVweDsiPk1lZXRpbmcgcGFzc3dvcmQ6PC90ZD4KCQkJCQkJCQk8dGQ+eWFuZ2lzZnVu bm93PC90ZD4KCQkJCQkJCTwvdHI+CgkJCQkJCTwvdGFibGU+CgoKCgkKCgk8dGFibGU+PHRyIHN0 eWxlPSJsaW5lLWhlaWdodDoyMHB4Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3Rk PjwvdHI+PC90YWJsZT48dGFibGU+PHRyPjx0ZCBzdHlsZT0iZm9udC1zaXplOjE2cHgiPjxiPkpv aW4gYnkgcGhvbmU8L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxiPjEt ODc3LTY2OC00NDkzPC9iPiZuYnNwO0NhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRh KTwvdGQ+PC90cj48dHIgc3R5bGU9Im1hcmdpbjowcHgiPjx0ZD48Yj4xLTY1MC00NzktMzIwODwv Yj4mbmJzcDtDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC90ZD48L3RyPjx0ciBzdHls ZT0ibWFyZ2luOjBweCI+PHRkPkFjY2VzcyBjb2RlOiZuYnNwOzY0NiAwMTEgMDE5PC90ZD48L3Ry Pjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkPjxhIGhyZWY9Imh0dHA6Ly93d3cud2ViZXguY29t L3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRmIiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5v bmU7Zm9udC1zaXplOjEzcHg7Y29sb3I6IzAwQUZGOTsiPlRvbGwtZnJlZSBjYWxsaW5nIHJlc3Ry aWN0aW9uczwvYT48L3RkPjwvdHI+PC90YWJsZT4KCgkJCQkJPHRhYmxlPjx0ciBzdHlsZT0ibGlu ZS1oZWlnaHQ6MjBweCI+PHRkIHN0eWxlPSJoZWlnaHQ6MjBweCI+Jm5ic3A7PC90ZD48L3RyPjwv dGFibGU+PHRhYmxlPjx0cj48dGQgc3R5bGU9ImZvbnQtc2l6ZToxM3B4Ij48YSBocmVmPSJodHRw czovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tMjUwMzdiYjE3MDlkMWNkNDg2Mjhk NjBiZDdjOWEzZmEiIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5OyBm b250LXNpemU6MTNweCI+QWRkIHRoaXMgbWVldGluZzwvYT4gdG8geW91ciBjYWxlbmRhci48L3Rk PjwvdHI+PC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQg c3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KPHRhYmxlPgogICAg PHRyPgogICAgICAgPHRkIHN0eWxlPSJmb250LXNpemU6IDEzcHg7Zm9udC1mYW1pbHk6IEFyaWFs O2NvbG9yOiAjNjY2NjY2OyI+CiAgICAgICAgQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8KICAgICAJ PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIiBzdHlsZT0idGV4dC1kZWNv cmF0aW9uOm5vbmU7Zm9udC1zaXplOjEzcHg7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6IzAwQUZG OTtmb250LWNvbG9yOiMwMEFGRjk7Ij4KICAgICAgICAJQ29udGFjdCBzdXBwb3J0LjwvYT4KCQk8 L3RkPgogICAgPC90cj4KPC90YWJsZT4KPHRhYmxlPjx0ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDEw cHg7Ij48dGQgc3R5bGU9ImhlaWdodDoxMHB4Ij4mbmJzcDs8L3RkPjwvdHI+PC90YWJsZT4KCQkJ CQkJPHRhYmxlPgoJCQkJCQkJPHRyPgoJCQkJCQkJCTx0ZCBzdHlsZT0iZm9udC1zaXplOjEycHg7 Y29sb3I6ICNBMEEwQTA7Ij4KCQkJCQkJCQkJSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUg dGhhdCB0aGlzIFdlYkV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlv biBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRp c2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3JkZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRo ZSBob3N0IG9yIGRvIG5vdCBqb2luIHRoZSBzZXNzaW9uLjwvdGQ+CgkJCQkJCQk8L3RyPgoJCQkJ CQk8L3RhYmxlPgoJCQkJPC90ZD4KCQkJPC90cj4KCQk8L3RhYmxlPgoJPC90ZD4KICAgPC90cj4K PC90YWJsZT4KCjwvYm9keT4= ------=_Part_34532_1241840572.1422574636076-- ------=_Part_34531_1420400432.1422574636076 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="WebEx_Meeting.ics" QkVHSU46VkNBTEVOREFSClBST0RJRDotLy9NaWNyb3NvZnQgQ29ycG9yYXRpb24vL091dGxvb2sg MTAuMCBNSU1FRElSLy9FTgpWRVJTSU9OOjIuMApNRVRIT0Q6UkVRVUVTVApCRUdJTjpWVElNRVpP TkUKVFpJRDpFYXN0ZXJuIFRpbWUKQkVHSU46U1RBTkRBUkQKRFRTVEFSVDoyMDEzMTEwMVQwMjAw MDAKUlJVTEU6RlJFUT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0xU1U7QllNT05USD0xMQpUWk9G RlNFVEZST006LTA0MDAKVFpPRkZTRVRUTzotMDUwMApUWk5BTUU6U3RhbmRhcmQgVGltZQpFTkQ6 U1RBTkRBUkQKQkVHSU46REFZTElHSFQKRFRTVEFSVDoyMDEzMDMwMVQwMjAwMDAKUlJVTEU6RlJF UT1ZRUFSTFk7SU5URVJWQUw9MTtCWURBWT0yU1U7QllNT05USD0zClRaT0ZGU0VURlJPTTotMDUw MApUWk9GRlNFVFRPOi0wNDAwClRaTkFNRTpEYXlsaWdodCBTYXZpbmdzIFRpbWUKRU5EOkRBWUxJ R0hUCkVORDpWVElNRVpPTkUKQkVHSU46VkVWRU5UCkFUVEVOREVFO0NOPSIiO1JPTEU9UkVRLVBB UlRJQ0lQQU5UO1JTVlA9VFJVRTpNQUlMVE86aTJyc0BpZXRmLm9yZwpPUkdBTklaRVI7Q049Ikky UlMgV29ya2luZyBHcm91cCI6TUFJTFRPOmkycnMtY2hhaXJzQHRvb2xzLmlldGYub3JnCkRUU1RB UlQ7VFpJRD0iRWFzdGVybiBUaW1lIjoyMDE1MDIxOVQxMDAwMDAKRFRFTkQ7VFpJRD0iRWFzdGVy biBUaW1lIjoyMDE1MDIxOVQxMTMwMDAKTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9p ZXRmClRSQU5TUDpPUEFRVUUKU0VRVUVOQ0U6MQpVSUQ6V0VCRVgtTUVFVElORyBDRU5URVItNi4w NDU2NjgwLTMyMTY4MjAxMi1TVT1pZXRmCkRUU1RBTVA6MjAxNTAyMTlUMTUwMDAwWgpERVNDUklQ VElPTjpcblxuXG5KT0lOIFdFQkVYIE1FRVRJTkdcbmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW1mNDYyYzMxYzA0Mjk0NTYxNjY0MzZjYjgwNjI1YjAyOVxuTWVldGluZyBu dW1iZXI6IDY0NiAwMTEgMDE5XG5NZWV0aW5nIHBhc3N3b3JkOiB5YW5naXNmdW5ub3dcblxuXG5K T0lOIEJZIFBIT05FXG4xLTg3Ny02NjgtNDQ5MyBDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIgKFVT L0NhbmFkYSkgXG4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEp XG5BY2Nlc3MgY29kZTogNjQ2IDAxMSAwMTlcblxuVG9sbC1mcmVlIGRpYWxpbmcgcmVzdHJpY3Rp b25zOiBcbmh0dHA6Ly93d3cud2ViZXguY29tL3BkZi90b2xsZnJlZV9yZXN0cmljdGlvbnMucGRm XG5cblxuXG5DYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVyZTpcbmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tY1xuXG5cbklNUE9SVEFOVCBOT1RJQ0U6IFBsZWFz ZSBub3RlIHRoYXQgdGhpcyBXZWJFeCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3RoZXIgaW5m b3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdoaWNoIG1h eSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIEJ5IGpvaW5pbmcgdGhpcyBzZXNz aW9uLCB5b3UgYXV0b21hdGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91 IGRvIG5vdCBjb25zZW50IHRvIGJlaW5nIHJlY29yZGVkLCBkaXNjdXNzIHlvdXIgY29uY2VybnMg d2l0aCB0aGUgaG9zdCBvciBkbyBub3Qgam9pbiB0aGUgc2Vzc2lvbi5cbgpYLUFMVC1ERVNDO0ZN VFRZUEU9dGV4dC9odG1sOgk8Rk9OVCBTSVpFPSIxIiBGQUNFPSJBUklBTCI+Jm5ic3A7PEJSPiA8 Rk9OVCBTSVpFPSI0IiBGQUNFPSJBUklBTCI+CQk8YQkJCQkJaHJlZj0iaHR0cHM6Ly9pZXRmLndl YmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWY0NjJjMzFjMDQyOTQ1NjE2NjQzNmNiODA2MjViMDI5 Ij48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkpvaW4gV2ViRXgg bWVldGluZzwvRk9OVD48L2E+CQkJPHRhYmxlPgkJCQk8dHI+CQkJCQk8dGQ+CQkJCQkJPEZPTlQg U0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5NZWV0aW5nIG51bWJlcjo8L0ZP TlQ+CQkJCQk8L3RkPgkJCQkJPHRkPgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2 IiBGQUNFPSJhcmlhbCI+NjQ2IDAxMSAwMTk8L0ZPTlQ+CQkJCQk8L3RkPgkJCQk8L3RyPgkJCTwv dGFibGU+CQkJPHRhYmxlPjx0cj48dGQ+PEZPTlQgU0laRT0iMiIgQ09MT1I9IiM2NjY2NjYiIEZB Q0U9ImFyaWFsIj5NZWV0aW5nIHBhc3N3b3JkOjwvRk9OVD48L3RkPjx0ZD48Rk9OVCBTSVpFPSIy IiAgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj55YW5naXNmdW5ub3c8L0ZPTlQ+PC90ZD48 L3RyPjwvdGFibGU+CQk8L0ZPTlQ+PEZPTlQgU0laRT0iMSIgRkFDRT0iQVJJQUwiPiZuYnNwOzxC Uj4mbmJzcDs8QlI+PC9GT05UPjxGT05UIFNJWkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpF PSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+Jm5i c3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPjxzdHJv bmc+MS04NzctNjY4LTQ0OTM8L3N0cm9uZz4mbmJzcDtDYWxsLWluIHRvbGwgZnJlZSBudW1iZXIg KFVTL0NhbmFkYSk8L0ZPTlQ+Jm5ic3A7IDxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2 NiIgRkFDRT0iYXJpYWwiPjxzdHJvbmc+MS02NTAtNDc5LTMyMDg8L3N0cm9uZz4mbmJzcDtDYWxs LWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPC9GT05UPiZuYnNwOyA8QlI+PEZPTlQgU0laRT0i MiIgQ09MT1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj5BY2Nlc3MgY29kZTogNjQ2IDAxMSAwMTk8 L0ZPTlQ+Jm5ic3A7IDxCUj48YSBocmVmPSJodHRwOi8vd3d3LndlYmV4LmNvbS9wZGYvdG9sbGZy ZWVfcmVzdHJpY3Rpb25zLnBkZiI+PEZPTlQgU0laRT0iMSIgQ09MT1I9IiMwMEFGRjkiIEZBQ0U9 ImFyaWFsIj5Ub2xsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnM8L0ZPTlQ+PC9hPiAmbmJzcDsg PEJSPjwvRk9OVD48QlI+PEJSPgkmbmJzcDs8QlI+CTxGT05UIFNJWkU9IjEiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+CQkJCUNhbid0IGpvaW4gdGhlIG1lZXRpbmc/PC9GT05UPgk8YSBo cmVmPSJodHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWMiPgk8Rk9OVCBTSVpFPSIxIiBDT0xP Uj0iIzAwQUZGOSIgRkFDRT0iQXJpYWwiPkNvbnRhY3Qgc3VwcG9ydC48L0ZPTlQ+PC9hPgkmbmJz cDs8QlI+Jm5ic3A7PEJSPjxGT05UIENPTE9SPSIjQTBBMEEwIiBzaXplPSIxIiBGQUNFPSJhcmlh bCI+SU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYkV4IHNlcnZpY2Ug YWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lv biB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1h dHRlci4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlvdSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQg dG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90IGNvbnNlbnQgdG8gYmVpbmcgcmVjb3Jk ZWQsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBob3N0IG9yIGRvIG5vdCBqb2luIHRo ZSBzZXNzaW9uLjwvRk9OVD48L0ZPTlQ+ClNVTU1BUlk6STJSUyBJbnRlcmltIDIvMTkvMjAxNQpQ UklPUklUWTo1CkNMQVNTOlBVQkxJQwpCRUdJTjpWQUxBUk0KVFJJR0dFUjotUFQ1TQpBQ1RJT046 RElTUExBWQpERVNDUklQVElPTjpSZW1pbmRlcgpFTkQ6VkFMQVJNCkVORDpWRVZFTlQKRU5EOlZD QUxFTkRBUgo= ------=_Part_34531_1420400432.1422574636076-- From nobody Mon Feb 2 15:53:31 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 E09E01A1B95 for ; Mon, 2 Feb 2015 15:53:28 -0800 (PST) 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 2wnIcxHLPmT3 for ; Mon, 2 Feb 2015 15:53:26 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9790E1A1B4B for ; Mon, 2 Feb 2015 15:53:26 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Mon, 2 Feb 2015 18:53:16 -0500 Message-ID: <011101d03f43$6b2b6870$41823950$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01D03F19.8257D170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdA/PnHrl9gFlR/FTJCQzd9Zf+vhmA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 02 Feb 2015 23:53:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0112_01D03F19.8257D170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG Adoption call for: draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can access the draft at: http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt The current I2RS charter states: "The I2RS working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the specific use cases, and that will lead to an understanding of the abstract informational models and requirements for encodings and protocols for the I2RS interfaces." This draft is part of setting the requirements for the I2RS protocol. As Andy has noted in early email, there may be nothing specific to I2RS in draft-voit-i2rs-pub-sub-requirements-00.txt. It may be something that should be just a part of the netconf/restconf functionality. As part of the adoption of this draft, the I2RS chairs would like to hear your opinion of Andy's statement. Andy also suggests that draft-netmod-clemm-datastore-push-00 should also be part of the I2RS requirements. http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html [chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. If the WG approves adoption of draft-voit-i2rs-pub-sub-requirements-00.txt and the WG feels these drafts should be netmod WG drafts with I2RS holding a requirement drafts, the I2RS chairs will do the right thing to make it happen. If enough people comment that draft-netmod-clemm-datastore-push-00 should be part of the I2RS requirements, we will do a WG adoption of call for this requirement. Sue Hares ------=_NextPart_000_0112_01D03F19.8257D170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG Adoption call for:  = draft-voit-i2rs-pub-sub-requirements-00  (2/2 to 2/16/2015).  = You can access the draft at:

 

http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt=

 

The current I2RS charter states:

 

“Th= e I2RS working group works to develop a high-level architecture = that describes the basic = building-blocks necessary to enable the specific use  cases, and that will lead to = an understanding of the abstract informational models and requirements = for encodings and protocols for the I2RS = interfaces.”

<= o:p> 

T= his draft is part of setting the requirements for the I2RS = protocol. 

<= o:p> 

A= s Andy has noted in early email, there may be nothing specific to I2RS = in draft-voit-i2rs-pub-sub-requirements-00.txt.  It may be = something that should be just a part of the netconf/restconf = functionality.  As part of the adoption of this draft, the I2RS = chairs would like to hear your opinion of Andy’s statement. =  Andy also suggests that draft-netmod-clemm-datastore-push-00 = should also be part of the I2RS requirements.

<= o:p> 

<= a = href=3D"http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html">= http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html

<= o:p> 

[= chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. =

<= o:p> 

I= f the WG approves adoption of = draft-voit-i2rs-pub-sub-requirements-00.txt and the WG feels these = drafts should be netmod WG drafts with I2RS holding a requirement = drafts, the I2RS chairs will do the right thing to make it happen.  =  If enough people comment that draft-netmod-clemm-datastore-push-00 = should be part of the I2RS requirements, we will do a WG adoption of = call for this requirement.  

<= o:p> 

S= ue Hares

<= o:p> 

 

------=_NextPart_000_0112_01D03F19.8257D170-- From nobody Mon Feb 2 16:09: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 26A501A87C6; Mon, 2 Feb 2015 16:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZsWJ9llt9y2p; Mon, 2 Feb 2015 16:08:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59911A87C7; Mon, 2 Feb 2015 16:08:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSA19851; Tue, 03 Feb 2015 00:08:43 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Feb 2015 00:08:42 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 16:08:40 -0800 From: Linda Dunbar To: "i2nsf@ietf.org" Thread-Topic: revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQ== Date: Tue, 3 Feb 2015 00:08:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.83] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EBBAABdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: [i2rs] revised charter for I2NSF 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, 03 Feb 2015 00:08:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EBBAABdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on the recent discussion on the I2NSF list, here is the revised chart= er for I2NSF. Copied to I2RS group to get wider review because I2NSF is rel= ated to I2RS in such a way that I2RS provides the interface to Router wher= eas I2NSF provides the interfaces to security functions. In a nutshell, The Interface to Network Security Functions (I2NSF) is to di= scuss interfaces for clients or application gateways to communicate their s= pecific security policies (request/monitor/report) with security controller= and security functions. I2NSF will specify the information model, along w= ith adequate data models, and protocols required for the Operation, Adminis= tration, Maintenance and Provisioning (OAM) for the following security func= tions: * Firewall * DDOS/Anti-DOS * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) * Access control/Authorization/Authentication There are two distinct interfaces for I2NSF: - Capability (or Functional) Layer interface between Security Cont= roller, which could be embedded in a network controller, and Security devic= es (virtual & physical), which focuses more on the functional aspects of th= e functions listed above. - Service Layer Interface between Clients (or App Gateway) and the= Security Controller, which is for clients or App Gateway to express/monit= or the needed security policies (e.g. develop a security policy language ba= sed on NIST endorsed Role Based Access Control.) I2NSF WG Deliverables for the Functional/Capability Layer Interface include= : - Develop a comprehensive set of informational Models for the foll= owing functions with regard to different aspects of OAM (Operations/Adminis= tration/Maintenance). For example: extending the ACL data model to be more = comprehensive, e.g. including multiple actions and policies. o Firewall o DDOS/Anti-DOS o Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) - Develop the corresponding Data Models, e.g. YANG model. - Specify the secure mechanisms to carry the content identified by= the informational/data models. E.g. TLS to carry the information. I2NSF WG Deliverables for the Service Layer Interface include: * Develop policy description (or language) for clients or App Gateway= to express/monitor the needed security policies (e.g. develop a security p= olicy language based on NIST endorsed Role Based Access Control.) - E.g. Develop comprehensive set of "TARGETs" for the Security Intent.= Security Target in Data Centers network, in Access Network, in Wide Area= network, etc - Develop descriptors for "Users", "Roles", "Permissions" * Develop the corresponding information or Data Models, e.g. YANG mod= el. * Compare with existing IETF protocols for "Roles", "Users", "Permiss= ions", etc. In addition, the I2NSF working group will * Document a high-level I2NSF framework that describes Services and = Capability layers interfaces and defines a reference model along with funct= ional components at each layer. - Terminology draft may be included in the framework or becomes a stan= dalone draft. * Document small and well-scoped use cases to constrain the scope of = the work and achieve sufficient focus for the working group to deliver succ= essful outcomes. And * Analyze candidate protocols that may carry the information to be e= xchanged through the various interfaces. - E.g. Compare with existing IETF protocols for "OBJECTs, ACTIONs, FIL= TERING, etc" (e.g. PCP, Radius, etc) . Looking for comments and suggestions. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EBBAABdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on the recent discussion on the I2NSF list, he= re is the revised charter for I2NSF. Copied to I2RS group to get wider revi= ew because I2NSF is related to I2RS in such a way that  I2RS provides = the interface to Router whereas I2NSF provides the interfaces to security functions.

 <= /p>

 

In a nutshell, The Interface to Network Security Fun= ctions (I2NSF) is to discuss interfaces for clients or application gateways= to communicate their specific security policies (request/monitor/report) w= ith security controller and security functions.  I2NSF will specify the information model, along with adeq= uate data models, and protocols required for the Operation, Administration,= Maintenance and Provisioning (OAM) for the following security functions:

·       Firewall

·       DDOS/Anti-DOS

·       Intrusion Detect= ion System/ Intrusion Prevention System (IDS/IPS)

·       Access control/A= uthorization/Authentication

 

There are two distinct interfaces for I2NSF:

-=    &n= bsp;      Capability = (or Functional) Layer interface between Security Controller, which could be= embedded in a network controller, and Security devices (virtual & phys= ical), which focuses more on the functional aspects of the functions listed above.

 <= /o:p>

-=    &n= bsp;      Service Lay= er Interface between Clients (or App Gateway) and the Security Controller, =  which is for clients or App Gateway to express/monitor the needed sec= urity policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.)

 

I2NSF WG Deliverables for the Functional/Capability = Layer Interface include:

-=    &n= bsp;      Develop a c= omprehensive set of informational Models for the following functions with r= egard to different aspects of OAM (Operations/Administration/Maintenance). = For example: extending the ACL data model to be more comprehensive, e.g.  including multiple actions and = policies.

o   Firewall

o   DDOS/Anti-D= OS

o   Intrusion D= etection System/ Intrusion Prevention System (IDS/IPS)

 <= /o:p>

-=    &n= bsp;      Develop the= corresponding Data Models, e.g. YANG model.

 

-=    &n= bsp;      Specify the= secure mechanisms to carry the content identified by the informational/dat= a models. E.g. TLS to carry the information.

 

I2NSF WG Deliverables for the Service Layer Interfac= e include:

•       Develop policy description (or language) for= clients or App Gateway to express/monitor the needed security policies (e.= g. develop a security policy language based on NIST endorsed Role Based Acc= ess Control.)

–      E.g. Develop comprehensive set of “TAR= GETs” for the Security Intent.   Security Target in Data Ce= nters network, in Access Network, in Wide Area network, etc

–      Develop descriptors for “Users”,= “Roles”, “Permissions”

 

•       Develop the corresponding information or Dat= a Models, e.g. YANG model.

•       Compare with existing IETF protocols for = 220;Roles”, “Users”, “Permissions”, etc.

 

 

In addition, the I2NSF working group will=

•        Document a high-level I2NSF framework = that describes Services and Capability layers interfaces and defines a refe= rence model along with functional components at each layer.

–      Terminology draft may be included in the fra= mework or becomes a standalone draft.

•       Document small and well-scoped use cases to = constrain the scope of the work and achieve sufficient focus for the workin= g group to deliver successful outcomes. And

&n= bsp;

•        Analyze candidate protocols that may c= arry the information to be exchanged through the various interfaces.

–    =   E.g. Compar= e with existing IETF protocols for “OBJECTs, ACTIONs, FILTERING, etc&= #8221; (e.g. PCP, Radius, etc) .

 

Looking for comments and suggestions.

 

Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645EBBAABdfweml701chm_-- From nobody Mon Feb 2 16:30: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 741B81A871C for ; Mon, 2 Feb 2015 16:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_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 7LYKp_L5JJzE for ; Mon, 2 Feb 2015 16:30:17 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0561A1B44 for ; Mon, 2 Feb 2015 16:30:16 -0800 (PST) Received: from [192.168.1.136] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id AEE072DA8E72; Mon, 2 Feb 2015 19:30:15 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F5A6A282-728C-490A-819C-F337EB7B8D4A" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: "Thomas D. Nadeau" In-Reply-To: <011101d03f43$6b2b6870$41823950$@ndzh.com> Date: Mon, 2 Feb 2015 19:30:15 -0500 Message-Id: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1993) Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 00:30:18 -0000 --Apple-Mail=_F5A6A282-728C-490A-819C-F337EB7B8D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Support. > On Feb 2, 2015:6:53 PM, at 6:53 PM, Susan Hares = wrote: >=20 > This begins a 2 week WG Adoption call for: = draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can = access the draft at:=20 > =20 > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt = > =20 > The current I2RS charter states:=20 > =20 > =E2=80=9CThe I2RS working group works to develop a high-level = architecture that describes the basic building-blocks necessary to = enable the specific use cases, and that will lead to an understanding = of the abstract informational models and requirements for encodings and = protocols for the I2RS interfaces.=E2=80=9D > =20 > This draft is part of setting the requirements for the I2RS protocol. =20= > =20 > As Andy has noted in early email, there may be nothing specific to = I2RS in draft-voit-i2rs-pub-sub-requirements-00.txt. It may be = something that should be just a part of the netconf/restconf = functionality. As part of the adoption of this draft, the I2RS chairs = would like to hear your opinion of Andy=E2=80=99s statement. Andy also = suggests that draft-netmod-clemm-datastore-push-00 should also be part = of the I2RS requirements.=20 > =20 > http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html = > =20 > [chair hat-off] IMHO, I think Andy is correct. [chair-hat on ].=20 > =20 > If the WG approves adoption of = draft-voit-i2rs-pub-sub-requirements-00.txt and the WG feels these = drafts should be netmod WG drafts with I2RS holding a requirement = drafts, the I2RS chairs will do the right thing to make it happen. If = enough people comment that draft-netmod-clemm-datastore-push-00 should = be part of the I2RS requirements, we will do a WG adoption of call for = this requirement. =20 > =20 > Sue Hares > =20 > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs = --Apple-Mail=_F5A6A282-728C-490A-819C-F337EB7B8D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Support.

On Feb 2, 2015:6:53 PM, at 6:53 = PM, Susan Hares <shares@ndzh.com> wrote:

This = begins a 2 week WG Adoption call for:  = draft-voit-i2rs-pub-sub-requirements-00  (2/2 to 2/16/2015).  = You can access the draft at: 
 
http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.= txt
 
The current I2RS charter states: 
 
=E2=80=9CT<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif;" = class=3D"">he I2RS working group works to develop a high-level = architecture that describes the basic = building-blocks necessary to enable the specific use  cases, and that will lead = to an understanding of the abstract informational models and = requirements for encodings and protocols for the I2RS interfaces.=E2=80=9D=
 
This draft is part of setting the requirements = for the I2RS protocol.  
 
As = Andy has noted in early email, there may be nothing specific to I2RS in = draft-voit-i2rs-pub-sub-requirements-00.txt.  It may be something = that should be just a part of the netconf/restconf functionality.  = As part of the adoption of this draft, the I2RS chairs would like to = hear your opinion of Andy=E2=80=99s statement.  Andy also suggests = that draft-netmod-clemm-datastore-push-00 should also be part of the = I2RS requirements. 
 
http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html=
 
[chair hat-off] IMHO, I = think Andy is correct. [chair-hat on ]. 
 
If = the WG approves adoption of draft-voit-i2rs-pub-sub-requirements-00.txt = and the WG feels these drafts should be netmod WG drafts with I2RS = holding a requirement drafts, the I2RS chairs will do the right thing to = make it happen.   If enough people comment that = draft-netmod-clemm-datastore-push-00 should be part of the I2RS = requirements, we will do a WG adoption of call for this requirement. =  
 
Sue Hares
 
 
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

= --Apple-Mail=_F5A6A282-728C-490A-819C-F337EB7B8D4A-- From nobody Mon Feb 2 16:36: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 1F7211A87C7 for ; Mon, 2 Feb 2015 16:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liXVsNYNAhIM for ; Mon, 2 Feb 2015 16:36:47 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6531A86EE for ; Mon, 2 Feb 2015 16:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14618; q=dns/txt; s=iport; t=1422923807; x=1424133407; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Sl5Fl3ucfvZLpXk20nlcHkPjEGVBwRXFJpTUEoAWKPw=; b=O6ejB41o17ZU+6a7STLJTw1eHEb+lGBFPCvY2ix65SFpCTVUi1XcdpzQ vnY9a1hSb/GlV4SD5XidK9q2FaME5whYPjmtR7+wcASIWM6zkW4biSF/W ZvgNtRECmIVlzHr014i97suGIh3yNWx7iwYxsicQpSXFBIDMnhTuu2Qqc k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAHAX0FStJA2N/2dsb2JhbABagkNDUlkExGIBCYVxAoEfQwEBAQEBfYQMAQEBBAEBARpRCxACAQgRAQIBAigHJwsUAwYIAQEEAQ0FCYgkDdYcAQEBAQEBAQEBAQEBAQEBAQEBAQEYjxYQAgE+DQQHhCkFjSaBY4klgReOCIM9IoIygTxvAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,509,1418083200"; d="scan'208,217";a="392825249" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-7.cisco.com with ESMTP; 03 Feb 2015 00:36:46 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t130akoc030015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 00:36:46 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.17]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 18:36:45 -0600 From: "Jan Medved (jmedved)" To: "Thomas D. Nadeau" , Susan Hares Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AdA/PnHrl9gFlR/FTJCQzd9Zf+vhmAAPGzeA//97r4A= Date: Tue, 3 Feb 2015 00:36:44 +0000 Message-ID: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.57.19] Content-Type: multipart/alternative; boundary="_000_D0F55815A9385jmedvedciscocom_" MIME-Version: 1.0 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 00:36:49 -0000 --_000_D0F55815A9385jmedvedciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable support From: "Thomas D. Nadeau" > Date: Monday, February 2, 2015 at 4:30 PM To: Susan Hares > Cc: Jeffrey Haas >, "i2rs@ietf.org" > Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit= -i2rs-pub-sub-requirements-00 Support. On Feb 2, 2015:6:53 PM, at 6:53 PM, Susan Hares > wrote: This begins a 2 week WG Adoption call for: draft-voit-i2rs-pub-sub-require= ments-00 (2/2 to 2/16/2015). You can access the draft at: http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt The current I2RS charter states: =93The I2RS working group works to develop a high-level architecture that d= escribes the basic building-blocks necessary to enable the specific use ca= ses, and that will lead to an understanding of the abstract informational m= odels and requirements for encodings and protocols for the I2RS interfaces.= =94 This draft is part of setting the requirements for the I2RS protocol. As Andy has noted in early email, there may be nothing specific to I2RS in = draft-voit-i2rs-pub-sub-requirements-00.txt. It may be something that shou= ld be just a part of the netconf/restconf functionality. As part of the ad= option of this draft, the I2RS chairs would like to hear your opinion of An= dy=92s statement. Andy also suggests that draft-netmod-clemm-datastore-pus= h-00 should also be part of the I2RS requirements. http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html [chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. If the WG approves adoption of draft-voit-i2rs-pub-sub-requirements-00.txt = and the WG feels these drafts should be netmod WG drafts with I2RS holding = a requirement drafts, the I2RS chairs will do the right thing to make it ha= ppen. If enough people comment that draft-netmod-clemm-datastore-push-00 = should be part of the I2RS requirements, we will do a WG adoption of call f= or this requirement. Sue Hares _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_D0F55815A9385jmedvedciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <71E314AE9B2F1D48ACC6383C82B4A3C7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
support

From: "Thomas D. Nadeau" = <tnadeau@lucidvision.com&= gt;
Date: Monday, February 2, 2015 at 4= :30 PM
To: Susan Hares <shares@ndzh.com>
Cc: Jeffrey Haas <jhaas@pfrc.org>, "i2rs@ietf.org" <i2rs@i= etf.org>
Subject: Re: [i2rs] 2 week WG Adopt= ion call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00

Support.

On Feb 2, 2015:6:53 PM, at 6:53 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG Adoption call for:  draft-voit-i2rs-pub-sub-re= quirements-00  (2/2 to 2/16/2015).  You can access the draft at:<= span class=3D"Apple-converted-space"> 
 
http://= www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt
 
The current I2RS charter states: = ;
 
=93The I2RS working group works to develop a high-level architecture that=  describes the basic buil= ding-blocks necessary to enable the specific use  = cases, and that will lead to an understanding of the abstract informational model= s and requirements for encodings and protocols for the I2RS interfaces.=94<= o:p class=3D"">
 
This draft is part of setting the requirements for the I2RS protocol. = ; <= /span>
 
As Andy has noted in early email, there may be nothing specific to I2RS in= draft-voit-i2rs-pub-sub-requirements-00.txt.  It may be something tha= t should be just a part of the netconf/restconf functionality.  As part of the adoption of this draft, the I2RS chair= s would like to hear your opinion of Andy=92s statement.  Andy also su= ggests that draft-netmod-clemm-datastore-push-00 should also be part of the= I2RS requirements. 
 
http://ww= w.ietf.org/mail-archive/web/i2rs/current/msg02252.html
 
[chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. 
 
If the WG approves adoption of draft-voit-i2rs-pub-sub-requirements-00.txt= and the WG feels these drafts should be netmod WG drafts with I2RS holding= a requirement drafts, the I2RS chairs will do the right thing to make it happen.   If enough people co= mment that draft-netmod-clemm-datastore-push-00 should be part of the I2RS = requirements, we will do a WG adoption of call for this requirement.  =
 
Sue Hares
 
 
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/m= ailman/listinfo/i2rs

 --_000_D0F55815A9385jmedvedciscocom_-- From nobody Tue Feb 3 00:03:38 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 C8B451A86F5 for ; Tue, 3 Feb 2015 00:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 n3IU2wbphvkx for ; Tue, 3 Feb 2015 00:03:32 -0800 (PST) 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 6F8E71A6FF6 for ; Tue, 3 Feb 2015 00:03:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4C8C15FE; Tue, 3 Feb 2015 09:03:30 +0100 (CET) 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 WHOjj4xbxygH; Tue, 3 Feb 2015 09:03:23 +0100 (CET) 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, 3 Feb 2015 09:03:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F00EA20036; Tue, 3 Feb 2015 09:03:29 +0100 (CET) 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 vBSd4fzrFnle; Tue, 3 Feb 2015 09:03:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1C8B20035; Tue, 3 Feb 2015 09:03:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 84193315B39A; Tue, 3 Feb 2015 09:03:27 +0100 (CET) Date: Tue, 3 Feb 2015 09:03:27 +0100 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150203080327.GA68276@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Jeffrey Haas' References: <011101d03f43$6b2b6870$41823950$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011101d03f43$6b2b6870$41823950$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 08:03:36 -0000 On Mon, Feb 02, 2015 at 06:53:16PM -0500, Susan Hares wrote: > This begins a 2 week WG Adoption call for: > draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can access > the draft at: > > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt > I like to point out that some statements in the draft are either unclear or wrong. o limited support for pushed notification of changes. (Currently notifications are for configuration data only. And even then, subscription mechanisms for such notifications are undefined.) RFC 5277 defines a mechanism. RFC 6470 defines notifications that allow to track changes in a configuration datastore. So why is the subscription mechanisms undefined? But in more general terms, I am wondering what the scope of this work is. Is the goal to provide a mechanism similar to what we have already for 'config true' datastores for 'config false' datastores or is the goal to replace the existing mechanism with a new mechanism that will cover both 'config true' and 'config false' datastores? /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 Feb 3 04:31:57 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 83D5B1A8A0B; Tue, 3 Feb 2015 04:31:54 -0800 (PST) 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 Ptd71GppveVz; Tue, 3 Feb 2015 04:31:51 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B5EA21A8A1C; Tue, 3 Feb 2015 04:31:50 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> Date: Tue, 3 Feb 2015 07:31:36 -0500 Message-ID: <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_039A_01D03F83.71D0F650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHe8BNDJn34omqge3ix4XQ/UM6E/ZzBb39A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: nfvrg@irtf.org, i2rs@ietf.org Subject: Re: [i2rs] revised charter for I2NSF 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, 03 Feb 2015 12:31:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_039A_01D03F83.71D0F650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Linda: Thank you for your encouragement to send comments on the gap-analysis and the use cases to the list. A few suggestions for the sequences of your charter events: I think that getting use cases, framework and protocol requirements is critical. Since the security area has a strong terminology draft, maybe you can just create an online update to that one. IMHO, I think it is important to have a goal of using existing protocols or extending these protocols. Adjusting your charter to indicate this at every step would prevent duplication of IETF work and increase the speed of development of your protocol. The capability (or functional) layer between controller and network devices may be able to leverage existing protocols in SACM, AAA, rtgwg, netmod, netconf/restconf, or other protocols. Or it may be able to be a combination of these protocols. Instead of in addition, the WG should consider this at the beginning. Making a decision on what type of service-based interface is important during the framework. If you wish an intent-based application driven interface, this may be different than the intent based or comprehensive API. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, February 02, 2015 7:09 PM To: i2nsf@ietf.org Cc: nfvrg@irtf.org; i2rs@ietf.org Subject: [i2rs] revised charter for I2NSF Based on the recent discussion on the I2NSF list, here is the revised charter for I2NSF. Copied to I2RS group to get wider review because I2NSF is related to I2RS in such a way that I2RS provides the interface to Router whereas I2NSF provides the interfaces to security functions. In a nutshell, The Interface to Network Security Functions (I2NSF) is to discuss interfaces for clients or application gateways to communicate their specific security policies (request/monitor/report) with security controller and security functions. I2NSF will specify the information model, along with adequate data models, and protocols required for the Operation, Administration, Maintenance and Provisioning (OAM) for the following security functions: . Firewall . DDOS/Anti-DOS . Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) . Access control/Authorization/Authentication There are two distinct interfaces for I2NSF: - Capability (or Functional) Layer interface between Security Controller, which could be embedded in a network controller, and Security devices (virtual & physical), which focuses more on the functional aspects of the functions listed above. - Service Layer Interface between Clients (or App Gateway) and the Security Controller, which is for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.) I2NSF WG Deliverables for the Functional/Capability Layer Interface include: - Develop a comprehensive set of informational Models for the following functions with regard to different aspects of OAM (Operations/Administration/Maintenance). For example: extending the ACL data model to be more comprehensive, e.g. including multiple actions and policies. o Firewall o DDOS/Anti-DOS o Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) - Develop the corresponding Data Models, e.g. YANG model. - Specify the secure mechanisms to carry the content identified by the informational/data models. E.g. TLS to carry the information. I2NSF WG Deliverables for the Service Layer Interface include: . Develop policy description (or language) for clients or App Gateway to express/monitor the needed security policies (e.g. develop a security policy language based on NIST endorsed Role Based Access Control.) - E.g. Develop comprehensive set of "TARGETs" for the Security Intent. Security Target in Data Centers network, in Access Network, in Wide Area network, etc - Develop descriptors for "Users", "Roles", "Permissions" . Develop the corresponding information or Data Models, e.g. YANG model. . Compare with existing IETF protocols for "Roles", "Users", "Permissions", etc. In addition, the I2NSF working group will . Document a high-level I2NSF framework that describes Services and Capability layers interfaces and defines a reference model along with functional components at each layer. - Terminology draft may be included in the framework or becomes a standalone draft. . Document small and well-scoped use cases to constrain the scope of the work and achieve sufficient focus for the working group to deliver successful outcomes. And . Analyze candidate protocols that may carry the information to be exchanged through the various interfaces. - E.g. Compare with existing IETF protocols for "OBJECTs, ACTIONs, FILTERING, etc" (e.g. PCP, Radius, etc) . Looking for comments and suggestions. Linda Dunbar ------=_NextPart_000_039A_01D03F83.71D0F650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda:

 

Thank you for your = encouragement to send comments on the gap-analysis and the use cases to = the list.   A few suggestions for the sequences of your = charter events:

 

I think that getting use = cases, framework and protocol requirements is critical.  Since the = security area has a strong terminology draft, maybe you can just create = an online update to that one.  

 

IMHO, I think it is = important to have a goal of using existing protocols or extending these = protocols.   Adjusting your charter to indicate this at every = step would prevent duplication of IETF work and increase the speed of = development of your protocol.

 

The capability (or = functional) layer between controller and network devices may be able to = leverage existing protocols in SACM, AAA, rtgwg, netmod, = netconf/restconf, or other protocols.  Or it may be able to be a = combination of these protocols.  Instead of in addition, the WG = should consider this at the beginning.   =

 

Making a decision on = what type of service-based interface is important during the = framework.  If you wish an intent-based application driven = interface, this may be different than the intent based or comprehensive = API.

 

Sue =

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Monday, February 02, 2015 7:09 PM
To: = i2nsf@ietf.org
Cc: nfvrg@irtf.org; = i2rs@ietf.org
Subject: [i2rs] revised charter for = I2NSF

 

Based on the = recent discussion on the I2NSF list, here is the revised charter for = I2NSF. Copied to I2RS group to get wider review because I2NSF is related = to I2RS in such a way that  I2RS provides the interface to Router = whereas I2NSF provides the interfaces to security = functions.

 

 

In a = nutshell, The Interface to Network Security Functions (I2NSF) is to = discuss interfaces for clients or application gateways to communicate = their specific security policies (request/monitor/report) with security = controller and security functions.  I2NSF will specify the = information model, along with adequate data models, and protocols = required for the Operation, Administration, Maintenance and Provisioning = (OAM) for the following security functions:

·         = Firewall

·         = DDOS/Anti-D= OS

·         = Intrusion = Detection System/ Intrusion Prevention System = (IDS/IPS)

·         = Access = control/Authorization/Authentication

 

There are = two distinct interfaces for I2NSF:

-          = Capability (or Functional) Layer interface = between Security Controller, which could be embedded in a network = controller, and Security devices (virtual & physical), which focuses = more on the functional aspects of the functions listed above. =

 

-          = Service = Layer Interface between Clients (or App Gateway) and the Security = Controller,  which is for clients or App Gateway to express/monitor = the needed security policies (e.g. develop a security policy language = based on NIST endorsed Role Based Access = Control.)

 

I2NSF WG = Deliverables for the Functional/Capability Layer Interface = include:

-          = Develop = a comprehensive set of informational Models for the following functions = with regard to different aspects of OAM = (Operations/Administration/Maintenance). For example: extending the ACL = data model to be more comprehensive, e.g.  including multiple = actions and policies.

o   Firewall

o   DDOS/Anti-DOS

o   Intrusion Detection System/ Intrusion = Prevention System (IDS/IPS)

 

-          = Develop = the corresponding Data Models, e.g. YANG model.

 

-          = Specify = the secure mechanisms to carry the content identified by the = informational/data models. E.g. TLS to carry the information. =

 

I2NSF WG Deliverables for the Service Layer Interface = include:

•       = Develop policy description (or language) = for clients or App Gateway to express/monitor the needed security = policies (e.g. develop a security policy language based on NIST endorsed = Role Based Access Control.)

–      = E.g. Develop comprehensive set of = “TARGETs” for the Security Intent.   Security = Target in Data Centers network, in Access Network, in Wide Area network, = etc

–      = Develop descriptors for = “Users”, “Roles”, = “Permissions”

 

•       = Develop the corresponding information or = Data Models, e.g. YANG model.

•       = Compare with existing IETF protocols for = “Roles”, “Users”, “Permissions”, = etc.

 

 

In addition, = the I2NSF working group will

•       =  Document a high-level I2NSF = framework that describes Services and Capability layers interfaces and = defines a reference model along with functional components at each = layer.

–      = Terminology draft may be included in the = framework or becomes a standalone draft.

•       = Document small and well-scoped use cases = to constrain the scope of the work and achieve sufficient focus for the = working group to deliver successful outcomes. And

 

•       =  Analyze candidate protocols that = may carry the information to be exchanged through the various = interfaces.

–      = E.g. = Compare with existing IETF protocols for “OBJECTs, ACTIONs, = FILTERING, etc” (e.g. PCP, Radius, etc) .

 

Looking for = comments and suggestions.

 

Linda = Dunbar

 

------=_NextPart_000_039A_01D03F83.71D0F650-- From nobody Tue Feb 3 05:34: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 19CFD1A005F; Tue, 3 Feb 2015 05:34:48 -0800 (PST) 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 im6JCwgad16V; Tue, 3 Feb 2015 05:34:47 -0800 (PST) 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 E5E871A006B; Tue, 3 Feb 2015 05:34:46 -0800 (PST) Received: from [216.53.141.131] (port=39610 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1YIdcj-000882-21; Tue, 03 Feb 2015 13:34:37 +0000 From: "Russ White" To: "'Susan Hares'" , "'Linda Dunbar'" , References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> In-Reply-To: <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> Date: Tue, 3 Feb 2015 08:34:31 -0500 Message-ID: <022c01d03fb6$27037480$750a5d80$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHe8BNDJn34omqge3ix4XQ/UM6E/QKkAZ6TnKxqu6A= 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: Cc: nfvrg@irtf.org, i2rs@ietf.org Subject: Re: [i2rs] revised charter for I2NSF 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, 03 Feb 2015 13:34:48 -0000 Interesting concept. One thought that might be helpful -- > * Firewall > * DDOS/Anti-DOS > * Intrusion Detection System/ Intrusion Prevention System > (IDS/IPS) > * Access control/Authorization/Authentication I think I would try to frame things in terms of services, rather than devices, or a mix of the two. For instance -- what does a "firewall" really do? Stateful packet inspection, deep packet inspection, and... ?? So maybe a list something like this might make sense -- (and remember, this is brainstorming, nothing more) -- - Stateful packet inspection - Deep packet inspection - Packet/flow/stream filtering (remote and local) - Packet/flow/stream redirect (remote and local) - Intrusion detection (or perhaps flow/stream pattern matching?) - AAA Don't know if this is a useful line of thought or not. :-) Russ From nobody Tue Feb 3 06:36: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 4B7B31A0687; Tue, 3 Feb 2015 06:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_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 PQjNRrZVPuud; Tue, 3 Feb 2015 06:36:07 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 9417B1A049A; Tue, 3 Feb 2015 06:36:06 -0800 (PST) Received: from [192.168.1.136] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 0A8B82DB2F3F; Tue, 3 Feb 2015 09:36:06 -0500 (EST) From: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary="Apple-Mail=_4C55996B-4842-4FD4-82D1-239795F1653B" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Date: Tue, 3 Feb 2015 09:36:05 -0500 References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> To: Susan Hares , Linda Dunbar , i2nsf@ietf.org, nfvrg@irtf.org, i2rs@ietf.org, Benoit Claise In-Reply-To: <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> X-Mailer: Apple Mail (2.1993) Archived-At: Subject: Re: [i2rs] revised charter for I2NSF 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, 03 Feb 2015 14:36:10 -0000 --Apple-Mail=_4C55996B-4842-4FD4-82D1-239795F1653B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Sorry for the top-post. I am not subscribed to the i2nsf list. = Some comments inline below. In general my comment on the latest charter are that I am = puzzled as the point of this proposed WG charter is. Anyone working in = the controller space these days will be scratching their head as I have = been after reading this charter just now. My suggestion is that if you = indeed want to embark on the work described below, that you do it within = the context of some reference implementation (most of the popular ones = will suffice) which may reveal some of the points I am raising below. > On Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares = wrote: >=20 > Linda:=20 > =20 > Thank you for your encouragement to send comments on the gap-analysis = and the use cases to the list. A few suggestions for the sequences of = your charter events:=20 > =20 > I think that getting use cases, framework and protocol requirements is = critical. Since the security area has a strong terminology draft, maybe = you can just create an online update to that one. =20 > =20 > IMHO, I think it is important to have a goal of using existing = protocols or extending these protocols. Adjusting your charter to = indicate this at every step would prevent duplication of IETF work and = increase the speed of development of your protocol.=20 > =20 > The capability (or functional) layer between controller and network = devices may be able to leverage existing protocols in SACM, AAA, rtgwg, = netmod, netconf/restconf, or other protocols. Or it may be able to be a = combination of these protocols. Instead of in addition, the WG should = consider this at the beginning. =20 > =20 > Making a decision on what type of service-based interface is important = during the framework. If you wish an intent-based application driven = interface, this may be different than the intent based or comprehensive = API.=20 > =20 > Sue=20 > =20 > =20 > From: i2rs [mailto:i2rs-bounces@ietf.org = ] On Behalf Of Linda Dunbar > Sent: Monday, February 02, 2015 7:09 PM > To: i2nsf@ietf.org > Cc: nfvrg@irtf.org ; i2rs@ietf.org = > Subject: [i2rs] revised charter for I2NSF > =20 > Based on the recent discussion on the I2NSF list, here is the revised = charter for I2NSF. Copied to I2RS group to get wider review because = I2NSF is related to I2RS in such a way that I2RS provides the interface = to Router whereas I2NSF provides the interfaces to security functions. > =20 > =20 > In a nutshell, The Interface to Network Security Functions (I2NSF) is = to discuss interfaces for clients or application gateways to communicate Is the purpose here to "discuss" or to "create" interfaces? If = it is the former, I am not sure what the point of the WG would be. If = the latter, those things being done in other WGs across the routing area = or outside of the IETF already. > their specific security policies (request/monitor/report) with = security controller and security functions. I2NSF will specify the = information model, along with adequate data models, and protocols = required for the Operation, Administration, Maintenance and Provisioning = (OAM) for the following security functions: > =C2=B7 Firewall > =C2=B7 DDOS/Anti-DOS=20 > =C2=B7 Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) > =C2=B7 Access control/Authorization/Authentication > =20 > There are two distinct interfaces for I2NSF:=20 > - Capability (or Functional) Layer interface between Security = Controller, which could be embedded in a network controller, and = Security devices (virtual & physical), which focuses more on the = functional aspects of the functions listed above.=20 No such layer is needed. Take a look at the commercial = controllers that are out there and you will see that its a part of the = protocols already, or people re-use existing (well designed) systems = such as RADIUS, etc.... > =20 > - Service Layer Interface between Clients (or App Gateway) = and the Security Controller, which is for clients or App Gateway to = express/monitor the needed security policies (e.g. develop a security = policy language based on NIST endorsed Role Based Access Control.) What would a "service layer interface" be? Today controllers = like OpenDaylight use RestConf and NetConf. Those are perfectly well = specified interfaces that come with various security mechanisms built-in = right out of the box. What else is needed? If you claim you want to = put RADIUS or AAA or something else in there, that is done as a side = action within the context of those things already. This already works = BTW, so again, I am not sure what would be achieved here. > I2NSF WG Deliverables for the Functional/Capability Layer Interface = include: > - Develop a comprehensive set of informational Models for the = following functions with regard to different aspects of OAM = (Operations/Administration/Maintenance). For example: extending the ACL = data model to be more comprehensive, e.g. including multiple actions = and policies. > o Firewall=20 > o DDOS/Anti-DOS=20 > o Intrusion Detection System/ Intrusion Prevention System (IDS/IPS)=20= > =20 > - Develop the corresponding Data Models, e.g. YANG model.=20 Again, these are being done in other places already. What are = you trying to accomplish here? > =20 > - Specify the secure mechanisms to carry the content = identified by the informational/data models. E.g. TLS to carry the = information.=20 Since we are talking about Yang models, I assume the = transport/protocol is Netconf or RestConf. Why would you re-specify that = TLS/SSL be used for Netconf or RestConf? =20 If you want to change something in those protocols, I suggest you stop = by the Netconf WG. Other options such as SNMP already have this = specified too in case you were thinking of going there. > I2NSF WG Deliverables for the Service Layer Interface include: > =E2=80=A2 Develop policy description (or language) for clients = or App Gateway to express/monitor the needed security policies (e.g. = develop a security policy language based on NIST endorsed Role Based = Access Control.) > =E2=80=93 E.g. Develop comprehensive set of =E2=80=9CTARGETs=E2=80=9D= for the Security Intent. Security Target in Data Centers network, in = Access Network, in Wide Area network, etc > =E2=80=93 Develop descriptors for =E2=80=9CUsers=E2=80=9D, = =E2=80=9CRoles=E2=80=9D, =E2=80=9CPermissions=E2=80=9D > =20 > =E2=80=A2 Develop the corresponding information or Data Models, = e.g. YANG model.=20 > =E2=80=A2 Compare with existing IETF protocols for =E2=80=9CRoles=E2= =80=9D, =E2=80=9CUsers=E2=80=9D, =E2=80=9CPermissions=E2=80=9D, etc.=20 What would such a policy description achieve? There are already = policy models out there: Congress from Openstack, GBP/Intent/ODL, op-nfv = policy, Op-flex, etc... Do we need another one? I'd recommend that you take a look at the significant work (and = implementations) that have been done over in those places. > In addition, the I2NSF working group will > =E2=80=A2 Document a high-level I2NSF framework that describes = Services and Capability layers interfaces and defines a reference model = along with functional components at each layer.=20 > =E2=80=93 Terminology draft may be included in the framework or = becomes a standalone draft. What would yet another "framework" achieve? Seriously, we = should be worried about building these things rather than documenting = all sorts of theoretical scenarios. --Tom > =E2=80=A2 Document small and well-scoped use cases to constrain = the scope of the work and achieve sufficient focus for the working group = to deliver successful outcomes. And > =20 > =E2=80=A2 Analyze candidate protocols that may carry the = information to be exchanged through the various interfaces.=20 > =E2=80=93 E.g. Compare with existing IETF protocols for = =E2=80=9COBJECTs, ACTIONs, FILTERING, etc=E2=80=9D (e.g. PCP, Radius, = etc) .=20 > =20 > Looking for comments and suggestions.=20 > =20 > Linda Dunbar > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs = --Apple-Mail=_4C55996B-4842-4FD4-82D1-239795F1653B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Sorry for the top-post. I am not = subscribed to the i2nsf list.  Some comments inline = below.

In = general my comment on the latest charter are that I am puzzled as the = point of this proposed WG charter is.   Anyone working in the = controller space these days will be scratching their head as I have been = after reading this charter just now.  My suggestion is that if you = indeed want to embark on the work described below, that you do it within = the context of some reference implementation (most of the popular ones = will suffice) which may reveal some of the points I am raising = below.


On = Feb 3, 2015:7:31 AM, at 7:31 AM, Susan Hares <shares@ndzh.com> = wrote:

Linda: 
 
Thank you for your encouragement to send comments on = the gap-analysis and the use cases to the list.   A few = suggestions for the sequences of your charter events: 
 
I think that getting use cases, framework and protocol = requirements is critical.  Since the security area has a strong = terminology draft, maybe you can just create an online update to that = one.  
 
IMHO, I think it is = important to have a goal of using existing protocols or extending these = protocols.   Adjusting your charter to indicate this at every = step would prevent duplication of IETF work and increase the speed of = development of your protocol. 
 
The capability (or functional) layer between = controller and network devices may be able to leverage existing = protocols in SACM, AAA, rtgwg, netmod, netconf/restconf, or other = protocols.  Or it may be able to be a combination of these = protocols.  Instead of in addition, the WG should consider this at = the beginning.   
 
Making a decision on what = type of service-based interface is important during the framework.  = If you wish an intent-based application driven interface, this may be = different than the intent based or comprehensive API. 
 
Sue 
 
 
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf = Of Linda Dunbar
Sent: Monday, February 02, 2015 = 7:09 PM
To: i2nsf@ietf.org
Cc: nfvrg@irtf.org; i2rs@ietf.org
Subject: [i2rs] revised charter for = I2NSF
 
Based on the recent discussion on the I2NSF list, here is the = revised charter for I2NSF. Copied to I2RS group to get wider review = because I2NSF is related to I2RS in such a way that  I2RS provides = the interface to Router whereas I2NSF provides the interfaces to = security functions.
 
 
In a nutshell, The Interface to Network Security Functions = (I2NSF) is to discuss interfaces for clients or application gateways to = communicate

Is the purpose here to "discuss" = or to "create" interfaces?  If it is the former, I am not sure what = the point of the WG would be. If the latter, those things being done in = other WGs across the routing area or outside of the IETF = already.

their specific security policies (request/monitor/report) = with security controller and security functions.  I2NSF will = specify the information model, along with adequate data models, and = protocols required for the Operation, Administration, Maintenance and = Provisioning (OAM) for the following security functions:
=C2=B7         Firewall
=C2=B7         DDOS/Anti-DOS 
=C2=B7         Intrusion Detection System/ Intrusion Prevention = System (IDS/IPS)
=C2=B7         Access control/Authorization/Authentication
 
There are = two distinct interfaces for I2NSF: 
-          Capability (or Functional) Layer = interface between Security Controller, which could be embedded in a = network controller, and Security devices (virtual & physical), which = focuses more on the functional aspects of the functions listed = above. 

No such layer is needed. Take a = look at the commercial controllers that are out there and you will see = that its a part of the protocols already, or people re-use existing = (well designed) systems such as RADIUS, etc....

 
-          Service Layer Interface between = Clients (or App Gateway) and the Security Controller,  which is for = clients or App Gateway to express/monitor the needed security policies = (e.g. develop a security policy language based on NIST endorsed Role = Based Access Control.)

What would a "service layer = interface" be?  Today controllers like OpenDaylight use RestConf = and NetConf. Those are perfectly well specified interfaces that come = with various security mechanisms built-in right out of the box. =  What else is needed?  If you claim you want to put RADIUS or = AAA or something else in there, that is done as a side action within the = context of those things already.  This already works BTW, so again, = I am not sure what would be achieved here.

 I2NSF = WG Deliverables for the Functional/Capability Layer Interface = include:
-          Develop a comprehensive set of = informational Models for the following functions with regard to = different aspects of OAM (Operations/Administration/Maintenance). For = example: extending the ACL data model to be more comprehensive, e.g. =  including multiple actions and policies.
o   Firewall 
o   DDOS/Anti-DOS 
o   Intrusion Detection System/ = Intrusion Prevention System (IDS/IPS) 
 
-          Develop the corresponding Data = Models, e.g. YANG model. 

Again, these are being done in = other places already.  What are you trying to accomplish = here?

 
-          Specify the secure mechanisms to = carry the content identified by the informational/data models. E.g. TLS = to carry the information. 

Since we are talking about Yang = models, I assume the transport/protocol is Netconf or RestConf. Why = would you re-specify that TLS/SSL be used for Netconf or RestConf? =  
If you want to change something in those protocols, I = suggest you stop by the Netconf WG.  Other options such as SNMP = already have this specified too in case you were
thinking of = going there.

 I2NSF WG Deliverables for the Service Layer Interface = include:
=E2=80=A2       Develop = policy description (or language) for clients or App Gateway to = express/monitor the needed security policies (e.g. develop a security = policy language based on NIST endorsed Role Based Access Control.)
=E2=80=93      E.g. = Develop comprehensive set of =E2=80=9CTARGETs=E2=80=9D for the Security = Intent.   Security Target in Data Centers network, in Access = Network, in Wide Area network, etc
=E2=80=93      Develop = descriptors for =E2=80=9CUsers=E2=80=9D, =E2=80=9CRoles=E2=80=9D, = =E2=80=9CPermissions=E2=80=9D
 
=E2=80=A2       Develop = the corresponding information or Data Models, e.g. YANG model. 
=E2=80=A2       Compare = with existing IETF protocols for =E2=80=9CRoles=E2=80=9D, =E2=80=9CUsers=E2= =80=9D, =E2=80=9CPermissions=E2=80=9D, etc. 

What would such a policy = description achieve?  There are already policy models out there: = Congress from Openstack, GBP/Intent/ODL, op-nfv policy, Op-flex, etc... =    Do we need another one?
I'd recommend that you = take a look at the significant work (and implementations) that have been = done over in those places.

 In = addition, the I2NSF working group will
=E2=80=A2        Do= cument a high-level I2NSF framework that describes Services and = Capability layers interfaces and defines a reference model along with = functional components at each layer. 
=E2=80=93      Terminol= ogy draft may be included in the framework or becomes a standalone = draft.

What = would yet another "framework" achieve?  Seriously, we should be = worried about building these things rather than documenting all sorts of = theoretical scenarios.

= --Tom




=E2=80=A2       Document= small and well-scoped use cases to constrain the scope of the work and = achieve sufficient focus for the working group to deliver successful = outcomes. And
 
=E2=80=A2        An= alyze candidate protocols that may carry the information to be exchanged = through the various interfaces. 
=E2=80=93      E.g. Compare with existing IETF = protocols for =E2=80=9COBJECTs, ACTIONs, FILTERING, etc=E2=80=9D (e.g. = PCP, Radius, etc) . 
 
Looking = for comments and suggestions. 
 
Linda = Dunbar
 
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

= --Apple-Mail=_4C55996B-4842-4FD4-82D1-239795F1653B-- From nobody Tue Feb 3 09:34: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 028711A1EFE for ; Tue, 3 Feb 2015 09:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZoBxPCv6nOz for ; Tue, 3 Feb 2015 09:34:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83CFC1A1BEF for ; Tue, 3 Feb 2015 09:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3072; q=dns/txt; s=iport; t=1422984850; x=1424194450; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bFB1z+RxECE8QtkCqWfo/C/Nz+3J17W1mkF+dgqoAF0=; b=Nu/aPdAA0BVyvVlqsTfiLytdPvUm00wtJUR7g10UjQVS97dndWcZR9Ob 3Jpt18C4cVNPu/4cIicIEFsbe9fMBqWHF60f6SgHjluyYeehVDAqzp3P9 k1ZyFPB+Fww5dn15JQ7lXHuqMtK0wsswzIkl429VTI4g9Nd7vNM7zWxek o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCBQC6BdFU/5FdJa1XA4MGUlkExHsKhXECgR5DAQEBAQF9hAwBAQEDAQEBARodNAsFCQICAQgOAgUDCgMREBsMCyUCBAENBQgBEogKCA3WfwEBAQEBAQEBAQEBAQEBAQEBAQEBARcEjxwnIRAHEYMFgRMFjwyKPYsOgn2DPSKCAhwUgTxvAYEBQn4BAQE X-IronPort-AV: E=Sophos;i="5.09,513,1418083200"; d="scan'208";a="120160988" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP; 03 Feb 2015 17:34:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t13HY9eg004422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:34:09 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.43]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:34:09 -0600 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder , Susan Hares Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AQHQP4fv798VqLS8skKWuMMIXvsm75ze7FAA Date: Tue, 3 Feb 2015 17:34:09 +0000 Message-ID: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> In-Reply-To: <20150203080327.GA68276@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 17:34:15 -0000 > From: i2rs on Behalf Of Juergen Schoenwaelder, February 03, 2015 3:03 AM >=20 > On Mon, Feb 02, 2015 at 06:53:16PM -0500, Susan Hares wrote: > > This begins a 2 week WG Adoption call for: > > draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can > > access the draft at: > > > > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt > > >=20 > I like to point out that some statements in the draft are either unclear = or wrong. As a "00" draft, I do expect that there will be changes needed. Your feedb= ack is certainly appreciated.=20 =20 > o limited support for pushed notification of changes. (Currently > notifications are for configuration data only. And even then, > subscription mechanisms for such notifications are undefined.) The sub-bullet was intended to refine the "existing YANG technology ecosyst= em" paragraph above it. That said, the word "undefined" will be changed i= n the next draft. More below. =20 > RFC 5277 defines a mechanism. RFC 6470 defines > notifications that allow to track changes in a configuration datastore. S= o why is > the subscription mechanisms undefined? Netconf Event Notifications RFC5277 is useful, and everything possible from= it should be incorporated in the ultimate technology solution. But RFC527= 7 does not follow the Pub/Sub paradigm. It predates YANG. In addition, a g= oal of this document is to frame requirements so as not to preclude support= for additional transports beyond Netconf. =20 Netconf Base Notifications RFC6470 is applicable for configuration info onl= y. The I2RS requirements mean we need to track many other things such as = routing changes. > But in more general terms, I am wondering what the scope of this work is.= Is the > goal to provide a mechanism similar to what we have already for 'config t= rue' > datastores for 'config false' datastores or is the goal to replace the ex= isting > mechanism with a new mechanism that will cover both 'config true' and 'co= nfig > false' datastores? The goal of this document is to aggregate and refine the I2RS requirements = which highlight the needs of YANG Pub/Sub. I believe there are several int= eresting requirements areas to explore here, including,=20 - Dampening: confining the visibility of volatility into something digestib= le by the subscriber - Liveliness: what to do if subsets of YANG subtrees can no longer be monit= ored or are stale - Presentation: how do we bundle a set of discrete object notifications int= o a single publishable update for a Subscription Mechanisms will follow requirements. Eric =20 > /js >=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 Tue Feb 3 09:41:31 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 BA0011A6F3A for ; Tue, 3 Feb 2015 09:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 j0q5smzoh8Ey for ; Tue, 3 Feb 2015 09:41:27 -0800 (PST) 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 658121A8A3D for ; Tue, 3 Feb 2015 09:38:40 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 372AF19DC; Tue, 3 Feb 2015 18:38:39 +0100 (CET) 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 0VFzRgm7GHW4; Tue, 3 Feb 2015 18:38:29 +0100 (CET) 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, 3 Feb 2015 18:38:38 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C48920039; Tue, 3 Feb 2015 18:38:38 +0100 (CET) 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 ivT-NipO_BUK; Tue, 3 Feb 2015 18:38:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CDC72003A; Tue, 3 Feb 2015 18:38:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 440383161338; Tue, 3 Feb 2015 18:38:37 +0100 (CET) Date: Tue, 3 Feb 2015 18:38:37 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20150203173837.GF81526@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Susan Hares , 'Jeffrey Haas' , "i2rs@ietf.org" References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 17:41:28 -0000 On Tue, Feb 03, 2015 at 05:34:09PM +0000, Eric Voit (evoit) wrote: > > From: i2rs on Behalf Of Juergen Schoenwaelder, February 03, 2015 3:03 AM > > > > On Mon, Feb 02, 2015 at 06:53:16PM -0500, Susan Hares wrote: > > > This begins a 2 week WG Adoption call for: > > > draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can > > > access the draft at: > > > > > > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt > > > > > > > I like to point out that some statements in the draft are either unclear or wrong. > > As a "00" draft, I do expect that there will be changes needed. Your feedback is certainly appreciated. > > > o limited support for pushed notification of changes. (Currently > > notifications are for configuration data only. And even then, > > subscription mechanisms for such notifications are undefined.) > > The sub-bullet was intended to refine the "existing YANG technology ecosystem" paragraph above it. That said, the word "undefined" will be changed in the next draft. More below. > > > RFC 5277 defines a mechanism. RFC 6470 defines > > notifications that allow to track changes in a configuration datastore. So why is > > the subscription mechanisms undefined? > > Netconf Event Notifications RFC5277 is useful, and everything possible from it should be incorporated in the ultimate technology solution. But RFC5277 does not follow the Pub/Sub paradigm. It predates YANG. In addition, a goal of this document is to frame requirements so as not to preclude support for additional transports beyond Netconf. > > Netconf Base Notifications RFC6470 is applicable for configuration info only. The I2RS requirements mean we need to track many other things such as routing changes. > I understand all that I think but I still think the text quoted above is incorrect and this should be fixed. I am not looking for long explanation, a simple "we will change that text to '...'" would be more efficient. /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 Feb 3 09:47: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 22DF21A1AE3 for ; Tue, 3 Feb 2015 09:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGjXtZdoauSG for ; Tue, 3 Feb 2015 09:47:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6DD1A1ADF for ; Tue, 3 Feb 2015 09:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=568; q=dns/txt; s=iport; t=1422985626; x=1424195226; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2/CNTKInrXWcl45x7jChldJNho4HFr+x4f2oGiIKANc=; b=EX22ffB+0FAb1dwbSM1zisSHMUADh/dtKrgFLRCMlFjGYMo+bjaJNSIP E9WyJlgOdI2bXKEYjqY3N6uHKvSQIVXQseMtw/LEYaQwTmkUcNEwwjNy0 jhEBRkDjzMYpfxHX7QkNj8YaJUsMCJJNNac4ShzC4X1a9JJa99vD6xFXP c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AhBQDxCNFU/4QNJK1agwaBL8p2AoEeQwEBAQEBfYQMAQEBAwE6PxACAQgOFAMREDIlAgQODYgdCNcwAQEBAQEBAQEBAQEBAQEBAQEBAQEBF48gJzEHgxaBEwEEjwycBSKCMoE8gXFCfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120092609" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-8.cisco.com with ESMTP; 03 Feb 2015 17:47:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t13Hl5Gs017721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:47:05 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.43]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:47:05 -0600 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AQHQP4fv798VqLS8skKWuMMIXvsm75ze7FAAgACpsID//5w0MA== Date: Tue, 3 Feb 2015 17:47:04 +0000 Message-ID: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> <20150203173837.GF81526@elstar.local> In-Reply-To: <20150203173837.GF81526@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 17:47:10 -0000 >> o limited support for pushed notification of changes. (Currently >> notifications are for configuration data only. And even then, >> subscription mechanisms for such notifications are undefined.) > I understand all that I think but I still think the text quoted above is = incorrect and > this should be fixed. I am not looking for long explanation, a simple "we= will > change that text to '...'" would be more efficient. I can just delete everything between the parenthesis. Would that be suffic= ient? Eric =20 > /js From nobody Tue Feb 3 09:52: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 8CF221A7021 for ; Tue, 3 Feb 2015 09:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaavQEj1ZdvU for ; Tue, 3 Feb 2015 09:52:46 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87DCA1A802C for ; Tue, 3 Feb 2015 09:52:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2007; q=dns/txt; s=iport; t=1422985953; x=1424195553; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/Gk8q32zAjXfUrF8HsM4ZdruMKmpJGtBFcFSxZtdZ/E=; b=P+vPaRR6Rvt6YeHnCkhg9PPg0J3YasxgzPkBZHGY/Wc8RJ6YfThA9fOZ +qBGTG83AlIoK5+IdUAWZWydFktCdc/oiXw8oR3Fx9BodU+mr0aPIt3G/ FKss/OxmOVGlSmeXm8FvBhA8qeJim/JunDLU8hKe7E1+RMmBr4b50ae2z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCBQCMCtFU/5ldJa1agwZSWcUACoVxAoEeQwEBAQEBfYQMAQEBAwEBAQEaFQEFNgoBEAsOBAYJFg8JAwIBAgEVIg4GAQwBBQIBAQWIHAgN1yoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjxYQAgFPB4QpBYodjhWBF4UniGSDPSKCMoFaIDEBgkEBAQE X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120167129" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 03 Feb 2015 17:52:33 +0000 Received: from [10.117.46.163] (rtp-jclarke-8912.cisco.com [10.117.46.163]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t13HqWJV029934; Tue, 3 Feb 2015 17:52:32 GMT Message-ID: <54D10AE0.6070908@cisco.com> Date: Tue, 03 Feb 2015 12:52:32 -0500 From: Joe Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org References: <011101d03f43$6b2b6870$41823950$@ndzh.com> In-Reply-To: <011101d03f43$6b2b6870$41823950$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: 'Jeffrey Haas' Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 17:52:47 -0000 On 2/2/15 6:53 PM, Susan Hares wrote: > This begins a 2 week WG Adoption call for: > draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can > access the draft at: > > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt Support. In fact, the traceability draft calls out pub-sub in 7.4.3. It would be nice to see this use case mentioned in the Voit draft. Joe > > The current I2RS charter states: > > “The I2RS working group works to develop a high-level architecture > thatdescribes the basic building-blocks necessary to enable the specific > usecases, and that will lead to an understanding of the abstract > informational models and requirements for encodings and protocols for > the I2RS interfaces.” > > This draft is part of setting the requirements for the I2RS protocol. > > As Andy has noted in early email, there may be nothing specific to I2RS > in draft-voit-i2rs-pub-sub-requirements-00.txt. It may be something > that should be just a part of the netconf/restconf functionality. As > part of the adoption of this draft, the I2RS chairs would like to hear > your opinion of Andy’s statement. Andy also suggests that > draft-netmod-clemm-datastore-push-00 should also be part of the I2RS > requirements. > > http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html > > [chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. > > If the WG approves adoption of > draft-voit-i2rs-pub-sub-requirements-00.txt and the WG feels these > drafts should be netmod WG drafts with I2RS holding a requirement > drafts, the I2RS chairs will do the right thing to make it happen. If > enough people comment that draft-netmod-clemm-datastore-push-00 should > be part of the I2RS requirements, we will do a WG adoption of call for > this requirement. > > Sue Hares > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Feb 3 10:03: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 231C61A8757 for ; Tue, 3 Feb 2015 10:03:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, 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 Qk6pQ_EAcQLI for ; Tue, 3 Feb 2015 10:03:21 -0800 (PST) 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 9DC941A8749 for ; Tue, 3 Feb 2015 10:03:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2060C1B78; Tue, 3 Feb 2015 19:03:20 +0100 (CET) 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 Z-3xLTxYokfz; Tue, 3 Feb 2015 19:03:10 +0100 (CET) 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, 3 Feb 2015 19:03:19 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0F4B20036; Tue, 3 Feb 2015 19:03:18 +0100 (CET) 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 Em5dG3YuUeKO; Tue, 3 Feb 2015 19:03:18 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9ED5A20037; Tue, 3 Feb 2015 19:03:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C3DBA316181A; Tue, 3 Feb 2015 19:03:17 +0100 (CET) Date: Tue, 3 Feb 2015 19:03:17 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20150203180317.GA82786@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Susan Hares , 'Jeffrey Haas' , "i2rs@ietf.org" References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> <20150203173837.GF81526@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 18:03:29 -0000 On Tue, Feb 03, 2015 at 05:47:04PM +0000, Eric Voit (evoit) wrote: > >> o limited support for pushed notification of changes. (Currently > >> notifications are for configuration data only. And even then, > >> subscription mechanisms for such notifications are undefined.) > > > I understand all that I think but I still think the text quoted above is incorrect and > > this should be fixed. I am not looking for long explanation, a simple "we will > > change that text to '...'" would be more efficient. > > I can just delete everything between the parenthesis. Would that be sufficient? This leaves it open what 'limited' means, which I think is not good either. Perhaps: o change notifications only for data residing in configuration datastores /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 Feb 3 10:20: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 5C8851A6F3A for ; Tue, 3 Feb 2015 10:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SV1drEdaM263 for ; Tue, 3 Feb 2015 10:20:09 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F004D1A8A3D for ; Tue, 3 Feb 2015 10:19:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1143; q=dns/txt; s=iport; t=1422987545; x=1424197145; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SddOjwRaSJXNOK26BDjgbkyRYvqsUFPo92HEh3GJvWw=; b=aOqeDSufSV8EBn1txcq9aFNqUUIg9DHgMZ394vjpFfh4qkuE+94RCdal 0We00FQpvcQc4N9E+WvHTmj25cS26/PX7vt43F4Xe6mfAAbG5scj5aKWi U7e7VTxNMwgWQj16wiBZNldBtZTcfsQyWnax6E9Lm4EbkZRTMQUhuBIl6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFALsP0VStJV2Y/2dsb2JhbABXA4MGUl3FAoV1AoEeQwEBAQEBfYQMAQEBAwE6PwUJAgIBCA4CCAoDERAbFyUCBA4NiB0I1xEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBI8cJyEQBxGDBYETBY8MnAUigjKBPIFxQn4BAQE X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="393448879" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 03 Feb 2015 18:19:03 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t13IJ2Ae006623 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 18:19:02 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.43]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 12:19:01 -0600 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AQHQP4fv798VqLS8skKWuMMIXvsm75ze7FAAgACpsID//5w0MIAAarCA//+fFvA= Date: Tue, 3 Feb 2015 18:19:01 +0000 Message-ID: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> <20150203173837.GF81526@elstar.local> <20150203180317.GA82786@elstar.local> In-Reply-To: <20150203180317.GA82786@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 03 Feb 2015 18:20:11 -0000 > On Tue, Feb 03, 2015 at 05:47:04PM +0000, Eric Voit (evoit) wrote: > > >> o limited support for pushed notification of changes. (Currentl= y > > >> notifications are for configuration data only. And even then= , > > >> subscription mechanisms for such notifications are > > >> undefined.) > > > > > I understand all that I think but I still think the text quoted > > > above is incorrect and this should be fixed. I am not looking for > > > long explanation, a simple "we will change that text to '...'" would = be more > efficient. > > > > I can just delete everything between the parenthesis. Would that be > sufficient? >=20 > This leaves it open what 'limited' means, which I think is not good eithe= r. > Perhaps: >=20 > o change notifications only for data residing in configuration > datastores Works for me. I will insert that into "-01" Eric > /js >=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 Tue Feb 3 12:10: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 C07BD1A1A0F; Tue, 3 Feb 2015 12:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZy7T8tk6kUB; Tue, 3 Feb 2015 12:10:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A306A1A886A; Tue, 3 Feb 2015 12:10:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOS87230; Tue, 03 Feb 2015 20:10:42 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Feb 2015 20:10:41 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Tue, 3 Feb 2015 12:10:38 -0800 From: Linda Dunbar To: "Thomas D. Nadeau" , Susan Hares , "i2nsf@ietf.org" , "nfvrg@irtf.org" , "i2rs@ietf.org" , Benoit Claise Thread-Topic: [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAARY+IAABVh7QA== Date: Tue, 3 Feb 2015 20:10:38 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBD7B1@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@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.212.245.107] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EBD7B1dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [i2rs] revised charter for I2NSF 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, 03 Feb 2015 20:10:50 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EBD7B1dfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9tLA0KDQpZb3VyIHBvaW50cyB0YWtlbiwgdGhlcmUgYXJlIG1hbnkgdHlwZXMgb2YgY29udHJv bGxlcnMgaW4gU0ROIHBhcmFkaWdtLiBUaHJvd2luZyBvbmUgbW9yZSBjYW4gYmUgY29uZnVzaW5n Lg0KDQpUaGUg4oCcc2VjdXJpdHkgY29udHJvbGxlcuKAnSBpbiB0aGUgY29udGV4dCBvZiBJMk5T RiBjYW4gYmUgdmlld2VkIGFzIGFuIGFkYXB0ZXIgYmV0d2VlbiBTZWN1cml0eSBTZXJ2aWNlIFJl cXVlc3QgKGUuZy4gYWxsb3cgdHJhZmZpYyB3aXRoIHNwZWNpZmljIGZpZWxkcyBmb3Igc3BlY2lm aWMgdGltZSBzcGFuKSBhbmQgdGhlIHNlY3VyaXR5IGRldmljZSBzcGVjaWZpYyBpbmZvcm1hdGlv biBtb2RlbC4NCg0KWWVzLCB3ZSB3aWxsIGhhdmUgYSAg4oCccmVmZXJlbmNlIGltcGxlbWVudGF0 aW9u4oCdIHRvIG1ha2UgdGhlIGRpc2N1c3Npb24gbW9yZSBmb2N1c2VkLg0KDQpUaGFua3MsIExp bmRhDQoNCkZyb206IGkycnMgW21haWx0bzppMnJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBUaG9tYXMgRC4gTmFkZWF1DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwMywgMjAxNSA4 OjM2IEFNDQpUbzogU3VzYW4gSGFyZXM7IExpbmRhIER1bmJhcjsgaTJuc2ZAaWV0Zi5vcmc7IG5m dnJnQGlydGYub3JnOyBpMnJzQGlldGYub3JnOyBCZW5vaXQgQ2xhaXNlDQpTdWJqZWN0OiBSZTog W2kycnNdIHJldmlzZWQgY2hhcnRlciBmb3IgSTJOU0YNCg0KICAgICAgICAgICAgU29ycnkgZm9y IHRoZSB0b3AtcG9zdC4gSSBhbSBub3Qgc3Vic2NyaWJlZCB0byB0aGUgaTJuc2YgbGlzdC4gIFNv bWUgY29tbWVudHMgaW5saW5lIGJlbG93Lg0KDQogICAgICAgICAgICBJbiBnZW5lcmFsIG15IGNv bW1lbnQgb24gdGhlIGxhdGVzdCBjaGFydGVyIGFyZSB0aGF0IEkgYW0gcHV6emxlZCBhcyB0aGUg cG9pbnQgb2YgdGhpcyBwcm9wb3NlZCBXRyBjaGFydGVyIGlzLiAgIEFueW9uZSB3b3JraW5nIGlu IHRoZSBjb250cm9sbGVyIHNwYWNlIHRoZXNlIGRheXMgd2lsbCBiZSBzY3JhdGNoaW5nIHRoZWly IGhlYWQgYXMgSSBoYXZlIGJlZW4gYWZ0ZXIgcmVhZGluZyB0aGlzIGNoYXJ0ZXIganVzdCBub3cu ICBNeSBzdWdnZXN0aW9uIGlzIHRoYXQgaWYgeW91IGluZGVlZCB3YW50IHRvIGVtYmFyayBvbiB0 aGUgd29yayBkZXNjcmliZWQgYmVsb3csIHRoYXQgeW91IGRvIGl0IHdpdGhpbiB0aGUgY29udGV4 dCBvZiBzb21lIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbiAobW9zdCBvZiB0aGUgcG9wdWxhciBv bmVzIHdpbGwgc3VmZmljZSkgd2hpY2ggbWF5IHJldmVhbCBzb21lIG9mIHRoZSBwb2ludHMgSSBh bSByYWlzaW5nIGJlbG93Lg0KDQoNCk9uIEZlYiAzLCAyMDE1Ojc6MzEgQU0sIGF0IDc6MzEgQU0s IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb208bWFpbHRvOnNoYXJlc0BuZHpoLmNvbT4+IHdy b3RlOg0KDQpMaW5kYToNCg0KVGhhbmsgeW91IGZvciB5b3VyIGVuY291cmFnZW1lbnQgdG8gc2Vu ZCBjb21tZW50cyBvbiB0aGUgZ2FwLWFuYWx5c2lzIGFuZCB0aGUgdXNlIGNhc2VzIHRvIHRoZSBs aXN0LiAgIEEgZmV3IHN1Z2dlc3Rpb25zIGZvciB0aGUgc2VxdWVuY2VzIG9mIHlvdXIgY2hhcnRl ciBldmVudHM6DQoNCkkgdGhpbmsgdGhhdCBnZXR0aW5nIHVzZSBjYXNlcywgZnJhbWV3b3JrIGFu ZCBwcm90b2NvbCByZXF1aXJlbWVudHMgaXMgY3JpdGljYWwuICBTaW5jZSB0aGUgc2VjdXJpdHkg YXJlYSBoYXMgYSBzdHJvbmcgdGVybWlub2xvZ3kgZHJhZnQsIG1heWJlIHlvdSBjYW4ganVzdCBj cmVhdGUgYW4gb25saW5lIHVwZGF0ZSB0byB0aGF0IG9uZS4NCg0KSU1ITywgSSB0aGluayBpdCBp cyBpbXBvcnRhbnQgdG8gaGF2ZSBhIGdvYWwgb2YgdXNpbmcgZXhpc3RpbmcgcHJvdG9jb2xzIG9y IGV4dGVuZGluZyB0aGVzZSBwcm90b2NvbHMuICAgQWRqdXN0aW5nIHlvdXIgY2hhcnRlciB0byBp bmRpY2F0ZSB0aGlzIGF0IGV2ZXJ5IHN0ZXAgd291bGQgcHJldmVudCBkdXBsaWNhdGlvbiBvZiBJ RVRGIHdvcmsgYW5kIGluY3JlYXNlIHRoZSBzcGVlZCBvZiBkZXZlbG9wbWVudCBvZiB5b3VyIHBy b3RvY29sLg0KDQpUaGUgY2FwYWJpbGl0eSAob3IgZnVuY3Rpb25hbCkgbGF5ZXIgYmV0d2VlbiBj b250cm9sbGVyIGFuZCBuZXR3b3JrIGRldmljZXMgbWF5IGJlIGFibGUgdG8gbGV2ZXJhZ2UgZXhp c3RpbmcgcHJvdG9jb2xzIGluIFNBQ00sIEFBQSwgcnRnd2csIG5ldG1vZCwgbmV0Y29uZi9yZXN0 Y29uZiwgb3Igb3RoZXIgcHJvdG9jb2xzLiAgT3IgaXQgbWF5IGJlIGFibGUgdG8gYmUgYSBjb21i aW5hdGlvbiBvZiB0aGVzZSBwcm90b2NvbHMuICBJbnN0ZWFkIG9mIGluIGFkZGl0aW9uLCB0aGUg V0cgc2hvdWxkIGNvbnNpZGVyIHRoaXMgYXQgdGhlIGJlZ2lubmluZy4NCg0KTWFraW5nIGEgZGVj aXNpb24gb24gd2hhdCB0eXBlIG9mIHNlcnZpY2UtYmFzZWQgaW50ZXJmYWNlIGlzIGltcG9ydGFu dCBkdXJpbmcgdGhlIGZyYW1ld29yay4gIElmIHlvdSB3aXNoIGFuIGludGVudC1iYXNlZCBhcHBs aWNhdGlvbiBkcml2ZW4gaW50ZXJmYWNlLCB0aGlzIG1heSBiZSBkaWZmZXJlbnQgdGhhbiB0aGUg aW50ZW50IGJhc2VkIG9yIGNvbXByZWhlbnNpdmUgQVBJLg0KDQpTdWUNCg0KDQpGcm9tOiBpMnJz IFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTGluZGEgRHVuYmFy DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDAyLCAyMDE1IDc6MDkgUE0NClRvOiBpMm5zZkBpZXRm Lm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+DQpDYzogbmZ2cmdAaXJ0Zi5vcmc8bWFpbHRvOm5m dnJnQGlydGYub3JnPjsgaTJyc0BpZXRmLm9yZzxtYWlsdG86aTJyc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFtpMnJzXSByZXZpc2VkIGNoYXJ0ZXIgZm9yIEkyTlNGDQoNCkJhc2VkIG9uIHRoZSByZWNl bnQgZGlzY3Vzc2lvbiBvbiB0aGUgSTJOU0YgbGlzdCwgaGVyZSBpcyB0aGUgcmV2aXNlZCBjaGFy dGVyIGZvciBJMk5TRi4gQ29waWVkIHRvIEkyUlMgZ3JvdXAgdG8gZ2V0IHdpZGVyIHJldmlldyBi ZWNhdXNlIEkyTlNGIGlzIHJlbGF0ZWQgdG8gSTJSUyBpbiBzdWNoIGEgd2F5IHRoYXQgIEkyUlMg cHJvdmlkZXMgdGhlIGludGVyZmFjZSB0byBSb3V0ZXIgd2hlcmVhcyBJMk5TRiBwcm92aWRlcyB0 aGUgaW50ZXJmYWNlcyB0byBzZWN1cml0eSBmdW5jdGlvbnMuDQoNCg0KSW4gYSBudXRzaGVsbCwg VGhlIEludGVyZmFjZSB0byBOZXR3b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAoSTJOU0YpIGlzIHRv IGRpc2N1c3MgaW50ZXJmYWNlcyBmb3IgY2xpZW50cyBvciBhcHBsaWNhdGlvbiBnYXRld2F5cyB0 byBjb21tdW5pY2F0ZQ0KDQogICAgICAgICAgICBJcyB0aGUgcHVycG9zZSBoZXJlIHRvICJkaXNj dXNzIiBvciB0byAiY3JlYXRlIiBpbnRlcmZhY2VzPyAgSWYgaXQgaXMgdGhlIGZvcm1lciwgSSBh bSBub3Qgc3VyZSB3aGF0IHRoZSBwb2ludCBvZiB0aGUgV0cgd291bGQgYmUuIElmIHRoZSBsYXR0 ZXIsIHRob3NlIHRoaW5ncyBiZWluZyBkb25lIGluIG90aGVyIFdHcyBhY3Jvc3MgdGhlIHJvdXRp bmcgYXJlYSBvciBvdXRzaWRlIG9mIHRoZSBJRVRGIGFscmVhZHkuDQoNCg0KdGhlaXIgc3BlY2lm aWMgc2VjdXJpdHkgcG9saWNpZXMgKHJlcXVlc3QvbW9uaXRvci9yZXBvcnQpIHdpdGggc2VjdXJp dHkgY29udHJvbGxlciBhbmQgc2VjdXJpdHkgZnVuY3Rpb25zLiAgSTJOU0Ygd2lsbCBzcGVjaWZ5 IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCwgYWxvbmcgd2l0aCBhZGVxdWF0ZSBkYXRhIG1vZGVscywg YW5kIHByb3RvY29scyByZXF1aXJlZCBmb3IgdGhlIE9wZXJhdGlvbiwgQWRtaW5pc3RyYXRpb24s IE1haW50ZW5hbmNlIGFuZCBQcm92aXNpb25pbmcgKE9BTSkgZm9yIHRoZSBmb2xsb3dpbmcgc2Vj dXJpdHkgZnVuY3Rpb25zOg0K4oCiICAgICAgICAgRmlyZXdhbGwNCuKAoiAgICAgICAgIERET1Mv QW50aS1ET1MNCuKAoiAgICAgICAgIEludHJ1c2lvbiBEZXRlY3Rpb24gU3lzdGVtLyBJbnRydXNp b24gUHJldmVudGlvbiBTeXN0ZW0gKElEUy9JUFMpDQrigKIgICAgICAgICBBY2Nlc3MgY29udHJv bC9BdXRob3JpemF0aW9uL0F1dGhlbnRpY2F0aW9uDQoNClRoZXJlIGFyZSB0d28gZGlzdGluY3Qg aW50ZXJmYWNlcyBmb3IgSTJOU0Y6DQotICAgICAgICAgIENhcGFiaWxpdHkgKG9yIEZ1bmN0aW9u YWwpIExheWVyIGludGVyZmFjZSBiZXR3ZWVuIFNlY3VyaXR5IENvbnRyb2xsZXIsIHdoaWNoIGNv dWxkIGJlIGVtYmVkZGVkIGluIGEgbmV0d29yayBjb250cm9sbGVyLCBhbmQgU2VjdXJpdHkgZGV2 aWNlcyAodmlydHVhbCAmIHBoeXNpY2FsKSwgd2hpY2ggZm9jdXNlcyBtb3JlIG9uIHRoZSBmdW5j dGlvbmFsIGFzcGVjdHMgb2YgdGhlIGZ1bmN0aW9ucyBsaXN0ZWQgYWJvdmUuDQoNCiAgICAgICAg ICAgIE5vIHN1Y2ggbGF5ZXIgaXMgbmVlZGVkLiBUYWtlIGEgbG9vayBhdCB0aGUgY29tbWVyY2lh bCBjb250cm9sbGVycyB0aGF0IGFyZSBvdXQgdGhlcmUgYW5kIHlvdSB3aWxsIHNlZSB0aGF0IGl0 cyBhIHBhcnQgb2YgdGhlIHByb3RvY29scyBhbHJlYWR5LCBvciBwZW9wbGUgcmUtdXNlIGV4aXN0 aW5nICh3ZWxsIGRlc2lnbmVkKSBzeXN0ZW1zIHN1Y2ggYXMgUkFESVVTLCBldGMuLi4uDQoNCg0K DQotICAgICAgICAgIFNlcnZpY2UgTGF5ZXIgSW50ZXJmYWNlIGJldHdlZW4gQ2xpZW50cyAob3Ig QXBwIEdhdGV3YXkpIGFuZCB0aGUgU2VjdXJpdHkgQ29udHJvbGxlciwgIHdoaWNoIGlzIGZvciBj bGllbnRzIG9yIEFwcCBHYXRld2F5IHRvIGV4cHJlc3MvbW9uaXRvciB0aGUgbmVlZGVkIHNlY3Vy aXR5IHBvbGljaWVzIChlLmcuIGRldmVsb3AgYSBzZWN1cml0eSBwb2xpY3kgbGFuZ3VhZ2UgYmFz ZWQgb24gTklTVCBlbmRvcnNlZCBSb2xlIEJhc2VkIEFjY2VzcyBDb250cm9sLikNCg0KICAgICAg ICAgICAgV2hhdCB3b3VsZCBhICJzZXJ2aWNlIGxheWVyIGludGVyZmFjZSIgYmU/ICBUb2RheSBj b250cm9sbGVycyBsaWtlIE9wZW5EYXlsaWdodCB1c2UgUmVzdENvbmYgYW5kIE5ldENvbmYuIFRo b3NlIGFyZSBwZXJmZWN0bHkgd2VsbCBzcGVjaWZpZWQgaW50ZXJmYWNlcyB0aGF0IGNvbWUgd2l0 aCB2YXJpb3VzIHNlY3VyaXR5IG1lY2hhbmlzbXMgYnVpbHQtaW4gcmlnaHQgb3V0IG9mIHRoZSBi b3guICBXaGF0IGVsc2UgaXMgbmVlZGVkPyAgSWYgeW91IGNsYWltIHlvdSB3YW50IHRvIHB1dCBS QURJVVMgb3IgQUFBIG9yIHNvbWV0aGluZyBlbHNlIGluIHRoZXJlLCB0aGF0IGlzIGRvbmUgYXMg YSBzaWRlIGFjdGlvbiB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhvc2UgdGhpbmdzIGFscmVhZHku ICBUaGlzIGFscmVhZHkgd29ya3MgQlRXLCBzbyBhZ2FpbiwgSSBhbSBub3Qgc3VyZSB3aGF0IHdv dWxkIGJlIGFjaGlldmVkIGhlcmUuDQoNCg0KIEkyTlNGIFdHIERlbGl2ZXJhYmxlcyBmb3IgdGhl IEZ1bmN0aW9uYWwvQ2FwYWJpbGl0eSBMYXllciBJbnRlcmZhY2UgaW5jbHVkZToNCi0gICAgICAg ICAgRGV2ZWxvcCBhIGNvbXByZWhlbnNpdmUgc2V0IG9mIGluZm9ybWF0aW9uYWwgTW9kZWxzIGZv ciB0aGUgZm9sbG93aW5nIGZ1bmN0aW9ucyB3aXRoIHJlZ2FyZCB0byBkaWZmZXJlbnQgYXNwZWN0 cyBvZiBPQU0gKE9wZXJhdGlvbnMvQWRtaW5pc3RyYXRpb24vTWFpbnRlbmFuY2UpLiBGb3IgZXhh bXBsZTogZXh0ZW5kaW5nIHRoZSBBQ0wgZGF0YSBtb2RlbCB0byBiZSBtb3JlIGNvbXByZWhlbnNp dmUsIGUuZy4gIGluY2x1ZGluZyBtdWx0aXBsZSBhY3Rpb25zIGFuZCBwb2xpY2llcy4NCm8gICBG aXJld2FsbA0KbyAgIERET1MvQW50aS1ET1MNCm8gICBJbnRydXNpb24gRGV0ZWN0aW9uIFN5c3Rl bS8gSW50cnVzaW9uIFByZXZlbnRpb24gU3lzdGVtIChJRFMvSVBTKQ0KDQotICAgICAgICAgIERl dmVsb3AgdGhlIGNvcnJlc3BvbmRpbmcgRGF0YSBNb2RlbHMsIGUuZy4gWUFORyBtb2RlbC4NCg0K ICAgICAgICAgICAgQWdhaW4sIHRoZXNlIGFyZSBiZWluZyBkb25lIGluIG90aGVyIHBsYWNlcyBh bHJlYWR5LiAgV2hhdCBhcmUgeW91IHRyeWluZyB0byBhY2NvbXBsaXNoIGhlcmU/DQoNCg0KDQot ICAgICAgICAgIFNwZWNpZnkgdGhlIHNlY3VyZSBtZWNoYW5pc21zIHRvIGNhcnJ5IHRoZSBjb250 ZW50IGlkZW50aWZpZWQgYnkgdGhlIGluZm9ybWF0aW9uYWwvZGF0YSBtb2RlbHMuIEUuZy4gVExT IHRvIGNhcnJ5IHRoZSBpbmZvcm1hdGlvbi4NCg0KICAgICAgICAgICAgU2luY2Ugd2UgYXJlIHRh bGtpbmcgYWJvdXQgWWFuZyBtb2RlbHMsIEkgYXNzdW1lIHRoZSB0cmFuc3BvcnQvcHJvdG9jb2wg aXMgTmV0Y29uZiBvciBSZXN0Q29uZi4gV2h5IHdvdWxkIHlvdSByZS1zcGVjaWZ5IHRoYXQgVExT L1NTTCBiZSB1c2VkIGZvciBOZXRjb25mIG9yIFJlc3RDb25mPw0KSWYgeW91IHdhbnQgdG8gY2hh bmdlIHNvbWV0aGluZyBpbiB0aG9zZSBwcm90b2NvbHMsIEkgc3VnZ2VzdCB5b3Ugc3RvcCBieSB0 aGUgTmV0Y29uZiBXRy4gIE90aGVyIG9wdGlvbnMgc3VjaCBhcyBTTk1QIGFscmVhZHkgaGF2ZSB0 aGlzIHNwZWNpZmllZCB0b28gaW4gY2FzZSB5b3Ugd2VyZQ0KdGhpbmtpbmcgb2YgZ29pbmcgdGhl cmUuDQoNCg0KIEkyTlNGIFdHIERlbGl2ZXJhYmxlcyBmb3IgdGhlIFNlcnZpY2UgTGF5ZXIgSW50 ZXJmYWNlIGluY2x1ZGU6DQrigKIgICAgICAgRGV2ZWxvcCBwb2xpY3kgZGVzY3JpcHRpb24gKG9y IGxhbmd1YWdlKSBmb3IgY2xpZW50cyBvciBBcHAgR2F0ZXdheSB0byBleHByZXNzL21vbml0b3Ig dGhlIG5lZWRlZCBzZWN1cml0eSBwb2xpY2llcyAoZS5nLiBkZXZlbG9wIGEgc2VjdXJpdHkgcG9s aWN5IGxhbmd1YWdlIGJhc2VkIG9uIE5JU1QgZW5kb3JzZWQgUm9sZSBCYXNlZCBBY2Nlc3MgQ29u dHJvbC4pDQrigJMgICAgICBFLmcuIERldmVsb3AgY29tcHJlaGVuc2l2ZSBzZXQgb2Yg4oCcVEFS R0VUc+KAnSBmb3IgdGhlIFNlY3VyaXR5IEludGVudC4gICBTZWN1cml0eSBUYXJnZXQgaW4gRGF0 YSBDZW50ZXJzIG5ldHdvcmssIGluIEFjY2VzcyBOZXR3b3JrLCBpbiBXaWRlIEFyZWEgbmV0d29y aywgZXRjDQrigJMgICAgICBEZXZlbG9wIGRlc2NyaXB0b3JzIGZvciDigJxVc2Vyc+KAnSwg4oCc Um9sZXPigJ0sIOKAnFBlcm1pc3Npb25z4oCdDQoNCuKAoiAgICAgICBEZXZlbG9wIHRoZSBjb3Jy ZXNwb25kaW5nIGluZm9ybWF0aW9uIG9yIERhdGEgTW9kZWxzLCBlLmcuIFlBTkcgbW9kZWwuDQri gKIgICAgICAgQ29tcGFyZSB3aXRoIGV4aXN0aW5nIElFVEYgcHJvdG9jb2xzIGZvciDigJxSb2xl c+KAnSwg4oCcVXNlcnPigJ0sIOKAnFBlcm1pc3Npb25z4oCdLCBldGMuDQoNCiAgICAgICAgICAg IFdoYXQgd291bGQgc3VjaCBhIHBvbGljeSBkZXNjcmlwdGlvbiBhY2hpZXZlPyAgVGhlcmUgYXJl IGFscmVhZHkgcG9saWN5IG1vZGVscyBvdXQgdGhlcmU6IENvbmdyZXNzIGZyb20gT3BlbnN0YWNr LCBHQlAvSW50ZW50L09ETCwgb3AtbmZ2IHBvbGljeSwgT3AtZmxleCwgZXRjLi4uICAgIERvIHdl IG5lZWQgYW5vdGhlciBvbmU/DQpJJ2QgcmVjb21tZW5kIHRoYXQgeW91IHRha2UgYSBsb29rIGF0 IHRoZSBzaWduaWZpY2FudCB3b3JrIChhbmQgaW1wbGVtZW50YXRpb25zKSB0aGF0IGhhdmUgYmVl biBkb25lIG92ZXIgaW4gdGhvc2UgcGxhY2VzLg0KDQoNCiBJbiBhZGRpdGlvbiwgdGhlIEkyTlNG IHdvcmtpbmcgZ3JvdXAgd2lsbA0K4oCiICAgICAgICBEb2N1bWVudCBhIGhpZ2gtbGV2ZWwgSTJO U0YgZnJhbWV3b3JrIHRoYXQgZGVzY3JpYmVzIFNlcnZpY2VzIGFuZCBDYXBhYmlsaXR5IGxheWVy cyBpbnRlcmZhY2VzIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFsb25nIHdpdGggZnVu Y3Rpb25hbCBjb21wb25lbnRzIGF0IGVhY2ggbGF5ZXIuDQrigJMgICAgICBUZXJtaW5vbG9neSBk cmFmdCBtYXkgYmUgaW5jbHVkZWQgaW4gdGhlIGZyYW1ld29yayBvciBiZWNvbWVzIGEgc3RhbmRh bG9uZSBkcmFmdC4NCg0KICAgICAgICAgICAgV2hhdCB3b3VsZCB5ZXQgYW5vdGhlciAiZnJhbWV3 b3JrIiBhY2hpZXZlPyAgU2VyaW91c2x5LCB3ZSBzaG91bGQgYmUgd29ycmllZCBhYm91dCBidWls ZGluZyB0aGVzZSB0aGluZ3MgcmF0aGVyIHRoYW4gZG9jdW1lbnRpbmcgYWxsIHNvcnRzIG9mIHRo ZW9yZXRpY2FsIHNjZW5hcmlvcy4NCg0KICAgICAgICAgICAgLS1Ub20NCg0KDQoNCg0KDQrigKIg ICAgICAgRG9jdW1lbnQgc21hbGwgYW5kIHdlbGwtc2NvcGVkIHVzZSBjYXNlcyB0byBjb25zdHJh aW4gdGhlIHNjb3BlIG9mIHRoZSB3b3JrIGFuZCBhY2hpZXZlIHN1ZmZpY2llbnQgZm9jdXMgZm9y IHRoZSB3b3JraW5nIGdyb3VwIHRvIGRlbGl2ZXIgc3VjY2Vzc2Z1bCBvdXRjb21lcy4gQW5kDQoN CuKAoiAgICAgICAgQW5hbHl6ZSBjYW5kaWRhdGUgcHJvdG9jb2xzIHRoYXQgbWF5IGNhcnJ5IHRo ZSBpbmZvcm1hdGlvbiB0byBiZSBleGNoYW5nZWQgdGhyb3VnaCB0aGUgdmFyaW91cyBpbnRlcmZh Y2VzLg0K4oCTICAgICAgRS5nLiBDb21wYXJlIHdpdGggZXhpc3RpbmcgSUVURiBwcm90b2NvbHMg Zm9yIOKAnE9CSkVDVHMsIEFDVElPTnMsIEZJTFRFUklORywgZXRj4oCdIChlLmcuIFBDUCwgUmFk aXVzLCBldGMpIC4NCg0KTG9va2luZyBmb3IgY29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zLg0KDQpM aW5kYSBEdW5iYXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCmkycnMgbWFpbGluZyBsaXN0DQppMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pMnJzDQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F645EBD7B1dfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29B Y2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNh bnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt dGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6 YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Ub20sDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPllvdXIgcG9pbnRzIHRha2VuLCB0aGVyZSBhcmUgbWFueSB0eXBl cyBvZiBjb250cm9sbGVycyBpbiBTRE4gcGFyYWRpZ20uIFRocm93aW5nIG9uZSBtb3JlIGNhbiBi ZSBjb25mdXNpbmcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSDigJxzZWN1cml0eSBjb250cm9sbGVy4oCdIGlu IHRoZSBjb250ZXh0IG9mIEkyTlNGIGNhbiBiZSB2aWV3ZWQgYXMgYW4gYWRhcHRlciBiZXR3ZWVu IFNlY3VyaXR5IFNlcnZpY2UgUmVxdWVzdCAoZS5nLiBhbGxvdyB0cmFmZmljIHdpdGggc3BlY2lm aWMgZmllbGRzIGZvcg0KIHNwZWNpZmljIHRpbWUgc3BhbikgYW5kIHRoZSBzZWN1cml0eSBkZXZp Y2Ugc3BlY2lmaWMgaW5mb3JtYXRpb24gbW9kZWwuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB3ZSB3aWxsIGhh dmUgYSAmbmJzcDvigJw8L3NwYW4+cmVmZXJlbmNlIGltcGxlbWVudGF0aW9u4oCdDQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+dG8gbWFrZSB0aGUgZGlzY3Vzc2lv biBtb3JlIGZvY3VzZWQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcywgTGluZGE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBpMnJzIFttYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5UaG9tYXMgRC4gTmFkZWF1PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5 IDAzLCAyMDE1IDg6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IFN1c2FuIEhhcmVzOyBMaW5kYSBEdW5i YXI7IGkybnNmQGlldGYub3JnOyBuZnZyZ0BpcnRmLm9yZzsgaTJyc0BpZXRmLm9yZzsgQmVub2l0 IENsYWlzZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2kycnNdIHJldmlzZWQgY2hhcnRlciBm b3IgSTJOU0Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlNvcnJ5 IGZvciB0aGUgdG9wLXBvc3QuIEkgYW0gbm90IHN1YnNjcmliZWQgdG8gdGhlIGkybnNmIGxpc3Qu ICZuYnNwO1NvbWUgY29tbWVudHMgaW5saW5lIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+SW4gZ2VuZXJhbCBteSBjb21tZW50IG9uIHRoZSBsYXRlc3Qg Y2hhcnRlciBhcmUgdGhhdCBJIGFtIHB1enpsZWQgYXMgdGhlIHBvaW50IG9mIHRoaXMgcHJvcG9z ZWQgV0cgY2hhcnRlciBpcy4gJm5ic3A7IEFueW9uZSB3b3JraW5nIGluIHRoZSBjb250cm9sbGVy IHNwYWNlIHRoZXNlIGRheXMgd2lsbCBiZSBzY3JhdGNoaW5nIHRoZWlyDQogaGVhZCBhcyBJIGhh dmUgYmVlbiBhZnRlciByZWFkaW5nIHRoaXMgY2hhcnRlciBqdXN0IG5vdy4gJm5ic3A7TXkgc3Vn Z2VzdGlvbiBpcyB0aGF0IGlmIHlvdSBpbmRlZWQgd2FudCB0byBlbWJhcmsgb24gdGhlIHdvcmsg ZGVzY3JpYmVkIGJlbG93LCB0aGF0IHlvdSBkbyBpdCB3aXRoaW4gdGhlIGNvbnRleHQgb2Ygc29t ZSByZWZlcmVuY2UgaW1wbGVtZW50YXRpb24gKG1vc3Qgb2YgdGhlIHBvcHVsYXIgb25lcyB3aWxs IHN1ZmZpY2UpIHdoaWNoIG1heSByZXZlYWwNCiBzb21lIG9mIHRoZSBwb2ludHMgSSBhbSByYWlz aW5nIGJlbG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZlYiAzLCAyMDE1Ojc6MzEgQU0sIGF0IDc6MzEgQU0sIFN1c2FuIEhhcmVzICZsdDs8 YSBocmVmPSJtYWlsdG86c2hhcmVzQG5kemguY29tIj5zaGFyZXNAbmR6aC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MaW5kYTo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgZm9yIHlvdXIgZW5j b3VyYWdlbWVudCB0byBzZW5kIGNvbW1lbnRzIG9uIHRoZSBnYXAtYW5hbHlzaXMgYW5kIHRoZSB1 c2UgY2FzZXMgdG8gdGhlIGxpc3QuICZuYnNwOyZuYnNwO0EgZmV3IHN1Z2dlc3Rpb25zIGZvciB0 aGUgc2VxdWVuY2VzIG9mIHlvdXIgY2hhcnRlciBldmVudHM6PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGF0IGdldHRpbmcgdXNlIGNhc2Vz LCBmcmFtZXdvcmsgYW5kIHByb3RvY29sIHJlcXVpcmVtZW50cyBpcyBjcml0aWNhbC4mbmJzcDsg U2luY2UgdGhlIHNlY3VyaXR5IGFyZWEgaGFzIGEgc3Ryb25nIHRlcm1pbm9sb2d5IGRyYWZ0LCBt YXliZSB5b3UgY2FuIGp1c3QNCiBjcmVhdGUgYW4gb25saW5lIHVwZGF0ZSB0byB0aGF0IG9uZS4g Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JTUhPLCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIGEgZ29hbCBvZiB1c2lu ZyBleGlzdGluZyBwcm90b2NvbHMgb3IgZXh0ZW5kaW5nIHRoZXNlIHByb3RvY29scy4mbmJzcDsm bmJzcDsgQWRqdXN0aW5nIHlvdXIgY2hhcnRlciB0byBpbmRpY2F0ZSB0aGlzIGF0IGV2ZXJ5IHN0 ZXANCiB3b3VsZCBwcmV2ZW50IGR1cGxpY2F0aW9uIG9mIElFVEYgd29yayBhbmQgaW5jcmVhc2Ug dGhlIHNwZWVkIG9mIGRldmVsb3BtZW50IG9mIHlvdXIgcHJvdG9jb2wuPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGNhcGFiaWxpdHkgKG9yIGZ1bmN0 aW9uYWwpIGxheWVyIGJldHdlZW4gY29udHJvbGxlciBhbmQgbmV0d29yayBkZXZpY2VzIG1heSBi ZSBhYmxlIHRvIGxldmVyYWdlIGV4aXN0aW5nIHByb3RvY29scyBpbiBTQUNNLCBBQUEsIHJ0Z3dn LCBuZXRtb2QsIG5ldGNvbmYvcmVzdGNvbmYsDQogb3Igb3RoZXIgcHJvdG9jb2xzLiZuYnNwOyBP ciBpdCBtYXkgYmUgYWJsZSB0byBiZSBhIGNvbWJpbmF0aW9uIG9mIHRoZXNlIHByb3RvY29scy4g Jm5ic3A7SW5zdGVhZCBvZiBpbiBhZGRpdGlvbiwgdGhlIFdHIHNob3VsZCBjb25zaWRlciB0aGlz IGF0IHRoZSBiZWdpbm5pbmcuJm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+TWFraW5nIGEgZGVjaXNpb24gb24gd2hhdCB0eXBlIG9mIHNl cnZpY2UtYmFzZWQgaW50ZXJmYWNlIGlzIGltcG9ydGFudCBkdXJpbmcgdGhlIGZyYW1ld29yay4m bmJzcDsgSWYgeW91IHdpc2ggYW4gaW50ZW50LWJhc2VkIGFwcGxpY2F0aW9uIGRyaXZlbiBpbnRl cmZhY2UsIHRoaXMNCiBtYXkgYmUgZGlmZmVyZW50IHRoYW4gdGhlIGludGVudCBiYXNlZCBvciBj b21wcmVoZW5zaXZlIEFQSS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5TdWU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+aTJycw0KIFs8YSBocmVmPSJtYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86aTJycy1ib3VuY2VzQGlldGYub3Jn PC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L2I+TGluZGEgRHVuYmFyPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgRmVicnVhcnkgMDIs IDIwMTUgNzowOSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5pMm5zZkBpZXRmLm9yZzwvc3Bhbj48L2E+PGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86bmZ2cmdAaXJ0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm5mdnJnQGlydGYub3JnPC9zcGFuPjwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5pMnJzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ W2kycnNdIHJldmlzZWQgY2hhcnRlciBmb3IgSTJOU0Y8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJhc2VkIG9uIHRoZSByZWNl bnQgZGlzY3Vzc2lvbiBvbiB0aGUgSTJOU0YgbGlzdCwgaGVyZSBpcyB0aGUgcmV2aXNlZCBjaGFy dGVyIGZvciBJMk5TRi4gQ29waWVkIHRvIEkyUlMgZ3JvdXAgdG8gZ2V0IHdpZGVyIHJldmlldyBi ZWNhdXNlIEkyTlNGIGlzIHJlbGF0ZWQgdG8gSTJSUyBpbiBzdWNoDQogYSB3YXkgdGhhdCAmbmJz cDtJMlJTIHByb3ZpZGVzIHRoZSBpbnRlcmZhY2UgdG8gUm91dGVyIHdoZXJlYXMgSTJOU0YgcHJv dmlkZXMgdGhlIGludGVyZmFjZXMgdG8gc2VjdXJpdHkgZnVuY3Rpb25zLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWJvdHRvbTpz b2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW4gYSBudXRzaGVsbCwgVGhlIEludGVyZmFjZSB0byBOZXR3 b3JrIFNlY3VyaXR5IEZ1bmN0aW9ucyAoSTJOU0YpIGlzIHRvIGRpc2N1c3MgaW50ZXJmYWNlcyBm b3IgY2xpZW50cyBvciBhcHBsaWNhdGlvbiBnYXRld2F5cyB0byBjb21tdW5pY2F0ZQ0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5JcyB0aGUgcHVycG9zZSBoZXJlIHRvICZxdW90O2Rpc2N1c3MmcXVvdDsgb3Ig dG8gJnF1b3Q7Y3JlYXRlJnF1b3Q7IGludGVyZmFjZXM/ICZuYnNwO0lmIGl0IGlzIHRoZSBmb3Jt ZXIsIEkgYW0gbm90IHN1cmUgd2hhdCB0aGUgcG9pbnQgb2YgdGhlIFdHIHdvdWxkIGJlLiBJZiB0 aGUgbGF0dGVyLCB0aG9zZSB0aGluZ3MgYmVpbmcgZG9uZSBpbiBvdGhlciBXR3MgYWNyb3NzDQog dGhlIHJvdXRpbmcgYXJlYSBvciBvdXRzaWRlIG9mIHRoZSBJRVRGIGFscmVhZHkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPnRoZWlyIHNwZWNpZmljIHNlY3VyaXR5IHBvbGljaWVzIChyZXF1ZXN0 L21vbml0b3IvcmVwb3J0KSB3aXRoIHNlY3VyaXR5IGNvbnRyb2xsZXIgYW5kIHNlY3VyaXR5IGZ1 bmN0aW9ucy4mbmJzcDsgSTJOU0Ygd2lsbCBzcGVjaWZ5IHRoZSBpbmZvcm1hdGlvbiBtb2RlbCwg YWxvbmcgd2l0aCBhZGVxdWF0ZQ0KIGRhdGEgbW9kZWxzLCBhbmQgcHJvdG9jb2xzIHJlcXVpcmVk IGZvciB0aGUgT3BlcmF0aW9uLCBBZG1pbmlzdHJhdGlvbiwgTWFpbnRlbmFuY2UgYW5kIFByb3Zp c2lvbmluZyAoT0FNKSBmb3IgdGhlIGZvbGxvd2luZyBzZWN1cml0eSBmdW5jdGlvbnM6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouOGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxh bmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZpcmV3YWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouOGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkRET1MvQW50aS1ET1M8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouOGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW4iPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpTeW1ib2wiPsK3PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkludHJ1c2lvbg0KIERl dGVjdGlvbiBTeXN0ZW0vIEludHJ1c2lvbiBQcmV2ZW50aW9uIFN5c3RlbSAoSURTL0lQUyk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi44aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+ wrc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t R0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QWNjZXNzDQogY29udHJvbC9BdXRob3JpemF0aW9u L0F1dGhlbnRpY2F0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIGFyZSB0d28gZGlzdGluY3QgaW50ZXJm YWNlcyBmb3IgSTJOU0Y6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Q2FwYWJpbGl0eSAob3IN CiBGdW5jdGlvbmFsKSBMYXllciBpbnRlcmZhY2UgYmV0d2VlbiBTZWN1cml0eSBDb250cm9sbGVy LCB3aGljaCBjb3VsZCBiZSBlbWJlZGRlZCBpbiBhIG5ldHdvcmsgY29udHJvbGxlciwgYW5kIFNl Y3VyaXR5IGRldmljZXMgKHZpcnR1YWwgJmFtcDsgcGh5c2ljYWwpLCB3aGljaCBmb2N1c2VzIG1v cmUgb24gdGhlIGZ1bmN0aW9uYWwgYXNwZWN0cyBvZiB0aGUgZnVuY3Rpb25zIGxpc3RlZCBhYm92 ZS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5ObyBz dWNoIGxheWVyIGlzIG5lZWRlZC4gVGFrZSBhIGxvb2sgYXQgdGhlIGNvbW1lcmNpYWwgY29udHJv bGxlcnMgdGhhdCBhcmUgb3V0IHRoZXJlIGFuZCB5b3Ugd2lsbCBzZWUgdGhhdCBpdHMgYSBwYXJ0 IG9mIHRoZSBwcm90b2NvbHMgYWxyZWFkeSwgb3IgcGVvcGxlIHJlLXVzZSBleGlzdGluZyAod2Vs bCBkZXNpZ25lZCkgc3lzdGVtcw0KIHN1Y2ggYXMgUkFESVVTLCBldGMuLi4uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+U2VydmljZSBMYXllcg0KIEludGVyZmFjZSBiZXR3ZWVu IENsaWVudHMgKG9yIEFwcCBHYXRld2F5KSBhbmQgdGhlIFNlY3VyaXR5IENvbnRyb2xsZXIsICZu YnNwO3doaWNoIGlzIGZvciBjbGllbnRzIG9yIEFwcCBHYXRld2F5IHRvIGV4cHJlc3MvbW9uaXRv ciB0aGUgbmVlZGVkIHNlY3VyaXR5IHBvbGljaWVzIChlLmcuIGRldmVsb3AgYSBzZWN1cml0eSBw b2xpY3kgbGFuZ3VhZ2UgYmFzZWQgb24gTklTVCBlbmRvcnNlZCBSb2xlIEJhc2VkIEFjY2VzcyBD b250cm9sLik8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPldoYXQgd291bGQgYSAmcXVvdDtzZXJ2aWNlIGxheWVyIGludGVyZmFjZSZxdW90 OyBiZT8gJm5ic3A7VG9kYXkgY29udHJvbGxlcnMgbGlrZSBPcGVuRGF5bGlnaHQgdXNlIFJlc3RD b25mIGFuZCBOZXRDb25mLiBUaG9zZSBhcmUgcGVyZmVjdGx5IHdlbGwgc3BlY2lmaWVkIGludGVy ZmFjZXMgdGhhdCBjb21lIHdpdGggdmFyaW91cyBzZWN1cml0eSBtZWNoYW5pc21zDQogYnVpbHQt aW4gcmlnaHQgb3V0IG9mIHRoZSBib3guICZuYnNwO1doYXQgZWxzZSBpcyBuZWVkZWQ/ICZuYnNw O0lmIHlvdSBjbGFpbSB5b3Ugd2FudCB0byBwdXQgUkFESVVTIG9yIEFBQSBvciBzb21ldGhpbmcg ZWxzZSBpbiB0aGVyZSwgdGhhdCBpcyBkb25lIGFzIGEgc2lkZSBhY3Rpb24gd2l0aGluIHRoZSBj b250ZXh0IG9mIHRob3NlIHRoaW5ncyBhbHJlYWR5LiAmbmJzcDtUaGlzIGFscmVhZHkgd29ya3Mg QlRXLCBzbyBhZ2FpbiwgSSBhbSBub3Qgc3VyZSB3aGF0IHdvdWxkDQogYmUgYWNoaWV2ZWQgaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtJMk5TRiBXRyBEZWxpdmVyYWJsZXMgZm9yIHRoZSBG dW5jdGlvbmFsL0NhcGFiaWxpdHkgTGF5ZXIgSW50ZXJmYWNlIGluY2x1ZGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EZXZlbG9wIGEgY29tcHJlaGVuc2l2ZQ0KIHNldCBvZiBp bmZvcm1hdGlvbmFsIE1vZGVscyBmb3IgdGhlIGZvbGxvd2luZyBmdW5jdGlvbnMgd2l0aCByZWdh cmQgdG8gZGlmZmVyZW50IGFzcGVjdHMgb2YgT0FNIChPcGVyYXRpb25zL0FkbWluaXN0cmF0aW9u L01haW50ZW5hbmNlKS4gRm9yIGV4YW1wbGU6IGV4dGVuZGluZyB0aGUgQUNMIGRhdGEgbW9kZWwg dG8gYmUgbW9yZSBjb21wcmVoZW5zaXZlLCBlLmcuICZuYnNwO2luY2x1ZGluZyBtdWx0aXBsZSBh Y3Rpb25zIGFuZCBwb2xpY2llcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZpcmV3 YWxsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RERPUy9BbnRpLURPUzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkludHJ1c2lvbiBEZXRlY3Rpb24gU3lzdGVtLyBJbnRydXNpb24NCiBQcmV2ZW50aW9u IFN5c3RlbSAoSURTL0lQUyk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRldmVs b3AgdGhlIGNvcnJlc3BvbmRpbmcNCiBEYXRhIE1vZGVscywgZS5nLiBZQU5HIG1vZGVsLjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BZ2FpbiwgdGhlc2UgYXJlIGJl aW5nIGRvbmUgaW4gb3RoZXIgcGxhY2VzIGFscmVhZHkuICZuYnNwO1doYXQgYXJlIHlvdSB0cnlp bmcgdG8gYWNjb21wbGlzaCBoZXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNwZWNpZnkg dGhlIHNlY3VyZQ0KIG1lY2hhbmlzbXMgdG8gY2FycnkgdGhlIGNvbnRlbnQgaWRlbnRpZmllZCBi eSB0aGUgaW5mb3JtYXRpb25hbC9kYXRhIG1vZGVscy4gRS5nLiBUTFMgdG8gY2FycnkgdGhlIGlu Zm9ybWF0aW9uLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5TaW5j ZSB3ZSBhcmUgdGFsa2luZyBhYm91dCBZYW5nIG1vZGVscywgSSBhc3N1bWUgdGhlIHRyYW5zcG9y dC9wcm90b2NvbCBpcyBOZXRjb25mIG9yIFJlc3RDb25mLiZuYnNwO1doeSB3b3VsZCB5b3UgcmUt c3BlY2lmeSB0aGF0IFRMUy9TU0wgYmUgdXNlZCBmb3IgTmV0Y29uZiBvciBSZXN0Q29uZj8gJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J ZiB5b3Ugd2FudCB0byBjaGFuZ2Ugc29tZXRoaW5nIGluIHRob3NlIHByb3RvY29scywgSSBzdWdn ZXN0IHlvdSBzdG9wIGJ5IHRoZSBOZXRjb25mIFdHLiAmbmJzcDtPdGhlciBvcHRpb25zIHN1Y2gg YXMgU05NUCBhbHJlYWR5IGhhdmUgdGhpcyBzcGVjaWZpZWQgdG9vIGluIGNhc2UgeW91IHdlcmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoaW5r aW5nIG9mIGdvaW5nIHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0kyTlNGIFdHIERlbGl2 ZXJhYmxlcyBmb3IgdGhlIFNlcnZpY2UgTGF5ZXIgSW50ZXJmYWNlIGluY2x1ZGU6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpbmUtaGVp Z2h0LWFsdDo4LjQ1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAojwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGV2ZWxvcA0KIHBvbGljeSBkZXNjcmlw dGlvbiAob3IgbGFuZ3VhZ2UpIGZvciBjbGllbnRzIG9yIEFwcCBHYXRld2F5IHRvIGV4cHJlc3Mv bW9uaXRvciB0aGUgbmVlZGVkIHNlY3VyaXR5IHBvbGljaWVzIChlLmcuIGRldmVsb3AgYSBzZWN1 cml0eSBwb2xpY3kgbGFuZ3VhZ2UgYmFzZWQgb24gTklTVCBlbmRvcnNlZCBSb2xlIEJhc2VkIEFj Y2VzcyBDb250cm9sLik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpbmUtaGVpZ2h0LWFsdDo4LjQ1cHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPuKAkzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RS5nLg0K IERldmVsb3AgY29tcHJlaGVuc2l2ZSBzZXQgb2Yg4oCcVEFSR0VUc+KAnSBmb3IgdGhlIFNlY3Vy aXR5IEludGVudC4mbmJzcDsmbmJzcDsgU2VjdXJpdHkgVGFyZ2V0IGluIERhdGEgQ2VudGVycyBu ZXR3b3JrLCBpbiBBY2Nlc3MgTmV0d29yaywgaW4gV2lkZSBBcmVhIG5ldHdvcmssIGV0YzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlu ZS1oZWlnaHQtYWx0OjguNDVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+4oCTPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZXZlbG9wDQogZGVzY3JpcHRvcnMgZm9y IOKAnFVzZXJz4oCdLCDigJxSb2xlc+KAnSwg4oCcUGVybWlzc2lvbnPigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpbmUt aGVpZ2h0LWFsdDo4LjQ1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAojwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGV2ZWxvcA0KIHRoZSBjb3JyZXNw b25kaW5nIGluZm9ybWF0aW9uIG9yIERhdGEgTW9kZWxzLCBlLmcuIFlBTkcgbW9kZWwuPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saW5lLWhlaWdodC1h bHQ6OC40NXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKI8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvbXBhcmUNCiB3aXRoIGV4aXN0aW5nIElFVEYg cHJvdG9jb2xzIGZvciDigJxSb2xlc+KAnSwg4oCcVXNlcnPigJ0sIOKAnFBlcm1pc3Npb25z4oCd LCBldGMuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPldoYXQgd291 bGQgc3VjaCBhIHBvbGljeSBkZXNjcmlwdGlvbiBhY2hpZXZlPyAmbmJzcDtUaGVyZSBhcmUgYWxy ZWFkeSBwb2xpY3kgbW9kZWxzIG91dCB0aGVyZTogQ29uZ3Jlc3MgZnJvbSBPcGVuc3RhY2ssIEdC UC9JbnRlbnQvT0RMLCBvcC1uZnYgcG9saWN5LCBPcC1mbGV4LCBldGMuLi4gJm5ic3A7ICZuYnNw O0RvIHdlIG5lZWQgYW5vdGhlciBvbmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2QgcmVjb21tZW5kIHRoYXQgeW91IHRha2UgYSBsb29rIGF0 IHRoZSBzaWduaWZpY2FudCB3b3JrIChhbmQgaW1wbGVtZW50YXRpb25zKSB0aGF0IGhhdmUgYmVl biBkb25lIG92ZXIgaW4gdGhvc2UgcGxhY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0luIGFk ZGl0aW9uLCB0aGUgSTJOU0Ygd29ya2luZyBncm91cCB3aWxsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpbmUtaGVpZ2h0LWFsdDo4LjQ1 cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7RG9jdW1lbnQNCiBhIGhpZ2gtbGV2ZWwgSTJOU0Yg ZnJhbWV3b3JrIHRoYXQgZGVzY3JpYmVzIFNlcnZpY2VzIGFuZCBDYXBhYmlsaXR5IGxheWVycyBp bnRlcmZhY2VzIGFuZCBkZWZpbmVzIGEgcmVmZXJlbmNlIG1vZGVsIGFsb25nIHdpdGggZnVuY3Rp b25hbCBjb21wb25lbnRzIGF0IGVhY2ggbGF5ZXIuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGluZS1oZWlnaHQtYWx0OjguNDVwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+4oCTPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5UZXJtaW5vbG9neQ0KIGRyYWZ0IG1heSBiZSBpbmNsdWRlZCBpbiB0aGUgZnJhbWV3b3JrIG9y IGJlY29tZXMgYSBzdGFuZGFsb25lIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPldoYXQgd291bGQgeWV0IGFub3RoZXIgJnF1b3Q7ZnJhbWV3 b3JrJnF1b3Q7IGFjaGlldmU/ICZuYnNwO1NlcmlvdXNseSwgd2Ugc2hvdWxkIGJlIHdvcnJpZWQg YWJvdXQgYnVpbGRpbmcgdGhlc2UgdGhpbmdzIHJhdGhlciB0aGFuIGRvY3VtZW50aW5nIGFsbCBz b3J0cyBvZiB0aGVvcmV0aWNhbCBzY2VuYXJpb3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj4tLVRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGluZS1oZWlnaHQtYWx0OjguNDVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+4oCiPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5E b2N1bWVudA0KIHNtYWxsIGFuZCB3ZWxsLXNjb3BlZCB1c2UgY2FzZXMgdG8gY29uc3RyYWluIHRo ZSBzY29wZSBvZiB0aGUgd29yayBhbmQgYWNoaWV2ZSBzdWZmaWNpZW50IGZvY3VzIGZvciB0aGUg d29ya2luZyBncm91cCB0byBkZWxpdmVyIHN1Y2Nlc3NmdWwgb3V0Y29tZXMuIEFuZDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjI1aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdodC1hbHQ6OC40NXB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saW5lLWhlaWdodC1hbHQ6OC40NXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwO0FuYWx5emUNCiBjYW5kaWRhdGUgcHJvdG9jb2xzIHRo YXQgbWF5IGNhcnJ5IHRoZSBpbmZvcm1hdGlvbiB0byBiZSBleGNoYW5nZWQgdGhyb3VnaCB0aGUg dmFyaW91cyBpbnRlcmZhY2VzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVu dDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPuKAkzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5FLmcuIENvbXBhcmUgd2l0aCBleGlzdGluZw0KIElFVEYg cHJvdG9jb2xzIGZvciDigJxPQkpFQ1RzLCBBQ1RJT05zLCBGSUxURVJJTkcsIGV0Y+KAnSAoZS5n LiBQQ1AsIFJhZGl1cywgZXRjKSAuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkxvb2tpbmcgZm9yIGNvbW1lbnRzIGFuZCBzdWdn ZXN0aW9ucy48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkxpbmRhIER1bmJhcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCmkycnMgbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFu PjxhIGhyZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjgu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnB1cnBsZSI+aTJyc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaTJycyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F645EBD7B1dfweml701chm_-- From nobody Wed Feb 4 08:25:24 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 8467B1A0451; Wed, 4 Feb 2015 08:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X68zoLEaErYq; Wed, 4 Feb 2015 08:25:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28031A0065; Wed, 4 Feb 2015 08:25:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOT81744; Wed, 04 Feb 2015 16:25:15 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 16:25:14 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 08:25:10 -0800 From: Linda Dunbar To: Russ White , "'Susan Hares'" , "i2nsf@ietf.org" Thread-Topic: [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAAIyhYAAJ0n7UA== Date: Wed, 4 Feb 2015 16:25:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> In-Reply-To: <022c01d03fb6$27037480$750a5d80$@riw.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] revised charter for I2NSF 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, 04 Feb 2015 16:25:19 -0000 Russ,=20 Thank you very much for the suggestion of framing in terms of services. Wha= t do you think with the following changes to the I2NSF charter with your su= ggestions added? In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate = their specific security policies (request/monitor/report) to security funct= ions. I2NSF will specify a vNSF framework, requirements for programmatic i= nterface to vNSF devices (configuration and dynamic programmatic) , and I= nformation and Data models for security functions' Operation, Administratio= n, Maintenance and Provisioning (OAM). The information models will include= the following security functions: * Firewall=20 including various services associated with FW, such as stateful or deep pa= cket inspection, packet/flow/stream filtering and redirect (remote and loc= al), etc * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) Including intrusion detection (flow/stream pattern matching) Linda -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Tuesday, February 03, 2015 7:35 AM To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org Cc: nfvrg@irtf.org; i2rs@ietf.org Subject: Re: [i2rs] revised charter for I2NSF Interesting concept. One thought that might be helpful --=20 > * Firewall > * DDOS/Anti-DOS > * Intrusion Detection System/ Intrusion Prevention System > (IDS/IPS) > * Access control/Authorization/Authentication I think I would try to frame things in terms of services, rather than devic= es, or a mix of the two. For instance -- what does a "firewall" really do? = Stateful packet inspection, deep packet inspection, and... ?? So maybe a li= st something like this might make sense -- (and remember, this is brainstor= ming, nothing more) -- - Stateful packet inspection - Deep packet inspection - Packet/flow/stream filtering (remote and local) - Packet/flow/stream redirect (remote and local) - Intrusion detection (or perhaps flow/stream pattern matching?) - AAA Don't know if this is a useful line of thought or not. :-) Russ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Feb 4 08:37:10 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 940961A1A9B; Wed, 4 Feb 2015 08:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 AiJs1oeMGrQL; Wed, 4 Feb 2015 08:37:05 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 416311A0469; Wed, 4 Feb 2015 08:37:05 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id AA1432DC5F4B; Wed, 4 Feb 2015 11:37:04 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> Date: Wed, 4 Feb 2015 11:37:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Russ White , "i2nsf@ietf.org" , "nfvrg@irtf.org" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] revised charter for I2NSF 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, 04 Feb 2015 16:37:06 -0000 > On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar = wrote: >=20 > Russ,=20 >=20 > Thank you very much for the suggestion of framing in terms of = services. What do you think with the following changes to the I2NSF = charter with your suggestions added? >=20 > In a nutshell, The Interface to vNSF (I2NSF) allows clients to = communicate their specific security policies (request/monitor/report) to = security functions. I2NSF will specify a vNSF framework, requirements = for programmatic interface to vNSF devices (configuration and dynamic = programmatic) , and Information and Data models for security = functions' Operation, Administration, Maintenance and Provisioning = (OAM). The information models will include the following security = functions: Why wouldn't you do the models for those OAM functions where = those functions are modeled already? I don't see the need for a special = WG that creates a subset of models that can done elsewhere like in LIME, = or the Routing Area groups that are already chartered to do this stuff. =20= This leaves just doing requirements and a framework for this = proposed group, which without clear goals to build things from is a WG = looking for a reason to exist rather than the other way around. --Tom >=20 > * Firewall=20 > including various services associated with FW, such as stateful = or deep packet inspection, packet/flow/stream filtering and redirect = (remote and local), etc >=20 > * Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) > Including intrusion detection (flow/stream pattern matching) >=20 >=20 > Linda >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White > Sent: Tuesday, February 03, 2015 7:35 AM > To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org > Cc: nfvrg@irtf.org; i2rs@ietf.org > Subject: Re: [i2rs] revised charter for I2NSF >=20 >=20 > Interesting concept. One thought that might be helpful --=20 >=20 >> * Firewall >> * DDOS/Anti-DOS >> * Intrusion Detection System/ Intrusion Prevention System >> (IDS/IPS) >> * Access control/Authorization/Authentication >=20 > I think I would try to frame things in terms of services, rather than = devices, or a mix of the two. For instance -- what does a "firewall" = really do? Stateful packet inspection, deep packet inspection, and... ?? = So maybe a list something like this might make sense -- (and remember, = this is brainstorming, nothing more) -- >=20 > - Stateful packet inspection > - Deep packet inspection > - Packet/flow/stream filtering (remote and local) > - Packet/flow/stream redirect (remote and local) > - Intrusion detection (or perhaps flow/stream pattern matching?) > - AAA >=20 > Don't know if this is a useful line of thought or not. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Wed Feb 4 10:20:38 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 067471A1AFB for ; Wed, 4 Feb 2015 10:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 8Nqsu29u8aSb for ; Wed, 4 Feb 2015 10:20:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84991A1AB6 for ; Wed, 4 Feb 2015 10:20:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSC73517; Wed, 04 Feb 2015 18:20:29 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 18:20:28 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 10:20:23 -0800 From: Linda Dunbar To: "i2rs@ietf.org" , "nfvrg@irtf.org" Thread-Topic: further trimed the I2NSF charter, with the timeline for deliverables added Thread-Index: AdBAo0gI2/188IUISWqDNnilr7PkdQAAYFEg Date: Wed, 4 Feb 2015 18:20:22 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBE528@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EBE528dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added 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, 04 Feb 2015 18:20:36 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EBE528dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I2RSers and NFVRGers, Appreciate your comments to the further trimmed I2NSF charter. Please copy your comments to I2NSF@ietf.org Thanks, Linda From: Linda Dunbar Sent: Wednesday, February 04, 2015 11:52 AM To: 'Kathleen Moriarty'; i2nsf@ietf.org Cc: 'Romascanu, Dan (Dan)'; Joseph Salowey Subject: further trimed the I2NSF charter, with the timeline for deliverabl= es added Kathleen, Thank you very much for the I2NSF BOF preparation call yesterday and the su= ggestion of further narrowing the scope. With Dan Romascanu's help, we further trimmed down the scope of I2NSF to ma= ke the charter more focused. We also incorporated the comments received from the I2NSF mailing list. Here is the revised charter, with the timeline for the deliverables added. Comments and suggestions are greatly appreciated. Thanks, Linda Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially the network security related functions that ar= e not running on their premises. The ETSI Network Function Virtualization = (NFV) initiative brings out another management challenges for security poli= cies to be enforced by distributed (virtual) network security functions (vN= SF). Those trends require a standard interface to express, monitor, and man= age the security policies on distributed security functions that may be run= ning on different premises. vNSF devices include two functional layers: - Security Policy Layer, which is for clients to express & monitor= the needed security policies for their specific flows. This layer will le= verage the existing protocols in RESTconf, AAA, SACM, and security policy e= xpression using Role Based Access Control (RBAC), Mandatory Access Control = (MAC), or Attribute-based access control (ABAC). - Capability (or Functional) Layer, which specifies the informatio= n/data models to Security functions/devices (virtual & physical). This laye= r will leverage the existing protocols and data models defined by I2RS, Net= conf, and NETMOD. In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate = their specific security policies (request/monitor/report) to security funct= ions. I2NSF will specify a vNSF framework, requirements for programmatic i= nterface to vNSF devices (configuration and dynamic programmatic)[L1] ,= and Information and Data models for security functions' Operation, Adminis= tration, Maintenance and Provisioning (OAM). The information models will i= nclude the following security functions: * Firewall including various services associated with FW, such as stateful or deep pac= ket inspection, packet/flow/stream filtering and redirect (remote and loca= l), etc * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) Including intrusion detection (flow/stream pattern matching) It is a non-goal to create new protocols or data models for I2NSF interface= s. I2NSF WG Deliverables - Use Case document - the WG will decide in a later phase if this = document will become an Informational RFC, or will just be used as a refere= nce during the WG lifetime - Framework Document - the WG will decide in a later phase if this= document will become an Informational RFC, or will just be used as a refer= ence during the WG lifetime - Requirement for extensions (if there are any) to existing protoc= ols at security layer and capability - the WG will decide in a later phase = if this document will become an Informational RFC, or will just be used as = a reference during the WG lifetime - Gap analysis of existing protocols and data modeling language - Information Models for the security functions listed above and a= ssociated capabilities. - Corresponding Data Models (e.g. YANG model). - (Optionally) Applicability Statements on how to use I2RS, Netc= onf, and NETMOD to carry the specified information/data models. Suggested Milestones - Use Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 mont= hs to WG document - Info models: Charter time + 8 months to WG Document - All Early Drafts to IESG: 10 months [decision point - +10 months] - Data Models: Charter + 9 Months to WG Document - Applicability Statements: 10 months to WG Document - Data Models and Applicability Statements to IESG - 16 months The WG will work closely with I2RS, Netconf and Netmod WGs. ________________________________ The framework, that describes the reference points and functional componen= ts, is to make the discussion more focused. Is it better to be left out to emphasize the final deliverables? --_000_4A95BA014132FF49AE685FAB4B9F17F645EBE528dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RSers and NFVRGers, =

 

Appreciate your commen= ts to the further trimmed I2NSF charter.

 

Please copy your comme= nts to I2NSF@ietf.org

 

Thanks, Linda

 

From: Linda Du= nbar
Sent: Wednesday, February 04, 2015 11:52 AM
To: 'Kathleen Moriarty'; i2nsf@ietf.org
Cc: 'Romascanu, Dan (Dan)'; Joseph Salowey
Subject: further trimed the I2NSF charter, with the timeline for del= iverables added

 

Kathleen,

 

Thank you very much for the I2NSF BOF preparation ca= ll yesterday and the suggestion of further narrowing the scope.

 

With Dan Romascanu’s help, we further trimmed = down the scope of I2NSF to make the charter more focused.

 

We also incorporated the comments received from the = I2NSF mailing list.

 

Here is the revised charter, with the timeline for t= he deliverables added.

Comments and suggestions are greatly appreciated.

 

Thanks, Linda

 

 

Enterprises, residential, and mobile cust= omers are increasingly consuming network functions, especially the network = security related functions that are not running on their premises.  The ETSI Network Function Virtualization (NFV) initiative = brings out another management challenges for security policies to be enforc= ed by distributed (virtual) network security functions (vNSF). Those trends= require a standard interface to express, monitor, and manage the security policies on distributed security function= s that may be running on different premises.

 

vNSF devices include two functional layer= s:

- &n= bsp;        Security Policy Layer, which is for clients to express & monitor the n= eeded security policies for their specific flows.  This layer will lev= erage the existing protocols in RESTconf, AAA, SACM, and security policy expression using Role Based Access Control (RBAC= ), Mandatory Access Control (MAC), or Attribute-based access control (ABAC)= .

=  

- &n= bsp;        Capability (or Functional) Layer, which specifies the information/data mod= els to Security functions/devices (virtual & physical). This layer will= leverage the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

In a nutshell, The Interface to vNSF (I2N= SF) allows clients to communicate their specific security policies (request= /monitor/report) to security functions.  I2NSF= will specify a vNSF framework, requirements for programmatic interface to = vNSF devices (configuration and dynamic programmatic)[L1]   =   = , and Information and Data models for security functions’ Operation, A= dministration, Maintenance and Provisioning (OAM).  The information mo= dels will include the following security functions:

 

·     =   Firewall

·     =   Intrusion Detection System/ Intrusion Prevention System (ID= S/IPS)

 

It is a non-goal to create new protocols = or data models for I2NSF interfaces. 

=  

I2NSF WG Deliverables

- &n= bsp;        Use Case document – the WG will decide in a later phase if this docu= ment will become an Informational RFC, or will just be used as a reference = during the WG lifetime

- &n= bsp;        Framework Document – the WG will decide in a later phase if this doc= ument will become an Informational RFC, or will just be used as a reference= during the WG lifetime

- &n= bsp;        Requirement for extensions (if there are any) to existing protocols at sec= urity layer and capability – the WG will decide in a later phase if t= his document will become an Informational RFC, or will just be used as a reference during the WG lifetime=

- &n= bsp;        Gap analysis of existing protocols and data modeling language

- &n= bsp;        Information Models for the security functions listed above and associated = capabilities.

- &n= bsp;        Corresponding Data Models (e.g. YANG model).

- &n= bsp;         (Optionally)  Applicability Statements on how to use I2RS, Netc= onf, and NETMOD to carry the specified information/data models.

 

Suggested M= ilestones

-Use Document:  Charter time + 1 month to WG Docu= ment

-Framework: Charter time + 4 months to WG Document

-Requirements for extensions to protocols:  Charter t= ime + 6 months to WG document

-Info models: Charter time + 8 months to WG Document

-All Early Drafts to IESG: 10 months

[decision poin= t – +10 months]  

-Data Models: Charter + 9 Months to WG Document

-Applicability Statements: 10 months to WG Document

-Data Models and Applicability Statements to IESG  - = 16 months

 

The WG will work closely with I2RS, Netconf and Netmod WGs.

 

 The framework, that describes the reference points and= functional components, is to make the discussion more focused. 

 

Is it better to be left out to emphasize the fi= nal deliverables?

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645EBE528dfweml701chm_-- From nobody Wed Feb 4 10:28:21 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 0859F1A1AE3 for ; Wed, 4 Feb 2015 10:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.487 X-Spam-Level: *** X-Spam-Status: No, score=3.487 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.795, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vzRS1MQShIUr for ; Wed, 4 Feb 2015 10:28:20 -0800 (PST) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD56D1A00F3 for ; Wed, 4 Feb 2015 10:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1423074499; bh=Nx/m62u6ccd/f/9hMghUunfwOIayWy3EGrKADvymJ6o=; h=Date:Subject:From:To:CC:From:Subject; b=RZfkiwYFDWroaLZ/t9yOLUtS47iaTF0wyyQ3Q/TWofoE/0tQeycUqWypM4K7HzJwZLku9y+jlmC0oyGad0kJR7mJz4k/V0tRxR75unuIx7e1XscdHTJ0xzqTCZ/r+H7eBeBayQBnjV5p763NhZXQat0M2bcmX8J+BUOHDHrdsKLAHKsJlDlYwuLTckiFlLAiF1K2bVo7hRxKMByecY1V3fZYkoagYy+R5wz883X5rnsi47tGCg2xOtVljo6rlwOeVStux1k/EGLbF0vMSNzVADx6nvTXvtglrg82Tfy6+nfQCHKcoe1O8mYdD+HNKrMPkyn4e5Z1P8YNRc1KAz8ECg== Received: from [98.139.215.140] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 18:28:19 -0000 Received: from [68.142.230.74] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 18:28:18 -0000 Received: from [127.0.0.1] by smtp231.mail.bf1.yahoo.com with NNFMP; 04 Feb 2015 18:28:18 -0000 X-Yahoo-Newman-Id: 982167.80297.bm@smtp231.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: t7vis9MVM1li9slGAnoT2naPFNE0GTGyVxJL85LpavMBXAT j51NdXe_.kLxkGM3q4JtyWDdJYUW3WOEs_lkBicJ30SStoLsrS6iBt_LW8FB 17HTgv6xp45tYs.tJwe1gjDMitEWEt2XKEK_7A01t3UA8Ee5CAiXbnQ8BVxs g1Pzc9oqG_a5vhbsjUuRpjITgZjThCKkhE3jGTd7ovVC9k0Nf.azEsqjJ_dE WcNDcHwDirEWF7eRwZD5CiMj.Mmh3otGJcaWYbJKW8rYj4nI1c1WfoFs06ZN 0yMDx5P8pcT5vYMb.mxDoqp_lrnHfUWQhkAO7AEZja_qtInsR0UNdlQvQlXM m8KbLObi3D2uarF2xYbR47oC8X4b5f11ZbcRQnVHUWu5YW.kBL.nBAjaTM3L t8INfBJ8WAWSxXYsC3Soq1GfKHl4955MjryP.Xmlvx3OAMlJdFutZ_DV2pha 65lftnjfSwAulsASRb.5mYkdxrD2CboZAqD_r2W_3PrdsiVN4osGOYc9DhTU rx1ueJzeBnlHqaBKSLscSUEBKELfNMQ-- X-Yahoo-SMTP: jU6Na92swBBdqSRkLOL9Cp_LhHZgQAQoL10- User-Agent: Microsoft-MacOutlook/14.4.4.140807 Date: Wed, 04 Feb 2015 10:28:11 -0800 From: Nitin Bahadur To: Linda Dunbar Message-ID: Thread-Topic: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3505890498_39214956" Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added 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, 04 Feb 2015 18:28:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3505890498_39214956 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Linda, Can you clarify the difference=8A? > It is a non-goal to create new protocols or data models for I2NSF interfa= ces. =20 > I2NSF WG Deliverables > - Corresponding Data Models (e.g. YANG model). Thanks Nitin --B_3505890498_39214956 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Hi Linda,

   Can you clarify the difference…?


> I= t is a non-goal to create new protocols or data models for I2NSF interfaces.=  

 

> I2NSF WG D= eliverables

> -       &= nbsp;  Corresponding Data Models (e.g. YANG model).<= /span>


Thanks
Niti= n


--B_3505890498_39214956-- From nobody Wed Feb 4 10:35: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 7A1AF1A1B59 for ; Wed, 4 Feb 2015 10:35:06 -0800 (PST) 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 YBsgNyf_CsEh for ; Wed, 4 Feb 2015 10:35:04 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295FB1A1A64 for ; Wed, 4 Feb 2015 10:35:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4GALxl0lSHCzIm/2dsb2JhbABagkMhIlJZBK90BQaYLwKBHkMBAQEBAQF8hAwBAQEBAgESG0wFCwIBCA0EBAEBCx0HMhQIAQgCBAENBQgaiAMIAbV8oQYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhgSJQzEGAYMWgRMFjxCPfowOIoIygTxvgUR+AQEB X-IronPort-AV: E=Sophos; i="5.09,519,1418101200"; d="scan'208,217"; a="90157814" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by de307622-de-outbound.net.avaya.com with ESMTP; 04 Feb 2015 13:35:01 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 04 Feb 2015 13:34:59 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Wed, 4 Feb 2015 13:34:58 -0500 From: "Romascanu, Dan (Dan)" To: Nitin Bahadur , Linda Dunbar Thread-Topic: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added Thread-Index: AQHQQKhdb1d01WlSOEala4jbSX9P5pzg0NjQ Date: Wed, 4 Feb 2015 18:34:58 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C981921@AZ-FFEXMB04.global.avaya.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C981921AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added 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, 04 Feb 2015 18:35:06 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C981921AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This should be 'data modeling languages' rather than 'data models' in non-g= oals. The idea being that we are not trying to re-create or invent a new YANG. Regards, Dan From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Wednesday, February 04, 2015 8:28 PM To: Linda Dunbar Cc: nfvrg@irtf.org; i2rs@ietf.org Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the timeline= for deliverables added Hi Linda, Can you clarify the difference...? > It is a non-goal to create new protocols or data models for I2NSF interfa= ces. > I2NSF WG Deliverables > - Corresponding Data Models (e.g. YANG model). Thanks Nitin --_000_9904FB1B0159DA42B0B887B7FA8119CA5C981921AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This should be ‘= data modeling languages’ rather than ‘data models’ in non= -goals.

 

The idea being that we= are not trying to re-create or invent a new YANG.

 

Regards,

 

Dan<= /p>

 

 

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur
Sent: Wednesday, February 04, 2015 8:28 PM
To: Linda Dunbar
Cc: nfvrg@irtf.org; i2rs@ietf.org
Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the t= imeline for deliverables added

 

Hi Lind= a,

&n= bsp;

  =  Can you clarify the difference…?

&n= bsp;

&n= bsp;

> It is a non-goal to create new pr= otocols or data models for I2NSF interfaces. 

 

> I2NSF WG Deliverables

> - &n= bsp;        Corresponding Data Mode= ls (e.g. YANG model).

&n= bsp;

Thanks<= o:p>

Nitin

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C981921AZFFEXMB04globa_-- From nobody Wed Feb 4 11:44: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 51A911A1BC5; Wed, 4 Feb 2015 11:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzIYKrNSCzbM; Wed, 4 Feb 2015 11:44:35 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 785DF1A6F22; Wed, 4 Feb 2015 11:44:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSC77666; Wed, 04 Feb 2015 19:44:20 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 19:44:20 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 11:44:17 -0800 From: Linda Dunbar To: "Thomas D. Nadeau" Thread-Topic: [I2nsf] [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAAIyhYAAJ0n7UAARYL8AAApyUrA= Date: Wed, 4 Feb 2015 19:44:17 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Russ White , "i2nsf@ietf.org" , Susan Hares , "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 04 Feb 2015 19:44:39 -0000 Thomas,=20 Comments inserted below: -----Original Message----- From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. Nadeau Sent: Wednesday, February 04, 2015 10:37 AM To: Linda Dunbar Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; i2rs@ietf.org Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar wrote: >=20 > Russ,=20 >=20 > Thank you very much for the suggestion of framing in terms of services. W= hat do you think with the following changes to the I2NSF charter with your = suggestions added? >=20 > In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicat= e their specific security policies (request/monitor/report) to security fun= ctions. I2NSF will specify a vNSF framework, requirements for programmatic= interface to vNSF devices (configuration and dynamic programmatic) , and= Information and Data models for security functions' Operation, Administrat= ion, Maintenance and Provisioning (OAM). The information models will inclu= de the following security functions: Why wouldn't you do the models for those OAM functions where those functio= ns are modeled already? I don't see the need for a special WG that creates= a subset of models that can done elsewhere like in LIME, or the Routing Ar= ea groups that are already chartered to do this stuff. =20 [Linda] LIME addresses OAM for network layer, connectivity (link/port) fail= ures, end to end performances measurement, whereas I2NSF is for security po= licies to be enforced by distributed (virtual) network security functions (= vNSF). I2NSF provides a standard interface to express, monitor, and manage = the security policies across distributed security functions that may be run= ning on different premises. This leaves just doing requirements and a framework for this proposed grou= p, which without clear goals to build things from is a WG looking for a rea= son to exist rather than the other way around. --Tom >=20 > * Firewall=20 > including various services associated with FW, such as stateful or deep = packet inspection, packet/flow/stream filtering and redirect (remote and l= ocal), etc >=20 > * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) > Including intrusion detection (flow/stream pattern matching) >=20 >=20 > Linda >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White > Sent: Tuesday, February 03, 2015 7:35 AM > To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org > Cc: nfvrg@irtf.org; i2rs@ietf.org > Subject: Re: [i2rs] revised charter for I2NSF >=20 >=20 > Interesting concept. One thought that might be helpful --=20 >=20 >> * Firewall >> * DDOS/Anti-DOS >> * Intrusion Detection System/ Intrusion Prevention System >> (IDS/IPS) >> * Access control/Authorization/Authentication >=20 > I think I would try to frame things in terms of services, rather than dev= ices, or a mix of the two. For instance -- what does a "firewall" really do= ? Stateful packet inspection, deep packet inspection, and... ?? So maybe a = list something like this might make sense -- (and remember, this is brainst= orming, nothing more) -- >=20 > - Stateful packet inspection > - Deep packet inspection > - Packet/flow/stream filtering (remote and local) > - Packet/flow/stream redirect (remote and local) > - Intrusion detection (or perhaps flow/stream pattern matching?) > - AAA >=20 > Don't know if this is a useful line of thought or not. >=20 > :-) >=20 > Russ >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Wed Feb 4 11:50: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 24C601A6EFE; Wed, 4 Feb 2015 11:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 mncmxUrZO8xX; Wed, 4 Feb 2015 11:50:23 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 669891A1BC5; Wed, 4 Feb 2015 11:50:23 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id BBEBF2DC8B30; Wed, 4 Feb 2015 14:50:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> Date: Wed, 4 Feb 2015 14:50:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Russ White , "i2nsf@ietf.org" , Susan Hares , "nfvrg@irtf.org" , "i2rs@ietf.org" Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 04 Feb 2015 19:50:25 -0000 > On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar = wrote: >=20 >=20 > Thomas,=20 >=20 > Comments inserted below: >=20 > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. = Nadeau > Sent: Wednesday, February 04, 2015 10:37 AM > To: Linda Dunbar > Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; = i2rs@ietf.org > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >=20 >=20 >> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar = wrote: >>=20 >> Russ,=20 >>=20 >> Thank you very much for the suggestion of framing in terms of = services. What do you think with the following changes to the I2NSF = charter with your suggestions added? >>=20 >> In a nutshell, The Interface to vNSF (I2NSF) allows clients to = communicate their specific security policies (request/monitor/report) to = security functions. I2NSF will specify a vNSF framework, requirements = for programmatic interface to vNSF devices (configuration and dynamic = programmatic) , and Information and Data models for security = functions' Operation, Administration, Maintenance and Provisioning = (OAM). The information models will include the following security = functions: >=20 > Why wouldn't you do the models for those OAM functions where = those functions are modeled already? I don't see the need for a special = WG that creates a subset of models that can done elsewhere like in LIME, = or the Routing Area groups that are already chartered to do this stuff. =20= >=20 > [Linda] LIME addresses OAM for network layer, connectivity (link/port) = failures, end to end performances measurement, whereas I2NSF is for = security policies to be enforced by distributed (virtual) network = security functions (vNSF). I2NSF provides a standard interface to = express, monitor, and manage the security policies across distributed = security functions that may be running on different premises. [TOM] The salient point I have been trying to make is that i2nsf does = not exist; LIME does. Why not just do it there (and other existing = places in the IETF)? We seem to be working REALLY hard here to make up = reasons why we need to form a new working group. I'd contend that it is = not needed and that the management overhead + other overhead of = reviewing/processing documents like a new framework, requirements, = etc... will unnecessarily spend precious IETF resources. --Tom > This leaves just doing requirements and a framework for this = proposed group, which without clear goals to build things from is a WG = looking for a reason to exist rather than the other way around. >=20 > --Tom >=20 >=20 >=20 >>=20 >> * Firewall=20 >> including various services associated with FW, such as stateful = or deep packet inspection, packet/flow/stream filtering and redirect = (remote and local), etc >>=20 >> * Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) >> Including intrusion detection (flow/stream pattern matching) >>=20 >>=20 >> Linda >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >> Sent: Tuesday, February 03, 2015 7:35 AM >> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >> Cc: nfvrg@irtf.org; i2rs@ietf.org >> Subject: Re: [i2rs] revised charter for I2NSF >>=20 >>=20 >> Interesting concept. One thought that might be helpful --=20 >>=20 >>> * Firewall >>> * DDOS/Anti-DOS >>> * Intrusion Detection System/ Intrusion Prevention System >>> (IDS/IPS) >>> * Access control/Authorization/Authentication >>=20 >> I think I would try to frame things in terms of services, rather than = devices, or a mix of the two. For instance -- what does a "firewall" = really do? Stateful packet inspection, deep packet inspection, and... ?? = So maybe a list something like this might make sense -- (and remember, = this is brainstorming, nothing more) -- >>=20 >> - Stateful packet inspection >> - Deep packet inspection >> - Packet/flow/stream filtering (remote and local) >> - Packet/flow/stream redirect (remote and local) >> - Intrusion detection (or perhaps flow/stream pattern matching?) >> - AAA >>=20 >> Don't know if this is a useful line of thought or not. >>=20 >> :-) >>=20 >> Russ >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf >=20 From nobody Wed Feb 4 11:59:26 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 437611A854D for ; Wed, 4 Feb 2015 11:59:24 -0800 (PST) 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 cbWUqdyX0vqn for ; Wed, 4 Feb 2015 11:59:22 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 71F971A1B61 for ; Wed, 4 Feb 2015 11:59:17 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Nitin Bahadur'" , "'Linda Dunbar'" References: In-Reply-To: Date: Wed, 4 Feb 2015 14:59:00 -0500 Message-ID: <014a01d040b5$05fb06e0$11f114a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01D0408B.1D26D3A0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJA6jdb29hQpIk3+9Uf90sdYWbwS5v/lXqw X-Authenticated-User: skh@ndzh.com Archived-At: Cc: nfvrg@irtf.org, i2rs@ietf.org Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added 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, 04 Feb 2015 19:59:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014B_01D0408B.1D26D3A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nitin: I believe the charter should have said "new protocols" only. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin Bahadur Sent: Wednesday, February 04, 2015 1:28 PM To: Linda Dunbar Cc: nfvrg@irtf.org; i2rs@ietf.org Subject: Re: [i2rs] FW: further trimed the I2NSF charter, with the timeline for deliverables added Hi Linda, Can you clarify the difference.? > It is a non-goal to create new protocols or data models for I2NSF interfaces. > I2NSF WG Deliverables > - Corresponding Data Models (e.g. YANG model). Thanks Nitin ------=_NextPart_000_014B_01D0408B.1D26D3A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nitin:

 

I believe the charter = should have said “new protocols” = only.

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Nitin = Bahadur
Sent: Wednesday, February 04, 2015 1:28 = PM
To: Linda Dunbar
Cc: nfvrg@irtf.org; = i2rs@ietf.org
Subject: Re: [i2rs] FW: further trimed the I2NSF = charter, with the timeline for deliverables = added

 

Hi = Linda,

 

=

   Can you clarify the = difference…?

 

=

 

=

> It is a non-goal to create new protocols or = data models for I2NSF interfaces. 

 

> I2NSF WG Deliverables

> -      = ;    Corresponding Data Models (e.g. = YANG model).

 

=

Thanks

=

Nitin

<= div>

 

------=_NextPart_000_014B_01D0408B.1D26D3A0-- From nobody Wed Feb 4 12:02: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 C83A61A3BA1; Wed, 4 Feb 2015 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 sy52bSQe9QrZ; Wed, 4 Feb 2015 12:02:23 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD3691A1B4F; Wed, 4 Feb 2015 12:02:22 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8GAFJ60lTGmAcV/2dsb2JhbABagmQiUlkEr3UFBpI+hXECgSFDAQEBAQEBfIQMAQEBAQMSKDQLDAQCAQgNBAQBAQEKFAkHMhQJCAIEAQ0FCBqICwEMtVGhBwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEhgSJQzEHBoMQgRMFjxCDUIZwhT6IUYM9IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,519,1418101200"; d="scan'208";a="105480768" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 04 Feb 2015 15:02:21 -0500 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 04 Feb 2015 15:02:20 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Wed, 4 Feb 2015 21:02:18 +0100 From: "Romascanu, Dan (Dan)" To: "Thomas D. Nadeau" , Linda Dunbar Thread-Topic: [I2nsf] [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAAIyhYAAJ0n7UP//9CYAgAA0ToCAAGZJAIAAUPww Date: Wed, 4 Feb 2015 20:02:17 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Russ White , "i2nsf@ietf.org" , "nfvrg@irtf.org" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 04 Feb 2015 20:02:26 -0000 Tom, I2NSF in its most recent (and better focused) charter includes IMs and DMs = for firewalls and IDSs, as well as a framework to manage virtualized securi= ty services. Does LIME or other WG in the IETF do any of these?=20 Regards, Dan > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. Nadeau > Sent: Wednesday, February 04, 2015 9:50 PM > To: Linda Dunbar > Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org; i2rs@ietf.or= g > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >=20 >=20 > > On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar > wrote: > > > > > > Thomas, > > > > Comments inserted below: > > > > -----Original Message----- > > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. > Nadeau > > Sent: Wednesday, February 04, 2015 10:37 AM > > To: Linda Dunbar > > Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; i2rs@ietf.= org > > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > > > > > >> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar > wrote: > >> > >> Russ, > >> > >> Thank you very much for the suggestion of framing in terms of services= . > What do you think with the following changes to the I2NSF charter with yo= ur > suggestions added? > >> > >> In a nutshell, The Interface to vNSF (I2NSF) allows clients to communi= cate > their specific security policies (request/monitor/report) to security fun= ctions. > I2NSF will specify a vNSF framework, requirements for programmatic > interface to vNSF devices (configuration and dynamic programmatic) , an= d > Information and Data models for security functions' Operation, > Administration, Maintenance and Provisioning (OAM). The information > models will include the following security functions: > > > > Why wouldn't you do the models for those OAM functions where > those functions are modeled already? I don't see the need for a special = WG > that creates a subset of models that can done elsewhere like in LIME, or = the > Routing Area groups that are already chartered to do this stuff. > > > > [Linda] LIME addresses OAM for network layer, connectivity (link/port) > failures, end to end performances measurement, whereas I2NSF is for > security policies to be enforced by distributed (virtual) network securit= y > functions (vNSF). I2NSF provides a standard interface to express, monitor= , > and manage the security policies across distributed security functions th= at > may be running on different premises. >=20 > [TOM] The salient point I have been trying to make is that i2nsf does not > exist; LIME does. Why not just do it there (and other existing places in = the > IETF)? We seem to be working REALLY hard here to make up reasons why > we need to form a new working group. I'd contend that it is not needed an= d > that the management overhead + other overhead of reviewing/processing > documents like a new framework, requirements, etc... will unnecessarily > spend precious IETF resources. >=20 > --Tom >=20 >=20 > > This leaves just doing requirements and a framework for this > proposed group, which without clear goals to build things from is a WG > looking for a reason to exist rather than the other way around. > > > > --Tom > > > > > > > >> > >> * Firewall > >> including various services associated with FW, such as stateful or > deep packet inspection, packet/flow/stream filtering and redirect (remot= e > and local), etc > >> > >> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) > >> Including intrusion detection (flow/stream pattern matching) > >> > >> > >> Linda > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White > >> Sent: Tuesday, February 03, 2015 7:35 AM > >> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org > >> Cc: nfvrg@irtf.org; i2rs@ietf.org > >> Subject: Re: [i2rs] revised charter for I2NSF > >> > >> > >> Interesting concept. One thought that might be helpful -- > >> > >>> * Firewall > >>> * DDOS/Anti-DOS > >>> * Intrusion Detection System/ Intrusion Prevention System > >>> (IDS/IPS) > >>> * Access control/Authorization/Authentication > >> > >> I think I would try to frame things in terms of services, rather than > devices, or a mix of the two. For instance -- what does a "firewall" real= ly do? > Stateful packet inspection, deep packet inspection, and... ?? So maybe a = list > something like this might make sense -- (and remember, this is > brainstorming, nothing more) -- > >> > >> - Stateful packet inspection > >> - Deep packet inspection > >> - Packet/flow/stream filtering (remote and local) > >> - Packet/flow/stream redirect (remote and local) > >> - Intrusion detection (or perhaps flow/stream pattern matching?) > >> - AAA > >> > >> Don't know if this is a useful line of thought or not. > >> > >> :-) > >> > >> Russ > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S > giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB > 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL > TDFHlxo1ys_wiueV8NI&e=3D > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S > giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB > 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL > TDFHlxo1ys_wiueV8NI&e=3D > >> > > > > _______________________________________________ > > I2nsf mailing list > > I2nsf@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN > B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- > U7rpbPenEFmJgJ11F9yjW29E&e=3D > > >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 > SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN > B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- > U7rpbPenEFmJgJ11F9yjW29E&e=3D From nobody Wed Feb 4 12:36:52 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 6FAB51A1A87; Wed, 4 Feb 2015 12:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 c_4QHRlAL-cQ; Wed, 4 Feb 2015 12:36:48 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE071A0372; Wed, 4 Feb 2015 12:36:48 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id C40B62DC9528; Wed, 4 Feb 2015 15:36:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> Date: Wed, 4 Feb 2015 15:36:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> To: "Romascanu, Dan (Dan)" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" , "i2nsf@ietf.org" , Linda Dunbar , Russ White , Susan Hares Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 04 Feb 2015 20:36:50 -0000 They certainly could, without the added management overhead of a = new WG. --Tom > On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) = wrote: >=20 > Tom, >=20 > I2NSF in its most recent (and better focused) charter includes IMs and = DMs for firewalls and IDSs, as well as a framework to manage virtualized = security services. Does LIME or other WG in the IETF do any of these?=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. = Nadeau >> Sent: Wednesday, February 04, 2015 9:50 PM >> To: Linda Dunbar >> Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org; = i2rs@ietf.org >> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>=20 >>=20 >>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar >> wrote: >>>=20 >>>=20 >>> Thomas, >>>=20 >>> Comments inserted below: >>>=20 >>> -----Original Message----- >>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. >> Nadeau >>> Sent: Wednesday, February 04, 2015 10:37 AM >>> To: Linda Dunbar >>> Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; = i2rs@ietf.org >>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>=20 >>>=20 >>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar >> wrote: >>>>=20 >>>> Russ, >>>>=20 >>>> Thank you very much for the suggestion of framing in terms of = services. >> What do you think with the following changes to the I2NSF charter = with your >> suggestions added? >>>>=20 >>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to = communicate >> their specific security policies (request/monitor/report) to security = functions. >> I2NSF will specify a vNSF framework, requirements for programmatic >> interface to vNSF devices (configuration and dynamic programmatic) = , and >> Information and Data models for security functions' Operation, >> Administration, Maintenance and Provisioning (OAM). The information >> models will include the following security functions: >>>=20 >>> Why wouldn't you do the models for those OAM functions where >> those functions are modeled already? I don't see the need for a = special WG >> that creates a subset of models that can done elsewhere like in LIME, = or the >> Routing Area groups that are already chartered to do this stuff. >>>=20 >>> [Linda] LIME addresses OAM for network layer, connectivity = (link/port) >> failures, end to end performances measurement, whereas I2NSF is for >> security policies to be enforced by distributed (virtual) network = security >> functions (vNSF). I2NSF provides a standard interface to express, = monitor, >> and manage the security policies across distributed security = functions that >> may be running on different premises. >>=20 >> [TOM] The salient point I have been trying to make is that i2nsf does = not >> exist; LIME does. Why not just do it there (and other existing places = in the >> IETF)? We seem to be working REALLY hard here to make up reasons why >> we need to form a new working group. I'd contend that it is not = needed and >> that the management overhead + other overhead of reviewing/processing >> documents like a new framework, requirements, etc... will = unnecessarily >> spend precious IETF resources. >>=20 >> --Tom >>=20 >>=20 >>> This leaves just doing requirements and a framework for this >> proposed group, which without clear goals to build things from is a = WG >> looking for a reason to exist rather than the other way around. >>>=20 >>> --Tom >>>=20 >>>=20 >>>=20 >>>>=20 >>>> * Firewall >>>> including various services associated with FW, such as stateful = or >> deep packet inspection, packet/flow/stream filtering and redirect = (remote >> and local), etc >>>>=20 >>>> * Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) >>>> Including intrusion detection (flow/stream pattern matching) >>>>=20 >>>>=20 >>>> Linda >>>>=20 >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >>>> Sent: Tuesday, February 03, 2015 7:35 AM >>>> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >>>> Cc: nfvrg@irtf.org; i2rs@ietf.org >>>> Subject: Re: [i2rs] revised charter for I2NSF >>>>=20 >>>>=20 >>>> Interesting concept. One thought that might be helpful -- >>>>=20 >>>>> * Firewall >>>>> * DDOS/Anti-DOS >>>>> * Intrusion Detection System/ Intrusion Prevention System >>>>> (IDS/IPS) >>>>> * Access control/Authorization/Authentication >>>>=20 >>>> I think I would try to frame things in terms of services, rather = than >> devices, or a mix of the two. For instance -- what does a "firewall" = really do? >> Stateful packet inspection, deep packet inspection, and... ?? So = maybe a list >> something like this might make sense -- (and remember, this is >> brainstorming, nothing more) -- >>>>=20 >>>> - Stateful packet inspection >>>> - Deep packet inspection >>>> - Packet/flow/stream filtering (remote and local) >>>> - Packet/flow/stream redirect (remote and local) >>>> - Intrusion detection (or perhaps flow/stream pattern matching?) >>>> - AAA >>>>=20 >>>> Don't know if this is a useful line of thought or not. >>>>=20 >>>> :-) >>>>=20 >>>> Russ >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >> TDFHlxo1ys_wiueV8NI&e=3D >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >> TDFHlxo1ys_wiueV8NI&e=3D >>>>=20 >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>=20 >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >> U7rpbPenEFmJgJ11F9yjW29E&e=3D >=20 From nobody Wed Feb 4 13:20: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 86F0B1A88B7 for ; Wed, 4 Feb 2015 13:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyo8K3fgyGbM for ; Wed, 4 Feb 2015 13:20:20 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1F91A885B for ; Wed, 4 Feb 2015 13:20:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1817; q=dns/txt; s=iport; t=1423084820; x=1424294420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9AaKi8Ej0n0J5dvTCzgVGRhchBqI0gD2k0wxxA2Bx4c=; b=MSBbl2RmGuEHGBtKrmN2IS1rJ0NiKPMWvl/rXf0fYFRRYf7AUql4oiPS mlAs4zS7+dzOdfZOJP7peq0P8owLrdWJI0h43x9wMIj0uDeJBDCk7Fy8L /3IzR1g1eIlSVK0+8VOE+Gc19Qks9sf06rd6UdEx9ftJG/ti6fesDLact w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAOSL0lStJV2b/2dsb2JhbABXA4MGUlkEwjQKhXECgSBDAQEBAQF9hAwBAQEDAQEBATc0CwUHAgICAQgQAQQBAQEKAxEJBxsMCxQJCAIEAQ0FCIgdCA3WUQEBAQEBAQEBAQEBAQEBAQEBAQEBARcEjxwnIRAHBguDBYETBY8QnAwigjKBPG+BAkJ+AQEB X-IronPort-AV: E=Sophos;i="5.09,519,1418083200"; d="scan'208";a="393502939" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 04 Feb 2015 21:20:19 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t14LKJax028461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 21:20:19 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.130]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 15:20:18 -0600 From: "Alexander Clemm (alex)" To: "Eric Voit (evoit)" , Juergen Schoenwaelder Thread-Topic: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AdA/PnHrl9gFlR/FTJCQzd9Zf+vhmAAe7yOAABPudYAAACfvgAAAS40AAACQ/YAAAIyrgAAr9TRA Date: Wed, 4 Feb 2015 21:20:18 +0000 Message-ID: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> <20150203080327.GA68276@elstar.local> <20150203173837.GF81526@elstar.local> <20150203180317.GA82786@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 04 Feb 2015 21:20:21 -0000 I agree, this modification will make it more accurate. =20 As mentioned earlier on the thread, this is a -00 draft and we should expec= t that some revisions will be needed. =20 Thanks --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, February 03, 2015 10:19 AM To: Juergen Schoenwaelder Cc: 'Jeffrey Haas'; i2rs@ietf.org; Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit= -i2rs-pub-sub-requirements-00 > On Tue, Feb 03, 2015 at 05:47:04PM +0000, Eric Voit (evoit) wrote: > > >> o limited support for pushed notification of changes. (Currentl= y > > >> notifications are for configuration data only. And even then= , > > >> subscription mechanisms for such notifications are > > >> undefined.) > > > > > I understand all that I think but I still think the text quoted=20 > > > above is incorrect and this should be fixed. I am not looking for=20 > > > long explanation, a simple "we will change that text to '...'"=20 > > > would be more > efficient. > > > > I can just delete everything between the parenthesis. Would that be > sufficient? >=20 > This leaves it open what 'limited' means, which I think is not good eithe= r. > Perhaps: >=20 > o change notifications only for data residing in configuration > datastores Works for me. I will insert that into "-01" Eric > /js >=20 > -- > 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 Wed Feb 4 14:22:21 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 3DE241A8986; Wed, 4 Feb 2015 14:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiIZTJfdWrvA; Wed, 4 Feb 2015 14:22:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28CF1A8973; Wed, 4 Feb 2015 14:22:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSC85064; Wed, 04 Feb 2015 22:22:15 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Feb 2015 22:22:14 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 14:22:13 -0800 From: Linda Dunbar To: "Thomas D. Nadeau" , "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAAIyhYAAJ0n7UAARYL8AAApyUrD//+JvAIAAA1SAgAAJpICAAGqdUA== Date: Wed, 4 Feb 2015 22:22:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBE866@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> In-Reply-To: <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Russ White , "i2nsf@ietf.org" , "nfvrg@irtf.org" , Susan Hares , "i2rs@ietf.org" Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 04 Feb 2015 22:22:20 -0000 Tom,=20 Will those existing WGs you mentioned also do the following? - a standard interface to express, monitor, and verify the security policie= s on distributed security functions that may be running on different premis= es. This layer will leverage the existing protocols in RESTconf, AAA, SACM, and= security policy expression using Role Based Access Control (RBAC), Mandato= ry Access Control (MAC), or Attribute-based access control (ABAC). Those WGs charters don't have those objectives.=20 Thanks, Linda -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Wednesday, February 04, 2015 2:37 PM To: Romascanu, Dan (Dan) Cc: Linda Dunbar; Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org; = i2rs@ietf.org Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF They certainly could, without the added management overhead of a new WG. --Tom > On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) wrote: >=20 > Tom, >=20 > I2NSF in its most recent (and better focused) charter includes IMs and DM= s for firewalls and IDSs, as well as a framework to manage virtualized secu= rity services. Does LIME or other WG in the IETF do any of these?=20 >=20 > Regards, >=20 > Dan >=20 >=20 >> -----Original Message----- >> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D.=20 >> Nadeau >> Sent: Wednesday, February 04, 2015 9:50 PM >> To: Linda Dunbar >> Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org;=20 >> i2rs@ietf.org >> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>=20 >>=20 >>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar >> wrote: >>>=20 >>>=20 >>> Thomas, >>>=20 >>> Comments inserted below: >>>=20 >>> -----Original Message----- >>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. >> Nadeau >>> Sent: Wednesday, February 04, 2015 10:37 AM >>> To: Linda Dunbar >>> Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares;=20 >>> i2rs@ietf.org >>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>=20 >>>=20 >>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar >> wrote: >>>>=20 >>>> Russ, >>>>=20 >>>> Thank you very much for the suggestion of framing in terms of services= . >> What do you think with the following changes to the I2NSF charter=20 >> with your suggestions added? >>>>=20 >>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to=20 >>>> communicate >> their specific security policies (request/monitor/report) to security fu= nctions. >> I2NSF will specify a vNSF framework, requirements for programmatic >> interface to vNSF devices (configuration and dynamic programmatic) , a= nd >> Information and Data models for security functions' Operation,=20 >> Administration, Maintenance and Provisioning (OAM). The information=20 >> models will include the following security functions: >>>=20 >>> Why wouldn't you do the models for those OAM functions where >> those functions are modeled already? I don't see the need for a=20 >> special WG that creates a subset of models that can done elsewhere=20 >> like in LIME, or the Routing Area groups that are already chartered to d= o this stuff. >>>=20 >>> [Linda] LIME addresses OAM for network layer, connectivity=20 >>> (link/port) >> failures, end to end performances measurement, whereas I2NSF is for=20 >> security policies to be enforced by distributed (virtual) network=20 >> security functions (vNSF). I2NSF provides a standard interface to=20 >> express, monitor, and manage the security policies across distributed=20 >> security functions that may be running on different premises. >>=20 >> [TOM] The salient point I have been trying to make is that i2nsf does=20 >> not exist; LIME does. Why not just do it there (and other existing=20 >> places in the IETF)? We seem to be working REALLY hard here to make=20 >> up reasons why we need to form a new working group. I'd contend that=20 >> it is not needed and that the management overhead + other overhead of=20 >> reviewing/processing documents like a new framework, requirements,=20 >> etc... will unnecessarily spend precious IETF resources. >>=20 >> --Tom >>=20 >>=20 >>> This leaves just doing requirements and a framework for this >> proposed group, which without clear goals to build things from is a=20 >> WG looking for a reason to exist rather than the other way around. >>>=20 >>> --Tom >>>=20 >>>=20 >>>=20 >>>>=20 >>>> * Firewall >>>> including various services associated with FW, such as stateful or >> deep packet inspection, packet/flow/stream filtering and redirect=20 >> (remote and local), etc >>>>=20 >>>> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) >>>> Including intrusion detection (flow/stream pattern matching) >>>>=20 >>>>=20 >>>> Linda >>>>=20 >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >>>> Sent: Tuesday, February 03, 2015 7:35 AM >>>> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >>>> Cc: nfvrg@irtf.org; i2rs@ietf.org >>>> Subject: Re: [i2rs] revised charter for I2NSF >>>>=20 >>>>=20 >>>> Interesting concept. One thought that might be helpful -- >>>>=20 >>>>> * Firewall >>>>> * DDOS/Anti-DOS >>>>> * Intrusion Detection System/ Intrusion Prevention System >>>>> (IDS/IPS) >>>>> * Access control/Authorization/Authentication >>>>=20 >>>> I think I would try to frame things in terms of services, rather=20 >>>> than >> devices, or a mix of the two. For instance -- what does a "firewall" rea= lly do? >> Stateful packet inspection, deep packet inspection, and... ?? So=20 >> maybe a list something like this might make sense -- (and remember,=20 >> this is brainstorming, nothing more) -- >>>>=20 >>>> - Stateful packet inspection >>>> - Deep packet inspection >>>> - Packet/flow/stream filtering (remote and local) >>>> - Packet/flow/stream redirect (remote and local) >>>> - Intrusion detection (or perhaps flow/stream pattern matching?) >>>> - AAA >>>>=20 >>>> Don't know if this is a useful line of thought or not. >>>>=20 >>>> :-) >>>>=20 >>>> Russ >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >> TDFHlxo1ys_wiueV8NI&e=3D >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >> TDFHlxo1ys_wiueV8NI&e=3D >>>>=20 >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>=20 >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >> U7rpbPenEFmJgJ11F9yjW29E&e=3D >=20 From nobody Wed Feb 4 16:29: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 7CBCD1A00BF for ; Wed, 4 Feb 2015 16:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.054 X-Spam-Level: X-Spam-Status: No, score=-101.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd4IfjgKdhS8 for ; Wed, 4 Feb 2015 16:28:54 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDC1A00B8 for ; Wed, 4 Feb 2015 16:28:53 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Wed, 4 Feb 2015 19:28:42 -0500 Message-ID: <028401d040da$b3728760$1a579620$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0285_01D040B0.CA9F6590" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBA2ZHZ9nqDprk2QCaNWTDXZWPfbw== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , Dean Bogdanovic , akatlas@gmail.com Subject: [i2rs] I2RS interim on 2/5/2015 at 10:00am - 11:00 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, 05 Feb 2015 00:28:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0285_01D040B0.CA9F6590 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0286_01D040B0.CA9F6590" ------=_NextPart_001_0286_01D040B0.CA9F6590 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The I2RS interim on 2/5/2015 at 10:00am has the following agenda = regarding the I2RS protocol=20 =20 1) 7 primitives that should be exposed from the I2RS Agent (Dean = Bogdanovic) 2) Discussion on 7 primitives=20 =20 Our discussion on the I2RS protocol are aimed at providing requirements = for the I2RS protocol. =20 Our past discussion have considered a smaller protocol and the use of = netconf/restconf for full functionality. Dan=E2=80=99s presentation is = considering what has to be in a protocol =E2=80=93 small or large. The = I2RS goal is to consider these requirements and finalize an I2RS = protocol requirements document in February that will be discussed for WG = adoption in IETF 92.=20 =20 For those who have proposed a protocol requirements in the past, and = would like to join a design team completing the I2RS protocol = requirements please esnd me a note.=20 =20 Sue =20 =20 From: I2RS Working Group [mailto:messenger@webex.com]=20 Sent: Wednesday, February 04, 2015 7:16 PM To: i2rs-chairs@tools.ietf.org Subject: (Forward to others) WebEx meeting invitation: I2RS Interim =20 You can forward this invitation to others.=20 =20 Hello,=20 I2RS Working Group invites you to join this WebEx meeting.=20 =20 =20 =20 I2RS Interim=20 Thursday, February 5, 2015=20 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 = mins=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 640 334 334=20 Meeting password: smallandbig =20 =20 =20 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 640 334 334 Toll-free calling = restrictions =20 =20 =20 = Add this meeting to your calendar. =20 =20 =20 Can't join the meeting? Contact = support.=20 =20 =20 =20 IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. =20 ------=_NextPart_001_0286_01D040B0.CA9F6590 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The I2RS interim on 2/5/2015 at 10:00am has the following agenda = regarding the I2RS protocol

 

1)      = 7 primitives that should be exposed from the I2RS Agent =C2=A0(Dean = Bogdanovic)

2)      = Discussion on 7 primitives

 

Our discussion on the I2RS protocol are aimed at providing = requirements for the I2RS protocol.

 

Our past discussion have considered a smaller protocol and the use of = netconf/restconf for full functionality.=C2=A0 Dan=E2=80=99s = presentation is considering what has to be in a protocol =E2=80=93 small = or large. =C2=A0The I2RS goal is to consider these requirements and = finalize an I2RS protocol requirements document in February that will be = discussed for WG adoption in IETF 92.

 

For those who have proposed a protocol requirements in the past, and = would like to join a design team completing the I2RS protocol = requirements please esnd me a note.

 

Sue =C2=A0=C2=A0=C2=A0

 

From:= = I2RS Working Group [mailto:messenger@webex.com]
Sent: = Wednesday, February 04, 2015 7:16 PM
To: = i2rs-chairs@tools.ietf.org
Subject: (Forward to others) WebEx = meeting invitation: I2RS Interim

 

You can forward this invitation to others. =

 

Hello,

I2RS Working Group invites you to join this WebEx meeting. =

 

 

 

I2RS = Interim =

Thursday, February 5, 2015

10:00 am  |  Eastern Standard Time (New York, = GMT-05:00)  |  1 hr 30 mins =

 

 

 

Join = WebEx meeting =

 

Meeting number:

640 334 334

Meeting password:

smallandbig

 

 

 

Join by = phone

1-877-668-4493 Call-in toll free number = (US/Canada)

1-650-479-3208 Call-in toll number = (US/Canada)

Access code: 640 334 334

Toll-free = calling = restrictions

 

 

 

Add this = meeting to your = calendar.

 

 

 

Can't join the meeting? Contact support. =

 

 

 

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

 

------=_NextPart_001_0286_01D040B0.CA9F6590-- ------=_NextPart_000_0285_01D040B0.CA9F6590 Content-Type: application/octet-stream; name="WebEx_Meeting.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting.ics" BEGIN:VCALENDAR=0A= PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN=0A= VERSION:2.0=0A= METHOD:REQUEST=0A= BEGIN:VTIMEZONE=0A= TZID:Eastern Time=0A= BEGIN:STANDARD=0A= DTSTART:20131101T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D1SU;BYMONTH=3D11=0A= TZOFFSETFROM:-0400=0A= TZOFFSETTO:-0500=0A= TZNAME:Standard Time=0A= END:STANDARD=0A= BEGIN:DAYLIGHT=0A= DTSTART:20130301T020000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D2SU;BYMONTH=3D3=0A= TZOFFSETFROM:-0500=0A= TZOFFSETTO:-0400=0A= TZNAME:Daylight Savings Time=0A= END:DAYLIGHT=0A= END:VTIMEZONE=0A= BEGIN:VEVENT=0A= ATTENDEE;CN=3D"I2RS Working = Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DTRUE:MAILTO:i2rs-chairs@tools.ietf.o= rg=0A= ORGANIZER;CN=3D"I2RS Working Group":MAILTO:i2rs-chairs@tools.ietf.org=0A= DTSTART;TZID=3D"Eastern Time":20150205T100000=0A= DTEND;TZID=3D"Eastern Time":20150205T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1423095373=0A= UID:7f5c01d4-2c43-4d22-8a46-0b28f73a116e=0A= DTSTAMP:20150205T150000Z=0A= DESCRIPTION:\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dmaba9c873682fdd02e322b4= 7f4c331c87\nMeeting number: 640 334 334\nMeeting password: = smallandbig\n\n\nJOIN BY PHONE\n1-877-668-4493 Call-in toll free number = (US/Canada) \n1-650-479-3208 Call-in toll number (US/Canada)\nAccess = code: 640 334 334\n\nToll-free dialing restrictions: = \nhttp://www.webex.com/pdf/tollfree_restrictions.pdf\n\n\n\nCan't join = the meeting? Contact support = here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note = that this WebEx service allows audio and other information sent during = the session to be recorded, which may be discoverable in a legal matter. = By joining this session, you automatically consent to such recordings. = If you do not consent to being recorded, discuss your concerns with the = host or do not join the session.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Join WebEx = meeting =
Meeting number: 640 334 = 334
Meeting = password:smallandbig
 
 
Join by = phone 
1-877-668-4493 Call-in toll free = number (US/Canada) 
1-650-479-3208 Call-in toll number = (US/Canada) 
Access code: 640 334 334 
Toll-free calling = restrictions  


 
Can't join the = meeting? Contact support. =  
 
IMPORTANT NOTICE: Please note that this WebEx service = allows audio and other information sent during the session to be = recorded, which may be discoverable in a legal matter. By joining this = session, you automatically consent to such recordings. If you do not = consent to being recorded, discuss your concerns with the host or do not = join the session.=0A= SUMMARY:I2RS Interim=0A= PRIORITY:5=0A= CLASS:PUBLIC=0A= BEGIN:VALARM=0A= TRIGGER:-PT5M=0A= ACTION:DISPLAY=0A= DESCRIPTION:Reminder=0A= END:VALARM=0A= END:VEVENT=0A= END:VCALENDAR=0A= ------=_NextPart_000_0285_01D040B0.CA9F6590-- From nobody Wed Feb 4 17:20: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 6F51D1A0121; Wed, 4 Feb 2015 17:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 C43EbYpYSvcH; Wed, 4 Feb 2015 17:19:57 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF411A00FB; Wed, 4 Feb 2015 17:19:56 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id F293F2DCD430; Wed, 4 Feb 2015 20:19:55 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EBE866@dfweml701-chm> Date: Wed, 4 Feb 2015 20:19:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645EBE866@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" , "i2nsf@ietf.org" , Russ White , "Romascanu, Dan \(Dan\)" , Susan Hares Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 05 Feb 2015 01:19:59 -0000 > On Feb 4, 2015:5:22 PM, at 5:22 PM, Linda Dunbar = wrote: >=20 > Tom,=20 >=20 > Will those existing WGs you mentioned also do the following? >=20 > - a standard interface to express, monitor, and verify the security = policies on distributed security functions that may be running on = different premises. >=20 > This layer will leverage the existing protocols in RESTconf, AAA, = SACM, and security policy expression using Role Based Access Control = (RBAC), Mandatory Access Control (MAC), or Attribute-based access = control (ABAC). As I've mentioned before, Yang models for any of these things = can and are underway today. I couldn't agree more that they are not needed.=20 However, regarding the other stuff, I invite you to look at just = two examples of what is going on outside of the IETF. =20 These are real implementations documented publicly in some cases such as = Comcast presented at the last Openstack summit. = https://wiki.opendaylight.org/view/Network_Intent_Composition:Main https://wiki.openstack.org/wiki/Congress Based on that, I really don't see any need to do any of this = work in a new WG. Not only will it be a duplicate of a lot=20 of actual work already being done elsewhere, as far as I can tell, it = will not be doing so based on any real implementations/deployments=20 (i.e.: "running code" from the IETF's mantra). Or have I missed = something? > Those WGs charters don't have those objectives.=20 =09 That doesn't mean they couldn't be added to existing ones. I'd = also bet that is easier than lifting off a new WG=20 to accomplish these goals and will be more efficient as we won't be = adding the extra management/processing overhead to the already heavy load at the IETF. =20 --Tom >=20 > Thanks, Linda >=20 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]=20 > Sent: Wednesday, February 04, 2015 2:37 PM > To: Romascanu, Dan (Dan) > Cc: Linda Dunbar; Russ White; i2nsf@ietf.org; Susan Hares; = nfvrg@irtf.org; i2rs@ietf.org > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >=20 >=20 > They certainly could, without the added management overhead of a = new WG. >=20 > --Tom >=20 >> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) = wrote: >>=20 >> Tom, >>=20 >> I2NSF in its most recent (and better focused) charter includes IMs = and DMs for firewalls and IDSs, as well as a framework to manage = virtualized security services. Does LIME or other WG in the IETF do any = of these?=20 >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>> -----Original Message----- >>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D.=20= >>> Nadeau >>> Sent: Wednesday, February 04, 2015 9:50 PM >>> To: Linda Dunbar >>> Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org;=20 >>> i2rs@ietf.org >>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>=20 >>>=20 >>>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar >>> wrote: >>>>=20 >>>>=20 >>>> Thomas, >>>>=20 >>>> Comments inserted below: >>>>=20 >>>> -----Original Message----- >>>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. >>> Nadeau >>>> Sent: Wednesday, February 04, 2015 10:37 AM >>>> To: Linda Dunbar >>>> Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares;=20 >>>> i2rs@ietf.org >>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>>=20 >>>>=20 >>>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar >>> wrote: >>>>>=20 >>>>> Russ, >>>>>=20 >>>>> Thank you very much for the suggestion of framing in terms of = services. >>> What do you think with the following changes to the I2NSF charter=20 >>> with your suggestions added? >>>>>=20 >>>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to=20 >>>>> communicate >>> their specific security policies (request/monitor/report) to = security functions. >>> I2NSF will specify a vNSF framework, requirements for programmatic >>> interface to vNSF devices (configuration and dynamic programmatic) = , and >>> Information and Data models for security functions' Operation,=20 >>> Administration, Maintenance and Provisioning (OAM). The information=20= >>> models will include the following security functions: >>>>=20 >>>> Why wouldn't you do the models for those OAM functions where >>> those functions are modeled already? I don't see the need for a=20 >>> special WG that creates a subset of models that can done elsewhere=20= >>> like in LIME, or the Routing Area groups that are already chartered = to do this stuff. >>>>=20 >>>> [Linda] LIME addresses OAM for network layer, connectivity=20 >>>> (link/port) >>> failures, end to end performances measurement, whereas I2NSF is for=20= >>> security policies to be enforced by distributed (virtual) network=20 >>> security functions (vNSF). I2NSF provides a standard interface to=20 >>> express, monitor, and manage the security policies across = distributed=20 >>> security functions that may be running on different premises. >>>=20 >>> [TOM] The salient point I have been trying to make is that i2nsf = does=20 >>> not exist; LIME does. Why not just do it there (and other existing=20= >>> places in the IETF)? We seem to be working REALLY hard here to make=20= >>> up reasons why we need to form a new working group. I'd contend that=20= >>> it is not needed and that the management overhead + other overhead = of=20 >>> reviewing/processing documents like a new framework, requirements,=20= >>> etc... will unnecessarily spend precious IETF resources. >>>=20 >>> --Tom >>>=20 >>>=20 >>>> This leaves just doing requirements and a framework for this >>> proposed group, which without clear goals to build things from is a=20= >>> WG looking for a reason to exist rather than the other way around. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> * Firewall >>>>> including various services associated with FW, such as stateful = or >>> deep packet inspection, packet/flow/stream filtering and redirect=20= >>> (remote and local), etc >>>>>=20 >>>>> * Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) >>>>> Including intrusion detection (flow/stream pattern matching) >>>>>=20 >>>>>=20 >>>>> Linda >>>>>=20 >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >>>>> Sent: Tuesday, February 03, 2015 7:35 AM >>>>> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >>>>> Cc: nfvrg@irtf.org; i2rs@ietf.org >>>>> Subject: Re: [i2rs] revised charter for I2NSF >>>>>=20 >>>>>=20 >>>>> Interesting concept. One thought that might be helpful -- >>>>>=20 >>>>>> * Firewall >>>>>> * DDOS/Anti-DOS >>>>>> * Intrusion Detection System/ Intrusion Prevention System >>>>>> (IDS/IPS) >>>>>> * Access control/Authorization/Authentication >>>>>=20 >>>>> I think I would try to frame things in terms of services, rather=20= >>>>> than >>> devices, or a mix of the two. For instance -- what does a "firewall" = really do? >>> Stateful packet inspection, deep packet inspection, and... ?? So=20 >>> maybe a list something like this might make sense -- (and remember,=20= >>> this is brainstorming, nothing more) -- >>>>>=20 >>>>> - Stateful packet inspection >>>>> - Deep packet inspection >>>>> - Packet/flow/stream filtering (remote and local) >>>>> - Packet/flow/stream redirect (remote and local) >>>>> - Intrusion detection (or perhaps flow/stream pattern matching?) >>>>> - AAA >>>>>=20 >>>>> Don't know if this is a useful line of thought or not. >>>>>=20 >>>>> :-) >>>>>=20 >>>>> Russ >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>>=20 >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>=20 >=20 >=20 From nobody Wed Feb 4 18:01:08 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 B1F4C1A0187; Wed, 4 Feb 2015 18:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eqr1g6AyCi-8; Wed, 4 Feb 2015 18:00:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2371A0143; Wed, 4 Feb 2015 18:00:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOU09682; Thu, 05 Feb 2015 02:00:48 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 5 Feb 2015 02:00:47 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Wed, 4 Feb 2015 18:00:34 -0800 From: Linda Dunbar To: "Thomas D. Nadeau" Thread-Topic: [I2nsf] [i2rs] revised charter for I2NSF Thread-Index: AdA/RYwf8Tf2QsUATvS/fcnlsHOIcQAqtusAAAIyhYAAJ0n7UAARYL8AAApyUrD//+JvAIAAA1SAgAAJpICAAGqdUP//5H6AgAB/PlA= Date: Thu, 5 Feb 2015 02:00:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EBEA3C@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645EBE866@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" , "i2nsf@ietf.org" , Russ White , "Romascanu, Dan \(Dan\)" , Susan Hares Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 05 Feb 2015 02:01:01 -0000 Tom,=20 Thank you for the link to OpenDayLight and OpenStack on the intent driven o= pen source initiatives. We contribute to OpenStack and ODL as well. That was very drive that started I2NSF initiative at IETF. =20 Open source projects like OpenStack and CloudStack have begun to tackle the= interfaces to security functions but much work remains. There are many pie= ces of open sourced code, and there are a lot of areas not covered. The com= bined contributed source code are not comprehensive.=20 OpenStack completed the Firewall as a Service project and specified the set= of APIs for Firewall services: http://docs.openstack.org/admin-guide-cloud= /content/fwaas_api_abstractions.html OpenStack has defined the APIs for managing Security Groups: http://docs.op= enstack.org/admin-guide-cloud/content/securitygroup_api_abstractions.html The attributes defined by OpenStack Firewall/Security as a Service are very= primitive. they can be the basis for the I2NSF IETF initiative. Our goal is to form a Collaborative Loop from IETF to Industry Open Source = Communities (as Dave Ward said at Nov IETF Lunch session).=20 This is Diego Lopez (ETSI NFV Technical Committee chair) said about IETF an= d Open Source initiatives: Open-source initiatives are not to be considered as an alternative to forma= l standardization processes. On the contrary, they are complementary, with = the former acting as an enabler and accelerator of the latter. Open-source = provides an ideal mechanism to quick prototyping and validating contending = proposals, and demonstrating the feasibility of disruptive ideas that could= otherwise not be considered. In this respect, open-source facilitates the = engagement in the standardization process of small (and typically more dyna= mic) players such as start-ups and research groups, that would see better o= pportunities of being heard and a clearer rewards to their efforts. An open= -source approach is extremely useful as well for the production of open ref= erence implementations of the standards at the same (or even faster) pace t= hey are defined. The availability of such reference implementations transla= te into much simpler interoperability and conformance assessments for both = providers and users, and can become the basis for incremental differentiati= on of a common solution, thus allowing a cooperative competition ("coopetit= ion") model. Linda -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]=20 https://wiki.opendaylight.org/view/Network_Intent_Composition:Main https://wiki.openstack.org/wiki/Congress Based on that, I really don't see any need to do any of this work in a new= WG. Not only will it be a duplicate of a lot of actual work already being = done elsewhere, as far as I can tell, it will not be doing so based on any = real implementations/deployments (i.e.: "running code" from the IETF's mantra). Or have I missed something? > Those WGs charters don't have those objectives.=20 =09 That doesn't mean they couldn't be added to existing ones. I'd also bet th= at is easier than lifting off a new WG to accomplish these goals and will b= e more efficient as we won't be adding the extra management/processing over= head to the already heavy load at the IETF. =20 --Tom >=20 > Thanks, Linda >=20 > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] > Sent: Wednesday, February 04, 2015 2:37 PM > To: Romascanu, Dan (Dan) > Cc: Linda Dunbar; Russ White; i2nsf@ietf.org; Susan Hares;=20 > nfvrg@irtf.org; i2rs@ietf.org > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >=20 >=20 > They certainly could, without the added management overhead of a new WG. >=20 > --Tom >=20 >> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) wrote: >>=20 >> Tom, >>=20 >> I2NSF in its most recent (and better focused) charter includes IMs and D= Ms for firewalls and IDSs, as well as a framework to manage virtualized sec= urity services. Does LIME or other WG in the IETF do any of these?=20 >>=20 >> Regards, >>=20 >> Dan >>=20 >>=20 >>> -----Original Message----- >>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D.=20 >>> Nadeau >>> Sent: Wednesday, February 04, 2015 9:50 PM >>> To: Linda Dunbar >>> Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org;=20 >>> i2rs@ietf.org >>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>=20 >>>=20 >>>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar >>> wrote: >>>>=20 >>>>=20 >>>> Thomas, >>>>=20 >>>> Comments inserted below: >>>>=20 >>>> -----Original Message----- >>>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. >>> Nadeau >>>> Sent: Wednesday, February 04, 2015 10:37 AM >>>> To: Linda Dunbar >>>> Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares;=20 >>>> i2rs@ietf.org >>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>>=20 >>>>=20 >>>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar >>> wrote: >>>>>=20 >>>>> Russ, >>>>>=20 >>>>> Thank you very much for the suggestion of framing in terms of service= s. >>> What do you think with the following changes to the I2NSF charter=20 >>> with your suggestions added? >>>>>=20 >>>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to=20 >>>>> communicate >>> their specific security policies (request/monitor/report) to security f= unctions. >>> I2NSF will specify a vNSF framework, requirements for programmatic >>> interface to vNSF devices (configuration and dynamic programmatic) , = and >>> Information and Data models for security functions' Operation,=20 >>> Administration, Maintenance and Provisioning (OAM). The information=20 >>> models will include the following security functions: >>>>=20 >>>> Why wouldn't you do the models for those OAM functions where >>> those functions are modeled already? I don't see the need for a=20 >>> special WG that creates a subset of models that can done elsewhere=20 >>> like in LIME, or the Routing Area groups that are already chartered to = do this stuff. >>>>=20 >>>> [Linda] LIME addresses OAM for network layer, connectivity >>>> (link/port) >>> failures, end to end performances measurement, whereas I2NSF is for=20 >>> security policies to be enforced by distributed (virtual) network=20 >>> security functions (vNSF). I2NSF provides a standard interface to=20 >>> express, monitor, and manage the security policies across=20 >>> distributed security functions that may be running on different premise= s. >>>=20 >>> [TOM] The salient point I have been trying to make is that i2nsf=20 >>> does not exist; LIME does. Why not just do it there (and other=20 >>> existing places in the IETF)? We seem to be working REALLY hard=20 >>> here to make up reasons why we need to form a new working group. I'd=20 >>> contend that it is not needed and that the management overhead +=20 >>> other overhead of reviewing/processing documents like a new=20 >>> framework, requirements, etc... will unnecessarily spend precious IETF = resources. >>>=20 >>> --Tom >>>=20 >>>=20 >>>> This leaves just doing requirements and a framework for this >>> proposed group, which without clear goals to build things from is a=20 >>> WG looking for a reason to exist rather than the other way around. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> * Firewall >>>>> including various services associated with FW, such as stateful=20 >>>>> or >>> deep packet inspection, packet/flow/stream filtering and redirect=20 >>> (remote and local), etc >>>>>=20 >>>>> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) >>>>> Including intrusion detection (flow/stream pattern matching) >>>>>=20 >>>>>=20 >>>>> Linda >>>>>=20 >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >>>>> Sent: Tuesday, February 03, 2015 7:35 AM >>>>> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >>>>> Cc: nfvrg@irtf.org; i2rs@ietf.org >>>>> Subject: Re: [i2rs] revised charter for I2NSF >>>>>=20 >>>>>=20 >>>>> Interesting concept. One thought that might be helpful -- >>>>>=20 >>>>>> * Firewall >>>>>> * DDOS/Anti-DOS >>>>>> * Intrusion Detection System/ Intrusion Prevention System >>>>>> (IDS/IPS) >>>>>> * Access control/Authorization/Authentication >>>>>=20 >>>>> I think I would try to frame things in terms of services, rather=20 >>>>> than >>> devices, or a mix of the two. For instance -- what does a "firewall" re= ally do? >>> Stateful packet inspection, deep packet inspection, and... ?? So=20 >>> maybe a list something like this might make sense -- (and remember,=20 >>> this is brainstorming, nothing more) -- >>>>>=20 >>>>> - Stateful packet inspection >>>>> - Deep packet inspection >>>>> - Packet/flow/stream filtering (remote and local) >>>>> - Packet/flow/stream redirect (remote and local) >>>>> - Intrusion detection (or perhaps flow/stream pattern matching?) >>>>> - AAA >>>>>=20 >>>>> Don't know if this is a useful line of thought or not. >>>>>=20 >>>>> :-) >>>>>=20 >>>>> Russ >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S >>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>>=20 >>>=20 >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1 >>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>=20 >=20 >=20 From nobody Thu Feb 5 04:34:38 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 1465E1A87C6; Thu, 5 Feb 2015 04:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, 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 gQcM7RV2IhCq; Thu, 5 Feb 2015 04:34:22 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 88F7F1A87AF; Thu, 5 Feb 2015 04:34:22 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 122CD2DD5544; Thu, 5 Feb 2015 07:34:22 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EBEA3C@dfweml701-chm> Date: Thu, 5 Feb 2015 07:34:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5C981AB5@AZ-FFEXMB04.global.avaya.com> <799964DA-14E6-4218-89A1-AF5CC814B2FC@lucidvision.com> <4A95BA014132FF49AE685FAB4B9F17F645EBE866@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBEA3C@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "nfvrg@irtf.org" , "i2rs@ietf.org" , "i2nsf@ietf.org" , Russ White , "Romascanu, Dan \(Dan\)" , Susan Hares Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 05 Feb 2015 12:34:28 -0000 > On Feb 4, 2015:9:00 PM, at 9:00 PM, Linda Dunbar = wrote: >=20 > Tom,=20 >=20 > Thank you for the link to OpenDayLight and OpenStack on the intent = driven open source initiatives. We contribute to OpenStack and ODL as = well. > That was very drive that started I2NSF initiative at IETF. =20 > Open source projects like OpenStack and CloudStack have begun to = tackle the interfaces to security functions but much work remains. There = are many pieces of open sourced code, and there are a lot of areas not = covered. The combined contributed source code are not comprehensive.=20 >=20 > OpenStack completed the Firewall as a Service project and specified = the set of APIs for Firewall services: = http://docs.openstack.org/admin-guide-cloud/content/fwaas_api_abstractions= .html >=20 > OpenStack has defined the APIs for managing Security Groups: = http://docs.openstack.org/admin-guide-cloud/content/securitygroup_api_abst= ractions.html >=20 > The attributes defined by OpenStack Firewall/Security as a Service are = very primitive. they can be the basis for the I2NSF IETF initiative. >=20 > Our goal is to form a Collaborative Loop from IETF to Industry Open = Source Communities (as Dave Ward said at Nov IETF Lunch session).=20 There is no question that collaborative efforts make sense. = However, lets again get back to the specifics of this proposal and where you would collaborate. Models can and are being done elsewhere at = the IETF and outside of it. Policy is being done in those organizations just referenced. Why would those = organizations need yet another one to be specifying policy constructs? =20= What specific value would this new WG add to the equation (or subtract = from it)? You have not made a good case as to why in my opinion. --Tom > This is Diego Lopez (ETSI NFV Technical Committee chair) said about = IETF and Open Source initiatives: >=20 > Open-source initiatives are not to be considered as an alternative to = formal standardization processes. On the contrary, they are = complementary, with the former acting as an enabler and accelerator of = the latter. Open-source provides an ideal mechanism to quick prototyping = and validating contending proposals, and demonstrating the feasibility = of disruptive ideas that could otherwise not be considered. In this = respect, open-source facilitates the engagement in the standardization = process of small (and typically more dynamic) players such as start-ups = and research groups, that would see better opportunities of being heard = and a clearer rewards to their efforts. An open-source approach is = extremely useful as well for the production of open reference = implementations of the standards at the same (or even faster) pace they = are defined. The availability of such reference implementations = translate into much simpler interoperability and conformance assessments = for both providers and users, and can become the basis for incremental = differentiation of a common solution, thus allowing a cooperative = competition ("coopetition") model. >=20 >=20 > Linda > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com]=20 >=20 >=20 >=20 > = https://wiki.opendaylight.org/view/Network_Intent_Composition:Main >=20 > https://wiki.openstack.org/wiki/Congress >=20 > Based on that, I really don't see any need to do any of this = work in a new WG. Not only will it be a duplicate of a lot of actual = work already being done elsewhere, as far as I can tell, it will not be = doing so based on any real implementations/deployments > (i.e.: "running code" from the IETF's mantra). Or have I missed = something? >=20 >> Those WGs charters don't have those objectives.=20 > =09 > That doesn't mean they couldn't be added to existing ones. I'd = also bet that is easier than lifting off a new WG to accomplish these = goals and will be more efficient as we won't be adding the extra = management/processing overhead to the already heavy load at the IETF. =20= >=20 > --Tom >=20 >=20 >=20 >>=20 >> Thanks, Linda >>=20 >> -----Original Message----- >> From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] >> Sent: Wednesday, February 04, 2015 2:37 PM >> To: Romascanu, Dan (Dan) >> Cc: Linda Dunbar; Russ White; i2nsf@ietf.org; Susan Hares;=20 >> nfvrg@irtf.org; i2rs@ietf.org >> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>=20 >>=20 >> They certainly could, without the added management overhead of a = new WG. >>=20 >> --Tom >>=20 >>> On Feb 4, 2015:3:02 PM, at 3:02 PM, Romascanu, Dan (Dan) = wrote: >>>=20 >>> Tom, >>>=20 >>> I2NSF in its most recent (and better focused) charter includes IMs = and DMs for firewalls and IDSs, as well as a framework to manage = virtualized security services. Does LIME or other WG in the IETF do any = of these?=20 >>>=20 >>> Regards, >>>=20 >>> Dan >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D.=20= >>>> Nadeau >>>> Sent: Wednesday, February 04, 2015 9:50 PM >>>> To: Linda Dunbar >>>> Cc: Russ White; i2nsf@ietf.org; Susan Hares; nfvrg@irtf.org;=20 >>>> i2rs@ietf.org >>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>>=20 >>>>=20 >>>>> On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar >>>> wrote: >>>>>=20 >>>>>=20 >>>>> Thomas, >>>>>=20 >>>>> Comments inserted below: >>>>>=20 >>>>> -----Original Message----- >>>>> From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. >>>> Nadeau >>>>> Sent: Wednesday, February 04, 2015 10:37 AM >>>>> To: Linda Dunbar >>>>> Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares;=20 >>>>> i2rs@ietf.org >>>>> Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF >>>>>=20 >>>>>=20 >>>>>> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar >>>> wrote: >>>>>>=20 >>>>>> Russ, >>>>>>=20 >>>>>> Thank you very much for the suggestion of framing in terms of = services. >>>> What do you think with the following changes to the I2NSF charter=20= >>>> with your suggestions added? >>>>>>=20 >>>>>> In a nutshell, The Interface to vNSF (I2NSF) allows clients to=20 >>>>>> communicate >>>> their specific security policies (request/monitor/report) to = security functions. >>>> I2NSF will specify a vNSF framework, requirements for programmatic >>>> interface to vNSF devices (configuration and dynamic programmatic) = , and >>>> Information and Data models for security functions' Operation,=20 >>>> Administration, Maintenance and Provisioning (OAM). The = information=20 >>>> models will include the following security functions: >>>>>=20 >>>>> Why wouldn't you do the models for those OAM functions where >>>> those functions are modeled already? I don't see the need for a=20 >>>> special WG that creates a subset of models that can done elsewhere=20= >>>> like in LIME, or the Routing Area groups that are already chartered = to do this stuff. >>>>>=20 >>>>> [Linda] LIME addresses OAM for network layer, connectivity >>>>> (link/port) >>>> failures, end to end performances measurement, whereas I2NSF is for=20= >>>> security policies to be enforced by distributed (virtual) network=20= >>>> security functions (vNSF). I2NSF provides a standard interface to=20= >>>> express, monitor, and manage the security policies across=20 >>>> distributed security functions that may be running on different = premises. >>>>=20 >>>> [TOM] The salient point I have been trying to make is that i2nsf=20 >>>> does not exist; LIME does. Why not just do it there (and other=20 >>>> existing places in the IETF)? We seem to be working REALLY hard=20 >>>> here to make up reasons why we need to form a new working group. = I'd=20 >>>> contend that it is not needed and that the management overhead +=20 >>>> other overhead of reviewing/processing documents like a new=20 >>>> framework, requirements, etc... will unnecessarily spend precious = IETF resources. >>>>=20 >>>> --Tom >>>>=20 >>>>=20 >>>>> This leaves just doing requirements and a framework for this >>>> proposed group, which without clear goals to build things from is a=20= >>>> WG looking for a reason to exist rather than the other way around. >>>>>=20 >>>>> --Tom >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>> * Firewall >>>>>> including various services associated with FW, such as stateful=20= >>>>>> or >>>> deep packet inspection, packet/flow/stream filtering and redirect=20= >>>> (remote and local), etc >>>>>>=20 >>>>>> * Intrusion Detection System/ Intrusion Prevention System = (IDS/IPS) >>>>>> Including intrusion detection (flow/stream pattern matching) >>>>>>=20 >>>>>>=20 >>>>>> Linda >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >>>>>> Sent: Tuesday, February 03, 2015 7:35 AM >>>>>> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >>>>>> Cc: nfvrg@irtf.org; i2rs@ietf.org >>>>>> Subject: Re: [i2rs] revised charter for I2NSF >>>>>>=20 >>>>>>=20 >>>>>> Interesting concept. One thought that might be helpful -- >>>>>>=20 >>>>>>> * Firewall >>>>>>> * DDOS/Anti-DOS >>>>>>> * Intrusion Detection System/ Intrusion Prevention = System >>>>>>> (IDS/IPS) >>>>>>> * Access control/Authorization/Authentication >>>>>>=20 >>>>>> I think I would try to frame things in terms of services, rather=20= >>>>>> than >>>> devices, or a mix of the two. For instance -- what does a = "firewall" really do? >>>> Stateful packet inspection, deep packet inspection, and... ?? So=20 >>>> maybe a list something like this might make sense -- (and remember,=20= >>>> this is brainstorming, nothing more) -- >>>>>>=20 >>>>>> - Stateful packet inspection >>>>>> - Deep packet inspection >>>>>> - Packet/flow/stream filtering (remote and local) >>>>>> - Packet/flow/stream redirect (remote and local) >>>>>> - Intrusion detection (or perhaps flow/stream pattern matching?) >>>>>> - AAA >>>>>>=20 >>>>>> Don't know if this is a useful line of thought or not. >>>>>>=20 >>>>>> :-) >>>>>>=20 >>>>>> Russ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S= >>>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>>=20 >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> 3A__www.ietf.org_mailman_listinfo_i2rs&d=3DAwICAg&c=3DBFpWQw8bsuKpl1S= >>>> giZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kNB >>>> 30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DYlZUo4btDn8UA3sAV2F_rWaL >>>> TDFHlxo1ys_wiueV8NI&e=3D >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> I2nsf mailing list >>>>> I2nsf@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1= >>>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> I2nsf mailing list >>>> I2nsf@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >>>> 3A__www.ietf.org_mailman_listinfo_i2nsf&d=3DAwICAg&c=3DBFpWQw8bsuKpl1= >>>> SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3DZXR0kN >>>> B30D6uuCLkN0px7Hbz_TNzdlg8r9YRdZx4kuc&s=3DAag4Z_qnWDkR36ft_q- >>>> U7rpbPenEFmJgJ11F9yjW29E&e=3D >>>=20 >>=20 >>=20 >=20 >=20 From nobody Thu Feb 5 05:23: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 240E91A879A; Thu, 5 Feb 2015 05:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 EomWfvpMzlN3; Thu, 5 Feb 2015 05:22:54 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399381A87AA; Thu, 5 Feb 2015 05:22:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id t15DMijx020257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Feb 2015 13:22:45 GMT Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id t15DMhjJ014187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Feb 2015 14:22:44 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 5 Feb 2015 14:22:43 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0224.002; Thu, 5 Feb 2015 14:22:43 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available Thread-Index: AdA9Z1V9LrIizW9/SFC3DbYz1F9geAD3GWuA Date: Thu, 5 Feb 2015 13:22:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 39423 X-purgate-ID: 151667::1423142565-000067C4-BF5EA218/0/0 Archived-At: Cc: "i2rs@ietf.org" , "6lo@ietf.org" <6lo@ietf.org>, "ops-ads@tools.ietf.org" , "app-ads@tools.ietf.org" , "core@ietf.org" , "rtg-ads@tools.ietf.org" , "int-ads@tools.ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Subject: [i2rs] WG Last Call for draft-ietf-netconf-restconf-04 and draft-ietf-netconf-yang-patch-03 WAS:RE: Restconf-04 and YANG-Patch-03 drafts available 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, 05 Feb 2015 13:23:07 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, we hereby issue a WG Last Call for 3 weeks for the drafts below: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Please review and send your comments to the NETCONF WG mailing list by Febr= uary 26, 2015 EOB PT. The related draft-ietf-netconf-yang-library will follow with LC as soon as = the remaining two issues are solved (see http://tools.ietf.org/html/draft-ietf-netconf-yang-library). RESTCONF documents are planned to publish as standard track documents. As RESTCONF is a major protocol we expect a detailed and thorough review wi= thin NETCONF WG but also by the related WGs before publishing. Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs wil= l be informed as well as Core, I2rs, 6lo, and 6tisch WGs are invited to rev= iew. Please state explicitly that you have read/reviewed and whether you support= the publication. Please indicate also if you plan to implement or have already implementatio= n experience with RESTCONF. Thank you, Mehmet and Mahesh From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Meh= met (NSN - DE/Munich) Sent: Saturday, January 31, 2015 4:05 PM To: netconf@ietf.org Subject: [Netconf] Restconf-04 and YANG-Patch-03 drafts available All, 1 YANG patch and 9 Restconf issues have been solved and provided in the dra= fts below. These issues have been set to the status Review (https://github.com/netconf= -wg/restconf/issues). Please check and comment on the drafts below before we go to WGLC soon: https://tools.ietf.org/html/draft-ietf-netconf-restconf-04 https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-03 Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear NETCONF WG,

=

= we hereby issue a WG Last Call for 3 weeks for the drafts below:

=  

https://tools.ietf.org/html/draft-ietf-netconf-restconf-04

https://tools.ietf.org/html/draft-ietf-netconf-yang-patch-= 03

=  

= Please review and send your comments to the NETC= ONF WG mailing list by February 26, 2015 EOB PT.

= The related draft-ietf-netconf-yang-library will follow with LC as soon as the remaining two issues are solved <= /span>

= (see http://tools.ietf.org/html/draft-ietf-netco= nf-yang-library).

=

= RESTCONF documents are planned to publish as standard track documents.

= As RESTCONF is a major protocol we expect a deta= iled and thorough review within NETCONF WG but also by the related WGs before p= ublishing.

= Therefore the WGLC is planned for 3 weeks and APP, INT and RTG area ADs will be informed as well as Core, I2rs, 6lo, and= 6tisch WGs are invited to review.

=

= Please state explicitly that you have read/revie= wed and whether you support the publication.

= Please indicate also if you plan to implement or have already implementation experience with RESTCONF.=

=  

= Thank you,

= Mehmet and Mahesh

=  

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Ersue, Mehmet (NSN - DE/Munich)
Sent: Saturday, January 31, = 2015 4:05 PM
To: netconf@ietf.org
Subject: [Netconf] Restconf-= 04 and YANG-Patch-03 drafts available

 

All,

 

1 YANG patch and 9 Restconf = issues have been solved and provided in the drafts below.

These issues have been set t= o the status Review (https://github.com/netconf-wg/restconf/issues).

 

Please check and comment on = the drafts below before we go to WGLC soon:

=  

= Regards,
Mehmet

=  

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F819611D6CDEMUMBX005nsnin_-- From nobody Thu Feb 5 07:10: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 4444B1A88FE for ; Thu, 5 Feb 2015 07:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, 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 VotAGzhnlYvs for ; Thu, 5 Feb 2015 07:09:39 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAB0B1A8958 for ; Thu, 5 Feb 2015 07:09:36 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id k14so8094225wgh.8 for ; Thu, 05 Feb 2015 07:09:30 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=hMGY6fGFCCEDdJpT5s0M7qdp3ZYwAjwRhACcEn6y2Vc=; b=tNC0Tt4IAQ+UUnhR0ASgDzwxCIAHNEFbb6xgbBJvNJUylhBptcz4c4iDIvx05axh2+ j0SkGWL5NOy4HXIGLnrpcOhUUvoMkGdqpYl72xbfkt9lhiItwme6MGn5L3jBDd/kvYf8 XLtEw8GAa46mB4NHgPrAF4QxGelKm+FqTfIH+9vmVxvfpLq1eRlpKWWcN3BQ9j09rvfH VQXUq4ROCp1nl69Blsrj//E5/J9431dWDy2Dq/l8Q4oUy9elO5NWm2UN18WwdAdZZJpd O2EIzl/RGKOumt2mkGRiccut07/i3OWXfNwAF6eJ/9Uas3A/M/XptanbsRX3vu9aeHoC ZLqQ== X-Received: by 10.180.100.202 with SMTP id fa10mr16210096wib.10.1423148970564; Thu, 05 Feb 2015 07:09:30 -0800 (PST) Received: from ams-giheron-89110.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id x18sm8271360wia.12.2015.02.05.07.09.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 07:09:29 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Giles Heron In-Reply-To: <028401d040da$b3728760$1a579620$@ndzh.com> Date: Thu, 5 Feb 2015 15:09:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <028401d040da$b3728760$1a579620$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org, Dean Bogdanovic , akatlas@gmail.com Subject: Re: [i2rs] I2RS interim on 2/5/2015 at 10:00am - 11:00 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, 05 Feb 2015 15:09:44 -0000 is there a time-zone mixup with this? the invite below says 10am EST. I suspect you meant 10am PST - given = that we have a total of 4 people on the WebEx. or maybe nobody (including the chairs) cares about I2RS any more. ;) On 5 Feb 2015, at 00:28, Susan Hares wrote: > The I2RS interim on 2/5/2015 at 10:00am has the following agenda = regarding the I2RS protocol > =20 > 1) 7 primitives that should be exposed from the I2RS Agent (Dean = Bogdanovic) > 2) Discussion on 7 primitives > =20 > Our discussion on the I2RS protocol are aimed at providing = requirements for the I2RS protocol. > =20 > Our past discussion have considered a smaller protocol and the use of = netconf/restconf for full functionality. Dan=92s presentation is = considering what has to be in a protocol =96 small or large. The I2RS = goal is to consider these requirements and finalize an I2RS protocol = requirements document in February that will be discussed for WG adoption = in IETF 92. > =20 > For those who have proposed a protocol requirements in the past, and = would like to join a design team completing the I2RS protocol = requirements please esnd me a note. > =20 > Sue =20 > =20 > From: I2RS Working Group [mailto:messenger@webex.com]=20 > Sent: Wednesday, February 04, 2015 7:16 PM > To: i2rs-chairs@tools.ietf.org > Subject: (Forward to others) WebEx meeting invitation: I2RS Interim > =20 > You can forward this invitation to others. > Hello, > I2RS Working Group invites you to join this WebEx meeting. > =20 > I2RS Interim > Thursday, February 5, 2015 > 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 = mins > =20 > Join WebEx meeting > Meeting number: > 640 334 334 > Meeting password: > smallandbig > =20 > Join by phone > 1-877-668-4493 Call-in toll free number (US/Canada) > 1-650-479-3208 Call-in toll number (US/Canada) > Access code: 640 334 334 > Toll-free calling restrictions > =20 > Add this meeting to your calendar. > =20 > Can't join the meeting? Contact support. > =20 > IMPORTANT NOTICE: Please note that this WebEx service allows audio and = other information sent during the session to be recorded, which may be = discoverable in a legal matter. By joining this session, you = automatically consent to such recordings. If you do not consent to being = recorded, discuss your concerns with the host or do not join the = session. > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 5 07:12: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 4E8361A897B for ; Thu, 5 Feb 2015 07:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.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, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcVeg1MDeHYK for ; Thu, 5 Feb 2015 07:12:33 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85FE1A8971 for ; Thu, 5 Feb 2015 07:11:19 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so777391yks.5 for ; Thu, 05 Feb 2015 07:11:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aB6pEiA9LHG3xHVuvmT//OgtM/TIk80KuQplph1UEw8=; b=W3g0JaqQux3oKlEXWTvH/gvwbZ3ol/LuX4nvH7+YGpFncs/n8uisZzKD0eYzrESZ/w 76y1hpTmT3qIZQ3EtQJ7kYRDRLk0vKmtXqLz7jHXiZNY35RRTZ8fM6Fjfk+4Vq9p2UoR yTf3yF0BXj/zb2AAA06dd+zWKbUD/qnYGQq9CpdCYxwXHFdq1pq0lQRvzYIIOyLfpYiv QNgXC5utPvE7zLoiv0kwMHqLdvN1dKbC0/lJQXGahlyiU0m58hHicBUbYYP5Rm17KJ5b lEKqNGTqj1MFn6VJ65qGX0Fu/kJRdwjkkD+p5S51wHfCDYRBt1ih9uJzlLjVFKbkrvCq MsIA== MIME-Version: 1.0 X-Received: by 10.170.119.195 with SMTP id l186mr1586387ykb.51.1423149078990; Thu, 05 Feb 2015 07:11:18 -0800 (PST) Received: by 10.170.133.80 with HTTP; Thu, 5 Feb 2015 07:11:18 -0800 (PST) In-Reply-To: References: <028401d040da$b3728760$1a579620$@ndzh.com> Date: Thu, 5 Feb 2015 10:11:18 -0500 Message-ID: From: Alia Atlas To: Giles Heron Content-Type: multipart/alternative; boundary=001a1137941c50d637050e58b7da Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Dean Bogdanovic , Susan Hares Subject: Re: [i2rs] I2RS interim on 2/5/2015 at 10:00am - 11:00 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, 05 Feb 2015 15:12:38 -0000 --001a1137941c50d637050e58b7da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There was confusion with different webex sessions. The meeting is happening on the webex in this email - not what was in, at least, my calendar. It's *Join WebEx meeting* Meeting number: 640 334 334 On Thu, Feb 5, 2015 at 10:09 AM, Giles Heron wrote: > is there a time-zone mixup with this? > > the invite below says 10am EST. I suspect you meant 10am PST - given > that we have a total of 4 people on the WebEx. > > or maybe nobody (including the chairs) cares about I2RS any more. ;) > > On 5 Feb 2015, at 00:28, Susan Hares wrote: > > > The I2RS interim on 2/5/2015 at 10:00am has the following agenda > regarding the I2RS protocol > > > > 1) 7 primitives that should be exposed from the I2RS Agent (Dean > Bogdanovic) > > 2) Discussion on 7 primitives > > > > Our discussion on the I2RS protocol are aimed at providing requirements > for the I2RS protocol. > > > > Our past discussion have considered a smaller protocol and the use of > netconf/restconf for full functionality. Dan=E2=80=99s presentation is c= onsidering > what has to be in a protocol =E2=80=93 small or large. The I2RS goal is = to > consider these requirements and finalize an I2RS protocol requirements > document in February that will be discussed for WG adoption in IETF 92. > > > > For those who have proposed a protocol requirements in the past, and > would like to join a design team completing the I2RS protocol requirement= s > please esnd me a note. > > > > Sue > > > > From: I2RS Working Group [mailto:messenger@webex.com] > > Sent: Wednesday, February 04, 2015 7:16 PM > > To: i2rs-chairs@tools.ietf.org > > Subject: (Forward to others) WebEx meeting invitation: I2RS Interim > > > > You can forward this invitation to others. > > Hello, > > I2RS Working Group invites you to join this WebEx meeting. > > > > I2RS Interim > > Thursday, February 5, 2015 > > 10:00 am | Eastern Standard Time (New York, GMT-05:00) | 1 hr 30 mi= ns > > > > Join WebEx meeting > > Meeting number: > > 640 334 334 > > Meeting password: > > smallandbig > > > > Join by phone > > 1-877-668-4493 Call-in toll free number (US/Canada) > > 1-650-479-3208 Call-in toll number (US/Canada) > > Access code: 640 334 334 > > Toll-free calling restrictions > > > > Add this meeting to your calendar. > > > > Can't join the meeting? Contact support. > > > > IMPORTANT NOTICE: Please note that this WebEx service allows audio and > other information sent during the session to be recorded, which may be > discoverable in a legal matter. By joining this session, you automaticall= y > consent to such recordings. If you do not consent to being recorded, > discuss your concerns with the host or do not join the session. > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > --001a1137941c50d637050e58b7da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There was confusion with different webex sessions.
The= meeting is happening on the webex in this email - not what was in, at leas= t, my calendar.

It's

Join WebEx meeting<= /p>


Meeting number:<= /p>

640 334 334


On Thu, Feb 5, 2015= at 10:09 AM, Giles Heron <giles.heron@gmail.com> wrote:=
is there a time-zone mixup with this?
the invite below says 10am EST.=C2=A0 =C2=A0I suspect you meant 10am PST - = given that we have a total of 4 people on the WebEx.

or maybe nobody (including the chairs) cares about I2RS any more. ;)

On 5 Feb 2015, at 00:28, Susan Hares <shares@ndzh.com> wrote:

> The I2RS interim on 2/5/2015 at 10:00am has the following agenda regar= ding the I2RS protocol
>
> 1)=C2=A0 =C2=A0 =C2=A0 7 primitives that should be exposed from the I2= RS Agent=C2=A0 (Dean Bogdanovic)
> 2)=C2=A0 =C2=A0 =C2=A0 Discussion on 7 primitives
>
> Our discussion on the I2RS protocol are aimed at providing requirement= s for the I2RS protocol.
>
> Our past discussion have considered a smaller protocol and the use of = netconf/restconf for full functionality.=C2=A0 Dan=E2=80=99s presentation i= s considering what has to be in a protocol =E2=80=93 small or large.=C2=A0 = The I2RS goal is to consider these requirements and finalize an I2RS protoc= ol requirements document in February that will be discussed for WG adoption= in IETF 92.
>
> For those who have proposed a protocol requirements in the past, and w= ould like to join a design team completing the I2RS protocol requirements p= lease esnd me a note.
>
> Sue
>
> From: I2RS Working Group [mailto:messenger@webex.com]
> Sent: Wednesday, February 04, 2015 7:16 PM
> To: i2rs-chairs@tools.ie= tf.org
> Subject: (Forward to others) WebEx meeting invitation: I2RS Interim >
> You can forward this invitation to others.
> Hello,
> I2RS Working Group invites you to join this WebEx meeting.
>
> I2RS Interim
> Thursday, February 5, 2015
> 10:00 am=C2=A0 |=C2=A0 Eastern Standard Time (New York, GMT-05:00)=C2= =A0 |=C2=A0 1 hr 30 mins
>
> Join WebEx meeting
> Meeting number:
> 640 334 334
> Meeting password:
> smallandbig
>
> Join by phone
> 1-877-668-4493 Call-in toll free number (US/Canada)
> 1-650-479-3208 Call-in toll number (US/Canada)
> Access code: 640 334 334
> Toll-free calling restrictions
>
> Add this meeting to your calendar.
>
> Can't join the meeting? Contact support.
>
> IMPORTANT NOTICE: Please note that this WebEx service allows audio and= other information sent during the session to be recorded, which may be dis= coverable in a legal matter. By joining this session, you automatically con= sent to such recordings. If you do not consent to being recorded, discuss y= our concerns with the host or do not join the session.
>
> <WebEx_Meeting.ics>_________________________________= ______________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs


--001a1137941c50d637050e58b7da-- From nobody Thu Feb 5 07:36: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 8BD561A888F for ; Thu, 5 Feb 2015 07:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQEAGq-5uCEw for ; Thu, 5 Feb 2015 07:36:22 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BCF1A8843 for ; Thu, 5 Feb 2015 07:36:21 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id h11so39740836wiw.5 for ; Thu, 05 Feb 2015 07:36:20 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=BjbTXuurstbNUM6iCfMdPZ/M2RqDYb8cn6W1+m70L+0=; b=m1nLlHr08KpxvASrLRr8muZTJvnKiaXYEAYKqlFD48yKhJQiWsBQRqvaERNJt9+2Xe 6CONYcozSnnKosR0U+6aDZiVPaLuLnV/kC8bYCwwM3VCfG3QpNK+eeg6yRukeciowyjI Sp0M+5TEYzVU2AtUvPmKhSBNLQZcXwFntjr2PvEuv4RS4rTmWV01tlNw3/sJdbC0/IEJ RbaOJDMkjEWsvBlcClKSZSLr1fuo8JFXNCFdaPfdRa1zisPRDtJCCTOhyumolDDIIKmL n0vfEJOQSLuqM6YYy/mmnRqnbjJpbzTmi1yhfnVPiXr8gbqHLgn5ykm/LCKIl3bVpTJb 6clg== X-Received: by 10.180.11.235 with SMTP id t11mr32452358wib.33.1423150580360; Thu, 05 Feb 2015 07:36:20 -0800 (PST) Received: from ams-giheron-89110.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id k6sm11666320wia.6.2015.02.05.07.36.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Feb 2015 07:36:19 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Giles Heron In-Reply-To: <011101d03f43$6b2b6870$41823950$@ndzh.com> Date: Thu, 5 Feb 2015 15:36:16 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <011101d03f43$6b2b6870$41823950$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 05 Feb 2015 15:36:24 -0000 support - it's a good starting point. On 2 Feb 2015, at 23:53, Susan Hares wrote: > This begins a 2 week WG Adoption call for: = draft-voit-i2rs-pub-sub-requirements-00 (2/2 to 2/16/2015). You can = access the draft at: > =20 > http://www.ietf.org/id/draft-voit-i2rs-pub-sub-requirements-00.txt > =20 > The current I2RS charter states: > =20 > =93The I2RS working group works to develop a high-level architecture = that describes the basic building-blocks necessary to enable the = specific use cases, and that will lead to an understanding of the = abstract informational models and requirements for encodings and = protocols for the I2RS interfaces.=94 > =20 > This draft is part of setting the requirements for the I2RS protocol.=20= > =20 > As Andy has noted in early email, there may be nothing specific to = I2RS in draft-voit-i2rs-pub-sub-requirements-00.txt. It may be = something that should be just a part of the netconf/restconf = functionality. As part of the adoption of this draft, the I2RS chairs = would like to hear your opinion of Andy=92s statement. Andy also = suggests that draft-netmod-clemm-datastore-push-00 should also be part = of the I2RS requirements. > =20 > http://www.ietf.org/mail-archive/web/i2rs/current/msg02252.html > =20 > [chair hat-off] IMHO, I think Andy is correct. [chair-hat on ]. > =20 > If the WG approves adoption of = draft-voit-i2rs-pub-sub-requirements-00.txt and the WG feels these = drafts should be netmod WG drafts with I2RS holding a requirement = drafts, the I2RS chairs will do the right thing to make it happen. If = enough people comment that draft-netmod-clemm-datastore-push-00 should = be part of the I2RS requirements, we will do a WG adoption of call for = this requirement. =20 > =20 > Sue Hares > =20 > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Feb 5 10:31:06 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 A612B1A1B35 for ; Thu, 5 Feb 2015 10:31:02 -0800 (PST) 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_20=-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 LekS3G2sQEcZ for ; Thu, 5 Feb 2015 10:30:59 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3A1A1B25 for ; Thu, 5 Feb 2015 10:30:59 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Thu, 5 Feb 2015 13:30:48 -0500 Message-ID: <01b201d04171$de254a00$9a6fde00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B3_01D04147.F5507A80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBBcdcjMgcF7ws6SJea8lvjXHr/2w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: bclaise@cisco.com, adrian@olddog.co.uk, Alia Atlas , 'Jeffrey Haas' Subject: [i2rs] I2RS interim meetings in February 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, 05 Feb 2015 18:31:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B3_01D04147.F5507A80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit A question arose at today's interim about schedules for I2RS adoption about the I2RS plan for drafts. This email provides details on the i2RS schedule for the next 3 months (February-April) and our goals. The chairs always welcome feedback on our schedule and objectives. Sue Hares and Jeff Haas --------- I2RS Focus and Schedule The current focus for the I2RS WG is the following things in priority: 1. Complete to WG LC the Protocol Requirements 2. Complete to WG LC the Protocol Independent RIB Information Model and Yang Data Model 3. Complete to WG LC the Protocol Independent Topology modules (Generic, L1, L2, L3, Service, TED) plus the protocol independent Policy-Based Routing Module Individual or I2RS Documents exist for all of these features. A complete set of these documents will be available by 2/26/2015 for review prior to the I2RS 3/5/2015 virtual interim (10:00 - 12:00 ET). A WG Adoption call will be made on 3/6/2015 for this set of documents, and a WG LC call after the I2RS session at IETF 92. Interim Meetings December to February ------------------------- The interim meetings in December examined enough of: a) RIB Information Model and Data model, and b) Protocol Independent Topology Yang Data Modules so that design teams could be formed for this work. Design have been operating for these groups for 2 weeks. The interims in January and February have examined the protocol requirements for a I2RS protocol. Two versions of the protocol have been discussed: a) fully capable protocol and b) minimal set based. The WG decided that netconf/restconf would be the initial direction for the fully capable protocol and requirements would be given to the netconf/restconf WGs. Today's interim had a proposal from Dean Bogdanovic (deanb@juniper.net) on the minimal set protocol capabilities and modules. The I2RS group is looking for feedback from implementers in February and March to validate the WGs direction in protocol and modules. Design teams Information --------------------- The design teams for these drafts are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki The I2RS Information Model and Yang Model work design team has completed its discussions. A revision to the draft will be out by 2/26/2015. The topology design team is producing a coherent set of Yang Data Modules for generic, L1, L2, L3, Service Layer, TED and PBR modules. A single summary Information model is being created in order to provide an introductory text. Interest parties can send a note to me (shares@ndzh.com) if you wish to join the design team. The Topology design team meets at 8pm ET/5pm PT on Thursdays, and you can find the webex number on the wiki page at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams The interim meeting on 3/5/2016 10-11am will have an open discussion of these Yang modules. Attendees are expected to have read the modules before attending the modules. ------=_NextPart_000_01B3_01D04147.F5507A80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A question = arose at today’s interim about schedules for I2RS adoption about = the I2RS plan for drafts.  This email provides details on the i2RS = schedule for the next 3 months (February-April) and our goals.  The = chairs always welcome feedback on our schedule and objectives. =

 

Sue Hares and Jeff Haas

 

---------

I2RS = Focus and Schedule

 

The current = focus for the I2RS WG is the following things in = priority:

 

1.       = Complete to WG LC the Protocol Requirements =  

2.       = Complete to WG LC the Protocol Independent RIB = Information Model and Yang Data Model

3.       = Complete to WG LC the Protocol Independent = Topology modules (Generic, L1, L2, L3, Service, TED) plus the protocol = independent Policy-Based Routing Module

 

Individual = or I2RS Documents exist for all of these features.  A complete set = of these documents will be available by 2/26/2015 for review prior to = the I2RS 3/5/2015 virtual interim (10:00 – 12:00 ET).  =  A WG Adoption call will be made on 3/6/2015 for this set of = documents, and a WG LC call after the I2RS session at IETF 92. =  

 

Interim Meetings December to February

-------------------------

The interim meetings in December examined enough of: = a) RIB Information Model and Data model, and b) Protocol Independent = Topology Yang Data Modules so that design teams could be formed for this = work.  Design have been operating for these groups for 2 weeks. =

 

The interims in January and February have examined the = protocol requirements for a I2RS protocol. 

Two versions of the protocol have been discussed: a) = fully capable protocol and b) minimal set based. The WG decided that = netconf/restconf would be the initial direction for the fully capable = protocol and requirements would be given to the netconf/restconf = WGs.  Today’s interim had a proposal from Dean Bogdanovic (deanb@juniper.net) on the minimal = set protocol capabilities and modules.  

 

The I2RS = group is looking for feedback from implementers in February and March to = validate the WGs direction in protocol and modules.

 

Design = teams Information

---------------------

The design teams for these drafts are at: =

 

http://trac.tools.i= etf.org/wg/i2rs/trac/wiki

 

The I2RS = Information Model and Yang Model work design team has completed its = discussions.  A revision to the draft will be out by = 2/26/2015.   

 

The topology = design team is producing a coherent set of Yang Data Modules for = generic, L1, L2, L3, Service Layer, TED and PBR modules.  A single = summary Information model is being created in order to provide an = introductory text.  Interest parties can send a note to me (shares@ndzh.com) if you wish to join = the design team.  The Topology design team meets at 8pm ET/5pm PT = on Thursdays, and you can find the webex number on the wiki page at: =

 

http://trac.tools.ietf.org/wg/i2rs/trac/wiki/TopologyDesignTeams

 

The interim meeting on 3/5/2016 10-11am will have an = open discussion of these Yang modules.  Attendees are expected to = have read the modules before attending the modules.

  

------=_NextPart_000_01B3_01D04147.F5507A80-- From nobody Fri Feb 6 08:33: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 80FEB1A6FE6 for ; Fri, 6 Feb 2015 08:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 s0DtFUXQq7Yn for ; Fri, 6 Feb 2015 08:33:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0741.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::741]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC4C1A6FE9 for ; Fri, 6 Feb 2015 08:33:04 -0800 (PST) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.1.75.20; Fri, 6 Feb 2015 16:32:41 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) with mapi id 15.01.0075.002; Fri, 6 Feb 2015 16:32:41 +0000 From: Dean Bogdanovic To: Linda Dunbar Thread-Topic: [i2rs] Does I2RS charter include both the interface to Network Controller and the interface to devices (i.e. routers)? Thread-Index: AdA6iyeKSdo2AdXvRzuimrSC+NP/RgHn1wwA Date: Fri, 6 Feb 2015 16:32:41 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EB6E7F@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EB6E7F@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.14] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(40100003)(86362001)(110136001)(66066001)(33656002)(561944003)(46102003)(2656002)(16236675004)(82746002)(83716003)(99286002)(19580395003)(122556002)(87936001)(36756003)(92566002)(76176999)(50986999)(2900100001)(77156002)(50226001)(19580405001)(62966003)(2950100001)(19617315012)(102836002)(57306001)(15975445007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BD869783442746CBA07EB81D882EF888junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2015 16:32:41.2964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB422 Archived-At: Cc: "jhaas@pfrc.org" , "i2rs@ietf.org" , Susan Hares Subject: Re: [i2rs] Does I2RS charter include both the interface to Network Controller and the interface to devices (i.e. routers)? 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, 06 Feb 2015 16:33:21 -0000 --_000_BD869783442746CBA07EB81D882EF888junipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Linda, I understand now your question (based on reading I2NSF emails). I2RS has two elements, agent and client and I2RS agent is sitting on the ne= twork device and exposes north bound interface to the I2RS client. How I2RS= agent communicates to the device is not specified. This is up to the imple= mentors to decide. How to communicate between I2RS agent and client, RESTCO= NF and YANG have been proposed. The interface from I2RS client northbound i= s not part of the WG. Now interface between I2RS agent and client can have multiple capabilities,= but my proposal is to expose basic capabilities (interface, routing, filte= ring, class of service) of the network device that can be used to manipulat= e traffic forwarding behavior of the device. There is nothing preventing to= expose higher level capabilities, like LxVPNs, by I2RS agent to be control= led by I2RS client. Please take a look at the Fig1 Figure 1: Architecture of I2RS clients and a= gents in http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/?inc= lude_text=3D1 Dean On Jan 27, 2015, at 6:44 PM, Linda Dunbar > wrote: I2RS charter states: It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. This statement makes me believe that I2RS charter includes both the interfa= ce to Network Controller (i.e. North Bound Interface) and the Interface to = devices/routers (i.e. South Bound Interface). The interface to =93Network Controller=94 should be more Service oriented, = e.g. allowing applications to indicate their desired features, enforcing a= specific QoS for some applications The interface to =93devices (routers)=94 should be more functional oriented= , e.g. enabling ISIS on a specific port, or, etc. Is it reasonable for I2RS to have two distinct layers of interfaces? Linda Dunbar _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_BD869783442746CBA07EB81D882EF888junipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <461DD0643B92C8409485CFFA3645C464@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Linda,

I understand now your question (based on reading I2NSF emails).

I2RS has two elements, agent and client and I2RS agent is sitting on t= he network device and exposes north bound interface to the I2RS client. How= I2RS agent communicates to the device is not specified. This is up to the = implementors to decide. How to communicate between I2RS agent and client, RESTCONF and YANG have been proposed. The i= nterface from I2RS client northbound is not part of the WG.

Now interface between I2RS agent and client can have multiple capabili= ties, but my proposal is to expose basic capabilities (interface, routing, = filtering, class of service) of the network device that can be used to mani= pulate traffic forwarding behavior of the device. There is nothing preventing to expose higher level capabili= ties, like LxVPNs, by I2RS agent to be controlled by I2RS client.

Please take a look at the Fig1 Figure 1: Architecture of I2RS clients = and agents  in http://datatracker.ietf.org/d= oc/draft-ietf-i2rs-architecture/?include_text=3D1

Dean

On Jan 27, 2015, at 6:44 PM, Linda Dunbar <linda.dunbar@huawei.com> wrote:

I2RS charter states:
 
It is = envisioned that users of the I2RS interfaces will be management 
applications, network controllers, and user applications that make 
specific demands on the network.
 
 
This statement makes me believe that I2RS charter includes both the interfa= ce to Network Controller (i.e. North Bound Interface) and the Interface to = devices/routers (i.e. South Bound Interface).
 
The interface to =93Network Controller=94 should be more Service oriented, = e.g. allowing applications to indicate their desired features,  enforc= ing a specific QoS for some applications
 
The interface to =93devices (routers)=94 should be more functional oriented= , e.g. enabling ISIS on a specific port, or, etc.
 
Is it reasonable for I2RS to have two distinct layers of interfaces?
 
Linda Dunbar
 
 
_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2r= s

--_000_BD869783442746CBA07EB81D882EF888junipernet_-- From nobody Fri Feb 6 10:05:53 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 76D3B1A870C; Fri, 6 Feb 2015 10:05:26 -0800 (PST) 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 BOR5eKzrw8sY; Fri, 6 Feb 2015 10:05:24 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 8B31C1A1E0F; Fri, 6 Feb 2015 10:05:23 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Thomas D. Nadeau'" , "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> In-Reply-To: Date: Fri, 6 Feb 2015 13:04:59 -0500 Message-ID: <011601d04237$6ca4d280$45ee7780$@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: AQHe8BNDJn34omqge3ix4XQ/UM6E/QKkAZ6TAhEHlGoA7PstLgL0bo3yAiYGG1IBpH4qW5xjg6tw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Russ White' , i2nsf@ietf.org, nfvrg@irtf.org, i2rs@ietf.org Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 06 Feb 2015 18:05:33 -0000 Tom: I'm catching up with emails after a few days of I2RS interims and design teams - so I apologize if this comes out of sequence. LIME has a solid basis in looking at generic OAM modules. I would not like to see the generic OAM work of LIME defocused by defining the vNSF functions. The two efforts work better in parallel. An example of this is the LIME OAM and the TRILL yang models (oam, fm, pm) with I2RS modules upcoming. You can look at IETF 90 for TIssa's original proposal in TRILL. The presentations and the ETSI work has demonstrated the desire for the vNSF requirements to be standardized. A WG with a short-term focus of defining Security and Networking people to decide what is needed for an interoperable vNSF. This type of effort creates a 12-18 month WG life-cycle that should aid OAM in LIME and the mechanisms in netconf/restconf. Sue -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@lucidvision.com] Sent: Wednesday, February 04, 2015 2:50 PM To: Linda Dunbar Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; i2rs@ietf.org Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > On Feb 4, 2015:2:44 PM, at 2:44 PM, Linda Dunbar wrote: > > > Thomas, > > Comments inserted below: > > -----Original Message----- > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Thomas D. Nadeau > Sent: Wednesday, February 04, 2015 10:37 AM > To: Linda Dunbar > Cc: Russ White; i2nsf@ietf.org; nfvrg@irtf.org; Susan Hares; i2rs@ietf.org > Subject: Re: [I2nsf] [i2rs] revised charter for I2NSF > > >> On Feb 4, 2015:11:25 AM, at 11:25 AM, Linda Dunbar wrote: >> >> Russ, >> >> Thank you very much for the suggestion of framing in terms of services. What do you think with the following changes to the I2NSF charter with your suggestions added? >> >> In a nutshell, The Interface to vNSF (I2NSF) allows clients to communicate their specific security policies (request/monitor/report) to security functions. I2NSF will specify a vNSF framework, requirements for programmatic interface to vNSF devices (configuration and dynamic programmatic) , and Information and Data models for security functions' Operation, Administration, Maintenance and Provisioning (OAM). The information models will include the following security functions: > > Why wouldn't you do the models for those OAM functions where those functions are modeled already? I don't see the need for a special WG that creates a subset of models that can done elsewhere like in LIME, or the Routing Area groups that are already chartered to do this stuff. > > [Linda] LIME addresses OAM for network layer, connectivity (link/port) failures, end to end performances measurement, whereas I2NSF is for security policies to be enforced by distributed (virtual) network security functions (vNSF). I2NSF provides a standard interface to express, monitor, and manage the security policies across distributed security functions that may be running on different premises. [TOM] The salient point I have been trying to make is that i2nsf does not exist; LIME does. Why not just do it there (and other existing places in the IETF)? We seem to be working REALLY hard here to make up reasons why we need to form a new working group. I'd contend that it is not needed and that the management overhead + other overhead of reviewing/processing documents like a new framework, requirements, etc... will unnecessarily spend precious IETF resources. --Tom > This leaves just doing requirements and a framework for this proposed group, which without clear goals to build things from is a WG looking for a reason to exist rather than the other way around. > > --Tom > > > >> >> * Firewall >> including various services associated with FW, such as stateful or deep packet inspection, packet/flow/stream filtering and redirect (remote and local), etc >> >> * Intrusion Detection System/ Intrusion Prevention System (IDS/IPS) >> Including intrusion detection (flow/stream pattern matching) >> >> >> Linda >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White >> Sent: Tuesday, February 03, 2015 7:35 AM >> To: 'Susan Hares'; Linda Dunbar; i2nsf@ietf.org >> Cc: nfvrg@irtf.org; i2rs@ietf.org >> Subject: Re: [i2rs] revised charter for I2NSF >> >> >> Interesting concept. One thought that might be helpful -- >> >>> * Firewall >>> * DDOS/Anti-DOS >>> * Intrusion Detection System/ Intrusion Prevention System >>> (IDS/IPS) >>> * Access control/Authorization/Authentication >> >> I think I would try to frame things in terms of services, rather than devices, or a mix of the two. For instance -- what does a "firewall" really do? Stateful packet inspection, deep packet inspection, and... ?? So maybe a list something like this might make sense -- (and remember, this is brainstorming, nothing more) -- >> >> - Stateful packet inspection >> - Deep packet inspection >> - Packet/flow/stream filtering (remote and local) >> - Packet/flow/stream redirect (remote and local) >> - Intrusion detection (or perhaps flow/stream pattern matching?) >> - AAA >> >> Don't know if this is a useful line of thought or not. >> >> :-) >> >> Russ >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > From nobody Fri Feb 6 14:57:26 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 1E6FE1A8887; Fri, 6 Feb 2015 14:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 CNVp20kqA65L; Fri, 6 Feb 2015 14:57:23 -0800 (PST) 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 00F101A8882; Fri, 6 Feb 2015 14:57:22 -0800 (PST) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:63458 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1YJrpl-0001kd-Vq; Fri, 06 Feb 2015 22:57:10 +0000 From: "Russ White" To: "'Susan Hares'" , "'Thomas D. Nadeau'" , "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F645EBBAAB@dfweml701-chm> <039901d03fad$5aa354d0$0fe9fe70$@ndzh.com> <022c01d03fb6$27037480$750a5d80$@riw.us> <4A95BA014132FF49AE685FAB4B9F17F645EBE13D@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645EBE5ED@dfweml701-chm> <011601d04237$6ca4d280$45ee7780$@ndzh.com> In-Reply-To: <011601d04237$6ca4d280$45ee7780$@ndzh.com> Date: Fri, 6 Feb 2015 17:57:05 -0500 Message-ID: <027301d04260$3af89e50$b0e9daf0$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHe8BNDJn34omqge3ix4XQ/UM6E/QKkAZ6TAhEHlGoA7PstLgL0bo3yAiYGG1IBpH4qWwHbxtNsnFT4lgA= 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: Cc: i2nsf@ietf.org, nfvrg@irtf.org, i2rs@ietf.org Subject: Re: [i2rs] [I2nsf] revised charter for I2NSF 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, 06 Feb 2015 22:57:24 -0000 > The presentations and the ETSI work has demonstrated the desire for the > vNSF requirements to be standardized. A WG with a short-term focus of > defining Security and Networking people to decide what is needed for an > interoperable vNSF. This type of effort creates a 12-18 month WG life-cycle > that should aid OAM in LIME and the mechanisms in netconf/restconf. I would agree with this assessment... :-) Russ From nobody Fri Feb 6 16:05: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 601231A1B0B; Fri, 6 Feb 2015 16:05:40 -0800 (PST) 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 1VdN1YYUXVBB; Fri, 6 Feb 2015 16:05:38 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B1B031A1B26; Fri, 6 Feb 2015 16:05:17 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Fri, 6 Feb 2015 19:04:33 -0500 Message-ID: <022f01d04269$a7e0c7f0$f7a257d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0230_01D0423F.BF0BF870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBCUhnxsvAIDurWRbWWzo23QAy9Sg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: nfvrg@irtf.org, i2rs@ietf.org, melinda.shore@gmail.org, linda.dunbar@huawei.com Subject: [i2rs] Gaps analysis (draft-zhang-gap-analysis-01) revisions - MIDCOM, SACM, PCP, and AAA 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, 07 Feb 2015 00:05:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0230_01D0423F.BF0BF870 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan: This is response to the email: http://www.ietf.org/mail-archive/web/i2nsf/current/msg00233.html I think that this group needs to dig a bit deeper to compare the MIDCOM architecture, protocol requirements, and protocol primitives to determine how vNSF based on the ETSI document. The I2NSF gap analysis leaves the MIDCOM section blank which is problem for a healthy discussion of the vNSF functions. The gap analysis for I2NSF needs a review of MIDCOM and a review of ETSI specification Diego mentions. While the high level comments (http://www.ietf.org/mail-archive/web/i2nsf/current/msg00219.html) from Melinda was helpful to point to the midcom work - we need the following details in the gap analysis: . Use case scenario of 2015 with NFV, managed services, and pervasive E2E encryption is different than the midcom deployment. We need a section that discusses whether this is a new scenarios or redefinition of midcom scenarios for the virtual environment. . Telefonica needs open mechanisms to establish trust between the user environment and security services hosted on a virtualized infrastructure, and to manage and operate them, in order to include those services in our product portfolio. Telefonica does not think this is the current security standards, and we see the results from open-source initiatives very much focused on particular deployment models and too coarse to support the services we have in mind. . Midcom's protocol analysis needs to be updated 10 years later. The Midcom protocol analysis needs to examined: SNMP, RSIP, Megaco, Diameter and Cops as potential protocol. It would be important to update this list to determine if netconf/netmod, RSIP (current), Megaco (current), and Diameter (current) support for the revised scenarios is sufficient. Does I2RS provide some valuable additions to dynamic nature of managing the security box? Dan these points need to discuss these points on the list before removing some of the Firewall and IDS/IPS sections in the charter. I suspect your tightly worded email hints that these answers are key to creating a tightly scoped WG forming BOF. I want to thank Melinda for her pointer to the MIDCOM work, and I hope she will provide additional response to Diego's email. Sue Hares ------=_NextPart_000_0230_01D0423F.BF0BF870 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan:

 

This is = response to the email:

 

http://www.ietf.org/mail-archive/web/i2nsf/current/msg00233.html

 

I think that this group needs to dig a bit deeper to = compare the MIDCOM architecture, protocol requirements, and protocol = primitives to determine how vNSF  based on the ETSI document.  = The I2NSF gap analysis leaves the MIDCOM section blank which is problem = for a healthy discussion of the vNSF functions.  

 

The gap = analysis for I2NSF needs a review of MIDCOM and a review of ETSI = specification Diego mentions. While the high level comments (http://www.ietf.org/mail-archive/web/i2nsf/current/msg00219.html) = from Melinda was helpful to point to the midcom work  - we need the = following details in the gap analysis:

 

·         = Use case scenario of 2015 with NFV, = managed services, and pervasive E2E encryption is different than the = midcom deployment.  We need a section that discusses whether this = is a new scenarios or redefinition of midcom scenarios for the virtual = environment.  

 

·         = Telefonica needs open mechanisms to = establish trust between the user environment and security services = hosted on a virtualized infrastructure, and to manage and operate them, = in order to include those services in our product portfolio. Telefonica = does not think this is the current security standards, and we see the = results from open-source initiatives very much focused on particular = deployment models and too coarse to support the services we have in = mind.

 

·         = Midcom’s protocol analysis needs to = be updated 10 years later.  The Midcom protocol analysis needs to = examined: SNMP, RSIP, Megaco,  Diameter and Cops as potential = protocol.   It would be important to update this list to = determine if netconf/netmod, RSIP (current), Megaco (current), and = Diameter (current) support for the revised scenarios is = sufficient.   Does I2RS provide some valuable additions to = dynamic nature of managing the security box?

 

Dan these = points need to discuss these points on the list before removing some of = the Firewall and IDS/IPS sections in the charter.  I suspect your = tightly worded email hints that these answers are key to creating a = tightly scoped WG forming BOF.  

 

I want to = thank Melinda for her pointer to the MIDCOM work, and I hope she will = provide additional response to Diego’s email.

 

Sue Hares =  

 

 

------=_NextPart_000_0230_01D0423F.BF0BF870-- From nobody Tue Feb 10 01:36: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 3E48B1A00F0 for ; Tue, 10 Feb 2015 01:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQjGr6UzrWTf for ; Tue, 10 Feb 2015 01:36:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B661A00B6 for ; Tue, 10 Feb 2015 01:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19147; q=dns/txt; s=iport; t=1423560999; x=1424770599; h=from:to:cc:subject:date:message-id:mime-version; bh=HtzBcEINrLue93q01n4JWvJjtAmUXtr3DuJT2nsKGq4=; b=b9ZlJeOL460JzFqLsjuk7+0iNv62mbA3o7D9Ihk/WBvRiD2D3c244h76 x2KYfNM1Q98vAAqxO1LA9aqTyqudgoCYhClIE9QSlNBWhgIwoYyfltT0l ZEvg9gmJZGMjp8CnT4KeWqo+UBZoc0aGRmET+QoRcugUOOvwk1krx0ZNS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusFANLP2VStJA2M/2dsb2JhbABZA4JDQ1JaBMBpghwBCYVxAoEfQwEBAQEBAXyEDAEBAQMBAQEBKkELBQcCBAEIEAEEAQELAxMHIgwLFAkJAQQOBQiIHQgNzW8BAQEBAQEBAQEBAQEBAQEBAQEBAQEXBI8bJyEMBA0DCIMFgRQFjTuBZYNRhyuRKCKCMoE8b4ECQn4BAQE X-IronPort-AV: E=Sophos;i="5.09,549,1418083200"; d="scan'208,217";a="394939554" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 10 Feb 2015 09:36:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t1A9acU7013449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Feb 2015 09:36:38 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.97]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 10 Feb 2015 03:36:38 -0600 From: "Ambika Prasad Tripathy (ambtripa)" To: "i2rs@ietf.org" Thread-Topic: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 Thread-Index: AdBFFQolkdJYNs7hQOKLJhuZiA2/IA== Date: Tue, 10 Feb 2015 09:36:38 +0000 Message-ID: <3B675C3A8DF102408C754E30986E43CF10FAAD59@xmb-aln-x08.cisco.com> Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.100.99] Content-Type: multipart/alternative; boundary="_000_3B675C3A8DF102408C754E30986E43CF10FAAD59xmbalnx08ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "jhaas@pfrc.org" , "Juergen Schoenwaelder \(j.schoenwaelder@jacobs-university.de\)" , "Alexander Clemm \(alex\)" , "Eric Voit \(evoit\)" , "shares@ndzh.com" Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 10 Feb 2015 09:36:42 -0000 --_000_3B675C3A8DF102408C754E30986E43CF10FAAD59xmbalnx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this draft. I think section 6.5 of RFC5277 restrict to single subscription in a netconf= session. If section 6.5 of rfc5277 will be extended to support unique mult= iple request is more scalable with this pub-sub model= . Br, Ambika Prasad Tripathy From: "Alexander Clemm (alex)" > Sent: Wed, 4 Feb 2015 21:20:18 +0000 To: "Eric Voit (evoit)" >, J= uergen Schoenwaelder > Cc: 'Jeffrey Haas' >, "i2rs a= t ietf.org" >, Susan Hares > I agree, this modification will make it more accurate. As mentioned earlier on the thread, this is a -00 draft and we should expec= t that some revisions will be needed. Thanks --- Alex -----Original Message----- From: i2rs [mailto:i2rs-bounces at ietf.org] On Behalf Of Eric Voit (evoit) Sent: Tuesday, February 03, 2015 10:19 AM To: Juergen Schoenwaelder Cc: 'Jeffrey Haas'; i2rs at ietf.org; Susan Hares Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit= -i2rs-pub-sub-requirements-00 > On Tue, Feb 03, 2015 at 05:47:04PM +0000, Eric Voit (evoit) wrote: > > >> o limited support for pushed notification of changes. (Currentl= y > > >> notifications are for configuration data only. And even then= , > > >> subscription mechanisms for such notifications are > > >> undefined.) > > > > > I understand all that I think but I still think the text quoted > > > above is incorrect and this should be fixed. I am not looking for > > > long explanation, a simple "we will change that text to '...'" > > > would be more > efficient. > > > > I can just delete everything between the parenthesis. Would that be > sufficient? > > This leaves it open what 'limited' means, which I think is not good eithe= r. > Perhaps: > > o change notifications only for data residing in configuration > datastores Works for me. I will insert that into "-01" Eric > /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 at ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_3B675C3A8DF102408C754E30986E43CF10FAAD59xmbalnx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
 
I support this draft.

 


I think section 6.5 of RFC5277 restrict to=
 single subscription in a netconf session. If section 6.5 of rfc5277 will b=
e extended to support unique multiple <create-subscription> request i=
s more scalable with this pub-sub model.


 


Br,


Ambika Prasad Tripathy

 


From: "Alexander Clemm (alex)" &=
lt;alex at cisco.com>


Sent: Wed, 4 Feb 2015 21:20:18 +0000


To: "Eric Voit (evoit)" <evoit at cisco.com>, Juergen Schoenwaelder <j.schoenwaelder at jacobs-university.de>


Cc: 'Jeffrey Haas' <jhaas =
at pfrc.org>, "i2rs at ietf.org&q=
uot; <i2rs at ietf.org>, Susan Hares <shares at ndzh.com>


 


I agree, this modification will make it mo=
re accurate.  


As mentioned earlier on the thread, this i=
s a -00 draft and we should expect that some revisions will be needed. =
; 


Thanks


--- Alex


 


-----Original Message-----


From: i2rs [mailto:i2rs-bounces at ietf.org] On Behalf Of Eric Voit (evoit)<=
/o:p>


Sent: Tuesday, February 03, 2015 10:19 AM<=
o:p>


To: Juergen Schoenwaelder


Cc: 'Jeffrey Haas'; i2rs at ietf.org; Susa=
n Hares


Subject: Re: [i2rs] 2 week WG Adoption cal=
l (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00


 


> On Tue, Feb 03, 2015 at 05:47:04PM &#=
43;0000, Eric Voit (evoit) wrote:


> > >>    o&nbs=
p; limited support for pushed notification of changes.  (Currently


> > >>    =
    notifications are for configuration data only.  And=
 even then,


> > >>    =
    subscription mechanisms for such notifications are<=
/o:p>


> > >> undefined.)<=
/span>


> > <snip>

> > > I understand all that I thi=
nk but I still think the text quoted 


> > > above is incorrect and this=
 should be fixed. I am not looking for 


> > > long explanation, a simple =
"we will change that text to '...'" 


> > > would be more


> efficient.


> >


> > I can just delete everything bet=
ween the parenthesis.  Would that be


> sufficient?


> 


> This leaves it open what 'limited' me=
ans, which I think is not good either.


> Perhaps:


> 


> o change notifications only for data =
residing in configuration


>   datastores


 


Works for me.   I will insert th=
at into "-01"


 


Eric


 


> /js


> 


> --


> Juergen Schoenwaelder  &nbs=
p;        Jacobs University Bremen gGmbH=



> Phone: +49 421 200 3587 &nbs=
p;       Campus Ring 1, 28759 Bremen, Germany=



> Fax:   +49 421 200 3103=
         <http://www.jacobs-university.de/><=
/span>


 


__________________________________________=
_____


i2rs mailing list


i2rs at ietf.org


https://www.ietf.org/mailman/listinfo/i2rs


 
--_000_3B675C3A8DF102408C754E30986E43CF10FAAD59xmbalnx08ciscoc_-- From nobody Tue Feb 10 12: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 121421A6F1E for ; Tue, 10 Feb 2015 12:44:49 -0800 (PST) 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 w4q8FstPYLtI for ; Tue, 10 Feb 2015 12:44:46 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D0BAD1A6D3F for ; Tue, 10 Feb 2015 12:44:45 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: "'Dean Bogdanovic'" , "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F645EB6E7F@dfweml701-chm> In-Reply-To: Date: Tue, 10 Feb 2015 15:44:25 -0500 Message-ID: <02dc01d04572$5bc80d90$135828b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DD_01D04548.72F44F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJbrkJCYZLOFcfW+0/cRVkBe2Zy/QE9LmlPm8meAaA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org Subject: Re: [i2rs] Does I2RS charter include both the interface to Network Controller and the interface to devices (i.e. routers)? 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, 10 Feb 2015 20:44:49 -0000 X-List-Received-Date: Tue, 10 Feb 2015 20:44:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02DD_01D04548.72F44F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dean: I'm looking forward to your writing up of concepts of the capabilities (interface, routing, filtering, class of services). Let me know when you have more to share for I2RS and I2NSF. Sue From: Dean Bogdanovic [mailto:deanb@juniper.net] Sent: Friday, February 06, 2015 11:33 AM To: Linda Dunbar Cc: Susan Hares; jhaas@pfrc.org; i2rs@ietf.org Subject: Re: [i2rs] Does I2RS charter include both the interface to Network Controller and the interface to devices (i.e. routers)? Linda, I understand now your question (based on reading I2NSF emails). I2RS has two elements, agent and client and I2RS agent is sitting on the network device and exposes north bound interface to the I2RS client. How I2RS agent communicates to the device is not specified. This is up to the implementors to decide. How to communicate between I2RS agent and client, RESTCONF and YANG have been proposed. The interface from I2RS client northbound is not part of the WG. Now interface between I2RS agent and client can have multiple capabilities, but my proposal is to expose basic capabilities (interface, routing, filtering, class of service) of the network device that can be used to manipulate traffic forwarding behavior of the device. There is nothing preventing to expose higher level capabilities, like LxVPNs, by I2RS agent to be controlled by I2RS client. Please take a look at the Fig1 Figure 1: Architecture of I2RS clients and agents in http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/?include_text=1 Dean On Jan 27, 2015, at 6:44 PM, Linda Dunbar wrote: I2RS charter states: It is envisioned that users of the I2RS interfaces will be management applications, network controllers, and user applications that make specific demands on the network. This statement makes me believe that I2RS charter includes both the interface to Network Controller (i.e. North Bound Interface) and the Interface to devices/routers (i.e. South Bound Interface). The interface to "Network Controller" should be more Service oriented, e.g. allowing applications to indicate their desired features, enforcing a specific QoS for some applications The interface to "devices (routers)" should be more functional oriented, e.g. enabling ISIS on a specific port, or, etc. Is it reasonable for I2RS to have two distinct layers of interfaces? Linda Dunbar _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_02DD_01D04548.72F44F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dean:

 

I’m looking forward to your writing up of concepts of the = capabilities (interface, routing, filtering, class of services).  =  Let me know when you have more to share for I2RS and I2NSF. =

 

Sue

 

From:= = Dean Bogdanovic [mailto:deanb@juniper.net]
Sent: Friday, = February 06, 2015 11:33 AM
To: Linda Dunbar
Cc: = Susan Hares; jhaas@pfrc.org; i2rs@ietf.org
Subject: Re: [i2rs] = Does I2RS charter include both the interface to Network Controller and = the interface to devices (i.e. = routers)?

 

Linda, =

 

I = understand now your question (based on reading I2NSF = emails).

 

I2RS has two elements, agent and client and I2RS agent = is sitting on the network device and exposes north bound interface to = the I2RS client. How I2RS agent communicates to the device is not = specified. This is up to the implementors to decide. How to communicate = between I2RS agent and client, RESTCONF and YANG have been proposed. The = interface from I2RS client northbound is not part of the = WG.

 

Now interface between I2RS agent and client can have = multiple capabilities, but my proposal is to expose basic capabilities = (interface, routing, filtering, class of service) of the network device = that can be used to manipulate traffic forwarding behavior of the = device. There is nothing preventing to expose higher level capabilities, = like LxVPNs, by I2RS agent to be controlled by I2RS = client.

 

Please take a look at the Fig1 Figure 1: Architecture = of I2RS clients and agents  in http://datatracker.ietf.org/doc/draft-ietf-i2rs-architectu= re/?include_text=3D1

 

Dean

 

On Jan 27, 2015, at 6:44 PM, Linda Dunbar <linda.dunbar@huawei.com> = wrote:



I2RS = charter states:

 =

It is = envisioned that users of the I2RS interfaces will be management 
applications, network = controllers, and user applications that make 
specific demands on the = network.=

 =

 =

This = statement makes me believe that I2RS charter includes both the interface = to Network Controller (i.e. North Bound Interface) and the Interface to = devices/routers (i.e. South Bound = Interface).

 =

The = interface to “Network Controller” should be more Service = oriented, e.g. allowing applications to indicate their desired features, =  enforcing a specific QoS for some = applications

 =

The = interface to “devices (routers)” should be more functional = oriented, e.g. enabling ISIS on a specific port, or, = etc.

 =

Is it = reasonable for I2RS to have two distinct layers of = interfaces?

 =

Linda = Dunbar

 =

 =

_________= ______________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs<= /a>

 

------=_NextPart_000_02DD_01D04548.72F44F80-- From nobody Wed Feb 18 06:29: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 364481A8831 for ; Wed, 18 Feb 2015 06:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.353 X-Spam-Level: X-Spam-Status: No, score=-96.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=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 t0t475mwWNO0 for ; Wed, 18 Feb 2015 06:29:09 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2618E1A87ED for ; Wed, 18 Feb 2015 06:29:09 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Wed, 18 Feb 2015 09:29:05 -0500 Message-ID: <005a01d04b87$404c8850$c0e598f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01D04B5D.577791C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBLhwkadZs71kmgThCBJAJbuM1F0w== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] I2RS Interim Meeting - 2/19/2015 - 10:00am - 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, 18 Feb 2015 14:29:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_005B_01D04B5D.577791C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS interim will be held at 02/19/2015 at 10:00 - 11:30am. We have one opening for a presentation on the I2RS protocol. If you wish to present regarding the protocol, please contact me today. Sue Hares ----------------- I2RS Meeting 2/19/2015 Agenda: draft-netmod-clemm-datastore-push-00 (Alexander Clemm) Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m16b13629a3e3768ba09d1d2b23849b53 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 011 019 Toll-free calling restrictions Etherpad for minutes: http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015-02-19-minutes virtual Blue sheets: http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015-02-19-bluesheets ------=_NextPart_000_005B_01D04B5D.577791C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = interim will be held at 02/19/2015 at 10:00 – = 11:30am.

 

We have one opening for a presentation on the I2RS = protocol.  If you wish to present regarding the protocol, please = contact me today.

 

Sue Hares =

 

 

-----------------

 

I2RS Meeting = 2/19/2015

 

Agenda:

 

= draft-netmod-clemm-datastore-push-00  (Alexander Clemm) =

 

Join WebEx meeting

 https://ietf.webex.com/ietf/j.php?MTID=3Dm16b1362= 9a3e3768ba09d1d2b23849b53        =

 

Join by = phone 

1-877-668-4493 Call-in = toll free number (US/Canada) 

1-650-479-3208 Call-in toll number (US/Canada)  =

Access code: 646 011 019  =

Toll-free calling = restrictions  

 

Etherpad for = minutes:

 

http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015= -02-19-minutes

 

virtual Blue = sheets:

http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015= -02-19-bluesheets

------=_NextPart_000_005B_01D04B5D.577791C0-- From nobody Wed Feb 18 08:05: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 6A84E1A899B for ; Wed, 18 Feb 2015 08:05:58 -0800 (PST) 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 LE0Vx_xyVb5E for ; Wed, 18 Feb 2015 08:05:57 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id EC4691A8992 for ; Wed, 18 Feb 2015 08:05:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Wed, 18 Feb 2015 11:05:47 -0500 Message-ID: <00a601d04b94$c279ce70$476d6b50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01D04B6A.D9A4FEF0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBLlGWOEypr+qKXQNeuh7V5+QH3RA== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , Juergen Schoenwaelder , 'Alia Atlas' Subject: Re: [i2rs] 2 week WG Adoption call (2/2 to 2/16/2015) - draft-voit-i2rs-pub-sub-requirements-00 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, 18 Feb 2015 16:05:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A7_01D04B6A.D9A4FEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 2 WG adoption call and the I2RS interims have discuss this draft. It has passed WG adoption call. Will the authors please submit the correct draft (per email discussion) to Draft-ietf-i2rs-pub-sub-requirements-00.txt As several people pointed out, this is a good place to begin work on these requirements. Sue Hares ------=_NextPart_000_00A7_01D04B6A.D9A4FEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 2 WG = adoption call and the I2RS interims have discuss this draft.  It = has passed WG adoption call.  Will the authors please submit the = correct draft (per email discussion) to

 

Draft-ietf-i2rs-pub-sub-requirements-00.txt =

 

As several people pointed out, this is a good place to = begin work on these requirements.

 

Sue Hares =

------=_NextPart_000_00A7_01D04B6A.D9A4FEF0-- From nobody Thu Feb 19 06:56: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 856B41A8795 for ; Thu, 19 Feb 2015 06:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.353 X-Spam-Level: X-Spam-Status: No, score=-96.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=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 HDvOb7Ye_JsC for ; Thu, 19 Feb 2015 06:56:55 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3239B1A0019 for ; Thu, 19 Feb 2015 06:56:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Thu, 19 Feb 2015 09:56:52 -0500 Message-ID: <00c901d04c54$4c43a5d0$e4caf170$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01D04C2A.636E3A10" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBMVEvShSPouE/bSsGxJOwFfqhMog== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] Interim Meeting on 2/19/2015 - 10-11AM ET - begins in 5 minutes 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, 19 Feb 2015 14:56:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CA_01D04C2A.636E3A10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS Meeting 2/19/2015 Agenda: draft-netmod-clemm-datastore-push-00 (Alexander Clemm) Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m16b13629a3e3768ba09d1d2b23849b53 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 646 011 019 Toll-free calling restrictions Etherpad for minutes: http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015-02-19-minutes virtual Blue sheets: http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015-02-19-bluesheets ------=_NextPart_000_00CA_01D04C2A.636E3A10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS = Meeting 2/19/2015

 

Agenda: =

 

draft-netmod-clemm-datastore-push-00  (Alexander = Clemm)

 

Join WebEx meeting

 https://ietf.webex.com/ietf/j.php?MTID=3Dm16b1362= 9a3e3768ba09d1d2b23849b53        =

 

Join by = phone 

1-877-668-4493 Call-in = toll free number (US/Canada) 

1-650-479-3208 Call-in toll number (US/Canada)  =

Access code: 646 011 019  =

Toll-free calling = restrictions  

 

Etherpad for = minutes:

 

http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015= -02-19-minutes

 

virtual Blue = sheets:

http://etherpad.tools.ietf.org:9000/p/i2rs-interim-2015= -02-19-bluesheets

------=_NextPart_000_00CA_01D04C2A.636E3A10-- From nobody Thu Feb 19 08:17: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 793031A897D for ; Thu, 19 Feb 2015 08:17:43 -0800 (PST) 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 6KdT9IcF9YuE for ; Thu, 19 Feb 2015 08:17:41 -0800 (PST) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4C1A896F for ; Thu, 19 Feb 2015 08:17:41 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.92; From: "Susan Hares" To: Date: Thu, 19 Feb 2015 11:17:37 -0500 Message-ID: <015701d04c5f$93d0e790$bb72b6b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0158_01D04C35.AAFC1810" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdBMXuaGdyNTWIZrQmWNTHSua8i9Pg== X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] Today's interim meeting 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, 19 Feb 2015 16:17:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0158_01D04C35.AAFC1810 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Today's interim meeting continued in our discussions of the protocol requirements for I2RS. Our focus was the publication/subscription model. Today we heard from Alexander Clemm on a proposed implement of the publication/subscription models described in: . draft-netmod-clemm-datastore-push-00.txt You download the presentation or see the minutes at: http://www.ietf.org/proceedings/interim/2015/02/19/i2rs/proceedings.html The location of the recording will be sent to the mail list as soon it is available. Sue Hares ------=_NextPart_000_0158_01D04C35.AAFC1810 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Today’s interim meeting continued in our = discussions of the protocol requirements for I2RS.  Our focus was = the publication/subscription model.   Today we heard from = Alexander Clemm on a proposed implement of the publication/subscription = models described in:  

 

·         = draft-netmod-clemm-datastore-push-00.txt =

 

You download the presentation or see the minutes at: =

 

http://www.ietf.org/proceedings/interim/2015/02/19/i2rs/proceedi= ngs.html

 

The location of the recording will be sent to the mail = list as soon it is available.

 

Sue Hares =

 

------=_NextPart_000_0158_01D04C35.AAFC1810-- From nobody Tue Feb 24 12:20:57 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 0CDB01A8865 for ; Tue, 24 Feb 2015 12:20:56 -0800 (PST) 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 dVRpaOjtALcD for ; Tue, 24 Feb 2015 12:20:48 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 576721A88BC for ; Tue, 24 Feb 2015 12:20:47 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 04B3825CA258 for ; Tue, 24 Feb 2015 20:20:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtQdM3STq4i6 for ; Tue, 24 Feb 2015 21:20:44 +0100 (CET) Received: from kopoli (p5DCC7BCB.dip0.t-ipconnect.de [93.204.123.203]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 7BD7925CA24A for ; Tue, 24 Feb 2015 21:20:44 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Tue, 24 Feb 2015 21:20:41 +0100 Message-ID: <00d901d0506f$5ce7a020$16b6e060$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdBQb1xpYVw+UFIwRQWUZ9C06cF7vQ== Content-Language: en-us Archived-At: Subject: [i2rs] gap analysis - I2NSF vs. I2RS 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, 24 Feb 2015 20:20:56 -0000 Hello, We are working on a new version of gap analysis document for I2NSF. Since it is important for us to identify the exact scope of each WG that might have any overlap with the work we are doing in I2NSF, we invite you to provide us your inputs on our work. The following is our current context about your group. ------ I2NSF should leverage the protocols developed by I2RS. I2NSF is only to develop the additional information models and data models for distributed security functions, like FW and IPS/IDS. The Policy structure specified by [bnpModel] can be used by I2NSF to be extended to include recursive actions to other security functions. [bnpModel] Hares, S., Wu, Q.,"An Information Model for Basic Network Policy", http://tools.ietf.org/html/draft-hares-i2rs-bnp-info-model-01, October 2014 ----- Thanks, Best, Hosnieh _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf From nobody Wed Feb 25 11:16:06 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 E5C381A6F7B for ; Wed, 25 Feb 2015 11:16:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wcODkfCQORem for ; Wed, 25 Feb 2015 11:16:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B6B1A1BFE for ; Wed, 25 Feb 2015 11:16:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ42577; Wed, 25 Feb 2015 19:16:00 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 19:15:57 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 11:15:40 -0800 From: Linda Dunbar To: Susan Hares , Mach Chen , "i2rs@ietf.org" Thread-Topic: Questions & suggestions to draft-ietf-i2rs-usecase-reqs-summary-00 Thread-Index: AdBRLmKNbMke7BltQdiItV707P8vIgAAQCnA Date: Wed, 25 Feb 2015 19:15:39 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE348D@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE348Ddfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] Questions & suggestions to draft-ietf-i2rs-usecase-reqs-summary-00 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, 25 Feb 2015 19:16:06 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE348Ddfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mach and Sue, I have some questions and suggestions for the Section 7: Req from SFC Use= Cases: - SFC-US-REQ01: o Is the "service node" here mean "Service Function" Node? Why need the = " host system" address? Is "host system address " the Server address When m= ultiple service functions are instantiated on the server? Then the "Server"= address is not referenced by Forwarding node. Why need here? o It makes more sense to have "Service Node Address & Service Function I= ndex" tuple to cover the case of one service node having multiple service f= unctions instantiated. - SFC-USE-REQ02: o SF type should be "Vendor & SF name". FW by different vendors have diff= erent functionalities. Same goes IP Firewall, LB, etc. - SFC-USE-REQ03: o What is the "virtual contexts" for? Is the "Virtual Context" here mean = the same as NVo3's "virtual context", i.e. the "Virtual Network Identifier"= ? I think Routers have to expose which fields that routers are capable of ste= ering. For example, - Steering packets based on L2 Layer: MPLS label, MAC destination,= MAC source, VID, EtherType - Steering packets based on any field of GRE header, VxLAN header,= .. - Steering packets based on L3 Layer: IP destination, IP Source, p= rotocol code, ... - Steering packets based on L4 fields: TCP port, UDP port - Steering packets based on ingress port, - Steering packets based on any bits in the packet - Steering packets based on packet size, - Steering packets based on time of the day, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645EE348Ddfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Mach and Sue,

 

I have some questions and suggestions  for the = Section 7:  Req from SFC Use Cases:

 

-     &= nbsp;    SFC-US-REQ01:

o   Is the  “service node” here= mean “Service Function” Node? Why need the “ host system= ” address? Is “host system address ” the Server address W= hen multiple service functions are instantiated on the server? Then the = 220;Server” address is not referenced by Forwarding node. Why need here?

o   It makes more sense to have  “Ser= vice Node Address & Service Function Index” tuple to cover the ca= se of one service node having multiple service functions instantiated.

 =

-     &= nbsp;     SFC-USE-REQ02:

o   SF type should be “Vendor & SF nam= e”. FW by different vendors have different functionalities. Same goes= IP Firewall, LB, etc.

 =

-     &= nbsp;    SFC-USE-REQ03:

o   What is the “virtual contexts” f= or? Is the “Virtual Context” here mean the same as NVo3’s= “virtual context”, i.e. the “Virtual Network Identifier&= #8221;?

 

I think Routers have to expose which fields that rou= ters are capable of steering. For example,

-     &= nbsp;    Steering packets based on L2 Layer: MPLS label, MAC= destination, MAC source, VID, EtherType

-     &= nbsp;    Steering packets based on any field of GRE header, = VxLAN header, ..

-     &= nbsp;    Steering packets based on L3 Layer: IP destination,= IP Source, protocol code, …

-     &= nbsp;    Steering packets based on L4 fields: TCP port, UDP = port

-     &= nbsp;    Steering packets based on ingress port, =

-     &= nbsp;    Steering packets based on any bits in the packet

-     &= nbsp;    Steering packets based on packet size, <= /p>

-     &= nbsp;    Steering packets based on time of the day,

 

 

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645EE348Ddfweml701chm_-- From nobody Wed Feb 25 12:50: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 D4BDD1A1F02 for ; Wed, 25 Feb 2015 12:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf1a6PLHbuzk for ; Wed, 25 Feb 2015 12:50:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DE01A1EED for ; Wed, 25 Feb 2015 12:50:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSZ47207; Wed, 25 Feb 2015 20:50:09 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 20:50:08 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 12:49:55 -0800 From: Linda Dunbar To: Susan Hares , Mach Chen , "i2rs@ietf.org" Thread-Topic: Qustion about SFC-Use-REQ07 of draft-ietf-i2rs-usecase-reqs-summary-00 Thread-Index: AQHQUTycOHSfCZbIIke36xJhnROQsA== Date: Wed, 25 Feb 2015 20:49:55 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE3532@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE3532dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] Qustion about SFC-Use-REQ07 of draft-ietf-i2rs-usecase-reqs-summary-00 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, 25 Feb 2015 20:50:15 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3532dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mach and Sue, One more question about SFC-Use-REQ07: SFC-Use-REQ07 (IC): Virtual Network Topology (VNT) which includes: * number of access points to which service topology applies * topology of access points Does the "Virtual Network Topology" in SFC-Use-REQ07" mean the "Topology of= Service Function Forwarder Nodes"? If yes, suggest to change the text to: SFC-Use-REQ07 : Service Function Forwarder Topology Which includes: * The number of SFF nodes * Topology of the SFF nodes If not, what is this "Virtual Network Topology" ? Linda From: Linda Dunbar Sent: Wednesday, February 25, 2015 1:16 PM To: 'Susan Hares'; Mach Chen; i2rs@ietf.org Subject: Questions & suggestions to draft-ietf-i2rs-usecase-reqs-summary-00 Mach and Sue, I have some questions and suggestions for the Section 7: Req from SFC Use= Cases: - SFC-US-REQ01: o Is the "service node" here mean "Service Function" Node? Why need the = " host system" address? Is "host system address " the Server address When m= ultiple service functions are instantiated on the server? Then the "Server"= address is not referenced by Forwarding node. Why need here? o It makes more sense to have "Service Node Address & Service Function I= ndex" tuple to cover the case of one service node having multiple service f= unctions instantiated. - SFC-USE-REQ02: o SF type should be "Vendor & SF name". FW by different vendors have diff= erent functionalities. Same goes IP Firewall, LB, etc. - SFC-USE-REQ03: o What is the "virtual contexts" for? Is the "Virtual Context" here mean = the same as NVo3's "virtual context", i.e. the "Virtual Network Identifier"= ? I think Routers have to expose which fields that routers are capable of ste= ering. For example, - Steering packets based on L2 Layer: MPLS label, MAC destination,= MAC source, VID, EtherType - Steering packets based on any field of GRE header, VxLAN header,= .. - Steering packets based on L3 Layer: IP destination, IP Source, p= rotocol code, ... - Steering packets based on L4 fields: TCP port, UDP port - Steering packets based on ingress port, - Steering packets based on any bits in the packet - Steering packets based on packet size, - Steering packets based on time of the day, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3532dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mach and Sue,

 

One more question abou= t SFC-Use-REQ07:

 

SFC-Use-REQ07 (IC): Virtual Network Topology= (VNT)

which includes:

* number of access points to which service t= opology applies

* topology of access points

 

 

Does the “Virtua= l Network Topology” in SFC-Use-REQ07” mean the “Topology = of Service Function Forwarder Nodes”?

 

If yes, suggest to cha= nge the text to:

 

SFC-Use-REQ07 : Servic= e Function Forwarder Topology

Which includes:

·       The number of =  SFF nodes

·       Topology of th= e SFF nodes

 

If not, what is this &= #8220;Virtual Network Topology” ?

 

Linda

From: Linda Du= nbar
Sent: Wednesday, February 25, 2015 1:16 PM
To: 'Susan Hares'; Mach Chen; i2rs@ietf.org
Subject: Questions & suggestions to draft-ietf-i2rs-usecase-reqs= -summary-00

 

 

Mach and Sue,

 

I have some questions and suggestions  for the = Section 7:  Req from SFC Use Cases:

 

-     &= nbsp;    SFC-US-REQ01:

o   Is the  “service node” here= mean “Service Function” Node? Why need the “ host system= ” address? Is “host system address ” the Server address W= hen multiple service functions are instantiated on the server? Then the = 220;Server” address is not referenced by Forwarding node. Why need here?

o   It makes more sense to have  “Ser= vice Node Address & Service Function Index” tuple to cover the ca= se of one service node having multiple service functions instantiated.

 =

-     &= nbsp;     SFC-USE-REQ02:

o   SF type should be “Vendor & SF nam= e”. FW by different vendors have different functionalities. Same goes= IP Firewall, LB, etc.

 =

-     &= nbsp;    SFC-USE-REQ03:

o   What is the “virtual contexts” f= or? Is the “Virtual Context” here mean the same as NVo3’s= “virtual context”, i.e. the “Virtual Network Identifier&= #8221;?

 

I think Routers have to expose which fields that rou= ters are capable of steering. For example,

-     &= nbsp;    Steering packets based on L2 Layer: MPLS label, MAC= destination, MAC source, VID, EtherType

-     &= nbsp;    Steering packets based on any field of GRE header, = VxLAN header, ..

-     &= nbsp;    Steering packets based on L3 Layer: IP destination,= IP Source, protocol code, …

-     &= nbsp;    Steering packets based on L4 fields: TCP port, UDP = port

-     &= nbsp;    Steering packets based on ingress port, =

-     &= nbsp;    Steering packets based on any bits in the packet

-     &= nbsp;    Steering packets based on packet size, <= /p>

-     &= nbsp;    Steering packets based on time of the day,

 

 

 

Linda

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645EE3532dfweml701chm_-- From nobody Thu Feb 26 11:15: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 68B471A1A5D for ; Thu, 26 Feb 2015 11:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xlBIkqETMwz for ; Thu, 26 Feb 2015 11:15:06 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D211A1A3C for ; Thu, 26 Feb 2015 11:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1394; q=dns/txt; s=iport; t=1424978105; x=1426187705; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=csAXtDHQkyBv5zhUTWYD91Si5QqdTAfbMpV1PCvIvQ0=; b=FA21/gmd0qawmGWIXZkoyf2pM0nsNrb6jg27gikLB+qzazqyehHilzYw v15W/QF5ioretn4V22UMEAHfklhCTOsZ/4eY6wjeWl4Y/nPhIbvEatsi2 IfXHgWPSScXGOhCsxLNRnD5xMRCzE/KCXWvV17zTUeFdY7o0+c2rMuNOk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBQAVcO9U/5BdJa1bgwJSWgS8DIQxgUaFcAKBJDgUAQEBAQEBAXyEEAEBBIEJAgEIRjIbAQYDAgQTG4gUDdccAQEBAQEBAQECAQEBAQEBAQEBFQSLE4E9gzMFhCsFhC+Fe4VFg2CDbIF5gSySHSOCD4FfbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,654,1418083200"; d="scan'208";a="127207958" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 26 Feb 2015 19:15:04 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1QJF4lY017722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 19:15:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 13:15:04 -0600 From: "Charles Eckel (eckelcu)" To: "i2rs@ietf.org" Thread-Topic: IETF Hackathon at IETF 92, March 21-22, Dallas, TX Thread-Index: AQHQUFOkH7HlE1Nn2E6m2YbduHXwrZ0DCnyA Date: Thu, 26 Feb 2015 19:15:03 +0000 Message-ID: References: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> In-Reply-To: <20150224170152.6224.60832.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.82.217.219] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2EF0DCBB24F4514CA4F8A23301AFA2C6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [i2rs] FW: IETF Hackathon at IETF 92, March 21-22, Dallas, TX 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, 26 Feb 2015 19:15:08 -0000 In case you missed the announcement, and because there is some work involving I2RS planned, I want to call attention to this event to folks on this alias. The following appears in the event details: ODL/NETCONF/I2RS =20 =09 * Working with NETCONF/YANG devices in OpenDaylight (ODL) =20 * Working with proposed I2RS YANG models in ODL and in Python =20 * Prototype model in ODL =20 * Prototype model in Python and have it work with the model in ODL =20 * Prototype candidate extensions to NETCONF/YANG to support I2RS Apologies in advance for the unfortunately short notice. Cheers, Charles On 2/24/15, 9:01 AM, "IETF Secretariat" wrote: > >The Internet Engineering Task Force (IETF) is holding a Hackathon to >encourage developers to discuss, collaborate and develop utilities, >ideas, sample code and solutions that show practical implementations of >IETF standards. It takes place just before IETF 92, and it=B9s free and >open to everyone. > >All you need is a knowledge of networking technologies, and you=B9ll be >guaranteed to learn something new and have fun! > >Event details: https://developer.cisco.com/site/ietf-hackathon >Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html >