From nobody Thu May 7 08:53: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 451851ACD0F; Thu, 7 May 2015 08:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzcTHKAPxUlb; Thu, 7 May 2015 08:53:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868781ACCF0; Thu, 7 May 2015 08:53:08 -0700 (PDT) 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 BSG35636; Thu, 07 May 2015 15:53:07 +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, 7 May 2015 16:53:06 +0100 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; Thu, 7 May 2015 08:53:01 -0700 From: Linda Dunbar To: "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2Q== Date: Thu, 7 May 2015 15:53:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.99] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [i2rs] Further Narrowing the I2NSF scope: the new charter for IETF 93 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, 07 May 2015 15:53:15 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 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 WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks to I2NSF contributors for the good progresses= made since  IETF92 side meetings. Among the two I2NSF interfaces, &nb= sp;i.e. the client facing Service Interface and the NSF facing Capability I= nterface, the work to be done at the Capability Interface becomes very clear and concrete. But the Service Interface is st= ill a little vague.

 

The feedback from last IETF side meetings was "= the scope is too big for one IETF WG". Therefore, we are leaning towar= ds narrowing the I2NSF scope to the Capability Interface. The thinking logi= c is: Once the Capability Interface is completed, we will see more clearly the work for Service interface. Even if Capabilit= y layer alone is standardized, it is a giant leap forward in building block= s for Service Provider to automate their Security Controller that can utili= ze NSF by multiple vendors

 

Here is the narrower scoped I2NSF charter. Your comm= ents and suggestions are greatly appreciated. CC’ed to DOTS, I2RS, an= d Netmod groups for wider review.

 

 <= /p>

 

Enterprises, residential, and mobile customers are i= ncreasingly consuming network functions, especially network security relate= d functions that are not running on their premises.  In addition, the = European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new manage= ment challenges for security policies to be enforced by distributed, virtua= l, network security functions (vNSF). Without standard interface to express= , monitor, and manage security policies to security functions deployed at different premises, it becomes virtually= impossible for security service providers to automate the service offering= utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is to enable enterprises = to utilize security functions not hosted on their own premises but instead = hosted in service provider domain, to establish how to communicate desired = security policies to NSF and how to get performance data or report out of NSF or vNSF.

 

There are two layers of interfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Lay= er specifies the functional security policies, which are translated from th= e client security policies, to security functions. I2NSF will NOT standardi= ze security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to the security funct= ions (not devices), in the form of “Subject – Object – Fu= nction – Action” paradigm. 

 =

The I2NSF Service Layer is for clients to express an= d monitor security policies for their specific flows, which is usually base= d on customers’ logical networks, addresses and context. I2NSF Servic= e Layer can also be security expectation or loose security requirement, especially for customers who don’t ha= ve the security expertise.

 

The concrete work at the L2NSF Capability Layer incl= udes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry is to make it feasible to ca= tegorize network security functions provided by different vendors based on = security policy provisioning capability without any need to standardize sec= urity functions themselves.  Standard provisioning capability interface is an essential building block for Secur= ity Service Provider to automate their Security Controllers that can utiliz= e NSF by multiple vendors. This layer will leverage the existing protocols = and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it is out of the scope = for I2NSF (at least for now) to standardize the interface facing clients. H= owever, I2NSF can have informational drafts showing sample APIs or/and REST= ful interfaces to clients and demonstrating the feasibility of them being translated to the Capability Layer policies.=

 =

Since different security vendors support different f= eatures & functions on their devices, I2NSF will focus on flow based se= curity functions that provide treatment to packets/flows, such as IPS/IDS, = Web filter, and flow filter. (They are different from other security functions such as Authentication, Authorizat= ion, or Encryption). Exemplar services associated with Flow Based Security = functions include deep packet inspection, packet/flow/stream filtering or p= attern matching and remediation, etc.

 

Similar to I2RS focusing on the interface to RIB/FIB= even though most routers provide far more functions than RIB/FIB, the I2NS= F focused functions can be a portion of features supported by vendors’= ; specific devices.

 

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

I2NSF WG Deliverables include:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d from the above Information Model.

-       = ;   IANA registry consideration for flow based security= function policy provisioning capability.

-       = ;    (Optionally) Applicability Statements on how = to use I2RS, Netconf, and NETMOD to carry the content of the specified info= rmation/data models.

 

[The W= G may decide that the Use cases, Framework, and Requirement are Information= al documents or simply reference documents during the lifetime of the WG. The framework, that describes the functional components = and the I2NSF work items, is to make I2NSF work more organized.]

 

Suggested Milestones

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

  - Framework: Charter time + 4 months to W= G Document

  - Requirements for extensions to protocols:&n= bsp; Charter time + 6 months to WG document

  - Info model: Charter time + 7 months to = WG Document

  - IANA registry consideration + 10 months= to WG Document

  - All Early Drafts to IESG: 10 months

 

[decision point – +10 months]  <= /o:p>

  - Data Models: Charter + 9 Months to= WG Document

  - Applicability Statements: 10 months to WG D= ocument

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

 

The WG will work c= losely with I2RS, Netconf and Netmod WGs. The WG will communicate with exte= rnal SDOs like ETSI NFV and will encourage open source code development rel= ated to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 <= /p>

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C11DC6dfweml701chm_-- From nobody Mon May 11 01:50: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 A2C831A7D85; Mon, 11 May 2015 01:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmskAbyXcISE; Mon, 11 May 2015 01:50:18 -0700 (PDT) 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 F13641A700E; Mon, 11 May 2015 01:50:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgHAFFsUFWHCzIm/2dsb2JhbABcgkUhKVReBrJpAQEBAQEBBplbAoElTAEBAQEBAYELhCABAQEBAxIbPg4QAgEIDQQEAQELFgEGBzIUCQgCBAENBQgTB4gKAakYnXABAQEBAQEBAQEBAQEBAQEBAQEBAQEXhhaFI4RUMQYBgxeBFgWLMYcMjAeGS4sTg1UjYYEFghFvgUWBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,405,1427774400"; d="scan'208,217";a="119809747" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 May 2015 04:49:21 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 11 May 2015 04:43:52 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0174.001; Mon, 11 May 2015 10:43:51 +0200 From: "Romascanu, Dan (Dan)" To: "Zarny, Myo" , 'Linda Dunbar' , "'i2nsf@ietf.org'" , 'Kathleen Moriarty' Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCJ2OCaxrcKG02LhKTLY5q9wZ12diUw Date: Mon, 11 May 2015 08:43:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@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.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [i2rs] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 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, 11 May 2015 08:50:25 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use 'non-standard' rather than= 'bespoke' which may puzzle the non-native English speakers. I had to go to= the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I'm fine with the suggested delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it = others to comment on whether the level of detail here is sufficient, too mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. MZ: Not sure if we need to explicitly specify a potential solution("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. MZ: I suggest "I2NSF Services Layer provides a set of interfaces for clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 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 WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be = only me!).

 

Mentioning another SDO= in the charter is actually fine as long as it points to the fact that we a= re aiming to work in cooperation with other SDOs and avoid duplicating work= . In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the = introduction is fine.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity service function belong to the same or different domains. Also, not= sure if we should bring in another organization’s name (ETSI) into an IETF charter.

 

I’ve taken a sta= b at rewording the first few paragraphs…

 

Network security functions (NS= Fs) are increasingly provided and consumed in increasingly diverse environm= ents. Users of NSFs could consume network security services hosted by one or more providers, which may be their own = enterprise, service providers, or a combination of both. Likewise, service = providers may offer their customers network security services that consist = of multiple security products from different vendors. Yet because no widely accepted industry standard securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

The primary goal of I2NSF is t= o define a set of interfaces and data models for policy provisioning and ma= nagement aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.

 

The scope of I2NSF can be furt= her divided into two layers:

·       &= nbsp; I2NSF Capabilities Layer

·       &= nbsp; I2NSF Services Layer<= /o:p>

…

 

I’ve made a few = comments inline below as well.

 

I’m not familiar= with how detailed a charter needs to be, so I’ll leave it others to = comment on whether the level of detail here is sufficient, too much or too = light.

 

Myo<= /p>

 

 

From: I2nsf [mailt= o:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contrib= utors for the good progresses made since  IETF92 side meetings. Among = the two I2NSF interfaces,  i.e. the client facing Service Interface an= d the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. Bu= t the Service Interface is still a little vague.

 

The feedback from last = IETF side meetings was "the scope is too big for one IETF WG". Th= erefore, we are leaning towards narrowing the I2NSF scope to the Capability= Interface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower sc= oped I2NSF charter. Your comments and suggestions are greatly appreciated. = CC’ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residentia= l, and mobile customers are increasingly consuming network functions, espec= ially network security related functions that are not running on their prem= ises.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2= NSF is to enable enterprises to utilize security functions not hosted on th= eir own premises but instead hosted in service provider domain, to establis= h how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vN= SF.

 

There are two layers of= interfaces:

-       = ;   Security Policies facing s= ecurity functions (I2NSF Capability Layer)

-       = ;   Security Policies facing c= lients (I2NSF Service Layer)

 

The I2NSF Capability Layer specifies the functional security policies,= which are translated from the client security policies, to security functi= ons. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential solu= tion(“Subject-Object-Function-Action”) in the charter.

 

The I2NSF Service Layer= is for clients to express and monitor security policies for their specific= flows, which is usually based on customers’ logical networks, addres= ses and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of in= terfaces for clients to express and monitor security policies. The policies= may be intent-based.”

 

The concrete work at th= e L2NSF Capability Layer includes

-  &= nbsp;       The informational &= amp; data models for each category to be represented to virtual or physical= network security functions,<= /p>

-  &= nbsp;       The capability regi= stry (IANA) of policy provisioning capability to flow based security functi= on, and

-  &= nbsp;       The proper secure c= ommunication channels to carry the security policies between Controller and= NSFs.

The capability registry= is to make it feasible to categorize network security functions provided b= y different vendors based on security policy provisioning capability withou= t any need to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service L= ayer, it is out of the scope for I2NSF (at least for now) to standardize th= e interface facing clients. However, I2NSF can have informational drafts sh= owing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

 

Since different securit= y vendors support different features & functions on their devices, I2NS= F will focus on flow based security functions that provide treatment to pac= kets/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as= Authentication, Authorization, or Encryption). Exemplar services associate= d with Flow Based Security functions include deep packet inspection, packet= /flow/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusin= g on the interface to RIB/FIB even though most routers provide far more fun= ctions than RIB/FIB, the I2NSF focused functions can be a portion of featur= es supported by vendors’ specific devices.

 

It is a non-goal to cre= ate new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables i= nclude:

 

-       = ;    Use Case document. <= o:p>

-       = ;   Framework Document.

-       = ;   Requirement for extensions= (if there are any) to existing protocols used by the WG.

-       = ;    Gap analysis of exis= ting protocols and modeling languages

-       = ;   A single, unified, Informa= tion Model for expressing policies to the Flow Based Security Functions des= cribed above.

-       = ;   Corresponding Data Models = (e.g. YANG models) derived from the above Information Model.

-       = ;   IANA registry consideratio= n for flow based security function policy provisioning capability.

-       = ;    (Optionally) Applica= bility Statements on how to use I2RS, Netconf, and NETMOD to carry the cont= ent of the specified information/data models.

 

[The WG may decide that the Use cases, Framework, an= d Requirement are Informational documents or simply reference documents during the lifetime of the WG. The framework, that descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones

  - Use Case Docum= ent:  Charter time + 1 month to WG Document

  - Framework: Cha= rter time + 4 months to WG Document

  - Requirements f= or extensions to protocols:  Charter time + 6 months to WG documen= t

  - Info model: Ch= arter time + 7 months to WG Document

  - IANA registry = consideration + 10 months to WG Document

  - All Early Draf= ts to IESG: 10 months

 

[decision point –= +10 months] 

  - Data Mode= ls: Charter + 9 Months to WG Document

  - Applicability = Statements: 10 months to WG Document

  - Data Models an= d Applicability Statements to IESG  - 16 months

 

The WG will work closel= y with I2RS, Netconf and Netmod WGs. The WG will communicate with external = SDOs like ETSI NFV and will encourage open source code development related = to the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar=

--_000_9904FB1B0159DA42B0B887B7FA8119CA5CA27888AZFFEXMB04globa_-- From nobody Mon May 11 04:20: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 085801A6F1D; Mon, 11 May 2015 04:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ufLWI5dKZQK; Mon, 11 May 2015 04:20:43 -0700 (PDT) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EAC1A3B9B; Mon, 11 May 2015 04:20:41 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C25033A01A8; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 945B43A02E0; Mon, 11 May 2015 13:20:38 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 11 May 2015 13:20:38 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.160.19; Mon, 11 May 2015 11:19:36 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0160.009; Mon, 11 May 2015 11:19:36 +0000 From: DIEGO LOPEZ GARCIA To: "Romascanu, Dan (Dan)" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QBji2ZgAFaiOYAABXA3AA== Date: Mon, 11 May 2015 11:19:35 +0000 Message-ID: <5E241E34-B620-4A92-A545-BA6A7C3E6870@telefonica.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: avaya.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [79.150.196.178] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0624; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0624; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0624; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(252514010)(24454002)(77156002)(19617315012)(82746002)(33656002)(76176999)(5001960100002)(16236675004)(50986999)(54356999)(62966003)(189998001)(92566002)(110136002)(2900100001)(2950100001)(40100003)(122556002)(36756003)(87936001)(83716003)(2656002)(15975445007)(66066001)(86362001)(102836002)(19580395003)(19580405001)(46102003)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2015 11:19:35.4160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0624 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , "Zarny, Myo" , Kathleen Moriarty Subject: Re: [i2rs] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 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, 11 May 2015 11:20:50 -0000 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Agree with Dan (and therefore Myo) in the suggested changes and in the fact= that mentioning ETSI out of the introduction is fine. And just a minor nit: I'd refrain to mention DPI as an exemplar function (t= he days of DPI as we know it days are close to be over, given the current c= oncerns about privacy and the usage of E2E encryption) and rephrase the sen= tence mentioning it from "Exemplar services associated with Flow Based Security functions include de= ep packet inspection, packet/flow/stream filtering or pattern matching and = remediation, etc." into "Exemplar services associated with Flow Based Security functions include ma= lware detection, packet/flow/stream filtering or pattern matching and remed= iation, etc." Be goode, On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) > wrote: I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use =91non-standard=92 rather = than =91bespoke=92 which may puzzle the non-native English speakers. I had = to go to the dictionary to see what it exactly means (but it may be only me= !). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Mori= arty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I=92m fine with the suggested deli= verables, milestones, etc. BUT we should tweak the first two paragraphs rel= ated to the goal of the WG. I2NSF shouldn=92t take a position on where the = security functions are hosted or if the caller and the security service fun= ction belong to the same or different domains. Also, not sure if we should = bring in another organization=92s name (ETSI) into an IETF charter. I=92ve taken a stab at rewording the first few paragraphs=85 Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: =95 I2NSF Capabilities Layer =95 I2NSF Services Layer =85 I=92ve made a few comments inline below as well. I=92m not familiar with how detailed a charter needs to be, so I=92ll leave= it others to comment on whether the level of detail here is sufficient, to= o much or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of =93Subject =96 Object =96 Function =96 Action=94 = paradigm. MZ: Not sure if we need to explicitly specify a potential solution(=93Subj= ect-Object-Function-Action=94) in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who d= on=92t have the security expertise. MZ: I suggest =93I2NSF Services Layer provides a set of interfaces for cli= ents to express and monitor security policies. The policies may be intent-b= ased.=94 The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 months to WG Document - All Early Drafts to IESG: 10 months [decision point =96 +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 WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar _______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

Agree with Dan (and therefore Myo) in the suggested changes and in the= fact that mentioning ETSI out of the introduction is fine.

And just a minor nit: I'd refrain to mention DPI as an exemplar functi= on (the days of DPI as we know it days are close to be over, given the curr= ent concerns about privacy and the usage of E2E encryption) and rephrase th= e sentence mentioning it from 
"Exemplar services associated with Flow Based Security functions = include deep packet inspection, packet/flow/stream filtering or pattern mat= ching and remediation, etc." 
into 
"Exemplar services associated with Flow Based Security functions = include malware detection, packet/flow/stream filtering or pattern matching= and remediation, etc."

Be goode,

On 11 May 2015, at 10:43 , Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

I am fine with the editing propose= d by Myo as it makes the scope more clear. Maybe the only thing I would sug= gest is to use =91non-standard=92 rather than =91bespoke=92 which may puzzl= e the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be only me!)= .
 
Mentioning another SDO in the char= ter is actually fine as long as it points to the fact that we are aiming to= work in cooperation with other SDOs and avoid duplicating work. In this ca= se we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the introduc= tion is fine.
 
Thanks and Regards,
 
Dan
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo=
Sent: Saturday, Ma= y 09, 2015 6:55 PM
To: 'Linda Dunbar'= ; 'i2nsf@ietf.org'; 'Kathleen Moriart= y'
Cc: 'i2rs@ietf.org'; 'd= ots@ietf.org'; 'netmod@ietf.org'=
Subject: Re: [I2ns= f] Further Narrowing the I2NSF scope: the new charter for IETF 93
 
Hi Linda,
 
Thanks very much for putting this = together. I agree that the scope needs to be tightened if it is to be meani= ngful. I=92m fine with the suggested deliverables, milestones, etc. BUT we = should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn=92t take a position on where = the security functions are hosted or if the caller and the security service= function belong to the same or different domains. Also, not sure if we sho= uld bring in another organization=92s name (ETSI) into an IETF charter.
 
I=92ve taken a stab at rewording t= he first few paragraphs=85
 
Network security functions (NSFs) are increasingly provided and consu= med in increasingly diverse environments. Users of NSFs could consume netwo= rk security services hosted by one or more providers, which may be their own enterprise, service providers, o= r a combination of both. Likewise, service providers may offer their custom= ers network security services that consist of multiple security products fr= om different vendors. Yet because no widely accepted industry standard security interfaces exist today, mana= gement of NSFs (device and policy provisioning, monitoring, etc.) tends to = be bespoke, essentially as offered by product vendors. As a result, automat= ion of such services, if it exists at all, is also bespoke.  
 
The primary goal of I2NSF is to define a set of interfaces and data m= odels for policy provisioning and management aspects of NSFs. Other aspects= of NSFs such as device or network provisioning are out of scope.
 
The scope of I2NSF can be further divided into two layers:=
=B7         <= /span>I2NSF Capabilities Layer
=B7         <= /span>I2NSF Services Layer
=85
 
I=92ve made a few comments inline = below as well.
 
I=92m not familiar with how detail= ed a charter needs to be, so I=92ll leave it others to comment on whether t= he level of detail here is sufficient, too much or too light.
 
Myo
 
 
From:<= /span> I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunb= ar
Sent: 7 May 2015 1= 1:53 AM
To: i2= nsf@ietf.org; Kathleen Moriarty
Cc: i2r= s@ietf.org; dots@ietf.org; netmod@ietf.org
Subject: [I2nsf] F= urther Narrowing the I2NSF scope: the new charter for IETF 93
 
Thanks to I2NSF contributors for the good progresses made since  IETF9= 2 side meetings. Among the two I2NSF interfaces,  i.e. the client faci= ng Service Interface and the NSF facing Capability Interface, the work to b= e done at the Capability Interface becomes very clear and concrete. But the Service Interface is still a little vague= .
 
The feedback from last IETF side meetings was "the scope is too big fo= r one IETF WG". Therefore, we are leaning towards narrowing the I2NSF = scope to the Capability Interface. The thinking logic is: Once the Capabili= ty Interface is completed, we will see more clearly the work for Service interface. Even if Capability layer alone is = standardized, it is a giant leap forward in building blocks for Service Pro= vider to automate their Security Controller that can utilize NSF by multipl= e vendors
 
Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC=92ed to DOTS, I2RS, and Netmod groups for wider r= eview.
 
 
 
Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises.  In addition, the European Telecommunicat= ions Standards Institute (ETSI) Network Function Virtualization (NFV) initiative creates new management challenges= for security policies to be enforced by distributed, virtual, network secu= rity functions (vNSF). Without standard interface to express, monitor, and = manage security policies to security functions deployed at different premises, it becomes virtually impossible = for security service providers to automate the service offering utilizing s= ecurity functions by multiple vendors.
 
The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF.
 
There are two layers of interfaces:
-          S= ecurity Policies facing security functions (I2NSF Capability Layer)
-          S= ecurity Policies facing clients (I2NSF Service Layer)
 
The I2NSF Capability Layer specifies the functional securi= ty policies, which are translated from the client security policies, to sec= urity functions. I2NSF will NOT standardize security functions or devices. = Instead, I2NSF is only to standardize the policy provisioning to the security functions (not devices), in the fo= rm of =93Subject =96 Object =96 Function =96 Action=94 paradigm. =
MZ:  Not sure if we need to exp= licitly specify a potential solution(=93Subject-Object-Function-Action=94) = in the charter.
 
The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers=92 logic= al networks, addresses and context. I2NSF Service Layer can also be securit= y expectation or loose security requirement, especially for customers who don=92t have the security expertise.
MZ:  I suggest =93I2NSF Service= s Layer provides a set of interfaces for clients to express and monitor sec= urity policies. The policies may be intent-based.=94
 
The concrete work at the L2NSF Capability Layer includes
-         = ; The informational & data models for each category to be represented to vir= tual or physical network security functions,
-         = ; The capability registry (IANA) of policy provisioning capability to flow based= security function, and
-         = ; The proper secure communication channels to carry the security policies betwee= n Controller and NSFs.
The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves.  Standard provisioning capability interface is an essential building block for Security Service Provider to = automate their Security Controllers that can utilize NSF by multiple vendor= s. This layer will leverage the existing protocols and data models defined = by I2RS, Netconf, and NETMOD.
 
For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capability Layer policies.
 
Since different security vendors support different features & functions= on their devices, I2NSF will focus on flow based security functions that p= rovide treatment to packets/flows, such as IPS/IDS, Web filter, and flow fi= lter. (They are different from other security functions such as Authentication, Authorization, or Encryption). = Exemplar services associated with Flow Based Security functions include dee= p packet inspection, packet/flow/stream filtering or pattern matching and r= emediation, etc.
 
Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors=92 specific devices.
 
It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces.
I2NSF WG Deliverables include:
 
-          &= nbsp;Use Case document.
-          F= ramework Document.
-          R= equirement for extensions (if there are any) to existing protocols used by the WG.
-          &= nbsp;Gap analysis of existing protocols and modeling languages
-          A= single, unified, Information Model for expressing policies to the Flow Based Security Funct= ions described above.
-          C= orresponding Data Models (e.g. YANG models) derived from the above Information Model.
-          I= ANA registry consideration for flow based security function policy provisioning capabil= ity.
-          &= nbsp;(Optionally) Applicability Statements on how to use I2RS, Netconf, and NETMOD to carry = the content of the specified information/data models.
 
[The WG may decide that the Use cases, Framework, and Requirement are = Informational documents or simply reference documents during the lifetime o= f the WG. The framework, that describes the functional components and the I2NSF work ite= ms, is to make I2NSF work more organized.]
 
Suggested Milestones
  - Use Case Document:  Charter time + 1 month to WG Document=
  - Framework: Charter time + 4 months to WG Document
  - Requirements for extensions to protocols:  Charter time += 6 months to WG document
  - Info model: Charter time + 7 months to WG Document<= /div>
  - IANA registry consideration + 10 months to WG Document
  - All Early Drafts to IESG: 10 months
 
[decision point =96 +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 WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV.
 
 
Cheers,
Linda Dunbar
_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lo= pez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_5E241E34B6204A92A545BA6A7C3E6870telefonicacom_-- From nobody Tue May 12 04:07: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 220931A87A9; Tue, 12 May 2015 04:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, 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 UvjLhoyo54tB; Tue, 12 May 2015 04:07:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87031A8779; Tue, 12 May 2015 04:07:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSK47304; Tue, 12 May 2015 11:07:21 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 May 2015 12:07:19 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.144]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 12 May 2015 19:07:10 +0800 From: "Xialiang (Frank)" To: Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AdCI3eREQdBVQ8yORRe/7nCVEnyK2QDwXbrg Date: Tue, 12 May 2015 11:07:10 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.43.91] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [i2rs] =?gb2312?b?tPC4tDogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0?= =?gb2312?b?aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURgk5Mw==?= 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, 12 May 2015 11:07:28 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgTGluZGEsDQpJIGFncmVlIHRoYXQgd2UgY2FuIHNwZWNpZnkgY2FwYWJpbGl0eSBpbnRlcmZh Y2UgZmlyc3RseSwgYW5kIGxlYXZlIHRoZSBjdXJyZW50bHkgdmFndWUgc2VydmljZSBpbnRlcmZh Y2Ugb3V0IG9mIHNjb3BlIG5vdy4gQnV0IHN0aWxsLCBhcyBhbiBlc3NlbnRpYWwgcGFydCBvZiB0 aGUgd2hvbGUgc29sdXRpb24sIHRoZSBzZXJ2aWNlIGludGVyZmFjZSBpcyBhbHNvIHZlcnkgaW1w b3J0YW50IGZvciB2YXJpb3VzIGNsaWVudHMgdG8gZXhwcmVzcyB0aGVpciBjdXN0b20gc2VjdXJp dHkgcmVxdWlyZW1lbnQgZmxleGlibHkuIFNvLCBJIHN1Z2dlc3Qgd2UgY2FuIHNldCB0aGUgc3Bl Y2lmaWNhdGlvbiBvZiBzZXJ2aWNlIGludGVyZmFjZSBhcyB0aGUgc2Vjb25kIHBoYXNlIG9mIEky TlNGIHdvcmsuDQoNCk90aGVyIGNvbW1lbnRzIGFyZSBpbmxpbmU6DQoNCkIuUi4NCkZyYW5rDQoN CreivP7IyzogSTJuc2YgW21haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRh IER1bmJhcg0Kt6LLzcqxvOQ6IDIwMTXE6jXUwjfI1SAyMzo1Mw0KytW8/sjLOiBpMm5zZkBpZXRm Lm9yZzsgS2F0aGxlZW4gTW9yaWFydHkNCrOty806IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5v cmc7IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUg STJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpUaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgIElFVEY5 MiBzaWRlIG1lZXRpbmdzLiBBbW9uZyB0aGUgdHdvIEkyTlNGIGludGVyZmFjZXMsICBpLmUuIHRo ZSBjbGllbnQgZmFjaW5nIFNlcnZpY2UgSW50ZXJmYWNlIGFuZCB0aGUgTlNGIGZhY2luZyBDYXBh YmlsaXR5IEludGVyZmFjZSwgdGhlIHdvcmsgdG8gYmUgZG9uZSBhdCB0aGUgQ2FwYWJpbGl0eSBJ bnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0IHRoZSBTZXJ2aWNl IEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCg0KVGhlIGZlZWRiYWNrIGZyb20g bGFzdCBJRVRGIHNpZGUgbWVldGluZ3Mgd2FzICJ0aGUgc2NvcGUgaXMgdG9vIGJpZyBmb3Igb25l IElFVEYgV0ciLiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRo ZSBJMk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBs b2dpYyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UgaXMgY29tcGxldGVkLCB3ZSB3 aWxsIHNlZSBtb3JlIGNsZWFybHkgdGhlIHdvcmsgZm9yIFNlcnZpY2UgaW50ZXJmYWNlLiBFdmVu IGlmIENhcGFiaWxpdHkgbGF5ZXIgYWxvbmUgaXMgc3RhbmRhcmRpemVkLCBpdCBpcyBhIGdpYW50 IGxlYXAgZm9yd2FyZCBpbiBidWlsZGluZyBibG9ja3MgZm9yIFNlcnZpY2UgUHJvdmlkZXIgdG8g YXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlciB0aGF0IGNhbiB1dGlsaXplIE5TRiBi eSBtdWx0aXBsZSB2ZW5kb3JzDQoNCkhlcmUgaXMgdGhlIG5hcnJvd2VyIHNjb3BlZCBJMk5TRiBj aGFydGVyLiBZb3VyIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyBhcmUgZ3JlYXRseSBhcHByZWNp YXRlZC4gQ0Ohr2VkIHRvIERPVFMsIEkyUlMsIGFuZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciBy ZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVzaWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9t ZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5nIG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lh bGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5p bmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRpdGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21t dW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRlIChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZp cnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUgY3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFs bGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRl ZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0 YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBtb25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5 IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJl bWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZp Y2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBz ZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUgdmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdv YWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVycHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkg ZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIgb3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhv c3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFpbiwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21t dW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGljaWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBw ZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQgb2YgTlNGIG9yIHZOU0YuDQpbRnJhbmtdOiB0 aGUgSTJOU0YgY2xpZW50cyBkbyBub3Qgb25seSBpbmNsdWRlIGVudGVycHJpc2UuIFNvLCBjaGFu Z2UgobBlbnRlcnByaXNlobEgdG8gobBJMk5TRiBjbGllbnRzobEuIFdoZXJlIGFyZSB0aGUgcGVy Zm9ybWFuY2UgZGF0YSBvciByZXBvcnQgc2VudCB0bz8gSSB0aGluayB0aGV5IHNob3VsZCBiZSB0 aGUgc2VjdXJpdHkgc2VydmljZSBwcm92aWRlcnMgb3IganVzdCB0aGUgSTJOU0YgY2xpZW50cy4N Cg0KVGhlcmUgYXJlIHR3byBsYXllcnMgb2YgaW50ZXJmYWNlczoNCg0KLSAgICAgICAgICBTZWN1 cml0eSBQb2xpY2llcyBmYWNpbmcgc2VjdXJpdHkgZnVuY3Rpb25zIChJMk5TRiBDYXBhYmlsaXR5 IExheWVyKQ0KDQotICAgICAgICAgIFNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJ Mk5TRiBTZXJ2aWNlIExheWVyKQ0KDQpUaGUgSTJOU0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZp ZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9saWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVk IGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xpY2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25z LiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNl cy4gSW5zdGVhZCwgSTJOU0YgaXMgb25seSB0byBzdGFuZGFyZGl6ZSB0aGUgcG9saWN5IHByb3Zp c2lvbmluZyB0byB0aGUgc2VjdXJpdHkgZnVuY3Rpb25zIChub3QgZGV2aWNlcyksIGluIHRoZSBm b3JtIG9mIKGwU3ViamVjdCCoQyBPYmplY3QgqEMgRnVuY3Rpb24gqEMgQWN0aW9uobEgcGFyYWRp Z20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGllbnRzIHRvIGV4cHJlc3Mg YW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNwZWNpZmljIGZsb3dzLCB3 aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc6GvIGxvZ2ljYWwgbmV0d29ya3MsIGFk ZHJlc3NlcyBhbmQgY29udGV4dC4gSTJOU0YgU2VydmljZSBMYXllciBjYW4gYWxzbyBiZSBzZWN1 cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1aXJlbWVudCwgZXNwZWNpYWxs eSBmb3IgY3VzdG9tZXJzIHdobyBkb26hr3QgaGF2ZSB0aGUgc2VjdXJpdHkgZXhwZXJ0aXNlLg0K W0ZyYW5rXTogZm9yIHRoZSB0d28gaW50ZXJmYWNlcywgbm90IG1lbnRpb25pbmcgdGhlIGZ1bmN0 aW9ucyByZWxhdGVkIHdpdGggcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQ/DQoNClRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAg ICAgICAgVGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0 byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkg ZnVuY3Rpb25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBv ZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBm dW5jdGlvbiwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlv biBjaGFubmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9s bGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFiaWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFz aWJsZSB0byBjYXRlZ29yaXplIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5 IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2VkIG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcg Y2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0 aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRhcmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJm YWNlIGlzIGFuIGVzc2VudGlhbCBidWlsZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQ cm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1 dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2Ug dGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBO ZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpGb3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlz IG91dCBvZiB0aGUgc2NvcGUgZm9yIEkyTlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFy ZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2luZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2 ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBzaG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVs IGludGVyZmFjZXMgdG8gY2xpZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkg b2YgdGhlbSBiZWluZyB0cmFuc2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVz Lg0KDQpTaW5jZSBkaWZmZXJlbnQgc2VjdXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBm ZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9u IGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8g cGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0 ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQgZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3Vj aCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1w bGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQgd2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9u cyBpbmNsdWRlIGRlZXAgcGFja2V0IGluc3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0 ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGluZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxh ciB0byBJMlJTIGZvY3VzaW5nIG9uIHRoZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3Vn aCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBmYXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0 aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlvbnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBz dXBwb3J0ZWQgYnkgdmVuZG9yc6GvIHNwZWNpZmljIGRldmljZXMuDQoNCkl0IGlzIGEgbm9uLWdv YWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3IgZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9y IEkyTlNGIGludGVyZmFjZXMuDQpJMk5TRiBXRyBEZWxpdmVyYWJsZXMgaW5jbHVkZToNCg0KDQot ICAgICAgICAgICBVc2UgQ2FzZSBkb2N1bWVudC4NCg0KLSAgICAgICAgICBGcmFtZXdvcmsgRG9j dW1lbnQuDQoNCi0gICAgICAgICAgUmVxdWlyZW1lbnQgZm9yIGV4dGVuc2lvbnMgKGlmIHRoZXJl IGFyZSBhbnkpIHRvIGV4aXN0aW5nIHByb3RvY29scyB1c2VkIGJ5IHRoZSBXRy4NCg0KLSAgICAg ICAgICAgR2FwIGFuYWx5c2lzIG9mIGV4aXN0aW5nIHByb3RvY29scyBhbmQgbW9kZWxpbmcgbGFu Z3VhZ2VzDQoNCi0gICAgICAgICAgQSBzaW5nbGUsIHVuaWZpZWQsIEluZm9ybWF0aW9uIE1vZGVs IGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2VkIFNlY3VyaXR5IEZ1bmN0 aW9ucyBkZXNjcmliZWQgYWJvdmUuDQoNCi0gICAgICAgICAgQ29ycmVzcG9uZGluZyBEYXRhIE1v ZGVscyAoZS5nLiBZQU5HIG1vZGVscykgZGVyaXZlZCBmcm9tIHRoZSBhYm92ZSBJbmZvcm1hdGlv biBNb2RlbC4NCg0KLSAgICAgICAgICBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gZm9yIGZs b3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24gcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 Lg0KDQotICAgICAgICAgICAoT3B0aW9uYWxseSkgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIG9u IGhvdyB0byB1c2UgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRCB0byBjYXJyeSB0aGUgY29udGVu dCBvZiB0aGUgc3BlY2lmaWVkIGluZm9ybWF0aW9uL2RhdGEgbW9kZWxzLg0KDQpbVGhlIFdHIG1h eSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVudCBh cmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVudHMg ZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgV0cuIFRoZSBmcmFtZXdvcmssIHRoYXQgZGVzY3Jp YmVzIHRoZSBmdW5jdGlvbmFsIGNvbXBvbmVudHMgYW5kIHRoZSBJMk5TRiB3b3JrIGl0ZW1zLCBp cyB0byBtYWtlIEkyTlNGIHdvcmsgbW9yZSBvcmdhbml6ZWQuXQ0KDQpTdWdnZXN0ZWQgTWlsZXN0 b25lcw0KICAtIFVzZSBDYXNlIERvY3VtZW50OiAgQ2hhcnRlciB0aW1lICsgMSBtb250aCB0byBX RyBEb2N1bWVudA0KICAtIEZyYW1ld29yazogQ2hhcnRlciB0aW1lICsgNCBtb250aHMgdG8gV0cg RG9jdW1lbnQNCiAgLSBSZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiAg Q2hhcnRlciB0aW1lICsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQNCiAgLSBJbmZvIG1vZGVsOiBD aGFydGVyIHRpbWUgKyA3IG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIElBTkEgcmVnaXN0cnkg Y29uc2lkZXJhdGlvbiArIDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFsbCBFYXJseSBE cmFmdHMgdG8gSUVTRzogMTAgbW9udGhzDQoNCltkZWNpc2lvbiBwb2ludCCoQyArMTAgbW9udGhz XQ0KICAtIERhdGEgTW9kZWxzOiBDaGFydGVyICsgOSBNb250aHMgdG8gV0cgRG9jdW1lbnQNCiAg LSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHM6IDEwIG1vbnRocyB0byBXRyBEb2N1bWVudA0KICAt IERhdGEgTW9kZWxzIGFuZCBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgdG8gSUVTRyAgLSAxNiBt b250aHMNCg0KVGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQg TmV0bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxp a2UgRVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1l bnQgcmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlIE9ORiwgT3Bl blN0YWNrLCBPREwsIGFuZCBPcGVuTkZWLg0KDQoNCkNoZWVycywNCkxpbmRhIER1bmJhcg0K --_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Linda,

I agree that we can specify capability interface firstly, and lea= ve the currently vague service interface out of scope now. But still, as an= essential part of the whole solution, the service interface is also very important for various clients to expres= s their custom security requirement flexibly. So, I suggest we can set the = specification of service interface as the second phase of I2NSF work.<= /o:p>

 

Other comments are inline:

 

B.R.

Frank

 

=B7=A2=BC=FE=C8=CB: I2nsf [= mailto:i2nsf-bounces@ietf.org] =B4=FA= =B1=ED Linda Dunbar
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA5=D4=C27=C8=D5 23:53
=CA=D5=BC=FE=C8=CB: i2nsf@ietf.org; Kathleen Moriarty
=B3=AD=CB=CD: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org
=D6=F7=CC=E2: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93

 

Thanks to I2NSF contributors fo= r the good progresses made since  IETF92 side meetings. Among the two = I2NSF interfaces,  i.e. the client facing Service Interface and the NS= F facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. But the = Service Interface is still a little vague.

 

The feedback from last IETF sid= e meetings was "the scope is too big for one IETF WG". Therefore,= we are leaning towards narrowing the I2NSF scope to the Capability Interfa= ce. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scoped I2N= SF charter. Your comments and suggestions are greatly appreciated. CC=A1=AF= ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential, and m= obile customers are increasingly consuming network functions, especially ne= twork security related functions that are not running on their premises.&nb= sp; In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NSF is t= o enable enterprises to utilize security functions not hosted on their own = premises but instead hosted in service provider domain, to establish how to= communicate desired security policies to NSF and how to get performance data or report out of NSF or vNSF.<= /o:p>

[Frank]: the I2NSF clients do not only include enterprise. So, ch= ange =A1=B0enterprise=A1=B1 to =A1=B0I2NSF clients=A1=B1. Where are the per= formance data or report sent to? I think they should be the security service providers or just the I2NSF clients.

 

There are two layers of interfa= ces:

-=    &n= bsp;      Security Policies facin= g security functions (I2NSF Capability Layer)

-=    &n= bsp;      Security Policies facin= g clients (I2NSF Service Layer)

 

The I2NSF= Capability Layer specifies the functional security policies, which are tra= nslated from the client security policies, to security functions. I2NSF wil= l NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy provisioning to = the security functions (not devices), in the form of =A1=B0Subject =A8C Obj= ect =A8C Function =A8C Action=A1=B1 paradigm. 

&nbs= p;

The I2NSF Service Layer is for = clients to express and monitor security policies for their specific flows, = which is usually based on customers=A1=AF logical networks, addresses and c= ontext. I2NSF Service Layer can also be security expectation or loose security requirement, especially for customers who do= n=A1=AFt have the security expertise.

[Frank]: for the two interfaces, not mentioning the functions rel= ated with performance data or report?

 

The concrete work at the L2NSF = Capability Layer includes

-The informational &= data models for each category to be represented to virtual or physical net= work security functions,

-The capability registry= (IANA) of policy provisioning capability to flow based security function, = and

-The proper secure commu= nication channels to carry the security policies between Controller and NSF= s.

The capability registry is to m= ake it feasible to categorize network security functions provided by differ= ent vendors based on security policy provisioning capability without any ne= ed to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Layer, it= is out of the scope for I2NSF (at least for now) to standardize the interf= ace facing clients. However, I2NSF can have informational drafts showing sa= mple APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

&nbs= p;

Since different security vendor= s support different features & functions on their devices, I2NSF will f= ocus on flow based security functions that provide treatment to packets/flo= ws, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Authenti= cation, Authorization, or Encryption). Exemplar services associated with Fl= ow Based Security functions include deep packet inspection, packet/flow/str= eam filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing on the= interface to RIB/FIB even though most routers provide far more functions t= han RIB/FIB, the I2NSF focused functions can be a portion of features suppo= rted by vendors=A1=AF specific devices.

 

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

I2NSF WG Deliverables include:<= o:p>

 

-=    &n= bsp;       Use Case document= .

-=    &n= bsp;      Framework Document.

-=    &n= bsp;      Requirement for extensi= ons (if there are any) to existing protocols used by the WG.

-=    &n= bsp;       Gap analysis of e= xisting protocols and modeling languages

-=    &n= bsp;      A single, unified, Info= rmation Model for expressing policies to the Flow Based Security Functions = described above.

-=    &n= bsp;      Corresponding Data Mode= ls (e.g. YANG models) derived from the above Information Model.<= /span>

-=    &n= bsp;      IANA registry considera= tion for flow based security function policy provisioning capability.<= /o:p>

-=    &n= bsp;       (Optionally) Appl= icability Statements on how to use I2RS, Netconf, and NETMOD to carry the c= ontent of the specified information/data models.

 

[The WG may decide that the Use cases, Framework, a= nd Requirement are Informational documents or simply reference documents during the lifetime of the WG. The f= ramework, that describes the functional components and the I2NSF work items= , is to make I2NSF work more organized.]=

 

Suggested Milestones=

  - Use Case Document:&nbs= p; Charter time + 1 month to WG Document

  - Framework: Charter tim= e + 4 months to WG Document

  - Requirements for exten= sions to protocols:  Charter time + 6 months to WG document

  - Info model: Charter ti= me + 7 months to WG Document

  - IANA registry consider= ation + 10 months to WG Document

  - All Early Drafts to IE= SG: 10 months

 

[decision point =A8C +10 mo= nths] 

  - Data Models: Char= ter + 9 Months to WG Document

  - Applicability Statemen= ts: 10 months to WG Document

  - Data Models and Applic= ability Statements to IESG  - 16 months

 

The WG will work closely with I= 2RS, Netconf and Netmod WGs. The WG will communicate with external SDOs lik= e ETSI NFV and will encourage open source code development related to the W= G scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar<= /p>

--_000_C02846B1344F344EB4FAA6FA7AF481F12ADB7711SZXEMA502MBSchi_-- From nobody Tue May 12 16:32: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 AD5B71A0248 for ; Tue, 12 May 2015 16:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVjT5WmC0qTp for ; Tue, 12 May 2015 16:32:48 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 89DF31A0211 for ; Tue, 12 May 2015 16:32:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.198; From: "Susan Hares" To: Date: Tue, 12 May 2015 19:32:44 -0400 Message-ID: <00a501d08d0b$f319dee0$d94d9ca0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A6_01D08CEA.6C09C580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCNC+aXmDEZLCE8SpGrXD9QGzccFg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' Subject: [i2rs] interim for 5/13/2015 is cancelled 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, 12 May 2015 23:32:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A6_01D08CEA.6C09C580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The interim for 5/13/2015 is cancelled. Sue Hares ------=_NextPart_000_00A6_01D08CEA.6C09C580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = interim for 5/13/2015 is cancelled.

 

Sue = Hares

------=_NextPart_000_00A6_01D08CEA.6C09C580-- From nobody Wed May 13 09:26: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 C53EC1A8A84; Wed, 13 May 2015 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKUS6xKe1b2K; Wed, 13 May 2015 09:26:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073211A88FF; Wed, 13 May 2015 09:26:32 -0700 (PDT) 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 BSM49135; Wed, 13 May 2015 16:26:31 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:26:31 +0100 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, 13 May 2015 09:26:21 -0700 From: Linda Dunbar To: Dacheng Zhang , "i2nsf@ietf.org" , "sacm@ietf.org" Thread-Topic: secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQjTCk1xjNa7wv+UGGDcLStnhTlZ16Fx/w Date: Wed, 13 May 2015 16:26:21 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C1443C@dfweml701-chm> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" Subject: [i2rs] secure communication channel to exchange security policy and monitor execution status for I2NSF (was RE: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 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, 13 May 2015 16:26:39 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGEgQ2hlbmcsDQoNCg0KWW91IHN0YXRlZCB0aGF0IHRoZSBidWxsZXQgZm9yIOKAnFRoZSBwcm9w ZXIgc2VjdXJlIGNvbW11bmljYXRpb24gY2hhbm5lbHMgdG8gY2FycnkgdGhlIHNlY3VyaXR5IHBv bGljaWVzIGJldHdlZW4gQ29udHJvbGxlciBhbmQgTlNGc+KAnSAgaXMgdHJpdmlhbC4gQnV0DQpT QUNNIGlzIGNvbnNpZGVyaW5nIHVzaW5nIFhNUFAgdG8gZXhjaGFuZ2UgZGF0YSBhbW9uZyBlbmQg ZGV2aWNlcyAoaW5zdGVhZCBvZiBORVRDT05GKTogc2VlICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNhY20teG1wcC1ncmlkLw0KDQoNClNvIHRoZXJlIG1p Z2h0IGJlIG1vcmUgdGhhbiBzaW1wbGUgTkVUQ09ORiwgbWF5IGJlIFRMUyAreHh4IGhhdmUgdG8g YmUgY29uc2lkZXJlZC4NCg0KTGluZGENCg0KRnJvbTogRGFjaGVuZyBaaGFuZyBbbWFpbHRvOmRh Y2hlbmcuemRjQGFsaWJhYmEtaW5jLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAx MDo1NSBQTQ0KVG86IExpbmRhIER1bmJhcjsgaTJuc2ZAaWV0Zi5vcmc7IEthdGhsZWVuIE1vcmlh cnR5DQpDYzogaTJyc0BpZXRmLm9yZzsgZG90c0BpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRo ZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5Mw0KDQpIae+8jExpbmRhOg0KDQpJIGxpa2UgdGhlIGN1 cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25hYmxlIHNj b3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLg0KDQoNClRoZSBjb25jcmV0ZSB3 b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAg VGhlIGluZm9ybWF0aW9uYWwgJiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSBy ZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rp b25zLA0KDQotICAgICAgICAgIFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xp Y3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlv biwgYW5kDQoNCi0gICAgICAgICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFu bmVscyB0byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFu ZCBOU0ZzLg0KDQoNCg0KPj5EYWNoZW5nOiB0aGUgdGhpcmQgYnVsbGV0IGlzIHF1aXRlIHRyaXZh bCBjb21wYXJlZCB3aXRoIHRoZSBmaXJzdCB0d28gYnVsbGV0cywgc2luY2Ugd2Ugd2lsbCB0cnkg dG8gcmUtdXNlIHRoZSB3b3JrIG9mIEkyUlMsTmV0Y29uZiB3aGVyZSB0aGUgZ2VuZXJhdGlvbiBv ZiBzZWN1cml0eSBjaGFubmVscyBoYXZlIGFscmVhZHkgY29uc2lkZXJlZC4gIFNvLCBtYXliZSB3 ZSBjb3VsZCByZW1vdmUgaXQuDQoNClRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2Ug aXQgZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92 aWRlZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlz aW9uaW5nIGNhcGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0 eSBmdW5jdGlvbnMgdGhlbXNlbHZlcy4gIFN0YW5kYXJkIHByb3Zpc2lvbmluZyBjYXBhYmlsaXR5 IGludGVyZmFjZSBpcyBhbiBlc3NlbnRpYWwgYnVpbGRpbmcgYmxvY2sgZm9yIFNlY3VyaXR5IFNl cnZpY2UgUHJvdmlkZXIgdG8gYXV0b21hdGUgdGhlaXIgU2VjdXJpdHkgQ29udHJvbGxlcnMgdGhh dCBjYW4gdXRpbGl6ZSBOU0YgYnkgbXVsdGlwbGUgdmVuZG9ycy4gVGhpcyBsYXllciB3aWxsIGxl dmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC4NCg0KPj5EYWNoZW5nOiBJIHN1Z2dlc3QgdG8gY2hh bmdlIHRoZSBsYXN0IHNlbnRlbmNlIHRvIOKAnEluIHRoaXMgbGF5ZXIsIHdlIHdpbGwgbGV2ZXJh Z2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBhbmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJT LCBOZXRjb25mLCBhbmQgTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdDQoNClNpbWlsYXIg dG8gSTJSUyBmb2N1c2luZyBvbiB0aGUgaW50ZXJmYWNlIHRvIFJJQi9GSUIgZXZlbiB0aG91Z2gg bW9zdCByb3V0ZXJzIHByb3ZpZGUgZmFyIG1vcmUgZnVuY3Rpb25zIHRoYW4gUklCL0ZJQiwgdGhl IEkyTlNGIGZvY3VzZWQgZnVuY3Rpb25zIGNhbiBiZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3Vw cG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMgZGV2aWNlcy4NCg0KPj5EYWNoZW5nOiB0aGUg Zmlyc3QgcGFydCBvZiB0aGlzIHNlbnRlbmNlIGlzIHJlZHVuZGFudC4gV2UgZG9u4oCZdCBoYXZl IHRvIGltcGx5IHRoYXQg4oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNhdXNlIEkyUlMgdXNlZCB0 byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYgeW91IHdhbnQgdG8gY2hhbGxlbmdlIHVzLCBwbGVh c2UgY2hhbGxlbmdlIEkyUlMgZmlyc3TigJ0uIE1heWJlIHdlIGNvdWxkIHJlbW92ZSBpdC4NCg0K 5Y+R5Lu25Lq6OiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3ZWkuY29tPG1haWx0bzps aW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQrml6XmnJ86IDIwMTXlubQ15pyIN+aXpSDmmJ/mnJ/l m5sg5LiL5Y2IMTE6NTMNCuiHszogImkybnNmQGlldGYub3JnPG1haWx0bzppMm5zZkBpZXRmLm9y Zz4iIDxpMm5zZkBpZXRmLm9yZzxtYWlsdG86aTJuc2ZAaWV0Zi5vcmc+PiwgS2F0aGxlZW4gTW9y aWFydHkgPGthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPG1haWx0bzprYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+DQrmioTpgIE6ICJpMnJzQGlldGYub3JnPG1haWx0bzpp MnJzQGlldGYub3JnPiIgPGkycnNAaWV0Zi5vcmc8bWFpbHRvOmkycnNAaWV0Zi5vcmc+PiwgImRv dHNAaWV0Zi5vcmc8bWFpbHRvOmRvdHNAaWV0Zi5vcmc+IiA8ZG90c0BpZXRmLm9yZzxtYWlsdG86 ZG90c0BpZXRmLm9yZz4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+ IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0K5Li76aKYOiBbSTJu c2ZdIEZ1cnRoZXIgTmFycm93aW5nIHRoZSBJMk5TRiBzY29wZTogdGhlIG5ldyBjaGFydGVyIGZv ciBJRVRGIDkzDQoNClRoYW5rcyB0byBJMk5TRiBjb250cmlidXRvcnMgZm9yIHRoZSBnb29kIHBy b2dyZXNzZXMgbWFkZSBzaW5jZSAgSUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28g STJOU0YgaW50ZXJmYWNlcywgIGkuZS4gdGhlIGNsaWVudCBmYWNpbmcgU2VydmljZSBJbnRlcmZh Y2UgYW5kIHRoZSBOU0YgZmFjaW5nIENhcGFiaWxpdHkgSW50ZXJmYWNlLCB0aGUgd29yayB0byBi ZSBkb25lIGF0IHRoZSBDYXBhYmlsaXR5IEludGVyZmFjZSBiZWNvbWVzIHZlcnkgY2xlYXIgYW5k IGNvbmNyZXRlLiBCdXQgdGhlIFNlcnZpY2UgSW50ZXJmYWNlIGlzIHN0aWxsIGEgbGl0dGxlIHZh Z3VlLg0KDQpUaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lkZSBtZWV0aW5ncyB3YXMgInRo ZSBzY29wZSBpcyB0b28gYmlnIGZvciBvbmUgSUVURiBXRyIuIFRoZXJlZm9yZSwgd2UgYXJlIGxl YW5pbmcgdG93YXJkcyBuYXJyb3dpbmcgdGhlIEkyTlNGIHNjb3BlIHRvIHRoZSBDYXBhYmlsaXR5 IEludGVyZmFjZS4gVGhlIHRoaW5raW5nIGxvZ2ljIGlzOiBPbmNlIHRoZSBDYXBhYmlsaXR5IElu dGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdpbGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBm b3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4gaWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBz dGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQgbGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2Nr cyBmb3IgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9s bGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMNCg0KSGVyZSBpcyB0 aGUgbmFycm93ZXIgc2NvcGVkIEkyTlNGIGNoYXJ0ZXIuIFlvdXIgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zIGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiBDQ+KAmWVkIHRvIERPVFMsIEkyUlMsIGFu ZCBOZXRtb2QgZ3JvdXBzIGZvciB3aWRlciByZXZpZXcuDQoNCg0KDQpFbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuICBJbiBhZGRp dGlvbiwgdGhlIEV1cm9wZWFuIFRlbGVjb21tdW5pY2F0aW9ucyBTdGFuZGFyZHMgSW5zdGl0dXRl IChFVFNJKSBOZXR3b3JrIEZ1bmN0aW9uIFZpcnR1YWxpemF0aW9uIChORlYpIGluaXRpYXRpdmUg Y3JlYXRlcyBuZXcgbWFuYWdlbWVudCBjaGFsbGVuZ2VzIGZvciBzZWN1cml0eSBwb2xpY2llcyB0 byBiZSBlbmZvcmNlZCBieSBkaXN0cmlidXRlZCwgdmlydHVhbCwgbmV0d29yayBzZWN1cml0eSBm dW5jdGlvbnMgKHZOU0YpLiBXaXRob3V0IHN0YW5kYXJkIGludGVyZmFjZSB0byBleHByZXNzLCBt b25pdG9yLCBhbmQgbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5IGZ1bmN0aW9u cyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmlydHVhbGx5IGlt cG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9tYXRlIHRoZSBz ZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkgbXVsdGlwbGUg dmVuZG9ycy4NCg0KVGhlIHVsdGltYXRlIGdvYWwgb2YgSTJOU0YgaXMgdG8gZW5hYmxlIGVudGVy cHJpc2VzIHRvIHV0aWxpemUgc2VjdXJpdHkgZnVuY3Rpb25zIG5vdCBob3N0ZWQgb24gdGhlaXIg b3duIHByZW1pc2VzIGJ1dCBpbnN0ZWFkIGhvc3RlZCBpbiBzZXJ2aWNlIHByb3ZpZGVyIGRvbWFp biwgdG8gZXN0YWJsaXNoIGhvdyB0byBjb21tdW5pY2F0ZSBkZXNpcmVkIHNlY3VyaXR5IHBvbGlj aWVzIHRvIE5TRiBhbmQgaG93IHRvIGdldCBwZXJmb3JtYW5jZSBkYXRhIG9yIHJlcG9ydCBvdXQg b2YgTlNGIG9yIHZOU0YuDQoNClRoZXJlIGFyZSB0d28gbGF5ZXJzIG9mIGludGVyZmFjZXM6DQoN Ci0gICAgICAgICAgU2VjdXJpdHkgUG9saWNpZXMgZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAo STJOU0YgQ2FwYWJpbGl0eSBMYXllcikNCg0KLSAgICAgICAgICBTZWN1cml0eSBQb2xpY2llcyBm YWNpbmcgY2xpZW50cyAoSTJOU0YgU2VydmljZSBMYXllcikNCg0KVGhlIEkyTlNGIENhcGFiaWxp dHkgTGF5ZXIgc3BlY2lmaWVzIHRoZSBmdW5jdGlvbmFsIHNlY3VyaXR5IHBvbGljaWVzLCB3aGlj aCBhcmUgdHJhbnNsYXRlZCBmcm9tIHRoZSBjbGllbnQgc2VjdXJpdHkgcG9saWNpZXMsIHRvIHNl Y3VyaXR5IGZ1bmN0aW9ucy4gSTJOU0Ygd2lsbCBOT1Qgc3RhbmRhcmRpemUgc2VjdXJpdHkgZnVu Y3Rpb25zIG9yIGRldmljZXMuIEluc3RlYWQsIEkyTlNGIGlzIG9ubHkgdG8gc3RhbmRhcmRpemUg dGhlIHBvbGljeSBwcm92aXNpb25pbmcgdG8gdGhlIHNlY3VyaXR5IGZ1bmN0aW9ucyAobm90IGRl dmljZXMpLCBpbiB0aGUgZm9ybSBvZiDigJxTdWJqZWN0IOKAkyBPYmplY3Qg4oCTIEZ1bmN0aW9u IOKAkyBBY3Rpb27igJ0gcGFyYWRpZ20uDQoNClRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZv ciBjbGllbnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRo ZWlyIHNwZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KA mSBsb2dpY2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2Ug TGF5ZXIgY2FuIGFsc28gYmUgc2VjdXJpdHkgZXhwZWN0YXRpb24gb3IgbG9vc2Ugc2VjdXJpdHkg cmVxdWlyZW1lbnQsIGVzcGVjaWFsbHkgZm9yIGN1c3RvbWVycyB3aG8gZG9u4oCZdCBoYXZlIHRo ZSBzZWN1cml0eSBleHBlcnRpc2UuDQoNClRoZSBjb25jcmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBD YXBhYmlsaXR5IExheWVyIGluY2x1ZGVzDQoNCi0gICAgICAgICAgVGhlIGluZm9ybWF0aW9uYWwg JiBkYXRhIG1vZGVscyBmb3IgZWFjaCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0 dWFsIG9yIHBoeXNpY2FsIG5ldHdvcmsgc2VjdXJpdHkgZnVuY3Rpb25zLA0KDQotICAgICAgICAg IFRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kDQoNCi0gICAgICAg ICAgVGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBjYXJyeSB0aGUg c2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLg0KVGhlIGNhcGFi aWxpdHkgcmVnaXN0cnkgaXMgdG8gbWFrZSBpdCBmZWFzaWJsZSB0byBjYXRlZ29yaXplIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zIHByb3ZpZGVkIGJ5IGRpZmZlcmVudCB2ZW5kb3JzIGJhc2Vk IG9uIHNlY3VyaXR5IHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSB3aXRob3V0IGFueSBu ZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAgU3RhbmRh cmQgcHJvdmlzaW9uaW5nIGNhcGFiaWxpdHkgaW50ZXJmYWNlIGlzIGFuIGVzc2VudGlhbCBidWls ZGluZyBibG9jayBmb3IgU2VjdXJpdHkgU2VydmljZSBQcm92aWRlciB0byBhdXRvbWF0ZSB0aGVp ciBTZWN1cml0eSBDb250cm9sbGVycyB0aGF0IGNhbiB1dGlsaXplIE5TRiBieSBtdWx0aXBsZSB2 ZW5kb3JzLiBUaGlzIGxheWVyIHdpbGwgbGV2ZXJhZ2UgdGhlIGV4aXN0aW5nIHByb3RvY29scyBh bmQgZGF0YSBtb2RlbHMgZGVmaW5lZCBieSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9ELg0KDQpG b3IgdGhlIEkyTlNGIFNlcnZpY2UgTGF5ZXIsIGl0IGlzIG91dCBvZiB0aGUgc2NvcGUgZm9yIEky TlNGIChhdCBsZWFzdCBmb3Igbm93KSB0byBzdGFuZGFyZGl6ZSB0aGUgaW50ZXJmYWNlIGZhY2lu ZyBjbGllbnRzLiBIb3dldmVyLCBJMk5TRiBjYW4gaGF2ZSBpbmZvcm1hdGlvbmFsIGRyYWZ0cyBz aG93aW5nIHNhbXBsZSBBUElzIG9yL2FuZCBSRVNUZnVsIGludGVyZmFjZXMgdG8gY2xpZW50cyBh bmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFuc2xhdGVk IHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KDQpTaW5jZSBkaWZmZXJlbnQgc2Vj dXJpdHkgdmVuZG9ycyBzdXBwb3J0IGRpZmZlcmVudCBmZWF0dXJlcyAmIGZ1bmN0aW9ucyBvbiB0 aGVpciBkZXZpY2VzLCBJMk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVu Y3Rpb25zIHRoYXQgcHJvdmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJ UFMvSURTLCBXZWIgZmlsdGVyLCBhbmQgZmxvdyBmaWx0ZXIuIChUaGV5IGFyZSBkaWZmZXJlbnQg ZnJvbSBvdGhlciBzZWN1cml0eSBmdW5jdGlvbnMgc3VjaCBhcyBBdXRoZW50aWNhdGlvbiwgQXV0 aG9yaXphdGlvbiwgb3IgRW5jcnlwdGlvbikuIEV4ZW1wbGFyIHNlcnZpY2VzIGFzc29jaWF0ZWQg d2l0aCBGbG93IEJhc2VkIFNlY3VyaXR5IGZ1bmN0aW9ucyBpbmNsdWRlIGRlZXAgcGFja2V0IGlu c3BlY3Rpb24sIHBhY2tldC9mbG93L3N0cmVhbSBmaWx0ZXJpbmcgb3IgcGF0dGVybiBtYXRjaGlu ZyBhbmQgcmVtZWRpYXRpb24sIGV0Yy4NCg0KU2ltaWxhciB0byBJMlJTIGZvY3VzaW5nIG9uIHRo ZSBpbnRlcmZhY2UgdG8gUklCL0ZJQiBldmVuIHRob3VnaCBtb3N0IHJvdXRlcnMgcHJvdmlkZSBm YXIgbW9yZSBmdW5jdGlvbnMgdGhhbiBSSUIvRklCLCB0aGUgSTJOU0YgZm9jdXNlZCBmdW5jdGlv bnMgY2FuIGJlIGEgcG9ydGlvbiBvZiBmZWF0dXJlcyBzdXBwb3J0ZWQgYnkgdmVuZG9yc+KAmSBz cGVjaWZpYyBkZXZpY2VzLg0KDQpJdCBpcyBhIG5vbi1nb2FsIHRvIGNyZWF0ZSBuZXcgcHJvdG9j b2xzIG9yIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2VzIGZvciBJMk5TRiBpbnRlcmZhY2VzLg0KSTJO U0YgV0cgRGVsaXZlcmFibGVzIGluY2x1ZGU6DQoNCg0KLSAgICAgICAgICAgVXNlIENhc2UgZG9j dW1lbnQuDQoNCi0gICAgICAgICAgRnJhbWV3b3JrIERvY3VtZW50Lg0KDQotICAgICAgICAgIFJl cXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBleGlzdGluZyBw cm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQoNCi0gICAgICAgICAgIEdhcCBhbmFseXNpcyBvZiBl eGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5nIGxhbmd1YWdlcw0KDQotICAgICAgICAgIEEg c2luZ2xlLCB1bmlmaWVkLCBJbmZvcm1hdGlvbiBNb2RlbCBmb3IgZXhwcmVzc2luZyBwb2xpY2ll cyB0byB0aGUgRmxvdyBCYXNlZCBTZWN1cml0eSBGdW5jdGlvbnMgZGVzY3JpYmVkIGFib3ZlLg0K DQotICAgICAgICAgIENvcnJlc3BvbmRpbmcgRGF0YSBNb2RlbHMgKGUuZy4gWUFORyBtb2RlbHMp IGRlcml2ZWQgZnJvbSB0aGUgYWJvdmUgSW5mb3JtYXRpb24gTW9kZWwuDQoNCi0gICAgICAgICAg SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1bmN0 aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS4NCg0KLSAgICAgICAgICAgKE9wdGlv bmFsbHkpIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50cyBvbiBob3cgdG8gdXNlIEkyUlMsIE5ldGNv bmYsIGFuZCBORVRNT0QgdG8gY2FycnkgdGhlIGNvbnRlbnQgb2YgdGhlIHNwZWNpZmllZCBpbmZv cm1hdGlvbi9kYXRhIG1vZGVscy4NCg0KW1RoZSBXRyBtYXkgZGVjaWRlIHRoYXQgdGhlIFVzZSBj YXNlcywgRnJhbWV3b3JrLCBhbmQgUmVxdWlyZW1lbnQgYXJlIEluZm9ybWF0aW9uYWwgZG9jdW1l bnRzIG9yIHNpbXBseSByZWZlcmVuY2UgZG9jdW1lbnRzIGR1cmluZyB0aGUgbGlmZXRpbWUgb2Yg dGhlIFdHLiBUaGUgZnJhbWV3b3JrLCB0aGF0IGRlc2NyaWJlcyB0aGUgZnVuY3Rpb25hbCBjb21w b25lbnRzIGFuZCB0aGUgSTJOU0Ygd29yayBpdGVtcywgaXMgdG8gbWFrZSBJMk5TRiB3b3JrIG1v cmUgb3JnYW5pemVkLl0NCg0KU3VnZ2VzdGVkIE1pbGVzdG9uZXMNCiAgLSBVc2UgQ2FzZSBEb2N1 bWVudDogIENoYXJ0ZXIgdGltZSArIDEgbW9udGggdG8gV0cgRG9jdW1lbnQNCiAgLSBGcmFtZXdv cms6IENoYXJ0ZXIgdGltZSArIDQgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gUmVxdWlyZW1l bnRzIGZvciBleHRlbnNpb25zIHRvIHByb3RvY29sczogIENoYXJ0ZXIgdGltZSArIDYgbW9udGhz IHRvIFdHIGRvY3VtZW50DQogIC0gSW5mbyBtb2RlbDogQ2hhcnRlciB0aW1lICsgNyBtb250aHMg dG8gV0cgRG9jdW1lbnQNCiAgLSBJQU5BIHJlZ2lzdHJ5IGNvbnNpZGVyYXRpb24gKyAxMCBtb250 aHMgdG8gV0cgRG9jdW1lbnQNCiAgLSBBbGwgRWFybHkgRHJhZnRzIHRvIElFU0c6IDEwIG1vbnRo cw0KDQpbZGVjaXNpb24gcG9pbnQg4oCTICsxMCBtb250aHNdDQogIC0gRGF0YSBNb2RlbHM6IENo YXJ0ZXIgKyA5IE1vbnRocyB0byBXRyBEb2N1bWVudA0KICAtIEFwcGxpY2FiaWxpdHkgU3RhdGVt ZW50czogMTAgbW9udGhzIHRvIFdHIERvY3VtZW50DQogIC0gRGF0YSBNb2RlbHMgYW5kIEFwcGxp Y2FiaWxpdHkgU3RhdGVtZW50cyB0byBJRVNHICAtIDE2IG1vbnRocw0KDQpUaGUgV0cgd2lsbCB3 b3JrIGNsb3NlbHkgd2l0aCBJMlJTLCBOZXRjb25mIGFuZCBOZXRtb2QgV0dzLiBUaGUgV0cgd2ls bCBjb21tdW5pY2F0ZSB3aXRoIGV4dGVybmFsIFNET3MgbGlrZSBFVFNJIE5GViBhbmQgd2lsbCBl bmNvdXJhZ2Ugb3BlbiBzb3VyY2UgY29kZSBkZXZlbG9wbWVudCByZWxhdGVkIHRvIHRoZSBXRyBz Y29wZSBpbiBvcmdhbml6YXRpb25zIGxpa2UgT05GLCBPcGVuU3RhY2ssIE9ETCwgYW5kIE9wZW5O RlYuDQoNCg0KQ2hlZXJzLA0KTGluZGEgRHVuYmFyDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBJMm5zZiBtYWlsaW5nIGxpc3QgSTJuc2ZAaWV0Zi5vcmc8 bWFpbHRvOkkybnNmQGlldGYub3JnPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2kybnNmDQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk65a6L5L2TO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsN CgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTg2MzA2NTcy Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTYxNTk5 ODIyIDE5ODI2NjA0MzYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMi41cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 MTU1MDYwNjg1NDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTMxMTkxOTA3MiAyMTMzMDcwMzI2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MjIuNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6U2ltU3VuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5EYSBDaGVuZywgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPllvdSBzdGF0ZWQg dGhhdCB0aGUgYnVsbGV0IGZvciDigJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dDtjb2xvcjpibGFjayI+VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0 byBjYXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2Vlbg0KIENvbnRyb2xsZXIgYW5kIE5T RnPigJ0gPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDtpcyB0cml2aWFs LiBCdXQgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNBQ00gaXMgY29uc2lkZXJpbmcgdXNpbmcgWE1QUCB0byBl eGNoYW5nZSBkYXRhIGFtb25nIGVuZCBkZXZpY2VzIChpbnN0ZWFkIG9mIE5FVENPTkYpOiBzZWUN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zYWxvd2V5LXNh Y20teG1wcC1ncmlkLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2Fs b3dleS1zYWNtLXhtcHAtZ3JpZC88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB0aGVyZSBtaWdodCBi ZSBtb3JlIHRoYW4gc2ltcGxlIE5FVENPTkYsIG1heSBiZSBUTFMgJiM0Mzt4eHggaGF2ZSB0byBi ZSBjb25zaWRlcmVkLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5MaW5k YSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiBEYWNoZW5nIFpoYW5nIFttYWlsdG86ZGFjaGVuZy56ZGNAYWxpYmFiYS1pbmMuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxMiwgMjAxNSAxMDo1NSBQTTxicj4N CjxiPlRvOjwvYj4gTGluZGEgRHVuYmFyOyBpMm5zZkBpZXRmLm9yZzsgS2F0aGxlZW4gTW9yaWFy dHk8YnI+DQo8Yj5DYzo8L2I+IGkycnNAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmc7IG5ldG1vZEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0kybnNmXSBGdXJ0aGVyIE5hcnJvd2lu ZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+SGk8L3NwYW4+ PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6U2lt U3VuO2NvbG9yOmJsYWNrIj7vvIw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkxpbmRhOjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5JIGxpa2Ug dGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBjaGFydGVyLCB3aGljaCBjbGFyaWZpZXMgYSByZWFzb25h YmxlIHNjb3BlIG9mIHRoaXMgd29yay4gU29tZSB0aW55IGNvbW1lbnRzLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBjb25j cmV0ZSB3b3JrIGF0IHRoZSBMMk5TRiBDYXBhYmlsaXR5IExheWVyIGluY2x1ZGVzPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIy LjVwdDt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29s b3I6YmxhY2siPi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtUaGUgaW5mb3JtYXRpb25hbCAmYW1wOyBkYXRhIG1vZGVscyBmb3IgZWFj aCBjYXRlZ29yeSB0byBiZSByZXByZXNlbnRlZCB0byB2aXJ0dWFsIG9yIHBoeXNpY2FsIG5ldHdv cmsgc2VjdXJpdHkgZnVuY3Rpb25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0u MjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+LSZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBj YXBhYmlsaXR5IHJlZ2lzdHJ5IChJQU5BKSBvZiBwb2xpY3kgcHJvdmlzaW9uaW5nIGNhcGFiaWxp dHkgdG8gZmxvdyBiYXNlZCBzZWN1cml0eSBmdW5jdGlvbiwgYW5kPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41 cHQ7dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9y OmJsYWNrIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhlIHByb3BlciBzZWN1cmUgY29tbXVuaWNhdGlvbiBjaGFubmVscyB0byBj YXJyeSB0aGUgc2VjdXJpdHkgcG9saWNpZXMgYmV0d2VlbiBDb250cm9sbGVyIGFuZCBOU0ZzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1p bmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj4m Z3Q7Jmd0O0RhY2hlbmc6IHRoZSB0aGlyZCBidWxsZXQgaXMgcXVpdGUgdHJpdmFsIGNvbXBhcmVk IHdpdGggdGhlIGZpcnN0IHR3byBidWxsZXRzLCBzaW5jZSB3ZSB3aWxsIHRyeSB0byByZS11c2Ug dGhlIHdvcmsgb2YgSTJSUyxOZXRjb25mIHdoZXJlIHRoZQ0KIGdlbmVyYXRpb24gb2Ygc2VjdXJp dHkgY2hhbm5lbHMgaGF2ZSBhbHJlYWR5IGNvbnNpZGVyZWQuICZuYnNwO1NvLCBtYXliZSB3ZSBj b3VsZCByZW1vdmUgaXQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQg ZmVhc2libGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRl ZCBieSBkaWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9u aW5nDQogY2FwYWJpbGl0eSB3aXRob3V0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIHNlY3VyaXR5 IGZ1bmN0aW9ucyB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJp bGl0eSBpbnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0 eSBTZXJ2aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJz IHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuDQogVGhpcyBsYXllciB3 aWxsIGxldmVyYWdlIHRoZSBleGlzdGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmlu ZWQgYnkgSTJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZndDsmZ3Q7RGFjaGVuZzogSSBzdWdnZXN0IHRvIGNoYW5nZSB0aGUgbGFz dCBzZW50ZW5jZSB0byDigJxJbiB0aGlzIGxheWVyLCB3ZSB3aWxsIGxldmVyYWdlIHRoZSBleGlz dGluZyBwcm90b2NvbHMgYW5kIGRhdGEgbW9kZWxzIGRlZmluZWQgYnkgSTJSUywgTmV0Y29uZiwg YW5kDQogTkVUTU9EIGFzIG11Y2ggYXMgcG9zc2libGUu4oCdPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRvIEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFj ZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1vc3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1 bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJMk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4NCiBi ZSBhIHBvcnRpb24gb2YgZmVhdHVyZXMgc3VwcG9ydGVkIGJ5IHZlbmRvcnPigJkgc3BlY2lmaWMg ZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsmZ3Q7RGFj aGVuZzogdGhlIGZpcnN0IHBhcnQgb2YgdGhpcyBzZW50ZW5jZSBpcyByZWR1bmRhbnQuIFdlIGRv buKAmXQgaGF2ZSB0byBpbXBseSB0aGF0Jm5ic3A74oCcd2Ugd29yayBpbiB0aGlzIHdheSBiZWNh dXNlIEkyUlMgdXNlZCB0byBkbyBzaW1pbGFyIHRoaW5ncy4gU28gaWYNCiB5b3Ugd2FudCB0byBj aGFsbGVuZ2UgdXMsIHBsZWFzZSBjaGFsbGVuZ2UgSTJSUyBmaXJzdOKAnS4gTWF5YmUgd2UgY291 bGQgcmVtb3ZlIGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNr Ij7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5MaW5kYSBEdW5iYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbSI+bGluZGEuZHVuYmFyQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCjwv c3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pel5pyfPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjo8 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+MjAxNTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+NTwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5 OlNpbVN1bjtjb2xvcjpibGFjayI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Nzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1bjtjb2xv cjpibGFjayI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iY29sb3I6YmxhY2si Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2Nv bG9yOmJsYWNrIj7mmJ/mnJ/lm5s8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJjb2xv cjpibGFjayI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LWZhbWlseTpT aW1TdW47Y29sb3I6YmxhY2siPuS4i+WNiDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjExOjUzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7o h7M8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mcXVvdDs8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmkybnNmQGlldGYub3JnIj5pMm5zZkBp ZXRmLm9yZzwvYT4mZ3Q7LCBLYXRobGVlbiBNb3JpYXJ0eSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmth dGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tIj5rYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdt YWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Ojwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4NCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mcXVvdDs8YSBocmVm PSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+aTJyc0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzppMnJzQGlldGYub3JnIj5pMnJzQGlldGYub3JnPC9hPiZndDssICZxdW90Ozxh IGhyZWY9Im1haWx0bzpkb3RzQGlldGYub3JnIj5kb3RzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmRvdHNAaWV0Zi5vcmciPmRvdHNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPiZx dW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt ZmFtaWx5OlNpbVN1bjtjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W0kybnNmXSBGdXJ0aGVyIE5h cnJvd2luZyB0aGUgSTJOU0Ygc2NvcGU6IHRoZSBuZXcgY2hhcnRlciBmb3IgSUVURiA5MzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFua3MgdG8gSTJO U0YgY29udHJpYnV0b3JzIGZvciB0aGUgZ29vZCBwcm9ncmVzc2VzIG1hZGUgc2luY2UgJm5ic3A7 SUVURjkyIHNpZGUgbWVldGluZ3MuIEFtb25nIHRoZSB0d28gSTJOU0YgaW50ZXJmYWNlcywgJm5i c3A7aS5lLiB0aGUgY2xpZW50IGZhY2luZyBTZXJ2aWNlIEludGVyZmFjZSBhbmQgdGhlIE5TRiBm YWNpbmcgQ2FwYWJpbGl0eSBJbnRlcmZhY2UsIHRoZSB3b3JrDQogdG8gYmUgZG9uZSBhdCB0aGUg Q2FwYWJpbGl0eSBJbnRlcmZhY2UgYmVjb21lcyB2ZXJ5IGNsZWFyIGFuZCBjb25jcmV0ZS4gQnV0 IHRoZSBTZXJ2aWNlIEludGVyZmFjZSBpcyBzdGlsbCBhIGxpdHRsZSB2YWd1ZS4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgZmVlZGJhY2sgZnJvbSBsYXN0IElFVEYgc2lk ZSBtZWV0aW5ncyB3YXMgJnF1b3Q7dGhlIHNjb3BlIGlzIHRvbyBiaWcgZm9yIG9uZSBJRVRGIFdH JnF1b3Q7LiBUaGVyZWZvcmUsIHdlIGFyZSBsZWFuaW5nIHRvd2FyZHMgbmFycm93aW5nIHRoZSBJ Mk5TRiBzY29wZSB0byB0aGUgQ2FwYWJpbGl0eSBJbnRlcmZhY2UuIFRoZSB0aGlua2luZyBsb2dp YyBpczogT25jZSB0aGUgQ2FwYWJpbGl0eQ0KIEludGVyZmFjZSBpcyBjb21wbGV0ZWQsIHdlIHdp bGwgc2VlIG1vcmUgY2xlYXJseSB0aGUgd29yayBmb3IgU2VydmljZSBpbnRlcmZhY2UuIEV2ZW4g aWYgQ2FwYWJpbGl0eSBsYXllciBhbG9uZSBpcyBzdGFuZGFyZGl6ZWQsIGl0IGlzIGEgZ2lhbnQg bGVhcCBmb3J3YXJkIGluIGJ1aWxkaW5nIGJsb2NrcyBmb3IgU2VydmljZSBQcm92aWRlciB0byBh dXRvbWF0ZSB0aGVpciBTZWN1cml0eSBDb250cm9sbGVyIHRoYXQgY2FuIHV0aWxpemUgTlNGIGJ5 DQogbXVsdGlwbGUgdmVuZG9yczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IZXJl IGlzIHRoZSBuYXJyb3dlciBzY29wZWQgSTJOU0YgY2hhcnRlci4gWW91ciBjb21tZW50cyBhbmQg c3VnZ2VzdGlvbnMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuIEND4oCZZWQgdG8gRE9UUywgSTJS UywgYW5kIE5ldG1vZCBncm91cHMgZm9yIHdpZGVyIHJldmlldy4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWJvdHRvbTpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAxLjBwdCAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5FbnRlcnByaXNlcywgcmVz aWRlbnRpYWwsIGFuZCBtb2JpbGUgY3VzdG9tZXJzIGFyZSBpbmNyZWFzaW5nbHkgY29uc3VtaW5n IG5ldHdvcmsgZnVuY3Rpb25zLCBlc3BlY2lhbGx5IG5ldHdvcmsgc2VjdXJpdHkgcmVsYXRlZCBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IHJ1bm5pbmcgb24gdGhlaXIgcHJlbWlzZXMuJm5ic3A7IElu IGFkZGl0aW9uLCB0aGUgRXVyb3BlYW4gVGVsZWNvbW11bmljYXRpb25zDQogU3RhbmRhcmRzIElu c3RpdHV0ZSAoRVRTSSkgTmV0d29yayBGdW5jdGlvbiBWaXJ0dWFsaXphdGlvbiAoTkZWKSBpbml0 aWF0aXZlIGNyZWF0ZXMgbmV3IG1hbmFnZW1lbnQgY2hhbGxlbmdlcyBmb3Igc2VjdXJpdHkgcG9s aWNpZXMgdG8gYmUgZW5mb3JjZWQgYnkgZGlzdHJpYnV0ZWQsIHZpcnR1YWwsIG5ldHdvcmsgc2Vj dXJpdHkgZnVuY3Rpb25zICh2TlNGKS4gV2l0aG91dCBzdGFuZGFyZCBpbnRlcmZhY2UgdG8gZXhw cmVzcywgbW9uaXRvciwgYW5kDQogbWFuYWdlIHNlY3VyaXR5IHBvbGljaWVzIHRvIHNlY3VyaXR5 IGZ1bmN0aW9ucyBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcHJlbWlzZXMsIGl0IGJlY29tZXMgdmly dHVhbGx5IGltcG9zc2libGUgZm9yIHNlY3VyaXR5IHNlcnZpY2UgcHJvdmlkZXJzIHRvIGF1dG9t YXRlIHRoZSBzZXJ2aWNlIG9mZmVyaW5nIHV0aWxpemluZyBzZWN1cml0eSBmdW5jdGlvbnMgYnkg bXVsdGlwbGUgdmVuZG9ycy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg dWx0aW1hdGUgZ29hbCBvZiBJMk5TRiBpcyB0byBlbmFibGUgZW50ZXJwcmlzZXMgdG8gdXRpbGl6 ZSBzZWN1cml0eSBmdW5jdGlvbnMgbm90IGhvc3RlZCBvbiB0aGVpciBvd24gcHJlbWlzZXMgYnV0 IGluc3RlYWQgaG9zdGVkIGluIHNlcnZpY2UgcHJvdmlkZXIgZG9tYWluLCB0byBlc3RhYmxpc2gg aG93IHRvIGNvbW11bmljYXRlIGRlc2lyZWQgc2VjdXJpdHkNCiBwb2xpY2llcyB0byBOU0YgYW5k IGhvdyB0byBnZXQgcGVyZm9ybWFuY2UgZGF0YSBvciByZXBvcnQgb3V0IG9mIE5TRiBvciB2TlNG LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSBhcmUgdHdvIGxheWVycyBv ZiBpbnRlcmZhY2VzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U2VjdXJpdHkgUG9saWNpZXMg ZmFjaW5nIHNlY3VyaXR5IGZ1bmN0aW9ucyAoSTJOU0YgQ2FwYWJpbGl0eSBMYXllcik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNlY3VyaXR5IFBvbGljaWVzIGZhY2luZyBjbGllbnRzIChJMk5T RiBTZXJ2aWNlIExheWVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUgSTJO U0YgQ2FwYWJpbGl0eSBMYXllciBzcGVjaWZpZXMgdGhlIGZ1bmN0aW9uYWwgc2VjdXJpdHkgcG9s aWNpZXMsIHdoaWNoIGFyZSB0cmFuc2xhdGVkIGZyb20gdGhlIGNsaWVudCBzZWN1cml0eSBwb2xp Y2llcywgdG8gc2VjdXJpdHkgZnVuY3Rpb25zLiBJMk5TRiB3aWxsIE5PVCBzdGFuZGFyZGl6ZSBz ZWN1cml0eSBmdW5jdGlvbnMgb3IgZGV2aWNlcy4gSW5zdGVhZCwNCiBJMk5TRiBpcyBvbmx5IHRv IHN0YW5kYXJkaXplIHRoZSBwb2xpY3kgcHJvdmlzaW9uaW5nIHRvIHRoZSBzZWN1cml0eSBmdW5j dGlvbnMgKG5vdCBkZXZpY2VzKSwgaW4gdGhlIGZvcm0gb2Yg4oCcU3ViamVjdCDigJMgT2JqZWN0 IOKAkyBGdW5jdGlvbiDigJMgQWN0aW9u4oCdIHBhcmFkaWdtLiZuYnNwOw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPlRoZSBJMk5TRiBTZXJ2aWNlIExheWVyIGlzIGZvciBjbGll bnRzIHRvIGV4cHJlc3MgYW5kIG1vbml0b3Igc2VjdXJpdHkgcG9saWNpZXMgZm9yIHRoZWlyIHNw ZWNpZmljIGZsb3dzLCB3aGljaCBpcyB1c3VhbGx5IGJhc2VkIG9uIGN1c3RvbWVyc+KAmSBsb2dp Y2FsIG5ldHdvcmtzLCBhZGRyZXNzZXMgYW5kIGNvbnRleHQuIEkyTlNGIFNlcnZpY2UgTGF5ZXIg Y2FuIGFsc28NCiBiZSBzZWN1cml0eSBleHBlY3RhdGlvbiBvciBsb29zZSBzZWN1cml0eSByZXF1 aXJlbWVudCwgZXNwZWNpYWxseSBmb3IgY3VzdG9tZXJzIHdobyBkb27igJl0IGhhdmUgdGhlIHNl Y3VyaXR5IGV4cGVydGlzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGNv bmNyZXRlIHdvcmsgYXQgdGhlIEwyTlNGIENhcGFiaWxpdHkgTGF5ZXIgaW5jbHVkZXM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoZSBpbmZvcm1hdGlvbmFsICZhbXA7IGRhdGEgbW9kZWxzIGZv ciBlYWNoIGNhdGVnb3J5IHRvIGJlIHJlcHJlc2VudGVkIHRvIHZpcnR1YWwgb3IgcGh5c2ljYWwg bmV0d29yayBzZWN1cml0eSBmdW5jdGlvbnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGUg Y2FwYWJpbGl0eSByZWdpc3RyeSAoSUFOQSkgb2YgcG9saWN5IHByb3Zpc2lvbmluZyBjYXBhYmls aXR5IHRvIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb24sIGFuZA0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoy Mi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaGUgcHJvcGVyIHNlY3VyZSBjb21tdW5pY2F0aW9uIGNoYW5uZWxzIHRvIGNh cnJ5IHRoZSBzZWN1cml0eSBwb2xpY2llcyBiZXR3ZWVuIENvbnRyb2xsZXIgYW5kIE5TRnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPlRoZSBjYXBhYmlsaXR5IHJlZ2lzdHJ5IGlzIHRvIG1ha2UgaXQgZmVhc2li bGUgdG8gY2F0ZWdvcml6ZSBuZXR3b3JrIHNlY3VyaXR5IGZ1bmN0aW9ucyBwcm92aWRlZCBieSBk aWZmZXJlbnQgdmVuZG9ycyBiYXNlZCBvbiBzZWN1cml0eSBwb2xpY3kgcHJvdmlzaW9uaW5nIGNh cGFiaWxpdHkgd2l0aG91dCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBzZWN1cml0eSBmdW5jdGlv bnMNCiB0aGVtc2VsdmVzLiAmbmJzcDtTdGFuZGFyZCBwcm92aXNpb25pbmcgY2FwYWJpbGl0eSBp bnRlcmZhY2UgaXMgYW4gZXNzZW50aWFsIGJ1aWxkaW5nIGJsb2NrIGZvciBTZWN1cml0eSBTZXJ2 aWNlIFByb3ZpZGVyIHRvIGF1dG9tYXRlIHRoZWlyIFNlY3VyaXR5IENvbnRyb2xsZXJzIHRoYXQg Y2FuIHV0aWxpemUgTlNGIGJ5IG11bHRpcGxlIHZlbmRvcnMuIFRoaXMgbGF5ZXIgd2lsbCBsZXZl cmFnZSB0aGUgZXhpc3RpbmcgcHJvdG9jb2xzIGFuZCBkYXRhIG1vZGVscw0KIGRlZmluZWQgYnkg STJSUywgTmV0Y29uZiwgYW5kIE5FVE1PRC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Rm9yIHRoZSBJMk5TRiBTZXJ2aWNlIExheWVyLCBpdCBpcyBvdXQgb2YgdGhlIHNjb3BlIGZv ciBJMk5TRiAoYXQgbGVhc3QgZm9yIG5vdykgdG8gc3RhbmRhcmRpemUgdGhlIGludGVyZmFjZSBm YWNpbmcgY2xpZW50cy4gSG93ZXZlciwgSTJOU0YgY2FuIGhhdmUgaW5mb3JtYXRpb25hbCBkcmFm dHMgc2hvd2luZyBzYW1wbGUgQVBJcyBvci9hbmQgUkVTVGZ1bCBpbnRlcmZhY2VzDQogdG8gY2xp ZW50cyBhbmQgZGVtb25zdHJhdGluZyB0aGUgZmVhc2liaWxpdHkgb2YgdGhlbSBiZWluZyB0cmFu c2xhdGVkIHRvIHRoZSBDYXBhYmlsaXR5IExheWVyIHBvbGljaWVzLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlNpbmNlIGRpZmZlcmVudCBzZWN1cml0eSB2ZW5kb3JzIHN1cHBv cnQgZGlmZmVyZW50IGZlYXR1cmVzICZhbXA7IGZ1bmN0aW9ucyBvbiB0aGVpciBkZXZpY2VzLCBJ Mk5TRiB3aWxsIGZvY3VzIG9uIGZsb3cgYmFzZWQgc2VjdXJpdHkgZnVuY3Rpb25zIHRoYXQgcHJv dmlkZSB0cmVhdG1lbnQgdG8gcGFja2V0cy9mbG93cywgc3VjaCBhcyBJUFMvSURTLCBXZWIgZmls dGVyLA0KIGFuZCBmbG93IGZpbHRlci4gKFRoZXkgYXJlIGRpZmZlcmVudCBmcm9tIG90aGVyIHNl Y3VyaXR5IGZ1bmN0aW9ucyBzdWNoIGFzIEF1dGhlbnRpY2F0aW9uLCBBdXRob3JpemF0aW9uLCBv ciBFbmNyeXB0aW9uKS4gRXhlbXBsYXIgc2VydmljZXMgYXNzb2NpYXRlZCB3aXRoIEZsb3cgQmFz ZWQgU2VjdXJpdHkgZnVuY3Rpb25zIGluY2x1ZGUgZGVlcCBwYWNrZXQgaW5zcGVjdGlvbiwgcGFj a2V0L2Zsb3cvc3RyZWFtIGZpbHRlcmluZyBvciBwYXR0ZXJuDQogbWF0Y2hpbmcgYW5kIHJlbWVk aWF0aW9uLCBldGMuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaW1pbGFyIHRv IEkyUlMgZm9jdXNpbmcgb24gdGhlIGludGVyZmFjZSB0byBSSUIvRklCIGV2ZW4gdGhvdWdoIG1v c3Qgcm91dGVycyBwcm92aWRlIGZhciBtb3JlIGZ1bmN0aW9ucyB0aGFuIFJJQi9GSUIsIHRoZSBJ Mk5TRiBmb2N1c2VkIGZ1bmN0aW9ucyBjYW4gYmUgYSBwb3J0aW9uIG9mIGZlYXR1cmVzIHN1cHBv cnRlZCBieSB2ZW5kb3Jz4oCZIHNwZWNpZmljIGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkl0IGlzIGEgbm9uLWdvYWwgdG8gY3JlYXRlIG5ldyBwcm90b2NvbHMgb3Ig ZGF0YSBtb2RlbGluZyBsYW5ndWFnZXMgZm9yIEkyTlNGIGludGVyZmFjZXMuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkkyTlNGIFdHIERlbGl2ZXJhYmxlcyBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoyMi41cHQ7dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDtVc2UgQ2FzZSBkb2N1bWVudC4gPG86cD4NCjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjIyLjVwdDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkZyYW1ld29yayBEb2N1bWVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlJlcXVpcmVtZW50IGZvciBleHRlbnNpb25zIChpZiB0aGVyZSBhcmUgYW55KSB0byBl eGlzdGluZyBwcm90b2NvbHMgdXNlZCBieSB0aGUgV0cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVwdDt0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwO0dhcCBhbmFseXNpcyBvZiBleGlzdGluZyBwcm90b2NvbHMgYW5kIG1vZGVsaW5n IGxhbmd1YWdlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSBzaW5nbGUsIHVuaWZpZWQsIElu Zm9ybWF0aW9uIE1vZGVsIGZvciBleHByZXNzaW5nIHBvbGljaWVzIHRvIHRoZSBGbG93IEJhc2Vk IFNlY3VyaXR5IEZ1bmN0aW9ucyBkZXNjcmliZWQgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMi41cHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5Db3JyZXNwb25kaW5nIERhdGEgTW9kZWxzIChlLmcuIFlBTkcgbW9kZWxzKSBkZXJpdmVk IGZyb20gdGhlIGFib3ZlIEluZm9ybWF0aW9uIE1vZGVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjIuNXB0O3Rl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+SUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uIGZvciBmbG93IGJhc2VkIHNlY3VyaXR5IGZ1 bmN0aW9uIHBvbGljeSBwcm92aXNpb25pbmcgY2FwYWJpbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIyLjVw dDt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyhPcHRpb25hbGx5KSBBcHBsaWNhYmlsaXR5IFN0YXRlbWVudHMgb24gaG93 IHRvIHVzZSBJMlJTLCBOZXRjb25mLCBhbmQgTkVUTU9EIHRvIGNhcnJ5IHRoZSBjb250ZW50IG9m IHRoZSBzcGVjaWZpZWQgaW5mb3JtYXRpb24vZGF0YSBtb2RlbHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5bPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIFdH IG1heSBkZWNpZGUgdGhhdCB0aGUgVXNlIGNhc2VzLCBGcmFtZXdvcmssIGFuZCBSZXF1aXJlbWVu dCBhcmUgSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgb3Igc2ltcGx5IHJlZmVyZW5jZSBkb2N1bWVu dHMgZHVyaW5nIHRoZSBsaWZldGltZQ0KIG9mIHRoZSBXRy4gVGhlIGZyYW1ld29yaywgdGhhdCBk ZXNjcmliZXMgdGhlIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBhbmQgdGhlIEkyTlNGIHdvcmsgaXRl bXMsIGlzIHRvIG1ha2UgSTJOU0Ygd29yayBtb3JlIG9yZ2FuaXplZC5dPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlN1Z2dlc3RlZCBNaWxlc3RvbmVzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgLSBVc2UgQ2FzZSBEb2N1bWVudDombmJzcDsgQ2hhcnRlciB0aW1lICYjNDM7IDEgbW9udGgg dG8gV0cgRG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEZyYW1ld29yazogQ2hhcnRlciB0 aW1lICYjNDM7IDQgbW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBS ZXF1aXJlbWVudHMgZm9yIGV4dGVuc2lvbnMgdG8gcHJvdG9jb2xzOiZuYnNwOyBDaGFydGVyIHRp bWUgJiM0MzsgNiBtb250aHMgdG8gV0cgZG9jdW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIElu Zm8gbW9kZWw6IENoYXJ0ZXIgdGltZSAmIzQzOyA3IG1vbnRocyB0byBXRyBEb2N1bWVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7IC0gSUFOQSByZWdpc3RyeSBjb25zaWRlcmF0aW9uICYjNDM7IDEwIG1v bnRocyB0byBXRyBEb2N1bWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7IC0gQWxsIEVhcmx5IERyYWZ0 cyB0byBJRVNHOiAxMCBtb250aHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+W2Rl Y2lzaW9uIHBvaW50IOKAkyAmIzQzOzEwIG1vbnRoc10mbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOy0gRGF0YSBNb2RlbHM6IENoYXJ0ZXIgJiM0MzsgOSBNb250aHMgdG8gV0cgRG9j dW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyAtIEFwcGxpY2FiaWxpdHkgU3RhdGVtZW50czogMTAg bW9udGhzIHRvIFdHIERvY3VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgLSBEYXRhIE1vZGVscyBh bmQgQXBwbGljYWJpbGl0eSBTdGF0ZW1lbnRzIHRvIElFU0cmbmJzcDsgLSAxNiBtb250aHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1ib3R0b206c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMS4wcHQgMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+VGhlIFdHIHdpbGwgd29yayBjbG9zZWx5IHdpdGggSTJSUywgTmV0Y29uZiBhbmQgTmV0 bW9kIFdHcy4gVGhlIFdHIHdpbGwgY29tbXVuaWNhdGUgd2l0aCBleHRlcm5hbCBTRE9zIGxpa2Ug RVRTSSBORlYgYW5kIHdpbGwgZW5jb3VyYWdlIG9wZW4gc291cmNlIGNvZGUgZGV2ZWxvcG1lbnQg cmVsYXRlZCB0byB0aGUgV0cgc2NvcGUgaW4gb3JnYW5pemF0aW9ucyBsaWtlDQogT05GLCBPcGVu U3RhY2ssIE9ETCwgYW5kIE9wZW5ORlYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DaGVlcnMsIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGluZGEg RHVuYmFyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXyBJMm5zZiBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpJMm5zZkBpZXRmLm9yZyI+ STJuc2ZAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJuc2YiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Mm5zZjwvYT4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F657C1443Cdfweml701chm_-- From nobody Wed May 13 09:31:30 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4071B2DFB; Wed, 13 May 2015 09:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQzgfpmJKayQ; Wed, 13 May 2015 09:31:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C211B2CEB; Wed, 13 May 2015 09:31:15 -0700 (PDT) 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 BSM49385; Wed, 13 May 2015 16:31:14 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 May 2015 17:31:14 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 13 May 2015 09:31:06 -0700 From: Linda Dunbar To: "Romascanu, Dan (Dan)" , "Zarny, Myo" , "'i2nsf@ietf.org'" , "'Kathleen Moriarty'" Thread-Topic: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 Thread-Index: AQHQinCAWnYgWx+c3k2SduRLi+ubTp127a2AgAMwn9A= Date: Wed, 13 May 2015 16:31:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C14453@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA27888@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.128] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'i2rs@ietf.org'" , "'dots@ietf.org'" , "'netmod@ietf.org'" Subject: Re: [i2rs] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 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, 13 May 2015 16:31:25 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Dan, Myo, Diego, Xiao Jun, Frank and Zing's suggestions. p.s. I had to check dictionary for "bespoke" too. Synonyms are "custom-made", "made to order", and "made to meas= ure", which is a very accurat= e description. I will update the charter per your suggestions, Linda From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Da= n) Sent: Monday, May 11, 2015 3:44 AM To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 I am fine with the editing proposed by Myo as it makes the scope more clear= . Maybe the only thing I would suggest is to use 'non-standard' rather than= 'bespoke' which may puzzle the non-native English speakers. I had to go to= the dictionary to see what it exactly means (but it may be only me!). Mentioning another SDO in the charter is actually fine as long as it points= to the fact that we are aiming to work in cooperation with other SDOs and = avoid duplicating work. In this case we say at the end that we plan to coop= erate with ETSI, so keeping explicit mentioning out of the introduction is = fine. Thanks and Regards, Dan From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo Sent: Saturday, May 09, 2015 6:55 PM To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty' Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org' Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new charter for= IETF 93 Hi Linda, Thanks very much for putting this together. I agree that the scope needs to= be tightened if it is to be meaningful. I'm fine with the suggested delive= rables, milestones, etc. BUT we should tweak the first two paragraphs relat= ed to the goal of the WG. I2NSF shouldn't take a position on where the secu= rity functions are hosted or if the caller and the security service functio= n belong to the same or different domains. Also, not sure if we should brin= g in another organization's name (ETSI) into an IETF charter. I've taken a stab at rewording the first few paragraphs... Network security functions (NSFs) are increasingly provided and consumed in= increasingly diverse environments. Users of NSFs could consume network sec= urity services hosted by one or more providers, which may be their own ente= rprise, service providers, or a combination of both. Likewise, service prov= iders may offer their customers network security services that consist of m= ultiple security products from different vendors. Yet because no widely acc= epted industry standard security interfaces exist today, management of NSFs= (device and policy provisioning, monitoring, etc.) tends to be bespoke, es= sentially as offered by product vendors. As a result, automation of such se= rvices, if it exists at all, is also bespoke. The primary goal of I2NSF is to define a set of interfaces and data models = for policy provisioning and management aspects of NSFs. Other aspects of NS= Fs such as device or network provisioning are out of scope. The scope of I2NSF can be further divided into two layers: * I2NSF Capabilities Layer * I2NSF Services Layer ... I've made a few comments inline below as well. I'm not familiar with how detailed a charter needs to be, so I'll leave it = others to comment on whether the level of detail here is sufficient, too mu= ch or too light. Myo From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: 7 May 2015 11:53 AM To: i2nsf@ietf.org; Kathleen Moriarty Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter for IET= F 93 Thanks to I2NSF contributors for the good progresses made since IETF92 sid= e meetings. Among the two I2NSF interfaces, i.e. the client facing Service= Interface and the NSF facing Capability Interface, the work to be done at = the Capability Interface becomes very clear and concrete. But the Service I= nterface is still a little vague. The feedback from last IETF side meetings was "the scope is too big for one= IETF WG". Therefore, we are leaning towards narrowing the I2NSF scope to t= he Capability Interface. The thinking logic is: Once the Capability Interfa= ce is completed, we will see more clearly the work for Service interface. E= ven if Capability layer alone is standardized, it is a giant leap forward i= n building blocks for Service Provider to automate their Security Controlle= r that can utilize NSF by multiple vendors Here is the narrower scoped I2NSF charter. Your comments and suggestions ar= e greatly appreciated. CC'ed to DOTS, I2RS, and Netmod groups for wider rev= iew. Enterprises, residential, and mobile customers are increasingly consuming n= etwork functions, especially network security related functions that are no= t running on their premises. In addition, the European Telecommunications = Standards Institute (ETSI) Network Function Virtualization (NFV) initiative= creates new management challenges for security policies to be enforced by = distributed, virtual, network security functions (vNSF). Without standard i= nterface to express, monitor, and manage security policies to security func= tions deployed at different premises, it becomes virtually impossible for s= ecurity service providers to automate the service offering utilizing securi= ty functions by multiple vendors. The ultimate goal of I2NSF is to enable enterprises to utilize security fun= ctions not hosted on their own premises but instead hosted in service provi= der domain, to establish how to communicate desired security policies to NS= F and how to get performance data or report out of NSF or vNSF. There are two layers of interfaces: - Security Policies facing security functions (I2NSF Capability La= yer) - Security Policies facing clients (I2NSF Service Layer) The I2NSF Capability Layer specifies the functional security policies, whic= h are translated from the client security policies, to security functions. = I2NSF will NOT standardize security functions or devices. Instead, I2NSF is= only to standardize the policy provisioning to the security functions (not= devices), in the form of "Subject - Object - Function - Action" paradigm. MZ: Not sure if we need to explicitly specify a potential solution("Subjec= t-Object-Function-Action") in the charter. The I2NSF Service Layer is for clients to express and monitor security poli= cies for their specific flows, which is usually based on customers' logical= networks, addresses and context. I2NSF Service Layer can also be security = expectation or loose security requirement, especially for customers who don= 't have the security expertise. MZ: I suggest "I2NSF Services Layer provides a set of interfaces for clien= ts to express and monitor security policies. The policies may be intent-bas= ed." The concrete work at the L2NSF Capability Layer includes - The informational & data models for each category to be represen= ted to virtual or physical network security functions, - The capability registry (IANA) of policy provisioning capability= to flow based security function, and - The proper secure communication channels to carry the security p= olicies between Controller and NSFs. The capability registry is to make it feasible to categorize network securi= ty functions provided by different vendors based on security policy provisi= oning capability without any need to standardize security functions themsel= ves. Standard provisioning capability interface is an essential building b= lock for Security Service Provider to automate their Security Controllers t= hat can utilize NSF by multiple vendors. This layer will leverage the exist= ing protocols and data models defined by I2RS, Netconf, and NETMOD. For the I2NSF Service Layer, it is out of the scope for I2NSF (at least for= now) to standardize the interface facing clients. However, I2NSF can have = informational drafts showing sample APIs or/and RESTful interfaces to clien= ts and demonstrating the feasibility of them being translated to the Capabi= lity Layer policies. Since different security vendors support different features & functions on = their devices, I2NSF will focus on flow based security functions that provi= de treatment to packets/flows, such as IPS/IDS, Web filter, and flow filter= . (They are different from other security functions such as Authentication,= Authorization, or Encryption). Exemplar services associated with Flow Base= d Security functions include deep packet inspection, packet/flow/stream fil= tering or pattern matching and remediation, etc. Similar to I2RS focusing on the interface to RIB/FIB even though most route= rs provide far more functions than RIB/FIB, the I2NSF focused functions can= be a portion of features supported by vendors' specific devices. It is a non-goal to create new protocols or data modeling languages for I2N= SF interfaces. I2NSF WG Deliverables include: - Use Case document. - Framework Document. - Requirement for extensions (if there are any) to existing protoc= ols used by the WG. - Gap analysis of existing protocols and modeling languages - A single, unified, Information Model for expressing policies to = the Flow Based Security Functions described above. - Corresponding Data Models (e.g. YANG models) derived from the ab= ove Information Model. - IANA registry consideration for flow based security function pol= icy provisioning capability. - (Optionally) Applicability Statements on how to use I2RS, Netco= nf, and NETMOD to carry the content of the specified information/data model= s. [The WG may decide that the Use cases, Framework, and Requirement are Infor= mational documents or simply reference documents during the lifetime of the= WG. The framework, that describes the functional components and the I2NSF = work items, is to make I2NSF work more organized.] Suggested Milestones - Use Case Document: Charter time + 1 month to WG Document - Framework: Charter time + 4 months to WG Document - Requirements for extensions to protocols: Charter time + 6 months to W= G document - Info model: Charter time + 7 months to WG Document - IANA registry consideration + 10 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 WG will com= municate with external SDOs like ETSI NFV and will encourage open source co= de development related to the WG scope in organizations like ONF, OpenStack= , ODL, and OpenNFV. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Dan, Myo, Diego= , Xiao Jun, Frank and Zing’s suggestions.

 

p.s. I had to check di= ctionary for “bespoke” too. Synonyms are "custom-made", "made to or= der", and "made to measure", which is a very accurate description.

 

I will update the char= ter per your suggestions,

 

Linda

 

From: I2nsf [m= ailto:i2nsf-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Monday, May 11, 2015 3:44 AM
To: Zarny, Myo; Linda Dunbar; 'i2nsf@ietf.org'; 'Kathleen Moriarty'<= br> Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

I am fine with the edi= ting proposed by Myo as it makes the scope more clear. Maybe the only thing= I would suggest is to use ‘non-standard’ rather than ‘be= spoke’ which may puzzle the non-native English speakers. I had to go to the dictionary to see what it exactly means (but it may be = only me!).

 

Mentioning another SDO= in the charter is actually fine as long as it points to the fact that we a= re aiming to work in cooperation with other SDOs and avoid duplicating work= . In this case we say at the end that we plan to cooperate with ETSI, so keeping explicit mentioning out of the = introduction is fine.

 

Thanks and Regards,

 

Dan<= /p>

 

 

From: I2nsf [<= a href=3D"mailto:i2nsf-bounces@ietf.org">mailto:i2nsf-bounces@ietf.org] On Behalf Of Zarny, Myo
Sent: Saturday, May 09, 2015 6:55 PM
To: 'Linda Dunbar'; 'i2nsf@ietf.org'; 'Kathleen Moriarty'
Cc: 'i2rs@ietf.org'; 'dots@ietf.org'; 'netmod@ietf.org'
Subject: Re: [I2nsf] Further Narrowing the I2NSF scope: the new char= ter for IETF 93

 

Hi Linda,

 

Thanks very much for p= utting this together. I agree that the scope needs to be tightened if it is= to be meaningful. I’m fine with the suggested deliverables, mileston= es, etc. BUT we should tweak the first two paragraphs related to the goal of the WG. I2NSF shouldn’t take a pos= ition on where the security functions are hosted or if the caller and the s= ecurity service function belong to the same or different domains. Also, not= sure if we should bring in another organization’s name (ETSI) into an IETF charter.

 

I’ve taken a sta= b at rewording the first few paragraphs…

 

Network security functions (NSFs= ) are increasingly provided and consumed in increasingly diverse environmen= ts. Users of NSFs could consume network security services hosted by one or more providers, which may be their own = enterprise, service providers, or a combination of both. Likewise, service = providers may offer their customers network security services that consist = of multiple security products from different vendors. Yet because no widely accepted industry standard securi= ty interfaces exist today, management of NSFs (device and policy provisioni= ng, monitoring, etc.) tends to be bespoke, essentially as offered by produc= t vendors. As a result, automation of such services, if it exists at all, is also bespoke.  <= /span>

 

The primary goal of I2NSF is to = define a set of interfaces and data models for policy provisioning and mana= gement aspects of NSFs. Other aspects of NSFs such as device or network provisioning are out of scope.

 

The scope of I2NSF can be furthe= r divided into two layers:

·       I2NSF Capabilities Layer

·       I2NSF Services Layer

…

 

I’ve made a few = comments inline below as well.

 

I’m not familiar= with how detailed a charter needs to be, so I’ll leave it others to = comment on whether the level of detail here is sufficient, too much or too = light.

 

Myo<= /p>

 

 

From: I2nsf [mailto:= i2nsf-bounces@ietf.org] On Behalf Of Linda Dunbar
Sent: 7 May 2015 11:53 AM
To: i2nsf@ietf.org; Kathleen M= oriarty
Cc: i2rs@ietf.org; dots@ietf.org; netmod@ietf.org Subject: [I2nsf] Further Narrowing the I2NSF scope: the new charter = for IETF 93

 

Thanks to I2NSF contribut= ors for the good progresses made since  IETF92 side meetings. Among th= e two I2NSF interfaces,  i.e. the client facing Service Interface and = the NSF facing Capability Interface, the work to be done at the Capability Interface becomes very clear and concrete. Bu= t the Service Interface is still a little vague.

 

The feedback from last IE= TF side meetings was "the scope is too big for one IETF WG". Ther= efore, we are leaning towards narrowing the I2NSF scope to the Capability I= nterface. The thinking logic is: Once the Capability Interface is completed, we will see more clearly the work for Service inte= rface. Even if Capability layer alone is standardized, it is a giant leap f= orward in building blocks for Service Provider to automate their Security C= ontroller that can utilize NSF by multiple vendors

 

Here is the narrower scop= ed I2NSF charter. Your comments and suggestions are greatly appreciated. CC= ’ed to DOTS, I2RS, and Netmod groups for wider review.

 

 

 

Enterprises, residential,= and mobile customers are increasingly consuming network functions, especia= lly network security related functions that are not running on their premis= es.  In addition, the European Telecommunications Standards Institute (ETSI) Network Function Virtualization (NFV) initiativ= e creates new management challenges for security policies to be enforced by= distributed, virtual, network security functions (vNSF). Without standard = interface to express, monitor, and manage security policies to security functions deployed at different premi= ses, it becomes virtually impossible for security service providers to auto= mate the service offering utilizing security functions by multiple vendors.

 

The ultimate goal of I2NS= F is to enable enterprises to utilize security functions not hosted on thei= r own premises but instead hosted in service provider domain, to establish = how to communicate desired security policies to NSF and how to get performance data or report out of NSF or vN= SF.

 

There are two layers of i= nterfaces:

-       = ;   Security Policies facing security functions (I2NSF = Capability Layer)

-       = ;   Security Policies facing clients (I2NSF Service Lay= er)

 

The I2NSF Capability Layer specifies the functional security policies, w= hich are translated from the client security policies, to security function= s. I2NSF will NOT standardize security functions or devices. Instead, I2NSF is only to standardize the policy pro= visioning to the security functions (not devices), in the form of “Su= bject – Object – Function – Action” paradigm. 

MZ:  Not sure if we need to explicitly specify a potential soluti= on(“Subject-Object-Function-Action”) in the charter.=

 

The I2NSF Service Layer i= s for clients to express and monitor security policies for their specific f= lows, which is usually based on customers’ logical networks, addresse= s and context. I2NSF Service Layer can also be security expectation or loose security requirement, especially for cust= omers who don’t have the security expertise.

MZ:  I suggest “I2NSF Services Layer provides a set of inte= rfaces for clients to express and monitor security policies. The policies m= ay be intent-based.”

 

The concrete work at the = L2NSF Capability Layer includes

-  &= nbsp;       The informational & data models for each= category to be represented to virtual or physical network security functio= ns,

-  &= nbsp;       The capability registry (IANA) of policy pro= visioning capability to flow based security function, and

-  &= nbsp;       The proper secure communication channels to = carry the security policies between Controller and NSFs.

The capability registry i= s to make it feasible to categorize network security functions provided by = different vendors based on security policy provisioning capability without = any need to standardize security functions themselves.  Standard provisioning capability interface is an essenti= al building block for Security Service Provider to automate their Security = Controllers that can utilize NSF by multiple vendors. This layer will lever= age the existing protocols and data models defined by I2RS, Netconf, and NETMOD.

 

For the I2NSF Service Lay= er, it is out of the scope for I2NSF (at least for now) to standardize the = interface facing clients. However, I2NSF can have informational drafts show= ing sample APIs or/and RESTful interfaces to clients and demonstrating the feasibility of them being translated to t= he Capability Layer policies.

 

Since different security = vendors support different features & functions on their devices, I2NSF = will focus on flow based security functions that provide treatment to packe= ts/flows, such as IPS/IDS, Web filter, and flow filter. (They are different from other security functions such as Aut= hentication, Authorization, or Encryption). Exemplar services associated wi= th Flow Based Security functions include deep packet inspection, packet/flo= w/stream filtering or pattern matching and remediation, etc.

 

Similar to I2RS focusing = on the interface to RIB/FIB even though most routers provide far more funct= ions than RIB/FIB, the I2NSF focused functions can be a portion of features= supported by vendors’ specific devices.

 

It is a non-goal to creat= e new protocols or data modeling languages for I2NSF interfaces.

I2NSF WG Deliverables inc= lude:

 

-       = ;    Use Case document.

-       = ;   Framework Document.

-       = ;   Requirement for extensions (if there are any) to ex= isting protocols used by the WG.

-       = ;    Gap analysis of existing protocols and modeli= ng languages

-       = ;   A single, unified, Information Model for expressing= policies to the Flow Based Security Functions described above.<= /p>

-       = ;   Corresponding Data Models (e.g. YANG models) derive= d from the above Information Model.

-       = ;   IANA registry consideration for flow based security= function policy provisioning capability.

-       = ;    (Optionally) Applicability Statements on how = to use I2RS, Netconf, and NETMOD to carry the content of the specified info= rmation/data models.

 

[The WG may decide that the Use cases, Framework, and = Requirement are Informational documents or simply reference documents during the lifetime of the WG. The framework, that descri= bes the functional components and the I2NSF work items, is to make I2NSF wo= rk more organized.]

 

Suggested Milestones=

  - Use Case Documen= t:  Charter time + 1 month to WG Document

  - Framework: Chart= er time + 4 months to WG Document

  - Requirements for= extensions to protocols:  Charter time + 6 months to WG document<= o:p>

  - Info model: Char= ter time + 7 months to WG Document

  - IANA registry co= nsideration + 10 months to WG Document

  - All Early Drafts= to IESG: 10 months

 

[decision point – &= #43;10 months] 

  - Data Models= : Charter + 9 Months to WG Document

  - Applicability St= atements: 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 WG will communicate with external SD= Os like ETSI NFV and will encourage open source code development related to= the WG scope in organizations like ONF, OpenStack, ODL, and OpenNFV.

 

 

Cheers,

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657C14453dfweml701chm_-- From nobody Wed May 13 14:37:46 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCF11AD0C9; Wed, 13 May 2015 14:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pSg3MP4uKk3; Wed, 13 May 2015 14:37:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64FBA1AD0CA; Wed, 13 May 2015 14:37:39 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D565519; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id WZY8lSeXizdW; Wed, 13 May 2015 23:37:29 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 13 May 2015 23:37:37 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49B0F2002B; Wed, 13 May 2015 23:37:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IhtJzKnap8i8; Wed, 13 May 2015 23:37:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1B2C920013; Wed, 13 May 2015 23:37:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 88009333336F; Wed, 13 May 2015 23:37:33 +0200 (CEST) Date: Wed, 13 May 2015 23:37:33 +0200 From: Juergen Schoenwaelder To: John Strassner Message-ID: <20150513213733.GA629@elstar.local> Mail-Followup-To: John Strassner , Linda Dunbar , "i2nsf@ietf.org" , Kathleen Moriarty , "i2rs@ietf.org" , "dots@ietf.org" , "netmod@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F657C11DC6@dfweml701-chm> 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: "i2rs@ietf.org" , "netmod@ietf.org" , "i2nsf@ietf.org" , "dots@ietf.org" , Linda Dunbar , Kathleen Moriarty Subject: Re: [i2rs] [netmod] [I2nsf] Further Narrowing the I2NSF scope: the new charter for IETF 93 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: Wed, 13 May 2015 21:37:44 -0000 Can we please stop this cross-posting thread? /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 Thu May 14 09:36: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 512201A88C8; Thu, 14 May 2015 09:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 CVUM9L1R3FXM; Thu, 14 May 2015 09:36:16 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E1D1A8876; Thu, 14 May 2015 09:36:11 -0700 (PDT) Received: by lagv1 with SMTP id v1so75833736lag.3; Thu, 14 May 2015 09:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=go7N5T/M88qorbFwZNQUzANTZUjFSJ+XeB7m6zQE8sE=; b=ALKwcLcCXggaa/MqzZHrmJOqqo219GTHQpwa+kcWgTi4Rv996ZmeU5m3FlISnecouQ VcY9cySqJcyuBWtQWSBPtC0n3Uo1C9nMqbu0Ag3WM9xIOxfYztruilf9qZ/hxMNWJ1kp 3pADBhLplJgf2pqiKwlUT914kw2iXqTj9kw7/rSLh2kp+vU4rn44xrlheMXOcQGgjfbL KMbFAEnbtFsWd0lyDJvM8dLGDnKc5+YNX3daGubP22zAHogRmuqrme1mPp4J5WAnilUM miTde5TLHfz5/nsyk1X4WWmNQTvdZFQThUn8wbc+jM1tcqnaOZRMaQ0HqrsB5KmmHgpl sFdQ== MIME-Version: 1.0 X-Received: by 10.152.88.46 with SMTP id bd14mr3786827lab.71.1431621370114; Thu, 14 May 2015 09:36:10 -0700 (PDT) Received: by 10.114.74.225 with HTTP; Thu, 14 May 2015 09:36:10 -0700 (PDT) Date: Thu, 14 May 2015 11:36:10 -0500 Message-ID: From: Behcet Sarikaya To: "Acee Lindem (acee)" , "i2rs@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "lhotka@nic.cz" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] draft-ietf-netmod-routing-cfg-18 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.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, 14 May 2015 16:36:17 -0000 Thanks, let me take it to I2RS list then. On Thu, May 14, 2015 at 11:29 AM, Acee Lindem (acee) wrote: > > > On 5/14/15, 12:16 PM, "Behcet Sarikaya" wrote: > >>Hi all, >> >>I am new to this list, I just sent my subscription request, if it >>doesn't go thru, I hope that chairs can subscribe me. >> >> I have been reading this draft and have a few comments: >> >>The draft defines one RPC operation called fib-route to query a >>routing instance for the active route in the FIB. As such it seems to >>be a read operation. >>What about write or modify type of operations? Are they not needed? > > Currently, this use-case is under the purview of the I2RS WG. > > Acee > From nobody Tue May 19 14:33: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 29E7A1B3377; Tue, 19 May 2015 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_084HtnYV8c; Tue, 19 May 2015 14:33:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D69431B3366; Tue, 19 May 2015 14:33:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150519213340.6361.41309.idtracker@ietfa.amsl.com> Date: Tue, 19 May 2015 14:33:40 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-usecase-reqs-summary-01.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:33:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Summary of I2RS Use Case Requirements Authors : Susan Hares Mach Chen Filename : draft-ietf-i2rs-usecase-reqs-summary-01.txt Pages : 34 Date : 2015-05-19 Abstract: The I2RS Working Group (WG) has described a set of use cases that the I2RS systems could fulfil. This document summarizes these use cases. It is designed to provide requirements that will aid the design of the I2RS architecture, Information Models, Data Models, Security, and protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-usecase-reqs-summary/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-usecase-reqs-summary-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-usecase-reqs-summary-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 12:40: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 4A0631B2D21 for ; Tue, 26 May 2015 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSiG8RtkTaBy for ; Tue, 26 May 2015 12:40:06 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC781A8773 for ; Tue, 26 May 2015 12:40:06 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3BE601E30B; Tue, 26 May 2015 15:40:42 -0400 (EDT) Date: Tue, 26 May 2015 15:40:42 -0400 From: Jeffrey Haas To: i2rs@ietf.org Message-ID: <20150526194041.GA20676@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:40:07 -0000 Working Group, The following document is a straw-man document attempting to document changes necessary to implement I2RS's ephemeral state needs. This document has already gotten some discussion off-list with several of the usual contributors to the netmod and netconf Working Groups as an attempt to gain some early traction in the discussion. While that discussion has been energetic, it hasn't achieved any further consensus from the contents posted herein. I would like to request that further discussion related to this draft take place on the mailing list. This draft will be a topic for tomorrow's virtual interim. My apologies for not posting this more promptly. -- Jeff ----- Forwarded message from internet-drafts@ietf.org ----- Date: Tue, 26 May 2015 12:14:57 -0700 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS Ephemeral State Requirements Author : Jeffrey Haas Filename : draft-haas-i2rs-ephemeral-state-reqs-00.txt Pages : 9 Date : 2015-05-26 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-haas-i2rs-ephemeral-state-reqs-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt ----- End forwarded message ----- From nobody Tue May 26 14:14: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 61B251B3183; Tue, 26 May 2015 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsmzlnFkjpKK; Tue, 26 May 2015 14:14:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CFBF21B317A; Tue, 26 May 2015 14:14:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:13:59 -0400 Message-ID: <00a101d097f8$e2847700$a78d6500$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00A2_01D097D7.5B78F180" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+KHfDvCKoPtTS9efx7CdbCb8fA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [i2rs] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) 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, 26 May 2015 21:14:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A2_01D097D7.5B78F180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A3_01D097D7.5B78F180" ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 =20 There are two topics on the agenda:=20 =20 1) I2RS Protocol requirements with discussion on the following = drafts =20 a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts (WG adoption 5/26 to 6/9/2015) c. = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( = WG LC 5/26 to 6/9/2015)=20 d. http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = WG LC 5/26 to 6/9/2015)=20 =20 These set of requirements are intent as a group of requirements to pass = to the netmod/netconf WG on 6/10.=20 The 6/10 I2RS interim will review the discussions on the email list, and = finalize the set of documents passed to netconf/netmod for review.=20 =20 2) Announcement of I2RS Design team for FB-RIB documents=20 a. Review of draft = = draft-kini-i2rs-fb-fib-info-model-00=20 b. Review of Yang models proposed=20 i. = Generic FB-RIB-info-model=20 ii. = Rules specific to individual RIB-forwarding=20 =20 This meeting is to provide verbal discussions as a prelude to the I2RS = mail list discussions on the protocol, and to inform the WG regarding = the FB-RIB models in order to aid the WG on the protocol discussion.=20 =20 We apologize for the reminder of the meeting time, and the web-ex = meeting.=20 =20 Sue Hares and Jeff Haas=20 =20 From: I2RS Working Group [mailto:messenger@webex.com]=20 Sent: Tuesday, May 26, 2015 4:34 PM To: i2rs-chairs@tools.ietf.org Subject: WebEx meeting scheduled: I2RS interim 5/27 =20 Hi, I2RS Working Group,=20 You are the host for this WebEx meeting.=20 =20 Host key: 487042 (Use this to reclaim host privileges.)=20 =20 =20 =20 I2RS interim 5/27=20 Wednesday, May 27, 2015=20 9:30 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs=20 =20 =20 =20 = Join WebEx meeting=20 =20 Meeting number:=20 646 391 150=20 Meeting password: jeff.is.wise =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: 646 391 150 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. You should inform all meeting attendees = prior to recording if you intend to record the meeting. =20 ------=_NextPart_001_00A3_01D097D7.5B78F180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready. =

 

There are two topics on the agenda:

 

1)      = I2RS Protocol requirements =C2=A0with discussion on the following = drafts =C2=A0

a.       = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/=C2=A0 (WG adoption 5/26 to 6/9/2015)

b.      = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netcon= f-requirements (WG adoption 5/26 to = 6/9/2015)

c.       = http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/ ( WG LC 5/26 to 6/9/2015)

d.      = ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/=C2=A0 WG = LC 5/26 to 6/9/2015)

 =

These set = of requirements are intent as a group of requirements to pass to the = netmod/netconf WG on 6/10.

The 6/10 = I2RS interim will review the discussions on the email list, and finalize = the set of documents passed to netconf/netmod for review. =

 =

2)      = Announcemen= t of I2RS Design team for FB-RIB documents

a.       = Review of = draft draft-kin= i-i2rs-fb-fib-info-model-00 

b.      = Review of Yang models proposed =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;   i.      = Generic FB-RIB-info-model =

           = ;            =             &= nbsp;           &n= bsp;           &nb= sp; ii.      = Rules specific to individual RIB-forwarding = =

 =

This = meeting is to provide verbal discussions as a prelude to the I2RS mail = list discussions on the protocol, and to inform the WG regarding the = FB-RIB models in order to aid the WG on the protocol discussion. =

 =

We = apologize for the reminder of the meeting time, and the web-ex meeting. =

 

Sue Hares and Jeff Haas

 

From:= = I2RS Working Group [mailto:messenger@webex.com]
Sent: = Tuesday, May 26, 2015 4:34 PM
To: = i2rs-chairs@tools.ietf.org
Subject: WebEx meeting scheduled: = I2RS interim 5/27

 

Hi, I2RS Working Group,

You are the host for this WebEx meeting. =

 

Host key: 487042 (Use this to reclaim host privileges.) =

 

 

 

I2RS interim = 5/27 =

Wednesday, May 27, 2015

9:30 am  |  Eastern Daylight Time (New York, = GMT-04:00)  |  2 hrs =

 

 

 

Join = WebEx meeting =

 

Meeting number:

646 391 150

Meeting password:

jeff.is.wise

 

 

 

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 391 150

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. You should inform all meeting attendees = prior to recording if you intend to record the = meeting.

 

------=_NextPart_001_00A3_01D097D7.5B78F180-- ------=_NextPart_000_00A2_01D097D7.5B78F180 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=3DFALSE:MAILTO:i2rs-chairs@tools.ietf.= org=0A= ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com=0A= DTSTART;TZID=3D"Eastern Time":20150527T093000=0A= DTEND;TZID=3D"Eastern Time":20150527T113000=0A= LOCATION:https://ietf.webex.com/ietf=0A= TRANSP:OPAQUE=0A= SEQUENCE:1432672422=0A= UID:ff572edf-29d8-499c-ae8b-114047c18e30=0A= DTSTAMP:20150527T133000Z=0A= DESCRIPTION:\nHost key: 487042\n\n\nJOIN WEBEX = MEETING\nhttps://ietf.webex.com/ietf/j.php?MTID=3Dm70918adad686cacc341500= c2d75e34c4\nMeeting number: 646 391 150\nMeeting password: = jeff.is.wise\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: 646 391 150\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. = You should inform all meeting attendees prior to recording if you intend = to record the meeting.\n=0A= X-ALT-DESC;FMTTYPE=3Dtext/html:  
Host key: = 487042 
 
 
Join WebEx = meeting =
Meeting number: 646 391 = 150
Meeting = password:jeff.is.wise
 
 
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 391 150 
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. You should inform = all meeting attendees prior to recording if you intend to record the = meeting.=0A= SUMMARY:I2RS interim 5/27=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_00A2_01D097D7.5B78F180-- From nobody Tue May 26 14:28: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 1CAE31B31F0; Tue, 26 May 2015 14:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ehjY_3dTaSy; Tue, 26 May 2015 14:28:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF51B31F9; Tue, 26 May 2015 14:28:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:28:17 -0400 Message-ID: <00d801d097fa$e1c756a0$a55603e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D9_01D097D9.5AB8C3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+oY2bTi4IH4qRaukXOC6nfsAwA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [i2rs] This is 2 week adoption call for draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9) 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, 26 May 2015 21:28:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9). Jeff is the author so he will be kicking of the adoption call and responding to the IPR question (do you know of any IPR on the requirements draft). Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00D9_01D097D9.5AB8C3E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: =

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 <= /p>

3)      draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-ephemeral-state-req (5/26 to 6/9).  Jeff is the = author so he will be kicking of the adoption call and responding to the = IPR question (do you know of any IPR on the requirements draft).  =

 

Sue Hares

 

PS – = Yes – I know an IPR call on a requirements draft may seem silly, = but it is required.

 

=

 

------=_NextPart_000_00D9_01D097D9.5AB8C3E0-- From nobody Tue May 26 14:36:32 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E15B1B3202; Tue, 26 May 2015 14:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.354 X-Spam-Level: X-Spam-Status: No, score=-96.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ue39Sygk4BP; Tue, 26 May 2015 14:36:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC8271B3201; Tue, 26 May 2015 14:36:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:36:26 -0400 Message-ID: <00f101d097fc$05a0a030$10e1e090$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01D097DA.7E914A20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX+y7VjhtpZaQbTuuEu5xIa4QtPA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [i2rs] draft-haas-i2rs-netmod-netconf-requirements-01 (2 week WG adoption - (5/26 to 6/9/2015) 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, 26 May 2015 21:36:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week adoption call for draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This document is a companion to three other documents for I2RS requirements which have WG calls: This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) The three other documents are: 1) Draft-haas-i2rs-ephemeral-state-reqs-00 https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. 2) draft-ietf-i2rs-pub-sub-requirements-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). Jeff is the author so he will be kicking of the response to the adoption call and state if he knows of any IPR. Please note that the adoption of this draft is to show WG direction, and we expect a more detailed draft may be created for mutual authentication requirements (section 2.2) and transaction requirements. Jeff and I welcome more detailed proposals for mutual authentication requirements (section 2.2) and transaction requirements. If you are interested in working on a quick turn on a proposal, please contact me. I am working on this draft and would like co-authors. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_00F2_01D097DA.7E914A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week adoption call for = draft-haas-i2rs-netmod-netconf-requirements-01 (5/26 to 6/9/2015). This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

This draft = is an early set of requirements from which the ephemeral state and = “identity, secondary-identity and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS = Status: WG Adoption (5/26 to 6/9)

 

The three = other documents are:

 

1)      = Draft-haas-i2rs-ephemeral-state-reqs-00

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the netmod and = netconf Working

   Groups = for functionality to support the ephemeral state = requirements

   to = implement the I2RS architecture.

 

2)      draft-ietf-= i2rs-pub-sub-requirements-02  =

    http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

    I2RS Status: WG LC (5/26 = to 6/9)

 

 <= /p>

3)      = draft-iet= f-i2rs-traceability-02 

     ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

      (5/26 to 6/9) =

 

This thread is to discuss the = draft-haas-i2rs-netmod-netconf-requirements-01 ( (5/26 to 6/9). =  Jeff is the author so he will be kicking of the response to the = adoption call and state if he knows of any IPR.

 

Please note = that the adoption of this draft is to show WG direction, and we expect a = more detailed draft may be created for mutual authentication = requirements (section 2.2) and transaction requirements.  Jeff and = I welcome more detailed proposals for mutual authentication requirements = (section 2.2) and transaction requirements.  If you are interested = in working on a quick turn on a proposal, please contact me.  I am = working on this draft and would like co-authors.

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

------=_NextPart_000_00F2_01D097DA.7E914A20-- From nobody Tue May 26 14:54: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 09AA11B3222; Tue, 26 May 2015 14:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S790X8F1Q_OI; Tue, 26 May 2015 14:54:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2E1B3224; Tue, 26 May 2015 14:54:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 17:54:31 -0400 Message-ID: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0128_01D097DD.0576C220" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/brn0dvPMo3GSuqLIt07oHEavg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: cpignata@cisco.com, netmod@ietf.org, jclarke@cisco.com, "'Gonzalo Salgueiro \(gsalguei\)'" , 'Alia Atlas' , netconf@ietf.org, 'Jeffrey Haas' Subject: [i2rs] 2 week WG LC for draft-ietf-i2rs-traceabilty 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, 26 May 2015 21:54:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9) (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) I2RS Status: WG LC (5/26 to 6/9) Carlos, joe, and Gonzalo - please indicate whether you know of any IPR on this draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draf-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) This thread is to discuss WG consensus on draft-ietf-i2rs-traceability-02 . Please discuss the merits of the traceability framework described in this draft as being part of the requirements forwarded to netmod/netconf. Also discuss if this framework provides the necessary things for I2RS deployment. This draft will also be forwarded as part of the requirements to the IESG. Sue Hares ------=_NextPart_000_0128_01D097DD.0576C220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC for draft-iet= f-i2rs-traceability-02 from (5/26 to 6/9)  

(ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) =

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Carlos, joe, = and Gonzalo – please indicate whether you know of any IPR on this = draft.

 

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draf-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

 

This thread = is to discuss WG consensus on  draft-iet= f-i2rs-traceability-02 .  Please discuss the merits of = the traceability framework described in this draft as being part of the = requirements forwarded to netmod/netconf.   Also discuss if = this framework provides the necessary things for I2RS deployment. =

 

This draft will also be forwarded as part of the = requirements to the IESG.

 

Sue Hares =

 

 

 

------=_NextPart_000_0128_01D097DD.0576C220-- From nobody Tue May 26 15:05:18 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB471B3229; Tue, 26 May 2015 15:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8IW3oqEChGku; Tue, 26 May 2015 15:05:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C02B1B320B; Tue, 26 May 2015 15:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13437; q=dns/txt; s=iport; t=1432677915; x=1433887515; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uGILI0wyIZ2UuPF06D5dvIJ03Fl1FmA1CcxYi3Je92U=; b=Y2LoXbSChyARssvmjbf3wafv0OIqR2HrK9Yoa7grX1cmK9fdIbeRhSwn m8quW8dG20BqZq0ytCALyt6CRPZaEuMlK54ZOeISkrKpdJuWEYzHV6r+W EUq+RC3OfX2UPwTGxVOkhkh3337DNViybGE/vXDFvGK7uO7OZMlvLE4ti k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BFBgDM7GRV/4UNJK1TCYJFS1RetHyNUTyCDoV1AoFLTAEBAQEBAYELhCMBAQQdEEwQAgEIDgQTGgcyFAMOAQEEDgWILA3MaAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOoQpWAQHgxeBFgWTCIQ1hlqBKT6DM5IVI4N4b4JHAQEB X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208,217";a="419690459" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP; 26 May 2015 22:05:14 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t4QM5DoM015685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 22:05:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.169]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 26 May 2015 17:05:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: Susan Hares Thread-Topic: 2 week WG LC for draft-ietf-i2rs-traceabilty Thread-Index: AdCX/brn0dvPMo3GSuqLIt07oHEavgAAk6Os Date: Tue, 26 May 2015 22:05:12 +0000 Message-ID: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> In-Reply-To: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_" MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Carlos Pignataro \(cpignata\)" , "Joe Clarke \(jclarke\)" , Alia Atlas , "netconf@ietf.org" , Jeffrey Haas Subject: Re: [i2rs] 2 week WG LC for draft-ietf-i2rs-traceabilty 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, 26 May 2015 22:05:17 -0000 --_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have no IPR to declare related to this draft, nor do I know of any. Regards, Gonzalo On May 26, 2015, at 5:54 PM, Susan Hares > wrote: This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9) (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) I2RS Status: WG LC (5/26 to 6/9) Carlos, joe, and Gonzalo =96 please indicate whether you know of any IPR on= this draft. This document is a companion to three other documents for I2RS requirements= which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-st= ate-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements= / [This draft is an early set of requirements from which the ephemeral state = and =93identity, secondary-identity and priority=94 were pulled into draft-= haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled= into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been = separated before draft-haas-i2rs-nemod-netconf-requirements was published. = This draft remains the only source for mutual authentication requirements (= section 2.2), transaction requirements, and the history of the discussion. = This draft is being requested to be adopted as a general roadmap for the = I2RS WG. In the future, the I2RS WG will accept more detailed specification= on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draf-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) This thread is to discuss WG consensus on draft-ietf-i2rs-traceability-02<= http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/> . Please di= scuss the merits of the traceability framework described in this draft as b= eing part of the requirements forwarded to netmod/netconf. Also discuss i= f this framework provides the necessary things for I2RS deployment. This draft will also be forwarded as part of the requirements to the IESG. Sue Hares --_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have no IPR to declare related to this draft, nor do I know of any.<= br>
Regards,

Gonzalo



On May 26, 2015, at 5:54 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG LC for draft= -ietf-i2rs-traceability-02 from (5/26 to 6/9)  

(http://datatracker.ietf.org/doc/draft-ietf-i2rs-trac= eability/)

 

I2RS Status: WG LC (5/26 to 6/9)

 

Carlos, joe, and Gonzalo =96 please indicate whether= you know of any IPR on this draft.

 

 

This document is a companion to three other document= s for I2RS requirements which have WG calls:

 

1)    &nbs= p; This begins a 2 week adoption call for draft-ha= as-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draf= t-haas-i2rs-ephemeral-state-reqs/

 

  This document covers requests to the n= etmod and netconf Working

   Groups for functionality to supp= ort the ephemeral state requirements

   to implement the I2RS architectu= re.

 

Status: WG adoption call (5/26 to 6/9) <= /o:p>

 

2)      draft-haas-i2rs-netmod-netconf-requirements-01 

http://datatracker.ietf.org/doc= /draft-haas-i2rs-netmod-netconf-requirements/

 

[This draft is an early set of requirements f= rom which the ephemeral state and =93identity, secondary-identity and prior= ity=94 were pulled into draft-haas-i2rs-ephemeral-state-reqs.  The &nb= sp;notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments.   The traceability had been= separated before draft-haas-i2rs-nemod-netconf-requirements was published.= This draft remains the only source for mutual authentication requirements = (section 2.2), transaction requirements, and the history of the discussion.   This draft is being requested t= o be adopted as a general roadmap for the I2RS WG. In the future, the I2RS = WG will accept more detailed specification on the mutual authentication or = the transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) <= /o:p>

 

3)    &nbs= p; draf-ietf-i2rs-pub-sub-requirements-02.

 

http://datatracker.ietf.org/= doc/draft-ietf-i2rs-pub-sub-requirements/

 

I2RS Status: WG LC (5/26 to 6/9)

 

 

This thread is to discuss WG consensus on  draft-ietf= -i2rs-traceability-02 .  Please discuss the merits of the traceability framework described in this draft a= s being part of the requirements forwarded to netmod/netconf.   A= lso discuss if this framework provides the necessary things for I2RS deploy= ment.

 

This draft will also be forwarded as part of the req= uirements to the IESG.

 

Sue Hares

 

 

 

--_000_9CD84E4E0899402CA1024B6DAFE3CBAFciscocom_-- From nobody Tue May 26 15:07:49 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE32A1B3230; Tue, 26 May 2015 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzFgHX_vgVtM; Tue, 26 May 2015 15:07:45 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12DA1B322C; Tue, 26 May 2015 15:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2919; q=dns/txt; s=iport; t=1432678066; x=1433887666; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NYVVt1CS83B6ht/AG80FwiJz6aRcLyjhwLXB862daBg=; b=A3l1dcM88iFSJq+m5KmG4CR4F6AQ2p3UBVGwQnRLllVlZiy+nzhpZ33k ke5wR5oYPlE08fLpJwOdDVF8EsmnGT8SqKlX1Z5XHJ502UWqLilvI/Sps b+dQfWrbNgWdw6oaESli3jgQDok0nmDmNZddEPjd59gyQretCCt94yKUv k=; X-IronPort-AV: E=Sophos;i="5.13,501,1427760000"; d="scan'208";a="422765105" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP; 26 May 2015 22:07:45 +0000 Received: from [10.117.46.173] (rtp-jclarke-89112.cisco.com [10.117.46.173]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t4QM7hla013958; Tue, 26 May 2015 22:07:43 GMT Message-ID: <5564EEAF.3040901@cisco.com> Date: Tue, 26 May 2015 18:07:43 -0400 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.7.0 MIME-Version: 1.0 To: "Gonzalo Salgueiro (gsalguei)" , Susan Hares References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Carlos Pignataro \(cpignata\)" , Alia Atlas , "netconf@ietf.org" , Jeffrey Haas Subject: Re: [i2rs] 2 week WG LC for draft-ietf-i2rs-traceabilty 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, 26 May 2015 22:07:46 -0000 On 5/26/15 6:05 PM, Gonzalo Salgueiro (gsalguei) wrote: > I have no IPR to declare related to this draft, nor do I know of any. No, no IPR. Joe > > Regards, > > Gonzalo > > > > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: > >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 >> from >> (5/26 to 6/9) >> >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/) >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> Carlos, joe, and Gonzalo please indicate whether you know of any IPR >> on this draft. >> >> This document is a companion to three other documents for I2RS >> requirements which have WG calls: >> >> 1)This begins a 2 week adoption call for >> draft-haas-i2rs-ephemeral-state-req: >> >> https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ >> >> This document covers requests to the netmod and netconf Working >> >> Groups for functionality to support the ephemeral state requirements >> >> to implement the I2RS architecture. >> >> Status: WG adoption call (5/26 to 6/9) >> >> 2)draft-haas-i2rs-netmod-netconf-requirements-01 >> >> >> http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ >> >> [This draft is an early set of requirements from which the ephemeral >> state and identity, secondary-identity and priority were pulled into >> draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription >> were pulled into the draft-ietf-i2rs-pub-sub-requirments. The >> traceability had been separated before >> draft-haas-i2rs-nemod-netconf-requirements was published. This draft >> remains the only source for mutual authentication requirements >> (section 2.2), transaction requirements, and the history of the >> discussion. This draft is being requested to be adopted as a general >> roadmap for the I2RS WG. In the future, the I2RS WG will accept more >> detailed specification on the mutual authentication or the transaction >> protocol. >> >> I2RS Status: WG Adoption (5/26 to 6/9) >> >> 3)draf-ietf-i2rs-pub-sub-requirements-02. >> >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ >> >> I2RS Status: WG LC (5/26 to 6/9) >> >> This thread is to discuss WG consensus on >> draft-ietf-i2rs-traceability-02 >> . >> Please discuss the merits of the traceability framework described in >> this draft as being part of the requirements forwarded to >> netmod/netconf. Also discuss if this framework provides the >> necessary things for I2RS deployment. >> >> This draft will also be forwarded as part of the requirements to the >> IESG. >> >> Sue Hares >> From nobody Tue May 26 17:20: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 E53AD1ACE38; Tue, 26 May 2015 17:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.155 X-Spam-Level: X-Spam-Status: No, score=-97.155 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMpHJ68Vxj5l; Tue, 26 May 2015 17:20:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 824A81ACE39; Tue, 26 May 2015 17:20:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: Date: Tue, 26 May 2015 20:20:34 -0400 Message-ID: <017a01d09812$f31d4780$d957d680$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017B_01D097F1.6C0EB4C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: [i2rs] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) 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, 27 May 2015 00:20:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR related to the draft. This document is a companion to three other documents for I2RS requirements which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-state-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ [This draft is an early set of requirements from which the ephemeral state and "identity, secondary-identity and priority" were pulled into draft-haas-i2rs-ephemeral-state-reqs. The notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments. The traceability had been separated before draft-haas-i2rs-nemod-netconf-requirements was published. This draft remains the only source for mutual authentication requirements (section 2.2), transaction requirements, and the history of the discussion. This draft is being requested to be adopted as a general roadmap for the I2RS WG. In the future, the I2RS WG will accept more detailed specification on the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but it is required. ------=_NextPart_000_017B_01D097F1.6C0EB4C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. =

 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirement= s/

 

I2RS Status: WG LC (5/26 to 6/9) =

 

Eric, = Alexander, Gonzalez – please state whether you know of any IPR = related to the draft.  

 

This = document is a companion to three other documents for I2RS requirements = which have WG calls:

 

1)      = This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req:

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-r= eqs/

 

  This document covers requests to the = netmod and netconf Working

   Groups for functionality to = support the ephemeral state requirements

   to implement the I2RS = architecture.

 

Status: WG adoption call (5/26 to 6/9) =

 

2)      draft-haas-i2rs-netmod-netconf= -requirements-01 

http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netco= nf-requirements/

 

[This draft is an early set of requirements = from which the ephemeral state and “identity, secondary-identity = and priority” were pulled into = draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.

 

I2RS Status: WG Adoption (5/26 to 6/9) =

 

3)      = draft-iet= f-i2rs-traceability-02 

ht= tp://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to 6/9) =

 

This thread is to discuss the = draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netconf = and IESG as requirement for I2RS.  

 

Sue Hares =

 

PS – Yes – I know an IPR call on a = requirements draft may seem silly, but it is required.

 

 

 

 

------=_NextPart_000_017B_01D097F1.6C0EB4C0-- From nobody Tue May 26 20:22:40 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBA1A00E6 for ; Tue, 26 May 2015 20:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoEu2NayCMm8 for ; Tue, 26 May 2015 20:22:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0114.outbound.protection.outlook.com [65.55.169.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C18B1A00E0 for ; Tue, 26 May 2015 20:22:36 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 03:22:34 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Wed, 27 May 2015 03:22:33 +0000 From: Kent Watsen To: Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] Thread-Index: AQHQl+vJBmxUDIPylUO1Ev2bl2oHg52Os5AA Date: Wed, 27 May 2015 03:22:32 +0000 Message-ID: References: <20150526194041.GA20676@pfrc.org> In-Reply-To: <20150526194041.GA20676@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB460; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB460; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(164054003)(189002)(377454003)(199003)(24454002)(479174004)(377424004)(66066001)(19580395003)(19580405001)(101416001)(64706001)(92566002)(2501003)(87936001)(2656002)(83506001)(76176999)(54356999)(50986999)(46102003)(2900100001)(5002640100001)(77156002)(62966003)(102836002)(15975445007)(68736005)(2950100001)(106116001)(106356001)(122556002)(40100003)(99286002)(105586002)(86362001)(561944003)(5001770100001)(97736004)(5001860100001)(5001960100002)(4001350100001)(189998001)(5001830100001)(230783001)(4001540100001)(81156007)(107886002)(36756003)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <8F10E0D64E96314BA7628831BBA6E97D@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 03:22:32.0551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB460 Archived-At: Subject: Re: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 03:22:39 -0000 I likely won't be able to make tomorrow's interim meeting. Hopefully this helps. In the off-list discussion Jeff mentioned, it was stated that using distinct datastores avoids architectural problems and special purpose extensions. This is a perspective I'm coming to have as well. Section 7.1 of draft-haas-i2rs-ephemeral-state-reqs-00 describes disadvantages to having multiple datastores, namely issues around instance-identifiers and must/when expressions. My opinion is that since I2RS is defining a new concept, it can also define the necessary semantics to enable what's needed. While it's true that normal datastores can't reference each other, these are not normal datastores. To underscore this, if I2RS selects RESTCONF, NETCONF's datastores are no longer relevant. In fact, the term "datastore" may be tripping us up, perhaps we call it an "overlay" ;) So Section 7.2 of draft-haas-i2rs-ephemeral-state-reqs-00 describes disadvantages to the overlay approach, namely complexity and consistency issues. Neither of which I fully understand. The overlay approach was discussed on list last September and again in October. It actually seemed to have a lot of support, albeit some minor issues, but they don't seemed nearly as bad as issues discussed in other proposals to date. My proposal is to revisit the overlay approach again, defining the necessary rules as needed. Taking a step into design, I propose not just one overlay, but N overlays for N priorities as follows: - each client has an assigned priority - each overlay has an assigned priority - clients can read lower priority overlays, but not higher priority overlays - each client writes into the overlay of matching priority (no exceptions) - the system calculates the effective configuration using this algorithm: initialize accumulation buffer with NV-config for priority from lowest to highest: merge into accumulation buffer overlay[priority] assert conceptual `validate` on accumulation buffer succeeds Where the merge operation includes the following rules: - merging a scalar value overwrites lower-priority values - merging an ordered-by user list entry causes the entry goes to The beginning of the list (this assumes an ordering semantic, a YANG annotation may be needed to indicate directionality) - it is not possible to simply delete a lower-priority value And client interactions with an overlay includes the following rules: - any update (including on NV config) that might cause the conceptual `validate` on the accumulation buffer to fail has the effect of necessary config to be first *copied* into the higher-priority overlay. The primary advantages to having multiple overlays are - priority doesn't need to be stored per leaf - issues around how lower priority client updates interact with higher priority config disappear. One problem with the approach of having multiple overlays (as oppose to just one) is that it has the consequence of re-exposing a lower-priority value when a higher-priority value is removed...unless we insist that writing higher-priority value wipes out matching lower-priority value (not including NV-config, of course). What's unnerving about re-exposing a lower-priority ephemeral value is that one might argue why the system didn't instead restore an ephemeral value from a client with the same priority instead. I assume that two clients of equal priority would have their own way of resolving it, or else I2RS disallows clients having equal priorities... Thanks, Kent On 5/26/15, 12:40 PM, "Jeffrey Haas" wrote: >Working Group, > >The following document is a straw-man document attempting to document >changes necessary to implement I2RS's ephemeral state needs. > >This document has already gotten some discussion off-list with several of >the usual contributors to the netmod and netconf Working Groups as an >attempt to gain some early traction in the discussion. While that >discussion has been energetic, it hasn't achieved any further consensus >from >the contents posted herein. > >I would like to request that further discussion related to this draft take >place on the mailing list. > >This draft will be a topic for tomorrow's virtual interim. My apologies >for >not posting this more promptly. > >-- Jeff > >----- Forwarded message from internet-drafts@ietf.org ----- > >Date: Tue, 26 May 2015 12:14:57 -0700 >From: internet-drafts@ietf.org >To: i-d-announce@ietf.org >Subject: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : I2RS Ephemeral State Requirements > Author : Jeffrey Haas > Filename : draft-haas-i2rs-ephemeral-state-reqs-00.txt > Pages : 9 > Date : 2015-05-26 > >Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support the ephemeral state requirements > to implement the I2RS architecture. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-haas-i2rs-ephemeral-state-reqs-00 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >----- End forwarded message ----- > >_______________________________________________ >i2rs mailing list >i2rs@ietf.org >https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue May 26 20:40: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 AF26E1A0369 for ; Tue, 26 May 2015 20:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA24_ABZiHoM for ; Tue, 26 May 2015 20:40:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779FE1A0363 for ; Tue, 26 May 2015 20:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 39E7F240650; Tue, 26 May 2015 20:40:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 89ECB240306; Tue, 26 May 2015 20:40:10 -0700 (PDT) Message-ID: <55653C96.7060004@joelhalpern.com> Date: Tue, 26 May 2015 23:40:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kent Watsen , Jeffrey Haas , "i2rs@ietf.org" References: <20150526194041.GA20676@pfrc.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 03:40:13 -0000 We discussed saving and re-exposing lower priority operations when higher priority ones were removed. The working group decided that was a bad idea, as it has a tendency to produce unintended consequences. Also, all direct over-writes among I2RS operations are considered errors. They will need to produce notifications of these errors. And then the higher priority one is applied as a means of producing deterministic results, not because it is reliably right. Also, if an I2RS client has read permission on I2RS data, it reads the current value. No matter what priority the value was set using. So I would be really unhappy with trying to model this as an overlay per priority. It seems to produce even more complexity, more unexpected results, and does not help us. If I2RS data can be modeled as a single datastore with read-through to the underlying operational state, and no possibility of performing a commit then it can probably be made to work. Yours, Joel On 5/26/15 11:22 PM, Kent Watsen wrote: > > I likely won't be able to make tomorrow's interim meeting. Hopefully this > helps. > > In the off-list discussion Jeff mentioned, it was stated that using > distinct datastores avoids architectural problems and special purpose > extensions. This is a perspective I'm coming to have as well. > > Section 7.1 of draft-haas-i2rs-ephemeral-state-reqs-00 describes > disadvantages to having multiple datastores, namely issues around > instance-identifiers and must/when expressions. My opinion is that since > I2RS is defining a new concept, it can also define the necessary semantics > to enable what's needed. While it's true that normal datastores can't > reference each other, these are not normal datastores. To underscore > this, if I2RS selects RESTCONF, NETCONF's datastores are no longer > relevant. In fact, the term "datastore" may be tripping us up, perhaps we > call it an "overlay" ;) > > So Section 7.2 of draft-haas-i2rs-ephemeral-state-reqs-00 describes > disadvantages to the overlay approach, namely complexity and consistency > issues. Neither of which I fully understand. The overlay approach was > discussed on list last September and again in October. It actually seemed > to have a lot of support, albeit some minor issues, but they don't seemed > nearly as bad as issues discussed in other proposals to date. > > My proposal is to revisit the overlay approach again, defining the > necessary rules as needed. Taking a step into design, I propose not just > one overlay, but N overlays for N priorities as follows: > > - each client has an assigned priority > - each overlay has an assigned priority > - clients can read lower priority overlays, but not higher priority > overlays > - each client writes into the overlay of matching priority (no > exceptions) > > - the system calculates the effective configuration using this algorithm: > > initialize accumulation buffer with NV-config > for priority from lowest to highest: > merge into accumulation buffer overlay[priority] > assert conceptual `validate` on accumulation buffer succeeds > > Where the merge operation includes the following rules: > - merging a scalar value overwrites lower-priority values > - merging an ordered-by user list entry causes the entry goes to > The beginning of the list (this assumes an ordering semantic, a > YANG annotation may be needed to indicate directionality) > - it is not possible to simply delete a lower-priority value > > And client interactions with an overlay includes the following rules: > - any update (including on NV config) that might cause the > conceptual `validate` on the accumulation buffer to fail has > the effect of necessary config to be first *copied* into the > higher-priority overlay. > > The primary advantages to having multiple overlays are > - priority doesn't need to be stored per leaf > - issues around how lower priority client updates interact > with higher priority config disappear. > > > One problem with the approach of having multiple overlays (as oppose to > just one) is that it has the consequence of re-exposing a lower-priority > value when a higher-priority value is removed...unless we insist that > writing higher-priority value wipes out matching lower-priority value (not > including NV-config, of course). What's unnerving about re-exposing a > lower-priority ephemeral value is that one might argue why the system > didn't instead restore an ephemeral value from a client with the same > priority instead. I assume that two clients of equal priority would have > their own way of resolving it, or else I2RS disallows clients having equal > priorities... > > > Thanks, > Kent > > > > > > On 5/26/15, 12:40 PM, "Jeffrey Haas" wrote: > >> Working Group, >> >> The following document is a straw-man document attempting to document >> changes necessary to implement I2RS's ephemeral state needs. >> >> This document has already gotten some discussion off-list with several of >> the usual contributors to the netmod and netconf Working Groups as an >> attempt to gain some early traction in the discussion. While that >> discussion has been energetic, it hasn't achieved any further consensus >> from >> the contents posted herein. >> >> I would like to request that further discussion related to this draft take >> place on the mailing list. >> >> This draft will be a topic for tomorrow's virtual interim. My apologies >> for >> not posting this more promptly. >> >> -- Jeff >> >> ----- Forwarded message from internet-drafts@ietf.org ----- >> >> Date: Tue, 26 May 2015 12:14:57 -0700 >> From: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> Subject: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : I2RS Ephemeral State Requirements >> Author : Jeffrey Haas >> Filename : draft-haas-i2rs-ephemeral-state-reqs-00.txt >> Pages : 9 >> Date : 2015-05-26 >> >> Abstract: >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-haas-i2rs-ephemeral-state-reqs-00 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> ----- End forwarded message ----- >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue May 26 22:41: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 0AB591A00B2; Tue, 26 May 2015 22:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIZaNOOR15EN; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6FD01A009B; Tue, 26 May 2015 22:41:55 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3CEC910C8; Wed, 27 May 2015 07:41:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QZvfogcwvDOp; Wed, 27 May 2015 07:41:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 92D0C2002B; Wed, 27 May 2015 07:41:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U4tkOcVBdnzZ; Wed, 27 May 2015 07:41:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96FC320013; Wed, 27 May 2015 07:41:52 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 368163384F67; Wed, 27 May 2015 07:41:48 +0200 (CEST) Date: Wed, 27 May 2015 07:41:48 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150527054148.GA6258@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org References: <00a101d097f8$e2847700$a78d6500$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <00a101d097f8$e2847700$a78d6500$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) 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: Wed, 27 May 2015 05:41:58 -0000 On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: > The I2RS interim is schedule for Wednesdsay 5/27 10:00am – 11:30am. The interim schedule opens 30 minutes early to allow speakers to check their mike and make sure there slides are ready. > > > > There are two topics on the agenda: > > > > 1) I2RS Protocol requirements with discussion on the following drafts > > a. https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ (WG adoption 5/26 to 6/9/2015) > > b. http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements (WG adoption 5/26 to 6/9/2015) > I can't make it to this meeting. My suggestion is to merge the above two I-Ds into one I-D. There is already overlap. It also seems that a. goes quite a bit into solution space, so calling it a requirements document may be a bit of a stretch. (But that said, we need to start talking about solutions since we already have a document full of requirements.) /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 Wed May 27 06:55: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 7DE4A1ACF55; Wed, 27 May 2015 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEDaoyKcrO7n; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 54FA31A1A86; Wed, 27 May 2015 06:55:14 -0700 (PDT) Received: from [192.168.1.70] (99-59-193-146.lightspeed.livnmi.sbcglobal.net [99.59.193.146]) by slice.pfrc.org (Postfix) with ESMTPSA id 13B101E30A; Wed, 27 May 2015 09:55:52 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jeffrey Haas In-Reply-To: <20150527054148.GA6258@elstar.local> Date: Wed, 27 May 2015 09:55:12 -0400 Message-Id: <75138D77-1D2C-4E2C-9976-4CC119E079C7@pfrc.org> References: <00a101d097f8$e2847700$a78d6500$@ndzh.com> <20150527054148.GA6258@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.2098) Archived-At: Cc: netmod@ietf.org, i2rs@ietf.org, Alia Atlas , netconf@ietf.org, Sue Hares Subject: Re: [i2rs] [netmod] I2RS interim 5/27 10:00am - 11:30am EDT (Webex) 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, 27 May 2015 13:55:17 -0000 --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder = wrote: >=20 > On Tue, May 26, 2015 at 05:13:59PM -0400, Susan Hares wrote: >> The I2RS interim is schedule for Wednesdsay 5/27 10:00am =E2=80=93 = 11:30am. The interim schedule opens 30 minutes early to allow speakers = to check their mike and make sure there slides are ready.=20 >>=20 >>=20 >>=20 >> There are two topics on the agenda:=20 >>=20 >>=20 >>=20 >> 1) I2RS Protocol requirements with discussion on the following = drafts =20 >>=20 >> a. = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = (WG adoption 5/26 to 6/9/2015)=20 >>=20 >> b. = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s (WG adoption 5/26 to 6/9/2015) >>=20 >=20 > I can't make it to this meeting. My suggestion is to merge the above > two I-Ds into one I-D. There is already overlap. I believe I=E2=80=99d prefer to not adopt the netmod-netconf draft. Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work. However, there was strong = pressure to have adopted WG items to cover the contents. The state = draft is another piece of that. I believe this leaves authentication requirements as the only meaningful = content. A last draft covering that may perhaps be spun out or not as = the WG desires. After that, the netmod-netconf requirements draft can = die. > It also seems that > a. goes quite a bit into solution space, so calling it a requirements > document may be a bit of a stretch. (But that said, we need to start > talking about solutions since we already have a document full of > requirements.) The actual requirements have been stalled since before the NYC interim: = We need ephemeral state. The implications of any given solution space = are too important to draft requirements in the absence of some = understanding of the likely solution. I=E2=80=99m happy to rename the draft something that doesn=E2=80=99t = contain the word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion. =E2=80=94 Jeff --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On May 27, 2015, at 1:41 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Tue, May 26, 2015 at 05:13:59PM -0400, Susan = Hares wrote:
The I2RS interim is schedule for Wednesdsay 5/27 = 10:00am =E2=80=93 11:30am. The interim schedule opens 30 minutes early = to allow speakers to check their mike and make sure there slides are = ready. 



There are two = topics on the agenda: 



1) =      I2RS Protocol requirements  with = discussion on the following drafts  

a. =       https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/  (WG adoption 5/26 to 6/9/2015) 

b.      http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements (WG adoption 5/26 to 6/9/2015)


I can't make it to this = meeting. My suggestion is to merge the above
two I-Ds into one I-D. There is already = overlap.

I believe = I=E2=80=99d prefer to not adopt the netmod-netconf draft.  Its = goal, as explained during the last netconf WG session that I presented = it in, is to simply use it as the placeholder =E2=80=9CTODO=E2=80=9D = list for the actual drafts covering the work.  However, there was = strong pressure to have adopted WG items to cover the contents. =  The state draft is another piece of that.

I believe this leaves authentication requirements = as the only meaningful content.  A last draft covering that may = perhaps be spun out or not as the WG desires.  After that, the = netmod-netconf requirements draft can die.

It also seems that
a. goes quite a bit into solution space, so = calling it a requirements
document may be a bit of a = stretch. (But that said, we need to start
talking about solutions since we already have a = document full of
requirements.)

The actual = requirements have been stalled since before the NYC interim: We need = ephemeral state.  The implications of any given solution space are = too important to draft requirements in the absence of some understanding = of the likely solution.

I=E2=80=99m = happy to rename the draft something that doesn=E2=80=99t contain the = word =E2=80=9Crequirements=E2=80=9D if you have a better = suggestion.

=E2=80=94 = Jeff

= --Apple-Mail=_4E3FF781-6069-4744-9151-078C842215F8-- From nobody Wed May 27 07:09: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 0F7B81B2ACE; Wed, 27 May 2015 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxNcYP8aLZ5h; Wed, 27 May 2015 07:09:45 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FE01B2ABE; Wed, 27 May 2015 07:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14845; q=dns/txt; s=iport; t=1432735787; x=1433945387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pzx2FcQxFTH7FyWj9H8vi4XEV2jn9Zk0G98cU/BJqmk=; b=eebS61YYZdQv4f8TBrousSAfMx/Lz4Ok3CWigOT0GyONQ4KMX3Gva54C ppG953rIu2ps3A5WiK7ujDTPycZEfbysOLTb/7a4Zw4BqJQhsDaFs88UW jVIe/ZSBO6BXLm/4dJGO9DjiPllO1T577jtUtpsE85YksZt/7aUklcMoG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D1BADcz2VV/5FdJa1TCYJFS1ReBrMljg0qCYFbhXUCgTw4FAEBAQEBAQGBCoQiAQEBBB0QTBACAQgOAwEDAQELAxoHMhQDBggBAQQBDQUIiCUN0GYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqEKSstBAYBgxeBFgWTCIQ1hluBKD6DM5IVI4I7gT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="scan'208,217";a="153774712" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP; 27 May 2015 14:09:46 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t4RE9iwu000358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 14:09:44 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Wed, 27 May 2015 09:09:44 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) Thread-Index: AdCX/SqdWbWgG8/OQamGAg9/X0In5wAiVB1Q Date: Wed, 27 May 2015 14:09:43 +0000 Message-ID: References: <017a01d09812$f31d4780$d957d680$@ndzh.com> In-Reply-To: <017a01d09812$f31d4780$d957d680$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.229] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" , "netmod@ietf.org" Subject: Re: [i2rs] [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (5/26 to 6/9) 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, 27 May 2015 14:09:53 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We know of no IPR related to draft-ietf-i2rs-pub-sub-requirements. Eric From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, May 26, 2015 8:21 PM To: i2rs@ietf.org Cc: netconf@ietf.org; netmod@ietf.org Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requrements-02 (= 5/26 to 6/9) This begins a 2 week WG LC on draft-ietf-i2rs-pub-sub-requirements-02. http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ I2RS Status: WG LC (5/26 to 6/9) Eric, Alexander, Gonzalez - please state whether you know of any IPR relate= d to the draft. This document is a companion to three other documents for I2RS requirements= which have WG calls: 1) This begins a 2 week adoption call for draft-haas-i2rs-ephemeral-st= ate-req: https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ This document covers requests to the netmod and netconf Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. Status: WG adoption call (5/26 to 6/9) 2) draft-haas-i2rs-netmod-netconf-requirements-01 http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements= / [This draft is an early set of requirements from which the ephemeral state = and "identity, secondary-identity and priority" were pulled into draft-haas= -i2rs-ephemeral-state-reqs. The notification-subscription were pulled int= o the draft-ietf-i2rs-pub-sub-requirments. The traceability had been sepa= rated before draft-haas-i2rs-nemod-netconf-requirements was published. This= draft remains the only source for mutual authentication requirements (sect= ion 2.2), transaction requirements, and the history of the discussion. Th= is draft is being requested to be adopted as a general roadmap for the I2RS= WG. In the future, the I2RS WG will accept more detailed specification on = the mutual authentication or the transaction protocol. I2RS Status: WG Adoption (5/26 to 6/9) 3) draft-ietf-i2rs-traceability-02 http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ (5/26 to 6/9) This thread is to discuss the draft-i2rs-pub-sub-requirements-02 and forwar= ding to the netmod/netconf and IESG as requirement for I2RS. Sue Hares PS - Yes - I know an IPR call on a requirements draft may seem silly, but i= t is required. --_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We know of no IPR rela= ted to draft-ietf-i2rs-pub-sub-requirements.

 

Eric=

 

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, May 26, 2015 8:21 PM
To: i2rs@ietf.org
Cc: netconf@ietf.org; netmod@ietf.org
Subject: [Netconf] 2 week WG LC on draft-ietf-i2rs-pub-sub-requremen= ts-02 (5/26 to 6/9)

 

This begins a 2 week WG L= C on draft-ietf-i2rs-pub-sub-requirements-02.

 

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/

 

I2RS Status: WG LC (5/26 to 6= /9)

 

Eric, Alexander, Gonzalez= – please state whether you know of any IPR related to the draft. &nb= sp;

 

This document is a compan= ion to three other documents for I2RS requirements which have WG calls:

 

1)      This begins a 2 week adoption call for draft-haas-i= 2rs-ephemeral-state-req:

https://d= atatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/

 =

  This docum= ent covers requests to the netmod and netconf Working

   Grou= ps for functionality to support the ephemeral state requirements=

   to i= mplement the I2RS architecture.

 =

Status: WG adopti= on call (5/26 to 6/9)

 =

2)&n= bsp;     draft-haas-i2rs-netmod-netconf-requirements-01 

htt= p://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 =

[This draft is an= early set of requirements from which the ephemeral state and “identi= ty, secondary-identity and priority” were pulled into draft-haas-i2rs= -ephemeral-state-reqs.  The  notification-subscription were pulled into the draft-ietf-i2rs-pub-sub-requirments.   The = traceability had been separated before draft-haas-i2rs-nemod-netconf-requir= ements was published. This draft remains the only source for mutual authent= ication requirements (section 2.2), transaction requirements, and the history of the discussion.   This draft is= being requested to be adopted as a general roadmap for the I2RS WG. In the= future, the I2RS WG will accept more detailed specification on the mutual = authentication or the transaction protocol.

 =

I2RS Status: WG A= doption (5/26 to 6/9)

 

&n= bsp;

3)      draft-ietf-i2rs-traceability-02&nb= sp;

http://d= atatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

(5/26 to= 6/9)

 

This thread is to discuss= the draft-i2rs-pub-sub-requirements-02 and forwarding to the netmod/netcon= f and IESG as requirement for I2RS.  

 

Sue Hares

 

PS – Yes – I = know an IPR call on a requirements draft may seem silly, but it is required= .

 

 

 

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B121AC00D1xmbalnx11ciscoc_-- From nobody Wed May 27 08:51:41 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526861B2D97; Wed, 27 May 2015 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xv8TfbdOzErP; Wed, 27 May 2015 08:51:37 -0700 (PDT) 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 4ADBA1B2E1E; Wed, 27 May 2015 08:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20039; q=dns/txt; s=iport; t=1432741892; x=1433951492; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rLCPMgPZvew6SBdfOCErBo+MdMce9Ag+wC5i0d/9GKI=; b=MBd+qYRwsmtsyg9BpCj2yu1eOsN1uB9vkavnsG42CaaZSMuRDukxPRvI LbUm025hEPTNQWZ3Aplg9HBXXH+4q+gxP4qhb7NicFKDAiBj3eBKjEdan OAGqXvmEFoXu+gBJ3X7POZs9ny6eU+E1qlA/UZEqZT+IPBzgkEyNiuGE7 o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBgCT5mVV/5xdJa1TCYJFS1RRDQazJo1RPIIOhXUCgT1MAQEBAQEBgQuEIgEBAQMBHVwFCwIBCBIGDRoHMhQDDgIEDgUOiBcIDdExAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s6hClYBAeDF4EWBZBMgjyCEoFDYIZaAYEoPoMzkhUjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="asc'?scan'208,217";a="423104413" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 May 2015 15:51:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t4RFpVWC022588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 May 2015 15:51:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Wed, 27 May 2015 10:51:31 -0500 From: "Carlos Pignataro (cpignata)" To: "Gonzalo Salgueiro (gsalguei)" Thread-Topic: 2 week WG LC for draft-ietf-i2rs-traceabilty Thread-Index: AQHQmJT/G84nv2mRhUmMuFoWysqLBQ== Date: Wed, 27 May 2015 15:51:30 +0000 Message-ID: References: <012701d097fe$8c8554e0$a58ffea0$@ndzh.com> <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> In-Reply-To: <9CD84E4E-0899-402C-A102-4B6DAFE3CBAF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.90] Content-Type: multipart/signed; boundary="Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" , "Joe Clarke \(jclarke\)" , Alia Atlas , "netconf@ietf.org" , Jeff Haas , Susan Hares Subject: Re: [i2rs] 2 week WG LC for draft-ietf-i2rs-traceabilty 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, 27 May 2015 15:51:39 -0000 --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C Content-Type: multipart/alternative; boundary="Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526" --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I do not know of any IPR relating to draft-ietf-i2rs-traceability-02. Thanks! =97 Carlos. > On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = wrote: >=20 > I have no IPR to declare related to this draft, nor do I know of any. >=20 > Regards, >=20 > Gonzalo >=20 >=20 >=20 > On May 26, 2015, at 5:54 PM, Susan Hares > wrote: >=20 >> This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 = from = (5/26 to 6/9) >> (http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ = ) >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >> Carlos, joe, and Gonzalo =96 please indicate whether you know of any = IPR on this draft. >>=20 >>=20 >> This document is a companion to three other documents for I2RS = requirements which have WG calls: >>=20 >> 1) This begins a 2 week adoption call for = draft-haas-i2rs-ephemeral-state-req: >> = https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ = >>=20 >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support the ephemeral state = requirements >> to implement the I2RS architecture. >>=20 >> Status: WG adoption call (5/26 to 6/9) >>=20 >> 2) draft-haas-i2rs-netmod-netconf-requirements-01 = >> = http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirement= s/ = >>=20 >> [This draft is an early set of requirements from which the ephemeral = state and =93identity, secondary-identity and priority=94 were pulled = into draft-haas-i2rs-ephemeral-state-reqs. The = notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments. The traceability had been = separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion. This draft is being requested to be adopted as a = general roadmap for the I2RS WG. In the future, the I2RS WG will accept = more detailed specification on the mutual authentication or the = transaction protocol. >>=20 >> I2RS Status: WG Adoption (5/26 to 6/9) >>=20 >> 3) draf-ietf-i2rs-pub-sub-requirements-02. >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ = >>=20 >> I2RS Status: WG LC (5/26 to 6/9) >>=20 >>=20 >> This thread is to discuss WG consensus on = draft-ietf-i2rs-traceability-02 = . = Please discuss the merits of the traceability framework described in = this draft as being part of the requirements forwarded to = netmod/netconf. Also discuss if this framework provides the necessary = things for I2RS deployment. >>=20 >> This draft will also be forwarded as part of the requirements to the = IESG. >>=20 >> Sue Hares --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I do not know of any IPR relating = to draft-ietf-i2rs-traceability-02.

Thanks!

=97 Carlos.

On May 26, 2015, at 6:05 PM, Gonzalo Salgueiro (gsalguei) = <gsalguei@cisco.com> wrote:

I have no IPR to = declare related to this draft, nor do I know of any.

Regards,

Gonzalo



On May 26, = 2015, at 5:54 PM, Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG LC for draft-ietf-i2rs-traceability-02 from (5/26 to 6/9)  
(http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/)
I2RS Status: WG LC (5/26 to 6/9)
 
This document is a companion to three = other documents for I2RS requirements which have WG calls:
 
1)      This begins a = 2 week adoption call for draft-haas-i2rs-ephemeral-state-req:
https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-stat= e-reqs/
 
  This document covers requests to the netmod and = netconf Working
   Groups for functionality to support the = ephemeral state requirements
   to implement the I2RS = architecture.
 
Status: WG adoption call (5/26 to 6/9) 
 
2)      draft-haas-i2rs-netmod-netconf-requirements-01 
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-= requirements/
 
[This draft is an early set of requirements from which the = ephemeral state and =93identity, secondary-identity and priority=94 were = pulled into draft-haas-i2rs-ephemeral-state-reqs.  The =  notification-subscription were pulled into the = draft-ietf-i2rs-pub-sub-requirments.   The traceability had = been separated before draft-haas-i2rs-nemod-netconf-requirements was = published. This draft remains the only source for mutual authentication = requirements (section 2.2), transaction requirements, and the history of = the discussion.   This draft is being requested to be adopted = as a general roadmap for the I2RS WG. In the future, the I2RS WG will = accept more detailed specification on the mutual authentication or the = transaction protocol.
 
I2RS Status: WG Adoption (5/26 to = 6/9) 
 
3)      draf-ietf-i2rs-= pub-sub-requirements-02. 
 
 
I2RS Status: WG LC (5/26 = to 6/9)
 
 
This thread is to discuss WG consensus = on  draft-ietf-i2rs-traceability-02 .  Please discuss the = merits of the traceability framework described in this draft as being = part of the requirements forwarded to netmod/netconf.   Also = discuss if this framework provides the necessary things for I2RS = deployment.
 
This draft will also be forwarded as part of the requirements = to the IESG.
 
Sue Hares 

= --Apple-Mail=_E3B5E6A4-6C15-4967-973D-854D6EB62526-- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVZegBAAoJEIXgpQGOZny9SaEP/0jBga0U+oiZlSm7K0jQ+NUa 1r49iW03CZP3ormv62G3W15I4YWPxqfHgt1XpgY+Fu9iEKldXTWAgFV03JtngY9M RFrkaM0hwlxDHKT+tHvpew81T7dBjQ+QL4ptUWFdFyUDCu8P5zWx0C0hL2yB9oUv +SQkptA4hCXFcM3pQXs2+Jvphgakle9XwOqXNn0CjWZ71J3BW0dkT5PmyNp1okf+ yE6/HchAxqlGvLCCoHEmpHmdn6JU77yGu/EM7I49xlWOnH/Mc3JDTlmIKUyq5Gjy /w+7OOaei7iYPMFL1vpIz00/OcCTkfBogk8s2csy/KwKUj85DnqkY+oZ3DcFH73+ 2itlWghr7+XuSg2BhZoA7IEGM9j/SeWOitqvgAUO41mc4nLRDjAN9w9RNJMN6eZP wJoxjS1klwLIZZncI9gQBvtcXE9yWZLy/QcgiglP9B6EBAWjlQwO+kYj6oo5M1Xs A8vgHksBa1DZ4M8k1rqGnaeErnRlmWA+aGBVCjhazXLWqbCzGywH3IIPGAjn2Fax RqxGSy+LZFMP0w2BrNV3cF2CTsm5pDEHuC/9BgNVZSsJJxYnXI1IAjg4okADoOyC e31hS+VLGssah/Qmbd4zvWaC2VYRvvymh7js2kxxPsINRy1XWxjlmxIi0dZN2irO Q5/u5Q23qKRpYMrO1mf9 =j1Kw -----END PGP SIGNATURE----- --Apple-Mail=_E7527E99-53A7-4D5B-B1EC-36281C97562C-- From nobody Wed May 27 09:04: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 F03A41A1B21; Wed, 27 May 2015 09:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB5a6dJa5Bcb; Wed, 27 May 2015 09:04:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1020A1A1AE3; Wed, 27 May 2015 09:04:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527160401.2294.79322.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 09:04:01 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-traceability-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:04:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : Interface to the Routing System (I2RS) Traceability: Framework and Information Model Authors : Joe Clarke Gonzalo Salgueiro Carlos Pignataro Filename : draft-ietf-i2rs-traceability-03.txt Pages : 13 Date : 2015-05-27 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 27 09:07: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 617FF1A1B29 for ; Wed, 27 May 2015 09:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-7krdpxujDf for ; Wed, 27 May 2015 09:07:04 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A62121A1B12 for ; Wed, 27 May 2015 09:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2104; q=dns/txt; s=iport; t=1432742825; x=1433952425; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pg8TcD3NE4u13CuQDNGRNkAowgMukp8/TR337MMfY7I=; b=LavsboTAEDT6Oms7E2GAdLjS+iJj4GA9drbC9ZIkdz2S5PYZs6aeMGM3 roiaV3QrPLinGpYU3D24bBjLV4KMsz4S2QZUv+vSQqLq42s7XUgZYSRKl seB0FwZX1d6vpjSOy0jCcfzc2YqGs6H2f7Q5Kf/P4z/S53cpSxaLo8SMZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzBQBH62VV/5tdJa1cgxBUXoMfwCiFdQKBPkwBAQEBAQGBC4QiAQEBBCMVPxIcAQIBAgMCBSECAg8COAQCCAYNBgIBAYgpDa0upCYBAQEBAQEBAQEBAQEBAQEBAQEBGYEhihmFDAaCYoFFAQSLVYtohlqBKT6DM4JejzcjhBQiMQGCRgEBAQ X-IronPort-AV: E=Sophos;i="5.13,506,1427760000"; d="scan'208";a="423028744" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 27 May 2015 16:06:52 +0000 Received: from [10.117.46.173] (rtp-jclarke-89112.cisco.com [10.117.46.173]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t4RG6phr008707 for ; Wed, 27 May 2015 16:06:51 GMT Message-ID: <5565EB9B.30801@cisco.com> Date: Wed, 27 May 2015 12:06:51 -0400 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.7.0 MIME-Version: 1.0 To: "i2rs@ietf.org" References: <20150527160401.2294.60886.idtracker@ietfa.amsl.com> In-Reply-To: <20150527160401.2294.60886.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150527160401.2294.60886.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [i2rs] Fwd: New Version Notification for draft-ietf-i2rs-traceability-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:07:06 -0000 Based on today's interim call, we added "Client Priority" as another field to be added to the traceability record. Please review this as part of WGLC. Thank you. Joe -------- Forwarded Message -------- Subject: New Version Notification for draft-ietf-i2rs-traceability-03.txt Date: Wed, 27 May 2015 09:04:01 -0700 From: internet-drafts@ietf.org To: Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro , Joe Clarke , Carlos Pignataro , Gonzalo Salgueiro A new version of I-D, draft-ietf-i2rs-traceability-03.txt has been successfully submitted by Joe Clarke and posted to the IETF repository. Name: draft-ietf-i2rs-traceability Revision: 03 Title: Interface to the Routing System (I2RS) Traceability: Framework and Information Model Document date: 2015-05-27 Group: i2rs Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-ietf-i2rs-traceability-03.txt Status: https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ Htmlized: https://tools.ietf.org/html/draft-ietf-i2rs-traceability-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-traceability-03 Abstract: This document describes a framework for traceability in the Interface to the Routing System (I2RS) and information model for that framework. It specifies the motivation, requirements, use cases, and defines an information model for recording interactions between elements implementing the I2RS protocol. This framework provides a consistent tracing interface for components implementing the I2RS architecture to record what was done, by which component, and when. It aims to improve the management of I2RS implementations, and can be used for troubleshooting, auditing, forensics, and accounting purposes. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Wed May 27 09:52: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 C45B71A871B for ; Wed, 27 May 2015 09:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PrUSd2Ydj6Z for ; Wed, 27 May 2015 09:52:26 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0145.outbound.protection.outlook.com [65.55.169.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 300701A8726 for ; Wed, 27 May 2015 09:52:26 -0700 (PDT) Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.1.172.22; Wed, 27 May 2015 16:52:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.154]) with mapi id 15.01.0172.012; Wed, 27 May 2015 16:52:24 +0000 From: Kent Watsen To: "Joel M. Halpern" , Jeffrey Haas , "i2rs@ietf.org" Thread-Topic: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] Thread-Index: AQHQl+vJBmxUDIPylUO1Ev2bl2oHg52Os5AAgAB6PQCAAGgGgA== Date: Wed, 27 May 2015 16:52:22 +0000 Message-ID: References: <20150526194041.GA20676@pfrc.org> <55653C96.7060004@joelhalpern.com> In-Reply-To: <55653C96.7060004@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.10] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB458; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CO1PR05MB458; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB458; x-forefront-prvs: 05891FB07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(24454002)(189002)(199003)(479174004)(377454003)(36756003)(97736004)(4001540100001)(4001350100001)(81156007)(5001770100001)(189998001)(107886002)(2501003)(5001960100002)(46102003)(92566002)(62966003)(5001860100001)(5001830100001)(122556002)(83506001)(64706001)(77156002)(105586002)(2900100001)(2656002)(87936001)(2950100001)(106356001)(54356999)(102836002)(50986999)(76176999)(19580395003)(561944003)(19580405001)(68736005)(40100003)(106116001)(99286002)(66066001)(230783001)(86362001)(5002640100001)(101416001)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-ID: <451D64226E3998409807E4D6A13899C7@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2015 16:52:22.6980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB458 Archived-At: Subject: Re: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 16:52:27 -0000 On 5/26/15, 8:40 PM, "Joel M. Halpern" wrote: >We discussed saving and re-exposing lower priority operations when >higher priority ones were removed. The working group decided that was a >bad idea, as it has a tendency to produce unintended consequences. Right, which is why I wrote that writing higher-priority value could wipeout lower-priority values, not simply shadow them. >Also, all direct over-writes among I2RS operations are considered >errors. They will need to produce notifications of these errors. And >then the higher priority one is applied as a means of producing >deterministic results, not because it is reliably right. I didn't mention notifications, but I think what you write is consistent with my proposal. >Also, if an I2RS client has read permission on I2RS data, it reads the >current value. No matter what priority the value was set using. There is the difference between config and op-state. I didn't mention op-state but I agree with your statement. >So I would be really unhappy with trying to model this as an overlay per >priority. It seems to produce even more complexity, more unexpected >results, and does not help us. To me it seems easier with more predictable results. That said, multiple overlays could be characterized as just an implementation detail, as it doesn't impact an I2RS Client's interactions with an I2RS Agent. >If I2RS data can be modeled as a single datastore with read-through to >the underlying operational state, and no possibility of performing a >commit then it can probably be made to work. Right, the overlay model gives us this. We seem to agree, only I'm not calling it a "datastore" for reasons described in my previous message. Thanks, Kent From nobody Wed May 27 11:08: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 D93A61A898C for ; Wed, 27 May 2015 11:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v61V_sZQECae for ; Wed, 27 May 2015 11:08:54 -0700 (PDT) Received: from mail-la0-f50.google.com (mail-la0-f50.google.com [209.85.215.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F47E1A8988 for ; Wed, 27 May 2015 11:08:54 -0700 (PDT) Received: by labko7 with SMTP id ko7so9892925lab.2 for ; Wed, 27 May 2015 11:08:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HMwcOcz7GpsWUiO9fH4iiNXfqlbxG49hikXbkazRaJw=; b=GSkGe6j11sr9FM7dbD3K207a9vIIDOGwrjDhtOSlbkN3Yo5ZqT5/FURr8msC2YlGN9 yAUpvcxRIMPG+RsW28/HLKQqWwcVB5mgfnOW/JKZuI01/wlZm8FLLHtfnnCYJWTQM67z cPAmRg46otmKOujrVPhu6/Q95QYTxMRV9JfMiaILpeDfUZRmDQfm1E/c7PDGCELezA6z 007Kl31S6zG60IJpQKwkbuE+wav7ubup+nDdLePmpHBYm5yPxbWD6XGbpuBNjw2dUZpk hVWjubywvy1SNs55P6VbQPg88+L2crd/4VFlbuG39P3CwJApa9ODRGfK/4OurBozr3qJ vw8g== X-Gm-Message-State: ALoCoQkZYPhN8GF6yqeT6RQ8ERmFC1qd8qCCbcgHNUsvZfj5j0qgAbobMJVmVObTr6CjCRRs/Zca MIME-Version: 1.0 X-Received: by 10.152.8.231 with SMTP id u7mr28545420laa.37.1432750132472; Wed, 27 May 2015 11:08:52 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 27 May 2015 11:08:52 -0700 (PDT) In-Reply-To: References: <20150526194041.GA20676@pfrc.org> Date: Wed, 27 May 2015 11:08:52 -0700 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" Subject: Re: [i2rs] [internet-drafts@ietf.org: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt] X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:08:58 -0000 On Tue, May 26, 2015 at 8:22 PM, Kent Watsen wrote: > > I likely won't be able to make tomorrow's interim meeting. Hopefully this > helps. > > In the off-list discussion Jeff mentioned, it was stated that using > distinct datastores avoids architectural problems and special purpose > extensions. This is a perspective I'm coming to have as well. > > Section 7.1 of draft-haas-i2rs-ephemeral-state-reqs-00 describes > disadvantages to having multiple datastores, namely issues around > instance-identifiers and must/when expressions. My opinion is that since > I2RS is defining a new concept, it can also define the necessary semantics > to enable what's needed. While it's true that normal datastores can't > reference each other, these are not normal datastores. To underscore > this, if I2RS selects RESTCONF, NETCONF's datastores are no longer > relevant. In fact, the term "datastore" may be tripping us up, perhaps we > call it an "overlay" ;) I think it is important that tools do not have to hack the path-expr in the Location URI of I2RS data when it is created. /restconf/data/foo/bar=1?datastore=datastore-name This approach allows the URI for the resource to be the same in all datastores, without the need to parse and patch the URI to access each datastore. Overlay implies patch or delta from the running config. > > So Section 7.2 of draft-haas-i2rs-ephemeral-state-reqs-00 describes > disadvantages to the overlay approach, namely complexity and consistency > issues. Neither of which I fully understand. The overlay approach was > discussed on list last September and again in October. It actually seemed > to have a lot of support, albeit some minor issues, but they don't seemed > nearly as bad as issues discussed in other proposals to date. > > My proposal is to revisit the overlay approach again, defining the > necessary rules as needed. Taking a step into design, I propose not just > one overlay, but N overlays for N priorities as follows: > > - each client has an assigned priority > - each overlay has an assigned priority > - clients can read lower priority overlays, but not higher priority > overlays > - each client writes into the overlay of matching priority (no > exceptions) > I agree with Joel that the requirements as written exclude this approach. IMO it would be better to understand how running-config and ephemeral-config interact to form operational state. The derivative case are these 2 panes. It makes a big difference whether the ephemeral pane contains a patch or a copy of the running config. module foo { leaf enable-foo { description "Enables some routing feature"; type boolean; default true; } container foo { config false; i2rs:ephemeral true; when "/enable-foo"; ... } } Does the 'enable-foo' leaf exist in the ephemeral datastore? There seems to be 2 approaches: 1) overlay - the when-stmt context for ephemeral is ephemeral first, and then config - any data in the running config but not in the overlay is visible 2) mirror - ephemeral starts as copy of running - data changed in running may or may not be automatically visible in ephemeral (could be operator selected) - when-stmt applies to the ephemeral datastore only What happens if the 'enable-foo' leaf gets deleted from the ephemeral datastore? According to YANG, the default of 'true' would be in effect. But this is not the desired behavior for an overlay model. The value in the running config is supposed to go into affect, not the default value in the ephemeral config. It seems that a client needs to include all the data related to an edit so it will be tagged with the correct priority. E.g., the caline needs to set 'enable-foo' even if it has the desired value already, to make sure a lower priority client cannot change it. Andy > - the system calculates the effective configuration using this algorithm: > > initialize accumulation buffer with NV-config > for priority from lowest to highest: > merge into accumulation buffer overlay[priority] > assert conceptual `validate` on accumulation buffer succeeds > > Where the merge operation includes the following rules: > - merging a scalar value overwrites lower-priority values > - merging an ordered-by user list entry causes the entry goes to > The beginning of the list (this assumes an ordering semantic, a > YANG annotation may be needed to indicate directionality) > - it is not possible to simply delete a lower-priority value > > And client interactions with an overlay includes the following rules: > - any update (including on NV config) that might cause the > conceptual `validate` on the accumulation buffer to fail has > the effect of necessary config to be first *copied* into the > higher-priority overlay. > > The primary advantages to having multiple overlays are > - priority doesn't need to be stored per leaf > - issues around how lower priority client updates interact > with higher priority config disappear. > > > One problem with the approach of having multiple overlays (as oppose to > just one) is that it has the consequence of re-exposing a lower-priority > value when a higher-priority value is removed...unless we insist that > writing higher-priority value wipes out matching lower-priority value (not > including NV-config, of course). What's unnerving about re-exposing a > lower-priority ephemeral value is that one might argue why the system > didn't instead restore an ephemeral value from a client with the same > priority instead. I assume that two clients of equal priority would have > their own way of resolving it, or else I2RS disallows clients having equal > priorities... > > > Thanks, > Kent > > > > > > On 5/26/15, 12:40 PM, "Jeffrey Haas" wrote: > >>Working Group, >> >>The following document is a straw-man document attempting to document >>changes necessary to implement I2RS's ephemeral state needs. >> >>This document has already gotten some discussion off-list with several of >>the usual contributors to the netmod and netconf Working Groups as an >>attempt to gain some early traction in the discussion. While that >>discussion has been energetic, it hasn't achieved any further consensus >>from >>the contents posted herein. >> >>I would like to request that further discussion related to this draft take >>place on the mailing list. >> >>This draft will be a topic for tomorrow's virtual interim. My apologies >>for >>not posting this more promptly. >> >>-- Jeff >> >>----- Forwarded message from internet-drafts@ietf.org ----- >> >>Date: Tue, 26 May 2015 12:14:57 -0700 >>From: internet-drafts@ietf.org >>To: i-d-announce@ietf.org >>Subject: I-D Action: draft-haas-i2rs-ephemeral-state-reqs-00.txt >> >> >>A New Internet-Draft is available from the on-line Internet-Drafts >>directories. >> >> >> Title : I2RS Ephemeral State Requirements >> Author : Jeffrey Haas >> Filename : draft-haas-i2rs-ephemeral-state-reqs-00.txt >> Pages : 9 >> Date : 2015-05-26 >> >>Abstract: >> This document covers requests to the netmod and netconf Working >> Groups for functionality to support the ephemeral state requirements >> to implement the I2RS architecture. >> >> >>The IETF datatracker status page for this draft is: >>https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs/ >> >>There's also a htmlized version available at: >>https://tools.ietf.org/html/draft-haas-i2rs-ephemeral-state-reqs-00 >> >> >>Please note that it may take a couple of minutes from the time of >>submission >>until the htmlized version and diff are available at tools.ietf.org. >> >>Internet-Drafts are also available by anonymous FTP at: >>ftp://ftp.ietf.org/internet-drafts/ >> >>_______________________________________________ >>I-D-Announce mailing list >>I-D-Announce@ietf.org >>https://www.ietf.org/mailman/listinfo/i-d-announce >>Internet-Draft directories: http://www.ietf.org/shadow.html >>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >>----- End forwarded message ----- >> >>_______________________________________________ >>i2rs mailing list >>i2rs@ietf.org >>https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 27 11: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 074481A1E0B for ; Wed, 27 May 2015 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEqt-j6KqjOd for ; Wed, 27 May 2015 11:52:44 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B9ECC1A8A7B for ; Wed, 27 May 2015 11:52:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.96; From: "Susan Hares" To: Date: Wed, 27 May 2015 14:52:39 -0400 Message-ID: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011F_01D0988C.C719BAE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCYp/XZYn6klBbfTwuT6Jmk03NtNA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' Subject: [i2rs] draft-chen-i2rs-identifier-management-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, 27 May 2015 18:52:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011F_01D0988C.C719BAE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ran I appreciate you taking the time to present your draft at the i2RS interim. Your draft suggests: When the I2RS session is opened, An I2RS Client should advertise to an I2RS Agent that the I2RS Client's identifier and priority. The I2RS Client's identifier and priority should be managed by the I2RS Agent, and associated with its I2RS session. It was an important contrast to the existing assumption which Joel pointed out - that I2RS authentication is done outside of the I2RS protocol. This is the agreed upon position in the I2RS architecture document. The I2RS architecture has proposed that the other authentication protocols (For Example AAA's Radius or Diameter) would establish the identity outside the I2RS protocol. Most routing people have AAA protocols to establish identity for other purposes. The priority would be associated with the client identity and stored by the I2RS agent per client. Your draft provides another alternative the WG should hear during its deliberation process. It could be done outside the I2RS protocol as a simple authentication scheme. As a WG chair, I appreciate your willingness to bring an alternate proposal to our current thoughts to help us keep nimble in our thinking. During the next 2 weeks, I hope you will continue to actively participate in the authentication and identity discussion. Joel's comments were: . We already have an identity establishing mechanism between the client-agent. It is the AAA authentication. If we introduce into the I2RS protocol any in-protocol portion fo identity, we make our lives harder . [Ran]: Could you expand upon the question and concepts? . [joel]: If you look at the I2RS mutual authentication in AAA, it is a identity that other people understand. The client -agent authentication in the out-protocol use is what people understand. . [Ran]: netconf/restconf have authentication, but it only includes identity. It does not include the priority. We can also modify priority. . [Joel]: Let me step back into your draft for a moment. You have a constraint on the format of Identity and the mappings between identity to implementation format. We had that debate, and decided these implementation mappings are an implementation format. . [Joel]: Let me return to priority, the NACM (as defined in Jeff's draft) will give us priority associated with a client. We do not need new mechanism. . [Ran]: Is this a requirement in the architecture or a restatement from the WG discussion? . [Sue]: Restatement of the WG discussion on NACM. The implementation mapping should be implied in the architecture document. However we are grateful for your question that makes this clearer. . [Alia]: We choose this direction to maximize re-use of existing protocols and mechanism for the first release of the I2RS protocol. . [Sue]: Is Client priority store in the agent per node? How does it occur? . [Jeff]: It is stored in the NACM for client, and the client identity is tagged to a node (E.g. per route). This further implies that priority is an attribute that is stored in the NETCONF Access Control Model [RFC6536 ] as part of a rule-list. E.g.: +--rw rule-list [name] +--rw name string +--rw group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(protocol-operation) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(data-node) | +--rw path node-instance-identifier +--rw access-operations? union +--rw action action-type +--rw comment? string +--rw i2rs:i2rs-priority i2rs-priority-type People may respond to this post with other discussion points on the identity and secondary identity. Sue ------=_NextPart_000_011F_01D0988C.C719BAE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ran

 

I appreciate = you taking the time to present your draft at the i2RS interim.  = Your draft suggests:

 

When the = I2RS session is opened, An I2RS Client should advertise = to

   an I2RS Agent that = the I2RS Client's identifier and priority.  The

   I2RS Client's identifier and priority = should be managed by the I2RS

   Agent, and associated with its I2RS = session.

 

It was an important contrast to the existing = assumption which Joel pointed out – that I2RS authentication is = done outside of the I2RS protocol.  This is the agreed upon = position in the I2RS architecture document.

 

The I2RS = architecture has proposed that the other authentication protocols (For = Example AAA’s Radius or Diameter) would establish the identity = outside the I2RS protocol.  Most routing people have AAA protocols = to establish identity for other purposes.  The priority would be = associated with the client identity and stored by the I2RS agent per = client.

 

Your draft provides another alternative the WG should = hear during its deliberation process.  It could be done outside the = I2RS protocol as a simple authentication scheme.  As a WG chair, I = appreciate your willingness to bring an alternate proposal to our = current thoughts to help us keep nimble in our thinking. =   During the next 2 weeks, I hope you will continue to = actively participate in the authentication and identity discussion. =

 

Joel’s comments were:

·         = We already have an identity establishing = mechanism between the client-agent. It is the AAA authentication. If we = introduce into the I2RS protocol any in-protocol portion fo identity, we = make our lives harder

·         = [Ran]: Could you expand upon the question = and concepts?

·         = [joel]: If you look at the I2RS mutual = authentication in AAA, it is a identity that other people understand. = The client –agent authentication in the out-protocol use is what = people understand.

·         = [Ran]: netconf/restconf have = authentication, but it only includes identity. It does not include the = priority.  We can also modify priority.

·         = [Joel]: Let me step back into your draft = for a moment.  You have a constraint on the format of Identity and = the mappings between identity to implementation format.  We had = that debate, and decided these implementation mappings are an = implementation format.

·         = [Joel]: Let me return to priority, the = NACM (as defined in Jeff’s draft) will give us priority associated = with a client.  We do not need new mechanism.

·         = [Ran]: Is this a requirement in the = architecture or a restatement from the WG discussion?

·         = [Sue]: Restatement of the WG discussion = on NACM.   The implementation mapping should be implied in the = architecture document.  However we are grateful for your question = that makes this clearer.

·         = [Alia]: We choose this direction to = maximize re-use of existing protocols and mechanism for the first = release of the I2RS protocol.

·         = [Sue]: Is Client priority store in the = agent per node? How does it occur?

·         = [Jeff]: It is stored in the NACM for = client, and the client identity is tagged to a node (E.g. per route). =  

 

This =
further implies that priority is an attribute that is stored =
in
   the NETCONF Access Control Model [RFC6536] as part of a =
rule-list.
   E.g.:

 

 

   +--rw rule-list = [name]

      +--rw = name     string

      +--rw = group*   union

      +--rw rule = [name]

         +--rw = name string

         +--rw = module-name?  union

         +--rw = (rule-type)?

         = |  +--:(protocol-operation)

         = |  |  +--rw rpc-name?  union

         = |  +--:(notification)

         = |  |  +--rw notification-name?  = union

         = |  +--:(data-node)

         = |     +--rw path = node-instance-identifier

         +--rw = access-operations?  union

         +--rw = action action-type

         +--rw = comment?  string

         +--rw = i2rs:i2rs-priority i2rs-priority-type

 

 

=  People may respond to this post with other discussion points on = the identity and secondary identity.

 

Sue =

------=_NextPart_000_011F_01D0988C.C719BAE0-- From nobody Wed May 27 12:59:25 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9361A908D for ; Wed, 27 May 2015 12:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnOMsqAd-kUo for ; Wed, 27 May 2015 12:59:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 607481A9082 for ; Wed, 27 May 2015 12:59:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.96; From: "Susan Hares" To: , "'Joel M. Halpern'" References: In-Reply-To: Date: Wed, 27 May 2015 15:59:12 -0400 Message-ID: <018601d098b7$9a51e5c0$cef5b140$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01D09896.13466040" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhlDvfs38NnK5WMTHm6i2/B5W1vZxuRXWA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 27 May 2015 19:59:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0187_01D09896.13466040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ran and Joel: Joel dropped me a note indicating two points on my message to you was unclear. . The WG has made a decision to have mutual authentication for client and agent done outside the I2RS protocol, . One example of an out-of-protocol work is AAA. In our discussions, most people indicated that a AAA protocol (diameter and radius) would be used. It is not mandatory to use these. . NACM is being proposed to link client ID (by Jeff's draft). At this point, any contribution to the I2RS requirements should discuss the pros/cons of the existing proposals. Joel - please let me know if I am clear enough on the draft. Sue From: Susan Hares [mailto:shares@ndzh.com] Sent: Wednesday, May 27, 2015 2:53 PM To: 'chen.ran@zte.com.cn' Cc: 'Alia Atlas'; 'i2rs@ietf.org'; 'Jeffrey Haas' Subject: draft-chen-i2rs-identifier-management-00 Ran I appreciate you taking the time to present your draft at the i2RS interim. Your draft suggests: When the I2RS session is opened, An I2RS Client should advertise to an I2RS Agent that the I2RS Client's identifier and priority. The I2RS Client's identifier and priority should be managed by the I2RS Agent, and associated with its I2RS session. It was an important contrast to the existing assumption which Joel pointed out - that I2RS authentication is done outside of the I2RS protocol. This is the agreed upon position in the I2RS architecture document. The I2RS architecture has proposed that the other authentication protocols (For Example AAA's Radius or Diameter) would establish the identity outside the I2RS protocol. Most routing people have AAA protocols to establish identity for other purposes. The priority would be associated with the client identity and stored by the I2RS agent per client. Your draft provides another alternative the WG should hear during its deliberation process. It could be done outside the I2RS protocol as a simple authentication scheme. As a WG chair, I appreciate your willingness to bring an alternate proposal to our current thoughts to help us keep nimble in our thinking. During the next 2 weeks, I hope you will continue to actively participate in the authentication and identity discussion. Joel's comments were: . We already have an identity establishing mechanism between the client-agent. It is the AAA authentication. If we introduce into the I2RS protocol any in-protocol portion fo identity, we make our lives harder . [Ran]: Could you expand upon the question and concepts? . [joel]: If you look at the I2RS mutual authentication in AAA, it is a identity that other people understand. The client -agent authentication in the out-protocol use is what people understand. . [Ran]: netconf/restconf have authentication, but it only includes identity. It does not include the priority. We can also modify priority. . [Joel]: Let me step back into your draft for a moment. You have a constraint on the format of Identity and the mappings between identity to implementation format. We had that debate, and decided these implementation mappings are an implementation format. . [Joel]: Let me return to priority, the NACM (as defined in Jeff's draft) will give us priority associated with a client. We do not need new mechanism. . [Ran]: Is this a requirement in the architecture or a restatement from the WG discussion? . [Sue]: Restatement of the WG discussion on NACM. The implementation mapping should be implied in the architecture document. However we are grateful for your question that makes this clearer. . [Alia]: We choose this direction to maximize re-use of existing protocols and mechanism for the first release of the I2RS protocol. . [Sue]: Is Client priority store in the agent per node? How does it occur? . [Jeff]: It is stored in the NACM for client, and the client identity is tagged to a node (E.g. per route). This further implies that priority is an attribute that is stored in the NETCONF Access Control Model [RFC6536 ] as part of a rule-list. E.g.: +--rw rule-list [name] +--rw name string +--rw group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(protocol-operation) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(data-node) | +--rw path node-instance-identifier +--rw access-operations? union +--rw action action-type +--rw comment? string +--rw i2rs:i2rs-priority i2rs-priority-type People may respond to this post with other discussion points on the identity and secondary identity. Sue ------=_NextPart_000_0187_01D09896.13466040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ran and Joel:

 

Joel dropped me a note = indicating two points on my message to you was unclear. =

 

·         = The WG has = made a decision to have mutual authentication for client and agent done = outside the I2RS protocol,

·         = One example = of an out-of-protocol work is AAA.  In our discussions, most people = indicated that a AAA protocol (diameter and radius) would be used.  = It is not mandatory to use these.

·         = NACM is = being proposed to link client ID (by Jeff’s draft). =

 

At this point, any = contribution to the I2RS requirements should discuss the pros/cons of = the existing proposals.

 

Joel – please let = me know if I am clear enough on the draft.

 

Sue =

 

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Wednesday, May 27, = 2015 2:53 PM
To: 'chen.ran@zte.com.cn'
Cc: 'Alia = Atlas'; 'i2rs@ietf.org'; 'Jeffrey Haas'
Subject: = draft-chen-i2rs-identifier-management-00

 

Ran

 

I appreciate = you taking the time to present your draft at the i2RS interim.  = Your draft suggests:

 

When the = I2RS session is opened, An I2RS Client should advertise = to

   an I2RS Agent that = the I2RS Client's identifier and priority.  The

   I2RS Client's identifier and priority = should be managed by the I2RS

   Agent, and associated with its I2RS = session.

 

It was an important contrast to the existing = assumption which Joel pointed out – that I2RS authentication is = done outside of the I2RS protocol.  This is the agreed upon = position in the I2RS architecture document.

 

The I2RS = architecture has proposed that the other authentication protocols (For = Example AAA’s Radius or Diameter) would establish the identity = outside the I2RS protocol.  Most routing people have AAA protocols = to establish identity for other purposes.  The priority would be = associated with the client identity and stored by the I2RS agent per = client.

 

Your draft provides another alternative the WG should = hear during its deliberation process.  It could be done outside the = I2RS protocol as a simple authentication scheme.  As a WG chair, I = appreciate your willingness to bring an alternate proposal to our = current thoughts to help us keep nimble in our thinking. =   During the next 2 weeks, I hope you will continue to = actively participate in the authentication and identity discussion. =

 

Joel’s comments were:

·         = We already have an identity establishing = mechanism between the client-agent. It is the AAA authentication. If we = introduce into the I2RS protocol any in-protocol portion fo identity, we = make our lives harder

·         = [Ran]: Could you expand upon the question = and concepts?

·         = [joel]: If you look at the I2RS mutual = authentication in AAA, it is a identity that other people understand. = The client –agent authentication in the out-protocol use is what = people understand.

·         = [Ran]: netconf/restconf have = authentication, but it only includes identity. It does not include the = priority.  We can also modify priority.

·         = [Joel]: Let me step back into your draft = for a moment.  You have a constraint on the format of Identity and = the mappings between identity to implementation format.  We had = that debate, and decided these implementation mappings are an = implementation format.

·         = [Joel]: Let me return to priority, the = NACM (as defined in Jeff’s draft) will give us priority associated = with a client.  We do not need new mechanism.

·         = [Ran]: Is this a requirement in the = architecture or a restatement from the WG discussion?

·         = [Sue]: Restatement of the WG discussion = on NACM.   The implementation mapping should be implied in the = architecture document.  However we are grateful for your question = that makes this clearer.

·         = [Alia]: We choose this direction to = maximize re-use of existing protocols and mechanism for the first = release of the I2RS protocol.

·         = [Sue]: Is Client priority store in the = agent per node? How does it occur?

·         = [Jeff]: It is stored in the NACM for = client, and the client identity is tagged to a node (E.g. per route). =  

 

This =
further implies that priority is an attribute that is stored =
in
   the NETCONF Access Control Model [RFC6536] as part of a =
rule-list.
   E.g.:

 

 

   +--rw rule-list = [name]

      +--rw = name     string

      +--rw = group*   union

      +--rw rule = [name]

         +--rw = name string

         +--rw = module-name?  union

         +--rw = (rule-type)?

         = |  +--:(protocol-operation)

         = |  |  +--rw rpc-name?  union

         = |  +--:(notification)

         = |  |  +--rw notification-name?  = union

         = |  +--:(data-node)

         = |     +--rw path = node-instance-identifier

         +--rw = access-operations?  union

         +--rw = action action-type

         +--rw = comment?  string

         +--rw = i2rs:i2rs-priority i2rs-priority-type

 

 

 People = may respond to this post with other discussion points on the identity = and secondary identity.

 

Sue =

------=_NextPart_000_0187_01D09896.13466040-- From nobody Wed May 27 15:09: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 87F451ACD1E for ; Wed, 27 May 2015 15:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKkf0yel9gbd for ; Wed, 27 May 2015 15:09:08 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3D281A8BB1 for ; Wed, 27 May 2015 15:09:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 902F21207; Thu, 28 May 2015 00:09:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QqDlxXZFq4Oa; Thu, 28 May 2015 00:08:58 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 May 2015 00:09:05 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5326D2002C; Thu, 28 May 2015 00:09:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mGXJ4Hq8f-Tn; Thu, 28 May 2015 00:09:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 889292002B; Thu, 28 May 2015 00:09:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B7EDC33AB0F2; Thu, 28 May 2015 00:09:02 +0200 (CEST) Date: Thu, 28 May 2015 00:09:01 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150527220901.GA67473@elstar.local> Mail-Followup-To: Susan Hares , chen.ran@zte.com.cn, 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, chen.ran@zte.com.cn, 'Alia Atlas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Wed, 27 May 2015 22:09:10 -0000 On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote: [discussion about priority] > . [Jeff]: It is stored in the NACM for client, and the client > identity is tagged to a node (E.g. per route). > > > This further implies that priority is an attribute that is stored in > the NETCONF Access Control Model [RFC6536 > ] as part of a rule-list. > E.g.: > > > > +--rw rule-list [name] > > +--rw name string > > +--rw group* union > > +--rw rule [name] > > +--rw name string > > +--rw module-name? union > > +--rw (rule-type)? > > | +--:(protocol-operation) > > | | +--rw rpc-name? union > > | +--:(notification) > > | | +--rw notification-name? union > > | +--:(data-node) > > | +--rw path node-instance-identifier > > +--rw access-operations? union > > +--rw action action-type > > +--rw comment? string > > +--rw i2rs:i2rs-priority i2rs-priority-type > I am confused since sometimes it sounds like the priority is a property of an I2RS client and yet at other times it sounds like the priority is associated with a scope accessible for an I2RS client. If I understand Jeff correctly, then he proposes that a data node remembers the identity of the I2RS client that created / last modified it and the priority is obtained at the time a confict needs to be resolved (and hence the priority may be different from the priority that was in effect when the data node was created / last modified). Note that NETCONF/RESTCONF so far allows every client with proper access rights to modify data nodes. There is no notion of ownership in the sense that if something got written by A then B cannot update it unless B has higher priority. If A and B have the same priority (which is so far always the case), then the last write wins. The I2RS architecture document, however, requires that the first write blocks any subsequent writes: remains in effect. In the case of priority ties, the first client whose attribution is associated with the data will keep control. If NETCONF/RESTCONF gets extended with ownership and priorities, I think it would be desirable if the current behaviour (where all clients have the same priority) would still fall out naturally. /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 Wed May 27 16:35: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 92B021B2AC6 for ; Wed, 27 May 2015 16:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tloQFhUEe5CR for ; Wed, 27 May 2015 16:35:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5D41B2AC4 for ; Wed, 27 May 2015 16:35:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C82272410FB; Wed, 27 May 2015 16:35:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 224F024033F; Wed, 27 May 2015 16:35:11 -0700 (PDT) Message-ID: <556654AB.9030206@joelhalpern.com> Date: Wed, 27 May 2015 19:35:07 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , chen.ran@zte.com.cn, 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> In-Reply-To: <20150527220901.GA67473@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 27 May 2015 23:35:18 -0000 I believe that most of us expect that in I2rs: Priority is associated with a client. A client does not get to change its priority (although adminsitrators clearly can). When a client performs an operation, the client identity and priority are recorded both for traceability and for future comparison. If a later action attempts to modify the same item, the acting client identity and priority are compared with the stored values. (While I read the architecture as saying that, I could be too close to the document.) Yours, Joel On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote: > On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote: > > [discussion about priority] > >> . [Jeff]: It is stored in the NACM for client, and the client >> identity is tagged to a node (E.g. per route). >> >> >> This further implies that priority is an attribute that is stored in >> the NETCONF Access Control Model [RFC6536 >> ] as part of a rule-list. >> E.g.: >> >> >> >> +--rw rule-list [name] >> >> +--rw name string >> >> +--rw group* union >> >> +--rw rule [name] >> >> +--rw name string >> >> +--rw module-name? union >> >> +--rw (rule-type)? >> >> | +--:(protocol-operation) >> >> | | +--rw rpc-name? union >> >> | +--:(notification) >> >> | | +--rw notification-name? union >> >> | +--:(data-node) >> >> | +--rw path node-instance-identifier >> >> +--rw access-operations? union >> >> +--rw action action-type >> >> +--rw comment? string >> >> +--rw i2rs:i2rs-priority i2rs-priority-type >> > > I am confused since sometimes it sounds like the priority is a > property of an I2RS client and yet at other times it sounds like the > priority is associated with a scope accessible for an I2RS client. > > If I understand Jeff correctly, then he proposes that a data node > remembers the identity of the I2RS client that created / last modified > it and the priority is obtained at the time a confict needs to be > resolved (and hence the priority may be different from the priority > that was in effect when the data node was created / last modified). > > Note that NETCONF/RESTCONF so far allows every client with proper > access rights to modify data nodes. There is no notion of ownership in > the sense that if something got written by A then B cannot update it > unless B has higher priority. If A and B have the same priority (which > is so far always the case), then the last write wins. The I2RS > architecture document, however, requires that the first write blocks > any subsequent writes: > > remains in effect. In the case of priority ties, the first client > whose attribution is associated with the data will keep control. > > If NETCONF/RESTCONF gets extended with ownership and priorities, I > think it would be desirable if the current behaviour (where all > clients have the same priority) would still fall out naturally. > > /js > From nobody Wed May 27 18:05:03 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B667C1B2AB2 for ; Wed, 27 May 2015 18:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT3feNglCp_W for ; Wed, 27 May 2015 18:05:00 -0700 (PDT) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (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 DC2BE1A8A3B for ; Wed, 27 May 2015 18:04:59 -0700 (PDT) Received: by labko7 with SMTP id ko7so16394123lab.2 for ; Wed, 27 May 2015 18:04:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4/np03zC7jYweCnhj0KiktIfW/W0aXwJqufqrG5J9zE=; b=leFXJjypWybKnGeKVL82W/sv9JiwmB4AaVv0WS7d+TfaE77vERnTk2nKAjZgmFwgGO Eqn1Vnc5sSvOkZa3f9CYcPYgVyzPJw6e0C9K6S4M83UHM2d/832t6Ote+TwVPbjwtywR BZ78seFGT0C+tIawa5bc3Vh8W7Po6B6jOJ3KZOBzTsEq1byC2ywrRGn5CFYmyfQXpXPZ dJ1pUHUZaEaNY50o7VU4JKrlorkShnvIxxFT+S4N70zgoBshL+67OCRo051SvPS8qi64 J3oxIEVPWMwxV3bI0IGLB0y1ecB/lSOGsYazGrqNq1r/RGpeFmrpRYhubZzlNoej7WQv k78g== X-Gm-Message-State: ALoCoQnpLcZV2w9QobveORBOwBd3xDRJA6ZtUzWjJqNBDgEwCEmsookoVoA/rFe1T2TwaGaoX8ow MIME-Version: 1.0 X-Received: by 10.112.124.71 with SMTP id mg7mr182316lbb.38.1432775098119; Wed, 27 May 2015 18:04:58 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 27 May 2015 18:04:58 -0700 (PDT) In-Reply-To: <556654AB.9030206@joelhalpern.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> Date: Wed, 27 May 2015 18:04:58 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , chen.ran@zte.com.cn, Alia Atlas , Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 01:05:02 -0000 On Wed, May 27, 2015 at 4:35 PM, Joel M. Halpern wrote: > I believe that most of us expect that in I2rs: > Priority is associated with a client. > A client does not get to change its priority (although adminsitrators > clearly can). > When a client performs an operation, the client identity and priority are > recorded both for traceability and for future comparison. > If a later action attempts to modify the same item, the acting client > identity and priority are compared with the stored values. > > (While I read the architecture as saying that, I could be too close to the > document.) > Sounds right to me. Jeff suggested in the conf-call that the i2rs-priority can be moved to the 'group' list. (I prefer the term 'client-priority'). Although I should be promoting use of NACM, I am not so sure it should be mandatory for I2RS or required to configure I2RS client priority. list i2rs-client { key name; leaf name { description "The client name"; type i2rs:client-name; } leaf priority { description "The priority value assigned to this client."; type i2rs:client-priority; } } I think I2RS interaction with NACM needs to be clearly defined. NACM implementations do not currently check write requests on config=false data. It is possible some edits to NACM are needed even if no objects are added to the data structure. In either case there is the issue of what happens to existing data if the client priority is changed by the administrator. Does it keep the old priority or change to the new priority? > Yours, > Joel Andy > > On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote: >> >> On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote: >> >> [discussion about priority] >> >>> . [Jeff]: It is stored in the NACM for client, and the client >>> identity is tagged to a node (E.g. per route). >>> >>> >>> This further implies that priority is an attribute that is stored in >>> the NETCONF Access Control Model [RFC6536 >>> ] as part of a rule-list. >>> E.g.: >>> >>> >>> >>> +--rw rule-list [name] >>> >>> +--rw name string >>> >>> +--rw group* union >>> >>> +--rw rule [name] >>> >>> +--rw name string >>> >>> +--rw module-name? union >>> >>> +--rw (rule-type)? >>> >>> | +--:(protocol-operation) >>> >>> | | +--rw rpc-name? union >>> >>> | +--:(notification) >>> >>> | | +--rw notification-name? union >>> >>> | +--:(data-node) >>> >>> | +--rw path node-instance-identifier >>> >>> +--rw access-operations? union >>> >>> +--rw action action-type >>> >>> +--rw comment? string >>> >>> +--rw i2rs:i2rs-priority i2rs-priority-type >>> >> >> I am confused since sometimes it sounds like the priority is a >> property of an I2RS client and yet at other times it sounds like the >> priority is associated with a scope accessible for an I2RS client. >> >> If I understand Jeff correctly, then he proposes that a data node >> remembers the identity of the I2RS client that created / last modified >> it and the priority is obtained at the time a confict needs to be >> resolved (and hence the priority may be different from the priority >> that was in effect when the data node was created / last modified). >> >> Note that NETCONF/RESTCONF so far allows every client with proper >> access rights to modify data nodes. There is no notion of ownership in >> the sense that if something got written by A then B cannot update it >> unless B has higher priority. If A and B have the same priority (which >> is so far always the case), then the last write wins. The I2RS >> architecture document, however, requires that the first write blocks >> any subsequent writes: >> >> remains in effect. In the case of priority ties, the first client >> whose attribution is associated with the data will keep control. >> >> If NETCONF/RESTCONF gets extended with ownership and priorities, I >> think it would be desirable if the current behaviour (where all >> clients have the same priority) would still fall out naturally. >> >> /js >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed May 27 23:05: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 A129C1A0273 for ; Wed, 27 May 2015 23:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pL67VVPmp60w for ; Wed, 27 May 2015 23:05:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C5D1A01F4 for ; Wed, 27 May 2015 23:05:09 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8E9412F7; Thu, 28 May 2015 08:05:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kOvwskvQQuTn; Thu, 28 May 2015 08:04:57 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 28 May 2015 08:05:05 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 343A520038; Thu, 28 May 2015 08:05:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DypJ7h8FspoW; Thu, 28 May 2015 08:05:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 896CF20045; Thu, 28 May 2015 08:05:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CFF1233AB4DE; Thu, 28 May 2015 08:05:02 +0200 (CEST) Date: Thu, 28 May 2015 08:05:02 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150528060502.GA68091@elstar.local> Mail-Followup-To: Andy Bierman , "Joel M. Halpern" , Jeffrey Haas , "i2rs@ietf.org" , chen.ran@zte.com.cn, Alia Atlas , Susan Hares References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> 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: "i2rs@ietf.org" , chen.ran@zte.com.cn, Alia Atlas , Jeffrey Haas , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Thu, 28 May 2015 06:05:11 -0000 On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: > > Although I should be promoting use of NACM, I am not so sure it should > be mandatory for I2RS or required to configure I2RS client priority. > > list i2rs-client { > key name; > leaf name { > description "The client name"; > type i2rs:client-name; > } > leaf priority { > description "The priority value assigned to this client."; > type i2rs:client-priority; > } > } So what is i2rs:client-name - is it any different from a NETCONF/RESTCONF username? NACM maps user names into groups and NACM allows to have the mapping supplied by an external source (e.g. RADIUS). If this priority mapping is kept separate from NACM, would we need to provision means to get the priority from AAA as well? And the bigger question: Do we create something specific for I2RS or are we going to extend the generic YANG/NC/RC framework to provide the tools I2RS needs? This is probably a question the NETCONF WG has to answer. /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 Thu May 28 02:20:02 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732051A0203 for ; Thu, 28 May 2015 02:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZcuDcbdhDll for ; Thu, 28 May 2015 02:19:59 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 82FB21A01BA for ; Thu, 28 May 2015 02:19:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Joel M. Halpern'" , , "'Jeffrey Haas'" , , "'Alia Atlas'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> In-Reply-To: <556654AB.9030206@joelhalpern.com> Date: Thu, 28 May 2015 05:19:50 -0400 Message-ID: <005901d09927$73ad35d0$5b07a170$@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: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOCd92GxIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 09:20:01 -0000 Joel and Juergen: This is my understanding as well. When a client performs an operation, the client identity (primary and secondary) and priority are recorded on the object (E.g. Route for traceability and for future comparison). If later actions change the attempt to change the object, only clients identities (primary and secondary) with greater priority can change it. You are correct that this means the first write wins in I2RS architecture. Alia remembers this was discussed on the list and in I2RS sessions. Jeff's proposal is that all actions by a client identity have the same priority, and that a client identity in a Transport connection cannot change priority. This is a good starting point. However, in the discussion in the interim session - Alia indicated that the client with multiple Transport connections might have different priorities for the different sessions. Alia - did I understand you correctly? Sue Hares -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, May 27, 2015 7:35 PM To: Susan Hares; chen.ran@zte.com.cn; 'Jeffrey Haas'; i2rs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 I believe that most of us expect that in I2rs: Priority is associated with a client. A client does not get to change its priority (although adminsitrators clearly can). When a client performs an operation, the client identity and priority are recorded both for traceability and for future comparison. If a later action attempts to modify the same item, the acting client identity and priority are compared with the stored values. (While I read the architecture as saying that, I could be too close to the document.) Yours, Joel On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote: > On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote: > > [discussion about priority] > >> . [Jeff]: It is stored in the NACM for client, and the client >> identity is tagged to a node (E.g. per route). >> >> >> This further implies that priority is an attribute that is stored in >> the NETCONF Access Control Model [RFC6536 >> ] as part of a rule-list. >> E.g.: >> >> >> >> +--rw rule-list [name] >> >> +--rw name string >> >> +--rw group* union >> >> +--rw rule [name] >> >> +--rw name string >> >> +--rw module-name? union >> >> +--rw (rule-type)? >> >> | +--:(protocol-operation) >> >> | | +--rw rpc-name? union >> >> | +--:(notification) >> >> | | +--rw notification-name? union >> >> | +--:(data-node) >> >> | +--rw path node-instance-identifier >> >> +--rw access-operations? union >> >> +--rw action action-type >> >> +--rw comment? string >> >> +--rw i2rs:i2rs-priority i2rs-priority-type >> > > I am confused since sometimes it sounds like the priority is a > property of an I2RS client and yet at other times it sounds like the > priority is associated with a scope accessible for an I2RS client. > > If I understand Jeff correctly, then he proposes that a data node > remembers the identity of the I2RS client that created / last modified > it and the priority is obtained at the time a confict needs to be > resolved (and hence the priority may be different from the priority > that was in effect when the data node was created / last modified). > > Note that NETCONF/RESTCONF so far allows every client with proper > access rights to modify data nodes. There is no notion of ownership in > the sense that if something got written by A then B cannot update it > unless B has higher priority. If A and B have the same priority (which > is so far always the case), then the last write wins. The I2RS > architecture document, however, requires that the first write blocks > any subsequent writes: > > remains in effect. In the case of priority ties, the first client > whose attribution is associated with the data will keep control. > > If NETCONF/RESTCONF gets extended with ownership and priorities, I > think it would be desirable if the current behaviour (where all > clients have the same priority) would still fall out naturally. > > /js > From nobody Thu May 28 03:19: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 DDFFD1A6FCB for ; Thu, 28 May 2015 03:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jePWkfQdd-Pi for ; Thu, 28 May 2015 03:19:56 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350771A6FFB for ; Thu, 28 May 2015 03:19:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id B4EE3250F50; Thu, 28 May 2015 03:19:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id EC54E240673; Thu, 28 May 2015 03:19:54 -0700 (PDT) Message-ID: <5566EBC4.2030809@joelhalpern.com> Date: Thu, 28 May 2015 06:19:48 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , chen.ran@zte.com.cn, 'Jeffrey Haas' , i2rs@ietf.org, 'Alia Atlas' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <005901d09927$73ad35d0$5b07a170$@ndzh.com> In-Reply-To: <005901d09927$73ad35d0$5b07a170$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 10:19:58 -0000 I believe the point of Alia's comment was that something that is actually one client could behave as if it is multiple clients. It could have multiple identities it can authenticate. Each of those could be used with different connections. From the point of view of I2RS this is multiple clients. From the point of view of the software, it is a single client with multiple prioritieis. This is a fairly typical implementation tchnique that keeps protocol simple, while allowing flexible operation. Yours, Joel On 5/28/15 5:19 AM, Susan Hares wrote: > Joel and Juergen: > > This is my understanding as well. When a client performs an operation, the > client identity (primary and secondary) and priority are recorded on the > object (E.g. Route for traceability and for future comparison). If later > actions change the attempt to change the object, only clients identities > (primary and secondary) with greater priority can change it. You are > correct that this means the first write wins in I2RS architecture. Alia > remembers this was discussed on the list and in I2RS sessions. > > Jeff's proposal is that all actions by a client identity have the same > priority, and that a client identity in a Transport connection cannot change > priority. This is a good starting point. > > However, in the discussion in the interim session - Alia indicated that the > client with multiple Transport connections might have different priorities > for the different sessions. Alia - did I understand you correctly? > > Sue Hares > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Wednesday, May 27, 2015 7:35 PM > To: Susan Hares; chen.ran@zte.com.cn; 'Jeffrey Haas'; i2rs@ietf.org; 'Alia > Atlas' > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > I believe that most of us expect that in I2rs: > Priority is associated with a client. > A client does not get to change its priority (although adminsitrators > clearly can). > When a client performs an operation, the client identity and priority are > recorded both for traceability and for future comparison. > If a later action attempts to modify the same item, the acting client > identity and priority are compared with the stored values. > > (While I read the architecture as saying that, I could be too close to the > document.) > > Yours, > Joel > > On 5/27/15 6:09 PM, Juergen Schoenwaelder wrote: >> On Wed, May 27, 2015 at 02:52:39PM -0400, Susan Hares wrote: >> >> [discussion about priority] >> >>> . [Jeff]: It is stored in the NACM for client, and the client >>> identity is tagged to a node (E.g. per route). >>> >>> >>> This further implies that priority is an attribute that is stored in >>> the NETCONF Access Control Model [RFC6536 >>> ] as part of a rule-list. >>> E.g.: >>> >>> >>> >>> +--rw rule-list [name] >>> >>> +--rw name string >>> >>> +--rw group* union >>> >>> +--rw rule [name] >>> >>> +--rw name string >>> >>> +--rw module-name? union >>> >>> +--rw (rule-type)? >>> >>> | +--:(protocol-operation) >>> >>> | | +--rw rpc-name? union >>> >>> | +--:(notification) >>> >>> | | +--rw notification-name? union >>> >>> | +--:(data-node) >>> >>> | +--rw path node-instance-identifier >>> >>> +--rw access-operations? union >>> >>> +--rw action action-type >>> >>> +--rw comment? string >>> >>> +--rw i2rs:i2rs-priority i2rs-priority-type >>> >> >> I am confused since sometimes it sounds like the priority is a >> property of an I2RS client and yet at other times it sounds like the >> priority is associated with a scope accessible for an I2RS client. >> >> If I understand Jeff correctly, then he proposes that a data node >> remembers the identity of the I2RS client that created / last modified >> it and the priority is obtained at the time a confict needs to be >> resolved (and hence the priority may be different from the priority >> that was in effect when the data node was created / last modified). >> >> Note that NETCONF/RESTCONF so far allows every client with proper >> access rights to modify data nodes. There is no notion of ownership in >> the sense that if something got written by A then B cannot update it >> unless B has higher priority. If A and B have the same priority (which >> is so far always the case), then the last write wins. The I2RS >> architecture document, however, requires that the first write blocks >> any subsequent writes: >> >> remains in effect. In the case of priority ties, the first client >> whose attribution is associated with the data will keep control. >> >> If NETCONF/RESTCONF gets extended with ownership and priorities, I >> think it would be desirable if the current behaviour (where all >> clients have the same priority) would still fall out naturally. >> >> /js >> > From nobody Thu May 28 08:17: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 87EE71B2B59 for ; Thu, 28 May 2015 08:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAOZv4_qTjEP for ; Thu, 28 May 2015 08:17:47 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 A39C61B2B6B for ; Thu, 28 May 2015 08:17:17 -0700 (PDT) Received: by lbcue7 with SMTP id ue7so30603929lbc.0 for ; Thu, 28 May 2015 08:17:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=VsgVOLr4R1H7KPwC1Kg8wLQcUFVH2B70b2ajpgdYE6s=; b=F9MD+A8W+imR/notA6UMbLT3wdGTGNCQplESTGQXhjgsi6ytY7AgwahaFuhCMrD3ob +XA8EhX7ukbv1xOL4g3bGLopqLNdYSm5lnQxZ8KflJ4+44pnJKVfWlUjFM6ENRG68Vjj w48DIOvMeqOMQWsvdSYCQONfsIoTf3bceV5OEGUa8rhmozjzo/1PBY3OPN+//lqlK7K2 1GYnYS4nyTK36DOqp19LM9JKI9VD7TjxlZWayi9PbDqjVWy7e1uWIr9rLse/aqbB+yWt BpKzK8qSPdGNatQ/EXNqdRb3KU45RUcXpPdsznwm5lmSMU+BpTkF/q7z2QnkcrkPI31N XPaQ== X-Gm-Message-State: ALoCoQmjgRbwF3VOgpG9PyY8v9y6DtKFjT8GEPjzRSoxKmYh3iyn+cs8y7IVG9CM9K0yr6UNFTGO MIME-Version: 1.0 X-Received: by 10.112.77.234 with SMTP id v10mr3309399lbw.119.1432826236184; Thu, 28 May 2015 08:17:16 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 28 May 2015 08:17:16 -0700 (PDT) In-Reply-To: <20150528060502.GA68091@elstar.local> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> Date: Thu, 28 May 2015 08:17:16 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "Joel M. Halpern" , Jeffrey Haas , "i2rs@ietf.org" , chen.ran@zte.com.cn, Alia Atlas , Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 15:17:49 -0000 On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder wrote: > On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >> >> Although I should be promoting use of NACM, I am not so sure it should >> be mandatory for I2RS or required to configure I2RS client priority. >> >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } > > So what is i2rs:client-name - is it any different from a > NETCONF/RESTCONF username? > Is is probably not different. > NACM maps user names into groups and NACM allows to have the mapping > supplied by an external source (e.g. RADIUS). If this priority mapping > is kept separate from NACM, would we need to provision means to get > the priority from AAA as well? > My point showing the 2 item list is that the information needed to implement I2RS client priority is rather trivial. It can certainly be made really complicated by the IETF, but it is an inherently trivial configuration. > And the bigger question: Do we create something specific for I2RS or > are we going to extend the generic YANG/NC/RC framework to provide the > tools I2RS needs? This is probably a question the NETCONF WG has to > answer. It is good to make reusable features. I don't want to change NETCONF or RESTCONF to use client priority. Let I2RS prove it is useful first. I am not convinced it will really help. It seems like an implementation detail that is being turned into ad administrative task. If multiple clients from multiple vendors are stepping on each other, then the likely outcome of a priority change by the administrator will be to select which clients should continue working and which should be broken. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu May 28 16:22:42 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ACA1A8BB3 for ; Thu, 28 May 2015 16:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qItXMy1p8LFb for ; Thu, 28 May 2015 16:22:39 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C57221A8BAF for ; Thu, 28 May 2015 16:22:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" , "'Juergen Schoenwaelder'" , "'Joel M. Halpern'" , "'Jeffrey Haas'" , , , "'Alia Atlas'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> In-Reply-To: Date: Thu, 28 May 2015 19:22:22 -0400 Message-ID: <020101d0999d$26fe2750$74fa75f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50qd0uyigA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 23:22:40 -0000 Andy:=20 Yes - the client with priority and secondary identity are inherently = simple additions. Can you confirm my understanding below based on = Jeff's document?=20 Can you explain your statement "I do not want to change NETCONF or = RESTCONF to use client priority?" What are you proposing that you do = not want to add the NACM list the priority? Sue=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Example ------------------------ 1) any multiple TCP sessions from a client application will use a = different ID if they want a different priority for write of an object=20 Application 1: TCP session 1 - priority 1, = secondary-identity "pub-sub monitor" Application 1: TCP session 2 - priority 10, = secondary-identity "tracing monitor"=20 Application 1: TCP session 3 - priority 20, opaque "Weekly config" =20 Application 1: TCP session 4 - priority 55, opaque "Emergency config" = Jeff's META-data example:=20 ... For my example TCP session 1=20 =20 Juergen's client example:=20 list i2rs-client { key name; leaf name { description "The client name"; type i2rs:client-name; } leaf priority { description "The priority value assigned to this client."; type i2rs:client-priority; } } +--rw rule-list [name] +--rw name string +--rw group* union +--rw rule [name] +--rw name string +--rw module-name? union +--rw (rule-type)? | +--:(protocol-operation) | | +--rw rpc-name? union | +--:(notification) | | +--rw notification-name? union | +--:(data-node) | +--rw path node-instance-identifier +--rw access-operations? union +--rw action action-type +--rw comment? string +--rw i2rs:i2rs-priority i2rs-priority-type Are you proposing something different than Jeff's proposal?=20 Sue=20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, May 28, 2015 11:17 AM To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey Haas; = i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder = wrote: > On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >> >> Although I should be promoting use of NACM, I am not so sure it=20 >> should be mandatory for I2RS or required to configure I2RS client = priority. >> >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } > > So what is i2rs:client-name - is it any different from a=20 > NETCONF/RESTCONF username? > Is is probably not different. > NACM maps user names into groups and NACM allows to have the mapping=20 > supplied by an external source (e.g. RADIUS). If this priority mapping = > is kept separate from NACM, would we need to provision means to get=20 > the priority from AAA as well? > My point showing the 2 item list is that the information needed to = implement I2RS client priority is rather trivial. It can certainly be made really complicated by the IETF, but it is an = inherently trivial configuration. > And the bigger question: Do we create something specific for I2RS or=20 > are we going to extend the generic YANG/NC/RC framework to provide the = > tools I2RS needs? This is probably a question the NETCONF WG has to=20 > answer. It is good to make reusable features. I don't want to change NETCONF or RESTCONF to use client priority. Let I2RS prove it is useful first. I am not convinced it will really = help. It seems like an implementation detail that is being turned into ad = administrative task. If multiple clients from multiple vendors are = stepping on each other, then the likely outcome of a priority change by = the administrator will be to select which clients should continue = working and which should be broken. > > /js > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Thu May 28 16:34: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 3FBC31ACDFD for ; Thu, 28 May 2015 16:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N74EDLnlLl-6 for ; Thu, 28 May 2015 16:34:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1E1ACE0E for ; Thu, 28 May 2015 16:34:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Andy Bierman'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> In-Reply-To: <20150528060502.GA68091@elstar.local> Date: Thu, 28 May 2015 19:34:15 -0400 Message-ID: <021001d0999e$cfc01960$6f404c20$@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: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tnd+oZtA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , 'Alia Atlas' , chen.ran@zte.com.cn Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 23:34:26 -0000 Juergen: In my opinion, the i2rs:client-name is not different than the NETCONF/RESTCONF user name. If you have a proposal on how to link the i2rs priority to different than Jeff's proposal for NACM rules, we would be glad to hear it. Jeff is trying to provide workable I2RS requirements to the netconf/netmod WGs The architecture document indicates that the I2RS Client will obtain the client identity and priority out-side of the protocol. Our intent was to re-use the AAA mechanisms to spread client-identity, priority, and secondary opaque id (if necessary). Early proof-of-concept implementations suggest this easily linked to. NETCONF/NETMOD will indeed need to determine how the NETCONF protocol WG will meet (or not meet) the I2RS requirements. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, May 28, 2015 2:05 AM To: Andy Bierman Cc: Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: > > Although I should be promoting use of NACM, I am not so sure it should > be mandatory for I2RS or required to configure I2RS client priority. > > list i2rs-client { > key name; > leaf name { > description "The client name"; > type i2rs:client-name; > } > leaf priority { > description "The priority value assigned to this client."; > type i2rs:client-priority; > } > } So what is i2rs:client-name - is it any different from a NETCONF/RESTCONF username? NACM maps user names into groups and NACM allows to have the mapping supplied by an external source (e.g. RADIUS). If this priority mapping is kept separate from NACM, would we need to provision means to get the priority from AAA as well? And the bigger question: Do we create something specific for I2RS or are we going to extend the generic YANG/NC/RC framework to provide the tools I2RS needs? This is probably a question the NETCONF WG has to answer. /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 Thu May 28 16:39: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 B6FCF1ACE60 for ; Thu, 28 May 2015 16:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTcg9pH6Sy55 for ; Thu, 28 May 2015 16:39:47 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 ED9ED1A8029 for ; Thu, 28 May 2015 16:39:46 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so38366960lbb.3 for ; Thu, 28 May 2015 16:39:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F0w6mH1RHuzBAkY/ydgarGuoL1QomBjuRGvL5r1MQ/U=; b=A5Zfc89jeaTuZaYY3AT3mEzwxazwJ1GLiOqOR2/qJogOS4NWRKush7+6MWyYSi54eC CxdQLrBnE3Pr7nHD3pHMOYKq+K/G8mBNCr04HFGJaRQ61ckGttsaAjJD/rRVJdvdD2JU u5vjvps/bK+cOJYQddA6lTp6MI9tAF32TxhGPT+zcWVt+F5O0HpNAGs5Kxbg90qxviD+ 0kCODCrLmHR81AHNdQ/9SZV3wcNMw6G80toMIAgTQ+fwttSKYbh3iabDoZh9TDUqH+9U SUkm4thKDb+4gDw4DkyHVg9rLG0Ps0/1nF77Xe9nh/HgIiwF+VBqt5TY/i9fo/GeLHjN 8e4A== X-Gm-Message-State: ALoCoQk/19/xf68Nfwp2MImzgaIOgeyzlTul4rzJJuPviPL7FarigIE2jqHVepwFcIjQNcjo1io9 MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr5192537laa.33.1432856385215; Thu, 28 May 2015 16:39:45 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 28 May 2015 16:39:45 -0700 (PDT) In-Reply-To: <020101d0999d$26fe2750$74fa75f0$@ndzh.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> Date: Thu, 28 May 2015 16:39:45 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , chen.ran@zte.com.cn, Juergen Schoenwaelder , Alia Atlas , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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, 28 May 2015 23:39:48 -0000 On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: > Andy: > > Yes - the client with priority and secondary identity are inherently simp= le additions. Can you confirm my understanding below based on Jeff's docu= ment? > Not sure what you mean. i don't think the client should provide the priority in request messages. This is configured on the agent, not requested by the client. > Can you explain your statement "I do not want to change NETCONF or RESTC= ONF to use client priority?" What are you proposing that you do not want t= o add the NACM list the priority? I don't want to change NETCONF and RESTCONF so that config=3Dtrue objects use priority. Only I2RS should use it. > > Sue Andy > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Example > ------------------------ > 1) any multiple TCP sessions from a client application will use a differe= nt ID if they want a different priority for write of an object > Application 1: TCP session 1 - priority 1, secondary-iden= tity "pub-sub monitor" > Application 1: TCP session 2 - priority 10, secondary-ident= ity "tracing monitor" > Application 1: TCP session 3 - priority 20, opaque "Weekly conf= ig" > Application 1: TCP session 4 - priority 55, opaque "Emergency c= onfig" > > Jeff's META-data example: > > i2rs:i2rs-secondary-identity=3D"user1" i2rs:i2rs-priority=3D"47"> > ... > > > For my example TCP session 1 > I2rs:i2rs-secondary-identity=3D"pub-sub montior" i2rs:i2rs-priori= ty=3D"1"> > > Juergen's client example: > > list i2rs-client { > key name; > leaf name { > description "The client name"; > type i2rs:client-name; > } > leaf priority { > description "The priority value assigned to this client."; > type i2rs:client-priority; > } > } > > +--rw rule-list [name] > +--rw name string > +--rw group* union > +--rw rule [name] > +--rw name string > +--rw module-name? union > +--rw (rule-type)? > | +--:(protocol-operation) > | | +--rw rpc-name? union > | +--:(notification) > | | +--rw notification-name? union > | +--:(data-node) > | +--rw path node-instance-identifier > +--rw access-operations? union > +--rw action action-type > +--rw comment? string > +--rw i2rs:i2rs-priority i2rs-priority-type > > Are you proposing something different than Jeff's proposal? > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 11:17 AM > To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey Haas; i= 2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder wrote: >> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>> >>> Although I should be promoting use of NACM, I am not so sure it >>> should be mandatory for I2RS or required to configure I2RS client prior= ity. >>> >>> list i2rs-client { >>> key name; >>> leaf name { >>> description "The client name"; >>> type i2rs:client-name; >>> } >>> leaf priority { >>> description "The priority value assigned to this client."; >>> type i2rs:client-priority; >>> } >>> } >> >> So what is i2rs:client-name - is it any different from a >> NETCONF/RESTCONF username? >> > > Is is probably not different. > > >> NACM maps user names into groups and NACM allows to have the mapping >> supplied by an external source (e.g. RADIUS). If this priority mapping >> is kept separate from NACM, would we need to provision means to get >> the priority from AAA as well? >> > > My point showing the 2 item list is that the information needed to implem= ent I2RS client priority is rather trivial. > It can certainly be made really complicated by the IETF, but it is an inh= erently trivial configuration. > >> And the bigger question: Do we create something specific for I2RS or >> are we going to extend the generic YANG/NC/RC framework to provide the >> tools I2RS needs? This is probably a question the NETCONF WG has to >> answer. > > It is good to make reusable features. > I don't want to change NETCONF or RESTCONF to use client priority. > Let I2RS prove it is useful first. I am not convinced it will really hel= p. > It seems like an implementation detail that is being turned into ad admin= istrative task. If multiple clients from multiple vendors are stepping on = each other, then the likely outcome of a priority change by the administrat= or will be to select which clients should continue working and which should= be broken. > > >> >> /js >> > > Andy > >> -- >> 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 Thu May 28 17:09:39 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DED1ACEC1 for ; Thu, 28 May 2015 17:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.455 X-Spam-Level: X-Spam-Status: No, score=-98.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_64=0.6, 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 XU8NH_kzXx28 for ; Thu, 28 May 2015 17:09:36 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id D76D41ACEA5 for ; Thu, 28 May 2015 17:09:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> In-Reply-To: Date: Thu, 28 May 2015 20:09:23 -0400 Message-ID: <022701d099a3$b822c5f0$286851d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88nbAclsA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 00:09:38 -0000 Andy:=20 Thank you for your question. Let me precise.=20 Jeff proposes that clients specify the priority mechanism is an = attribute that is stored in the NACM list on the agent (see Section 5.2 = as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted = below). The client-Agent identities are load in a mechanism which is = out-of-band from the I2RS protocol these values. Into the Client, the = Agent's ID is loaded. Into the Agent, the valid client's identity is = loaded along with the client's priority. AAA (Radius/Diameter) is an = example of an out-of-band mechanism to pass the information with. IMU = (in my understanding), the NACM on the agent is created based on this = AAA loading. The i2rs secondary identity is loaded via an edit-config = mechanism in a config operation (see section 5.1 of Jeff's document.). = Please let me know if my understanding of NACM creation based on AAA = input is correct. =20 I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent = will be annotated with meta-data with the client-id, priority, and = secondary ID. =20 The only proposed change to section 5.2 requirements is to the sentence=20 "Additionally, during commit processing, if nodes are found where i2rs-priority is already present, and the priority is better than the transaction's user's priority for that node, the commit SHALL fail. " Additionally, during commit processing" is incorrect because there is = not commit processing. Jeff stated we are still working with both = NETCONF and RESTCONF - so we must allow for a commit process. In the = meeting I noted that the architecture indicates a change is possible = only if the priority is greater than (>) existing priority. (First = rather than last). Therefore this text should read: "Additionally, = during the operation (RESTCONF)/Commit (NETCONF) processing, if the = nodes are found where i2rs-priority is already present, and the priority = is equal to or better than the transaction's user's priority for the = node, the operation/commit SHALL fail."=20 Do you have any suggestions for modifications to section 5 of Jeff's = document?=20 Sue=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Jeff's document 5.2 states:=20 To support Multi-Headed Control, I2RS requires that there be a decidable means of arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This is done via a priority mechanism with the highest priority winning. This priority may vary on a per-node or sub-tree basis based for a given identity. This further implies that priority is an attribute that is stored in the NETCONF Access Control Model [RFC6536] as part of a rule-list. E.g.: Ephemeral configuration state nodes that are created or altered by users that match a rule carrying i2rs-priority will have those nodes annotated with metadata. Additionally, during commit processing, if nodes are found where i2rs-priority is already present, and the priority is better than the transaction's user's priority for that node, the commit SHALL fail. An appropriate error should be returned to the user stating the nodes where the user had insufficient priority to override the state. =20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, May 28, 2015 7:40 PM To: Susan Hares Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: > Andy: > > Yes - the client with priority and secondary identity are inherently = simple additions. Can you confirm my understanding below based on = Jeff's document? > Not sure what you mean. i don't think the client should provide the priority in request = messages. This is configured on the agent, not requested by the client. > Can you explain your statement "I do not want to change NETCONF or = RESTCONF to use client priority?" What are you proposing that you do = not want to add the NACM list the priority? I don't want to change NETCONF and RESTCONF so that config=3Dtrue = objects use priority. Only I2RS should use it. > > Sue Andy > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Example > ------------------------ > 1) any multiple TCP sessions from a client application will use a = different ID if they want a different priority for write of an object > Application 1: TCP session 1 - priority 1, = secondary-identity "pub-sub monitor" > Application 1: TCP session 2 - priority 10, = secondary-identity "tracing monitor" > Application 1: TCP session 3 - priority 20, opaque "Weekly = config" > Application 1: TCP session 4 - priority 55, opaque = "Emergency config" > > Jeff's META-data example: > > i2rs:i2rs-secondary-identity=3D"user1" = i2rs:i2rs-priority=3D"47"> > ... > > > For my example TCP session 1 > I2rs:i2rs-secondary-identity=3D"pub-sub montior"=20 > i2rs:i2rs-priority=3D"1"> > > Juergen's client example: > > list i2rs-client { > key name; > leaf name { > description "The client name"; > type i2rs:client-name; > } > leaf priority { > description "The priority value assigned to this client."; > type i2rs:client-priority; > } > } > > +--rw rule-list [name] > +--rw name string > +--rw group* union > +--rw rule [name] > +--rw name string > +--rw module-name? union > +--rw (rule-type)? > | +--:(protocol-operation) > | | +--rw rpc-name? union > | +--:(notification) > | | +--rw notification-name? union > | +--:(data-node) > | +--rw path node-instance-identifier > +--rw access-operations? union > +--rw action action-type > +--rw comment? string > +--rw i2rs:i2rs-priority i2rs-priority-type > > Are you proposing something different than Jeff's proposal? > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 11:17 AM > To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey=20 > Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder = wrote: >> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>> >>> Although I should be promoting use of NACM, I am not so sure it=20 >>> should be mandatory for I2RS or required to configure I2RS client = priority. >>> >>> list i2rs-client { >>> key name; >>> leaf name { >>> description "The client name"; >>> type i2rs:client-name; >>> } >>> leaf priority { >>> description "The priority value assigned to this client."; >>> type i2rs:client-priority; >>> } >>> } >> >> So what is i2rs:client-name - is it any different from a=20 >> NETCONF/RESTCONF username? >> > > Is is probably not different. > > >> NACM maps user names into groups and NACM allows to have the mapping=20 >> supplied by an external source (e.g. RADIUS). If this priority=20 >> mapping is kept separate from NACM, would we need to provision means=20 >> to get the priority from AAA as well? >> > > My point showing the 2 item list is that the information needed to = implement I2RS client priority is rather trivial. > It can certainly be made really complicated by the IETF, but it is an = inherently trivial configuration. > >> And the bigger question: Do we create something specific for I2RS or=20 >> are we going to extend the generic YANG/NC/RC framework to provide=20 >> the tools I2RS needs? This is probably a question the NETCONF WG has=20 >> to answer. > > It is good to make reusable features. > I don't want to change NETCONF or RESTCONF to use client priority. > Let I2RS prove it is useful first. I am not convinced it will really = help. > It seems like an implementation detail that is being turned into ad = administrative task. If multiple clients from multiple vendors are = stepping on each other, then the likely outcome of a priority change by = the administrator will be to select which clients should continue = working and which should be broken. > > >> >> /js >> > > Andy > >> -- >> 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 Thu May 28 17:22:42 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A161ACD52 for ; Thu, 28 May 2015 17:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvA1_tEoQZHA for ; Thu, 28 May 2015 17:22:39 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868C91A9109 for ; Thu, 28 May 2015 17:22:38 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so38776296lbb.3 for ; Thu, 28 May 2015 17:22:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kex3+CO3+aiWb5AIYDSM1YBrt9BOdv92zNJ5NmeQ7Os=; b=SHlblwhhS+p2a4TlfyceEaH/8mqjOwCHCGmBliuiZiadANNeHi5h6RNPXZUOwHUdG3 AYpn6yhbHrDoXVK9gGAZx6ME94hvA38l2xlTbwB495MheifmX4TP8S3sLOP4T8wixk3r BxKgV9I1KkWvh7pynf/Df8zjMhz+/4Lj3Gb20aUDR+kKKkWxiyg51CZAqYNmjSctaELn 6Ih1TrgxUmkGkm73g4YZgRuAlvGlfS8mWkjSmp99msomoOl/LNAtOGtNJmMT20KHO+NU V9FlKuQsCvrgau2qHp2ciCYY4cs5HbgLZJm0TLzoIp1kYrAcMlPppHvIIVoJzVI20JoJ AnSw== X-Gm-Message-State: ALoCoQkM4/KYp5pw4HB5JNUR9rVmVWauCVZqAaSFkSYxa7dmjeVfIvC7pi4ZdU1cQ0K9InuweIVM MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr5297686lab.82.1432858956841; Thu, 28 May 2015 17:22:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 28 May 2015 17:22:36 -0700 (PDT) In-Reply-To: <022701d099a3$b822c5f0$286851d0$@ndzh.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> Date: Thu, 28 May 2015 17:22:36 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , chen.ran@zte.com.cn, Juergen Schoenwaelder , Alia Atlas , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 00:22:41 -0000 On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: > Andy: > > Thank you for your question. Let me precise. > > Jeff proposes that clients specify the priority mechanism is an attribute= that is stored in the NACM list on the agent (see Section 5.2 as described= in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The clien= t-Agent identities are load in a mechanism which is out-of-band from the I2= RS protocol these values. Into the Client, the Agent's ID is loaded. Into= the Agent, the valid client's identity is loaded along with the client's p= riority. AAA (Radius/Diameter) is an example of an out-of-band mechanism t= o pass the information with. IMU (in my understanding), the NACM on the ag= ent is created based on this AAA loading. The i2rs secondary identity is l= oaded via an edit-config mechanism in a config operation (see section 5.1 o= f Jeff's document.). Please let me know if my understanding of NACM creati= on based on AAA input is correct. > That is an optional mode. There is also a local users table that can be used. > I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will= be annotated with meta-data with the client-id, priority, and secondary ID= . > > The only proposed change to section 5.2 requirements is to the sentence > "Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. > > " Additionally, during commit processing" is incorrect because there is n= ot commit processing. Jeff stated we are still working with both NETCONF = and RESTCONF - so we must allow for a commit process. In the meeting I not= ed that the architecture indicates a change is possible only if the priorit= y is greater than (>) existing priority. (First rather than last). Theref= ore this text should read: "Additionally, during the operation (RESTCONF)/= Commit (NETCONF) processing, if the nodes are found where i2rs-priority is = already present, and the priority is equal to or better than the transactio= n's user's priority for the node, the operation/commit SHALL fail." > > Do you have any suggestions for modifications to section 5 of Jeff's docu= ment? > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Jeff's document 5.2 states: > > To support Multi-Headed Control, I2RS requires that there be a > decidable means of arbitrating the correct state of data when > multiple clients attempt to manipulate the same piece of data. This > is done via a priority mechanism with the highest priority winning. > This priority may vary on a per-node or sub-tree basis based for a > given identity. > > This further implies that priority is an attribute that is stored in > the NETCONF Access Control Model [RFC6536] as part of a rule-list. > E.g.: > > Ephemeral configuration state nodes that are created or altered by > users that match a rule carrying i2rs-priority will have those nodes > annotated with metadata. Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. An appropriate error should be returned > to the user stating the nodes where the user had insufficient > priority to override the state. > The last paragraph sounds like some nodes will be accepted and others rejec= ted. If any nodes are rejected, the entire edit should be rejected. I don;t think the rule-list should store the client priority. It should be in the 'group' list, or outside NACM completely. Andy > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 7:40 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >> Andy: >> >> Yes - the client with priority and secondary identity are inherently sim= ple additions. Can you confirm my understanding below based on Jeff's doc= ument? >> > > Not sure what you mean. > i don't think the client should provide the priority in request messages. > This is configured on the agent, not requested by the client. > > >> Can you explain your statement "I do not want to change NETCONF or REST= CONF to use client priority?" What are you proposing that you do not want = to add the NACM list the priority? > > I don't want to change NETCONF and RESTCONF so that config=3Dtrue objects= use priority. Only I2RS should use it. > >> >> Sue > > Andy > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> Example >> ------------------------ >> 1) any multiple TCP sessions from a client application will use a differ= ent ID if they want a different priority for write of an object >> Application 1: TCP session 1 - priority 1, secondary-ide= ntity "pub-sub monitor" >> Application 1: TCP session 2 - priority 10, secondary-iden= tity "tracing monitor" >> Application 1: TCP session 3 - priority 20, opaque "Weekly con= fig" >> Application 1: TCP session 4 - priority 55, opaque "Emergency = config" >> >> Jeff's META-data example: >> >> > i2rs:i2rs-secondary-identity=3D"user1" i2rs:i2rs-priority=3D"47"= > >> ... >> >> >> For my example TCP session 1 >> > I2rs:i2rs-secondary-identity=3D"pub-sub montior" >> i2rs:i2rs-priority=3D"1"> >> >> Juergen's client example: >> >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } >> >> +--rw rule-list [name] >> +--rw name string >> +--rw group* union >> +--rw rule [name] >> +--rw name string >> +--rw module-name? union >> +--rw (rule-type)? >> | +--:(protocol-operation) >> | | +--rw rpc-name? union >> | +--:(notification) >> | | +--rw notification-name? union >> | +--:(data-node) >> | +--rw path node-instance-identifier >> +--rw access-operations? union >> +--rw action action-type >> +--rw comment? string >> +--rw i2rs:i2rs-priority i2rs-priority-type >> >> Are you proposing something different than Jeff's proposal? >> >> Sue >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 11:17 AM >> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder wrote: >>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>> >>>> Although I should be promoting use of NACM, I am not so sure it >>>> should be mandatory for I2RS or required to configure I2RS client prio= rity. >>>> >>>> list i2rs-client { >>>> key name; >>>> leaf name { >>>> description "The client name"; >>>> type i2rs:client-name; >>>> } >>>> leaf priority { >>>> description "The priority value assigned to this client."; >>>> type i2rs:client-priority; >>>> } >>>> } >>> >>> So what is i2rs:client-name - is it any different from a >>> NETCONF/RESTCONF username? >>> >> >> Is is probably not different. >> >> >>> NACM maps user names into groups and NACM allows to have the mapping >>> supplied by an external source (e.g. RADIUS). If this priority >>> mapping is kept separate from NACM, would we need to provision means >>> to get the priority from AAA as well? >>> >> >> My point showing the 2 item list is that the information needed to imple= ment I2RS client priority is rather trivial. >> It can certainly be made really complicated by the IETF, but it is an in= herently trivial configuration. >> >>> And the bigger question: Do we create something specific for I2RS or >>> are we going to extend the generic YANG/NC/RC framework to provide >>> the tools I2RS needs? This is probably a question the NETCONF WG has >>> to answer. >> >> It is good to make reusable features. >> I don't want to change NETCONF or RESTCONF to use client priority. >> Let I2RS prove it is useful first. I am not convinced it will really he= lp. >> It seems like an implementation detail that is being turned into ad admi= nistrative task. If multiple clients from multiple vendors are stepping on= each other, then the likely outcome of a priority change by the administra= tor will be to select which clients should continue working and which shoul= d be broken. >> >> >>> >>> /js >>> >> >> Andy >> >>> -- >>> 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 Thu May 28 23:10:36 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9177B1B2A46 for ; Thu, 28 May 2015 23:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzsR4BbBMHHc for ; Thu, 28 May 2015 23:10:32 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250C81B2A4A for ; Thu, 28 May 2015 23:10:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6141C1939; Fri, 29 May 2015 08:10:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kW0JdYjQlRhW; Fri, 29 May 2015 08:10:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 May 2015 08:10:29 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 791252002C; Fri, 29 May 2015 08:10:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7JcG81or-xba; Fri, 29 May 2015 08:10:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 51A0020013; Fri, 29 May 2015 08:10:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 68D0433AC843; Fri, 29 May 2015 08:10:24 +0200 (CEST) Date: Fri, 29 May 2015 08:10:24 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150529061023.GB1694@elstar.local> Mail-Followup-To: Susan Hares , 'Andy Bierman' , "'Joel M. Halpern'" , 'Jeffrey Haas' , i2rs@ietf.org, chen.ran@zte.com.cn, 'Alia Atlas' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <022701d099a3$b822c5f0$286851d0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 06:10:35 -0000 On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: > Andy: > > Thank you for your question. Let me precise. > > Jeff proposes that clients specify the priority mechanism is an attribute that is stored in the NACM list on the agent (see Section 5.2 as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The client-Agent identities are load in a mechanism which is out-of-band from the I2RS protocol these values. Into the Client, the Agent's ID is loaded. Into the Agent, the valid client's identity is loaded along with the client's priority. AAA (Radius/Diameter) is an example of an out-of-band mechanism to pass the information with. IMU (in my understanding), the NACM on the agent is created based on this AAA loading. The i2rs secondary identity is loaded via an edit-config mechanism in a config operation (see section 5.1 of Jeff's document.). Please let me know if my understanding of NACM creation based on AAA input is correct. > So I will ask again: If the priority is a property of the I2RS client (this is how I understand the I2RS architecture document), why would it be configured as part of a NACM rule as suggestd in section 5.2 of draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a property of the scope of a NACM group. /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 Thu May 28 23:15: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 A58201B2A4C for ; Thu, 28 May 2015 23:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWejUEms8NoD for ; Thu, 28 May 2015 23:15:18 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0164C1B2A4B for ; Thu, 28 May 2015 23:15:18 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C569B196D; Fri, 29 May 2015 08:15:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1PYQsqc_-cj0; Fri, 29 May 2015 08:15:04 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 May 2015 08:15:16 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD14120031; Fri, 29 May 2015 08:15:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8mrHOZeRaUQB; Fri, 29 May 2015 08:15:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE75120013; Fri, 29 May 2015 08:15:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF9E733AC86F; Fri, 29 May 2015 08:15:14 +0200 (CEST) Date: Fri, 29 May 2015 08:15:14 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150529061514.GC1694@elstar.local> Mail-Followup-To: Susan Hares , 'Andy Bierman' , "'Joel M. Halpern'" , 'Jeffrey Haas' , i2rs@ietf.org, chen.ran@zte.com.cn, 'Alia Atlas' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <021001d0999e$cfc01960$6f404c20$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <021001d0999e$cfc01960$6f404c20$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 06:15:20 -0000 On Thu, May 28, 2015 at 07:34:15PM -0400, Susan Hares wrote: > Juergen: > > In my opinion, the i2rs:client-name is not different than the > NETCONF/RESTCONF user name. If you have a proposal on how to link the i2rs > priority to different than Jeff's proposal for NACM rules, we would be glad > to hear it. Jeff is trying to provide workable I2RS requirements to the > netconf/netmod WGs Andy already made a proposal. > The architecture document indicates that the I2RS Client will obtain the > client identity and priority out-side of the protocol. Our intent was to > re-use the AAA mechanisms to spread client-identity, priority, and secondary > opaque id (if necessary). Early proof-of-concept implementations suggest > this easily linked to. I do not care where the I2RS client obtains its identity from. My concern is the server and I like to get an answer whether the priority is a property of a client, a property of a NACM group (of clients), or whether the priority is a property of a NACM access control rule. /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 Fri May 29 09:03:42 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E0F1ACD87 for ; Fri, 29 May 2015 09:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5Pe5EN4w96J for ; Fri, 29 May 2015 09:03:35 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 447291ACDB9 for ; Fri, 29 May 2015 09:03:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> In-Reply-To: <20150529061023.GB1694@elstar.local> Date: Fri, 29 May 2015 12:03:18 -0400 Message-ID: <036601d09a28$faab15f0$f00141d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0367_01D09A07.739C8330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8BuHT/cJ2T2AOg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 16:03:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0367_01D09A07.739C8330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: Thank you for asking the question again. I appreciate your patience as I attempt to answer your question carefully. Short answer: I2RS strategy is re-use of other protocols rather than invent, and this seemed a reasonable place to put it. Context: Jeff's document is a proposal for the requirements for I2RS to the NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier descriptions from the I2RS group had been "too vague" so Jeff's document is providing detailed requirements. I2RS is not designing thing for NETCONF only making known in detailed terms our requirements to aid the NETCONF group's response on whether the I2RS design requirements can be met. Longer Answer: His proposal arises out of section 4.2 in the I2RS architecture document. This section states: An approach to a similar access control problem is defined in the NetConf Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be specified for a data node instance identifier while defining meaningful manipulable defaults. The identity within NACM [RFC6536] can be specifying as either a user name or a group user name (e.g. Root), and this name is linked a scope policy that contained in a set of access control rules. Similarly, it is expected the I2RS identity links to one role which has a scope policy specified by a set of access control rules. This scope policy is can be provided via Local Config, exposed as an I2RS Service for manipulation by authorized clients, or via some other method (e.g. AAA service). You can see in this point that the client identity is being linked to the scope policy controlling read or write. Section 7.8 points out that priority "ensures predictability" in write conditions between two I2RS Clients trying to write data in one agent, or between an I2RS client and the local config. Jeff's requirements flow out of these two sections in the architecture document. What you can do: If you have an alternate suggestion for priority for Jeff's document, please make a suggestion and indicate why you think it fits within the I2RS architecture document (please list sections). Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, May 29, 2015 2:10 AM To: Susan Hares Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; 'Jeffrey Haas'; 'Joel M. Halpern' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: > Andy: > > Thank you for your question. Let me precise. > > Jeff proposes that clients specify the priority mechanism is an attribute that is stored in the NACM list on the agent (see Section 5.2 as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The client-Agent identities are load in a mechanism which is out-of-band from the I2RS protocol these values. Into the Client, the Agent's ID is loaded. Into the Agent, the valid client's identity is loaded along with the client's priority. AAA (Radius/Diameter) is an example of an out-of-band mechanism to pass the information with. IMU (in my understanding), the NACM on the agent is created based on this AAA loading. The i2rs secondary identity is loaded via an edit-config mechanism in a config operation (see section 5.1 of Jeff's document.). Please let me know if my understanding of NACM creation based on AAA input is correct. > So I will ask again: If the priority is a property of the I2RS client (this is how I understand the I2RS architecture document), why would it be configured as part of a NACM rule as suggestd in section 5.2 of draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a property of the scope of a NACM group. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0367_01D09A07.739C8330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Thank = you for asking the question again. I appreciate your patience as I = attempt to answer your question carefully. 

 

Short answer: I2RS strategy is re-use of = other protocols rather than invent, and this seemed a reasonable place = to put it.

 

Context: Jeff’s document is a proposal = for the requirements for I2RS to the NETCONF/NETMOD WG on ephemeral = state.  Feedback on the earlier descriptions from the I2RS group = had been “too vague” so Jeff’s document is providing = detailed requirements.  I2RS is not designing thing for NETCONF = only making known in detailed terms our requirements to aid the NETCONF = group’s response on whether the I2RS design requirements can be = met.  

 

Longer Answer:  His proposal arises out = of section 4.2 in the I2RS architecture document.  This section = states:

 

An approach to a similar = access control problem is defined in the NetConf Access Control Model = (NACM) [RFC6536]; it allows arbitrary access to be specified for a data = node instance identifier while defining meaningful manipulable = defaults.  The identity within NACM [RFC6536] can be specifying as = either a user name or a group user name (e.g.  Root), and this name = is linked a scope policy that contained in a set of access control = rules.  Similarly, it is expected the I2RS identity links to one = role which has a scope policy specified by a set of access control = rules.  This scope policy is can be provided via Local Config, = exposed as an I2RS Service for  manipulation by authorized clients, = or via some other method (e.g.   AAA = service).

 

You can see in this point that the client identity = is being linked to the scope policy controlling read or write.  = Section 7.8 points out that priority “ensures = predictability” in write conditions between two I2RS Clients = trying to write data in one agent, or between an I2RS client and the = local config.   Jeff’s requirements flow out of these = two sections in the architecture document.   

 

What you can do: If you have an alternate = suggestion for priority for Jeff’s document, please make a = suggestion and indicate why you think it fits within the I2RS = architecture document (please list sections).

 

Sue =

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan = Hares
Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia = Atlas'; 'Jeffrey Haas'; 'Joel M. Halpern'
Subject: Re: [i2rs] = draft-chen-i2rs-identifier-management-00

 

On = Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares = wrote:

> Andy: =

>

> Thank you for your question.  Let me = precise.

>

> Jeff proposes that clients specify the = priority mechanism is an attribute that is stored in the NACM list on = the agent (see Section 5.2 as described in the = draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The = client-Agent identities are load in a mechanism which is out-of-band = from the I2RS protocol these values.  Into the Client, the Agent's = ID is loaded.  Into the Agent, the valid client's identity is = loaded along with the client's priority.  AAA (Radius/Diameter) is = an example of an out-of-band mechanism to pass the information = with.  IMU (in my understanding), the NACM on the agent is created = based on this AAA loading.  The i2rs secondary identity is loaded = via an edit-config mechanism in a config operation (see section 5.1 of = Jeff's document.).  Please let me know if my understanding of NACM = creation based on AAA input is correct. 

> 

 

So I = will ask again: If the priority is a property of the I2RS client (this = is how I understand the I2RS architecture document), why would it be = configured as part of a NACM rule as suggestd in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the = priority a property of the scope of a NACM group.

 

/js

 

-- =

Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

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

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0367_01D09A07.739C8330-- From nobody Fri May 29 09:25: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 1770C1AC424 for ; Fri, 29 May 2015 09:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLwBogCpoGlF for ; Fri, 29 May 2015 09:25:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479051A913D for ; Fri, 29 May 2015 09:25:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1593A734; Fri, 29 May 2015 18:25:15 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3wYSr9M8QHaq; Fri, 29 May 2015 18:25:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 29 May 2015 18:25:13 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD23F20031; Fri, 29 May 2015 18:25:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DjBnc00WBoOW; Fri, 29 May 2015 18:25:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1ECCC2002C; Fri, 29 May 2015 18:25:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1773D3412FB6; Fri, 29 May 2015 18:25:08 +0200 (CEST) Date: Fri, 29 May 2015 18:25:08 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150529162508.GA6146@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, chen.ran@zte.com.cn, 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" References: <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> <036601d09a28$faab15f0$f00141d0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <036601d09a28$faab15f0$f00141d0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Andy Bierman' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 16:25:19 -0000 Thanks for all the details but I am missing an answer to my question. Shall I repeat it once more? /js On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote: > Juergen: > > > > Thank you for asking the question again. I appreciate your patience as I > attempt to answer your question carefully. > > > > Short answer: I2RS strategy is re-use of other protocols rather than invent, > and this seemed a reasonable place to put it. > > > > Context: Jeff's document is a proposal for the requirements for I2RS to the > NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier descriptions > from the I2RS group had been "too vague" so Jeff's document is providing > detailed requirements. I2RS is not designing thing for NETCONF only making > known in detailed terms our requirements to aid the NETCONF group's response > on whether the I2RS design requirements can be met. > > > > Longer Answer: His proposal arises out of section 4.2 in the I2RS > architecture document. This section states: > > > > An approach to a similar access control problem is defined in the NetConf > Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be > specified for a data node instance identifier while defining meaningful > manipulable defaults. The identity within NACM [RFC6536] can be specifying > as either a user name or a group user name (e.g. Root), and this name is > linked a scope policy that contained in a set of access control rules. > Similarly, it is expected the I2RS identity links to one role which has a > scope policy specified by a set of access control rules. This scope policy > is can be provided via Local Config, exposed as an I2RS Service for > manipulation by authorized clients, or via some other method (e.g. AAA > service). > > > > You can see in this point that the client identity is being linked to the > scope policy controlling read or write. Section 7.8 points out that > priority "ensures predictability" in write conditions between two I2RS > Clients trying to write data in one agent, or between an I2RS client and the > local config. Jeff's requirements flow out of these two sections in the > architecture document. > > > > What you can do: If you have an alternate suggestion for priority for Jeff's > document, please make a suggestion and indicate why you think it fits within > the I2RS architecture document (please list sections). > > > > Sue > > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Friday, May 29, 2015 2:10 AM > To: Susan Hares > Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; > 'Jeffrey Haas'; 'Joel M. Halpern' > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > > > On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: > > > Andy: > > > > > > Thank you for your question. Let me precise. > > > > > > Jeff proposes that clients specify the priority mechanism is an attribute > that is stored in the NACM list on the agent (see Section 5.2 as described > in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The > client-Agent identities are load in a mechanism which is out-of-band from > the I2RS protocol these values. Into the Client, the Agent's ID is loaded. > Into the Agent, the valid client's identity is loaded along with the > client's priority. AAA (Radius/Diameter) is an example of an out-of-band > mechanism to pass the information with. IMU (in my understanding), the NACM > on the agent is created based on this AAA loading. The i2rs secondary > identity is loaded via an edit-config mechanism in a config operation (see > section 5.1 of Jeff's document.). Please let me know if my understanding of > NACM creation based on AAA input is correct. > > > > > > > So I will ask again: If the priority is a property of the I2RS client (this > is how I understand the I2RS architecture document), why would it be > configured as part of a NACM rule as suggestd in section 5.2 of > draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a > property of the scope of a NACM group. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 < > http://www.jacobs-university.de/> > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri May 29 09:32: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 3A8C01ACD58 for ; Fri, 29 May 2015 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxPTDYDTKqMn for ; Fri, 29 May 2015 09:32:17 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FF41ACD4F for ; Fri, 29 May 2015 09:32:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 507AD2401BE; Fri, 29 May 2015 09:32:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9D0C1240063; Fri, 29 May 2015 09:32:16 -0700 (PDT) Message-ID: <55689482.4030102@joelhalpern.com> Date: Fri, 29 May 2015 12:32:02 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , i2rs@ietf.org, 'Andy Bierman' , 'Alia Atlas' References: <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> <036601d09a28$faab15f0$f00141d0$@ndzh.com> <20150529162508.GA6146@elstar.local> In-Reply-To: <20150529162508.GA6146@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I2RS priority location 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, 29 May 2015 16:32:19 -0000 I think that the problem answering your question is that as long as the priority gets associated with the client, I2RS does not care where the information is. So we are open to the various alternatives that have been suggested in this regard. Yours, Joel On 5/29/15 12:25 PM, Juergen Schoenwaelder wrote: > Thanks for all the details but I am missing an answer to my question. > Shall I repeat it once more? > > /js > > On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote: >> Juergen: >> >> >> >> Thank you for asking the question again. I appreciate your patience as I >> attempt to answer your question carefully. >> >> >> >> Short answer: I2RS strategy is re-use of other protocols rather than invent, >> and this seemed a reasonable place to put it. >> >> >> >> Context: Jeff's document is a proposal for the requirements for I2RS to the >> NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier descriptions >> from the I2RS group had been "too vague" so Jeff's document is providing >> detailed requirements. I2RS is not designing thing for NETCONF only making >> known in detailed terms our requirements to aid the NETCONF group's response >> on whether the I2RS design requirements can be met. >> >> >> >> Longer Answer: His proposal arises out of section 4.2 in the I2RS >> architecture document. This section states: >> >> >> >> An approach to a similar access control problem is defined in the NetConf >> Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be >> specified for a data node instance identifier while defining meaningful >> manipulable defaults. The identity within NACM [RFC6536] can be specifying >> as either a user name or a group user name (e.g. Root), and this name is >> linked a scope policy that contained in a set of access control rules. >> Similarly, it is expected the I2RS identity links to one role which has a >> scope policy specified by a set of access control rules. This scope policy >> is can be provided via Local Config, exposed as an I2RS Service for >> manipulation by authorized clients, or via some other method (e.g. AAA >> service). >> >> >> >> You can see in this point that the client identity is being linked to the >> scope policy controlling read or write. Section 7.8 points out that >> priority "ensures predictability" in write conditions between two I2RS >> Clients trying to write data in one agent, or between an I2RS client and the >> local config. Jeff's requirements flow out of these two sections in the >> architecture document. >> >> >> >> What you can do: If you have an alternate suggestion for priority for Jeff's >> document, please make a suggestion and indicate why you think it fits within >> the I2RS architecture document (please list sections). >> >> >> >> Sue >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder >> Sent: Friday, May 29, 2015 2:10 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; >> 'Jeffrey Haas'; 'Joel M. Halpern' >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> >> >> On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: >> >>> Andy: >> >>> >> >>> Thank you for your question. Let me precise. >> >>> >> >>> Jeff proposes that clients specify the priority mechanism is an attribute >> that is stored in the NACM list on the agent (see Section 5.2 as described >> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >> client-Agent identities are load in a mechanism which is out-of-band from >> the I2RS protocol these values. Into the Client, the Agent's ID is loaded. >> Into the Agent, the valid client's identity is loaded along with the >> client's priority. AAA (Radius/Diameter) is an example of an out-of-band >> mechanism to pass the information with. IMU (in my understanding), the NACM >> on the agent is created based on this AAA loading. The i2rs secondary >> identity is loaded via an edit-config mechanism in a config operation (see >> section 5.1 of Jeff's document.). Please let me know if my understanding of >> NACM creation based on AAA input is correct. >> >>> >> >> >> >> So I will ask again: If the priority is a property of the I2RS client (this >> is how I understand the I2RS architecture document), why would it be >> configured as part of a NACM rule as suggestd in section 5.2 of >> draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a >> property of the scope of a NACM group. >> >> >> >> /js >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >> Fax: +49 421 200 3103 < >> http://www.jacobs-university.de/> >> >> >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs >> > From nobody Fri May 29 09:34: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 5632F1ACD7F; Fri, 29 May 2015 09:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cb4Odhz6RwsV; Fri, 29 May 2015 09:34:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 557951ACD7A; Fri, 29 May 2015 09:34:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529163403.19655.34267.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 09:34:03 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I2RS WG Virtual Interim meeting: July 1, 2015 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@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: Fri, 29 May 2015 16:34:04 -0000 The Interface to the Routing System (I2RS) WG has added an additional virtual interim meeting on the following date: Date: July 1, 2015 Time: 10:00 - 11:30AM EDT (1400-1530 UTC) Topic: Initial I2RS protocol feedback from netconf/netmod I2RS Use Case updates WebEx details will follow on the I2RS mailing list. Additionally, please note the following topic changes for the previously-announced [1] I2RS virtual interim meetings: Date: May 27, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: I2RS protocol requirements and FB FIB Date: June 10, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: I2RS Protocol specification Date: June 24, 2015 Time: 10:00-11:30 AM EDT (14:00-15:30 UTC) Topic: I2RS FB-RIB, I2RS RIB update, I2RS Topology with Traffic Engineering [1] https://mailarchive.ietf.org/arch/msg/ietf-announce/8AlO1M9zhgNgcjNUxK8bfSUnnH8 From nobody Fri May 29 09:40:48 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 0AB9A1ACD4F for ; Fri, 29 May 2015 09:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.855 X-Spam-Level: X-Spam-Status: No, score=-97.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, 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 zaX5Nm6JhpJd for ; Fri, 29 May 2015 09:40:45 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id ADEC11A8965 for ; Fri, 29 May 2015 09:40:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> In-Reply-To: Date: Fri, 29 May 2015 12:40:37 -0400 Message-ID: <039401d09a2e$316b40b0$9441c210$@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: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4p2M5Fhg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeff Haas' , i2rs@ietf.org, 'Alia Atlas' , 'Joel Halpern Direct' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 16:40:47 -0000 Andy: Just to clarify is this an a "That is an optional mode [of NACM]. There is also a local users table that can be used." Can you provide an example? Is this an alternate proposal to Jeff's proposal on NACM? Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, May 28, 2015 8:23 PM To: Susan Hares Cc: i2rs@ietf.org; chen.ran@zte.com.cn; Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: > Andy: > > Thank you for your question. Let me precise. > > Jeff proposes that clients specify the priority mechanism is an attribute that is stored in the NACM list on the agent (see Section 5.2 as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The client-Agent identities are load in a mechanism which is out-of-band from the I2RS protocol these values. Into the Client, the Agent's ID is loaded. Into the Agent, the valid client's identity is loaded along with the client's priority. AAA (Radius/Diameter) is an example of an out-of-band mechanism to pass the information with. IMU (in my understanding), the NACM on the agent is created based on this AAA loading. The i2rs secondary identity is loaded via an edit-config mechanism in a config operation (see section 5.1 of Jeff's document.). Please let me know if my understanding of NACM creation based on AAA input is correct. > That is an optional mode. There is also a local users table that can be used. [Sue]: You mean this is an optional mode of NACM? Can you give me a reference for the local users table? Is it RFC6536 in section 2.5 where a configurable set of users can be defined, and linked to a NACM (section 3.1.1)? Can you provide an example how the local users table could be used? > I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will be annotated with meta-data with the client-id, priority, and secondary ID. > > The only proposed change to section 5.2 requirements is to the > sentence "Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. > > " Additionally, during commit processing" is incorrect because there is not commit processing. Jeff stated we are still working with both NETCONF and RESTCONF - so we must allow for a commit process. In the meeting I noted that the architecture indicates a change is possible only if the priority is greater than (>) existing priority. (First rather than last). Therefore this text should read: "Additionally, during the operation (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where i2rs-priority is already present, and the priority is equal to or better than the transaction's user's priority for the node, the operation/commit SHALL fail." > > Do you have any suggestions for modifications to section 5 of Jeff's document? > > Sue > > ============================ > Jeff's document 5.2 states: > > To support Multi-Headed Control, I2RS requires that there be a > decidable means of arbitrating the correct state of data when > multiple clients attempt to manipulate the same piece of data. This > is done via a priority mechanism with the highest priority winning. > This priority may vary on a per-node or sub-tree basis based for a > given identity. > > This further implies that priority is an attribute that is stored in > the NETCONF Access Control Model [RFC6536] as part of a rule-list. > E.g.: > > Ephemeral configuration state nodes that are created or altered by > users that match a rule carrying i2rs-priority will have those nodes > annotated with metadata. Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. An appropriate error should be returned > to the user stating the nodes where the user had insufficient > priority to override the state. > The last paragraph sounds like some nodes will be accepted and others rejected. If any nodes are rejected, the entire edit should be rejected. I don;t think the rule-list should store the client priority. It should be in the 'group' list, or outside NACM completely. Andy > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 7:40 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; > i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >> Andy: >> >> Yes - the client with priority and secondary identity are inherently simple additions. Can you confirm my understanding below based on Jeff's document? >> > > Not sure what you mean. > i don't think the client should provide the priority in request messages. > This is configured on the agent, not requested by the client. > > >> Can you explain your statement "I do not want to change NETCONF or RESTCONF to use client priority?" What are you proposing that you do not want to add the NACM list the priority? > > I don't want to change NETCONF and RESTCONF so that config=true objects use priority. Only I2RS should use it. > >> >> Sue > > Andy > >> =============== >> >> Example >> ------------------------ >> 1) any multiple TCP sessions from a client application will use a different ID if they want a different priority for write of an object >> Application 1: TCP session 1 - priority 1, secondary-identity "pub-sub monitor" >> Application 1: TCP session 2 - priority 10, secondary-identity "tracing monitor" >> Application 1: TCP session 3 - priority 20, opaque "Weekly config" >> Application 1: TCP session 4 - priority 55, opaque "Emergency config" >> >> Jeff's META-data example: >> >> > i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> >> ... >> >> >> For my example TCP session 1 >> > I2rs:i2rs-secondary-identity="pub-sub montior" >> i2rs:i2rs-priority="1"> >> >> Juergen's client example: >> >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } >> >> +--rw rule-list [name] >> +--rw name string >> +--rw group* union >> +--rw rule [name] >> +--rw name string >> +--rw module-name? union >> +--rw (rule-type)? >> | +--:(protocol-operation) >> | | +--rw rpc-name? union >> | +--:(notification) >> | | +--rw notification-name? union >> | +--:(data-node) >> | +--rw path node-instance-identifier >> +--rw access-operations? union >> +--rw action action-type >> +--rw comment? string >> +--rw i2rs:i2rs-priority i2rs-priority-type >> >> Are you proposing something different than Jeff's proposal? >> >> Sue >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 11:17 AM >> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder wrote: >>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>> >>>> Although I should be promoting use of NACM, I am not so sure it >>>> should be mandatory for I2RS or required to configure I2RS client priority. >>>> >>>> list i2rs-client { >>>> key name; >>>> leaf name { >>>> description "The client name"; >>>> type i2rs:client-name; >>>> } >>>> leaf priority { >>>> description "The priority value assigned to this client."; >>>> type i2rs:client-priority; >>>> } >>>> } >>> >>> So what is i2rs:client-name - is it any different from a >>> NETCONF/RESTCONF username? >>> >> >> Is is probably not different. >> >> >>> NACM maps user names into groups and NACM allows to have the mapping >>> supplied by an external source (e.g. RADIUS). If this priority >>> mapping is kept separate from NACM, would we need to provision means >>> to get the priority from AAA as well? >>> >> >> My point showing the 2 item list is that the information needed to implement I2RS client priority is rather trivial. >> It can certainly be made really complicated by the IETF, but it is an inherently trivial configuration. >> >>> And the bigger question: Do we create something specific for I2RS or >>> are we going to extend the generic YANG/NC/RC framework to provide >>> the tools I2RS needs? This is probably a question the NETCONF WG has >>> to answer. >> >> It is good to make reusable features. >> I don't want to change NETCONF or RESTCONF to use client priority. >> Let I2RS prove it is useful first. I am not convinced it will really help. >> It seems like an implementation detail that is being turned into ad administrative task. If multiple clients from multiple vendors are stepping on each other, then the likely outcome of a priority change by the administrator will be to select which clients should continue working and which should be broken. >> >> >>> >>> /js >>> >> >> Andy >> >>> -- >>> 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 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 29 09:47: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 EB6DA1ACD7D for ; Fri, 29 May 2015 09:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93TjQclw10y6 for ; Fri, 29 May 2015 09:47:20 -0700 (PDT) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) (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 3AE651ACD7A for ; Fri, 29 May 2015 09:47:20 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so52164067lbb.3 for ; Fri, 29 May 2015 09:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=y4+McSnmuQ0iSlC9hUTFKziYCQqdBek551RxQRwdi7s=; b=QDcQWur3G6FYtHy868Jzs9u1Io9t/SJ+crRygZYnnqg49TAyr5WS3pkJW7tXBZmG+W aAdY5sJZs+tJfhc/zNkfp5GyZJfpuG751yJrYRtlOv8sGr2Xl7h+Pb1VoSX1s0zzYYpO llpRsNedp+M5Ga9D6fuAxiCvdBIqMyUjD+NzzEygvwvI3LQ4htAvQW7Fr0EOABFdtvgz mhcJAIqU0vAk1d6gtU8OXjzrjwlWDSdoYGm/eXgfgaACZcaqwmgZt9dNn2ij57hnONc6 h6hO8azFvB/r1B3RZISwhjnU6E5mSHcdKt0thni9VvAg9HaYJKqUzh2w8l9+dgA+8mhY 32vQ== X-Gm-Message-State: ALoCoQmHLfO9cLjc8sMzvwj0g37JpVW2MWWHK53MUitIxw/mz2S9IWYA3WZF6a4RUWSrvGxjrn+D MIME-Version: 1.0 X-Received: by 10.152.8.231 with SMTP id u7mr8747637laa.37.1432918038525; Fri, 29 May 2015 09:47:18 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 29 May 2015 09:47:18 -0700 (PDT) In-Reply-To: <20150529162508.GA6146@elstar.local> References: <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> <036601d09a28$faab15f0$f00141d0$@ndzh.com> <20150529162508.GA6146@elstar.local> Date: Fri, 29 May 2015 09:47:18 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Susan Hares , "i2rs@ietf.org" , chen.ran@zte.com.cn, Andy Bierman , Alia Atlas , Jeffrey Haas , "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 16:47:23 -0000 On Fri, May 29, 2015 at 9:25 AM, Juergen Schoenwaelder wrote: > Thanks for all the details but I am missing an answer to my question. > Shall I repeat it once more? The proposal is that the priority is a property of each NACM rule. Since NACM rules can be shared by multiple groups this design will not actually work. As Martin pointed out, rules common to multiple groups will produce data with the same priority. It should also be noted that NACM has "default behavior" that is followed even if no rules are actually configured. IMO priority is associated with the client. A client can be placed in multiple NACM groups. When an edit request is made the client does not indicate which group should be used. The server will pick the highest priority group that the user is a member, and use that for the priority. (Therefore priority is not the property of the group either). It has been suggested that the client can connect multiple times, and each transport connection will somehow convey a different priority to the server. I don't see how this will work. It seems that different client names are needed. This is true whether NACM or a client mapping table is used. The system must produce a different client name in order to use a different priority. > > /js Andy > > On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote: >> Juergen: >> >> >> >> Thank you for asking the question again. I appreciate your patience as I >> attempt to answer your question carefully. >> >> >> >> Short answer: I2RS strategy is re-use of other protocols rather than invent, >> and this seemed a reasonable place to put it. >> >> >> >> Context: Jeff's document is a proposal for the requirements for I2RS to the >> NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier descriptions >> from the I2RS group had been "too vague" so Jeff's document is providing >> detailed requirements. I2RS is not designing thing for NETCONF only making >> known in detailed terms our requirements to aid the NETCONF group's response >> on whether the I2RS design requirements can be met. >> >> >> >> Longer Answer: His proposal arises out of section 4.2 in the I2RS >> architecture document. This section states: >> >> >> >> An approach to a similar access control problem is defined in the NetConf >> Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be >> specified for a data node instance identifier while defining meaningful >> manipulable defaults. The identity within NACM [RFC6536] can be specifying >> as either a user name or a group user name (e.g. Root), and this name is >> linked a scope policy that contained in a set of access control rules. >> Similarly, it is expected the I2RS identity links to one role which has a >> scope policy specified by a set of access control rules. This scope policy >> is can be provided via Local Config, exposed as an I2RS Service for >> manipulation by authorized clients, or via some other method (e.g. AAA >> service). >> >> >> >> You can see in this point that the client identity is being linked to the >> scope policy controlling read or write. Section 7.8 points out that >> priority "ensures predictability" in write conditions between two I2RS >> Clients trying to write data in one agent, or between an I2RS client and the >> local config. Jeff's requirements flow out of these two sections in the >> architecture document. >> >> >> >> What you can do: If you have an alternate suggestion for priority for Jeff's >> document, please make a suggestion and indicate why you think it fits within >> the I2RS architecture document (please list sections). >> >> >> >> Sue >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder >> Sent: Friday, May 29, 2015 2:10 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; >> 'Jeffrey Haas'; 'Joel M. Halpern' >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> >> >> On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: >> >> > Andy: >> >> > >> >> > Thank you for your question. Let me precise. >> >> > >> >> > Jeff proposes that clients specify the priority mechanism is an attribute >> that is stored in the NACM list on the agent (see Section 5.2 as described >> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >> client-Agent identities are load in a mechanism which is out-of-band from >> the I2RS protocol these values. Into the Client, the Agent's ID is loaded. >> Into the Agent, the valid client's identity is loaded along with the >> client's priority. AAA (Radius/Diameter) is an example of an out-of-band >> mechanism to pass the information with. IMU (in my understanding), the NACM >> on the agent is created based on this AAA loading. The i2rs secondary >> identity is loaded via an edit-config mechanism in a config operation (see >> section 5.1 of Jeff's document.). Please let me know if my understanding of >> NACM creation based on AAA input is correct. >> >> > >> >> >> >> So I will ask again: If the priority is a property of the I2RS client (this >> is how I understand the I2RS architecture document), why would it be >> configured as part of a NACM rule as suggestd in section 5.2 of >> draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a >> property of the scope of a NACM group. >> >> >> >> /js >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> >> Fax: +49 421 200 3103 < >> http://www.jacobs-university.de/> >> >> >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs >> > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri May 29 09:59:02 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1E61ACDD1 for ; Fri, 29 May 2015 09:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6BXWutewPEd for ; Fri, 29 May 2015 09:58:57 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) (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 4206A1ACDEE for ; Fri, 29 May 2015 09:58:14 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so52392862lbc.1 for ; Fri, 29 May 2015 09:58:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xRIMWFlOqh5Ngu+tSIrIuo6NBiUkrlFVE5M4SuatF1k=; b=AaBlNsFSHr/WLPAzty299ipbex72XZYtdMaXSIRVPd0F40Exbvb017xHYtnFk0GzE9 XUUFRiQGs7G2CAR0kGWPX00FBP7Psp/xvwdbkfMVpZRk4zW0fSR+uk5zPezKAqQ5WOHj 7bXdjVouL6wM2gGIyOsW/NuyuGn+6eLr+oX3mxij7D/ql0GvWs2ISiQ6/F2rfQptF6B3 pLwCyR+qbUDz+qj/9ZgaYJClBm5/nQ7gleDvG967Fsl26V8d5Nf7jylAGvn41BrhP3nz pgezSf8j4D8oS/lui29JoCwLHslvuMYeFu1NF5yRikJUTuy6dw+wtTrn2tcviLVO9ROo flnQ== X-Gm-Message-State: ALoCoQmabFAyrel0Z5P35uSr5Z9S0ikquKcs1KKe/NjoOt+vi63i57hfS8Xtw1whAT0VEWjIgF6F MIME-Version: 1.0 X-Received: by 10.152.115.207 with SMTP id jq15mr1269294lab.119.1432918692808; Fri, 29 May 2015 09:58:12 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 29 May 2015 09:58:12 -0700 (PDT) In-Reply-To: <039401d09a2e$316b40b0$9441c210$@ndzh.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <039401d09a2e$316b40b0$9441c210$@ndzh.com> Date: Fri, 29 May 2015 09:58:12 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jeff Haas , "i2rs@ietf.org" , Alia Atlas , Joel Halpern Direct Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 16:59:00 -0000 On Fri, May 29, 2015 at 9:40 AM, Susan Hares wrote: > Andy: > > Just to clarify is this an a > > "That is an optional mode [of NACM]. There is also a local users table > that can be used." Can you provide an example? Is this an alternate > proposal to Jeff's proposal on NACM? > Actually the local user table is in ietf-system.yang: http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.659 The 'user-name' leaf-list in the NACM 'group' list is populated by the administrator. The actual values are irrelevant to NACM. They can be local users, Radius, or anything else. Adding a user-name to this list does not in any way enable the server to accept sessions from that user. This is outside the scope of NACM. > Sue Hares Andy > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Thursday, May 28, 2015 8:23 PM > To: Susan Hares > Cc: i2rs@ietf.org; chen.ran@zte.com.cn; Juergen Schoenwaelder; Alia Atlas; > Jeffrey Haas; Joel M. Halpern > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: >> Andy: >> >> Thank you for your question. Let me precise. >> >> Jeff proposes that clients specify the priority mechanism is an attribute > that is stored in the NACM list on the agent (see Section 5.2 as described > in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The > client-Agent identities are load in a mechanism which is out-of-band from > the I2RS protocol these values. Into the Client, the Agent's ID is loaded. > Into the Agent, the valid client's identity is loaded along with the > client's priority. AAA (Radius/Diameter) is an example of an out-of-band > mechanism to pass the information with. IMU (in my understanding), the NACM > on the agent is created based on this AAA loading. The i2rs secondary > identity is loaded via an edit-config mechanism in a config operation (see > section 5.1 of Jeff's document.). Please let me know if my understanding of > NACM creation based on AAA input is correct. >> > > That is an optional mode. > There is also a local users table that can be used. > > [Sue]: You mean this is an optional mode of NACM? Can you give me a > reference for the local users table? Is it RFC6536 in section 2.5 where a > configurable set of users can be defined, and linked to a NACM (section > 3.1.1)? Can you provide an example how the local users table could be > used? > > >> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent will > be annotated with meta-data with the client-id, priority, and secondary ID. >> >> The only proposed change to section 5.2 requirements is to the >> sentence "Additionally, during commit processing, if >> nodes are found where i2rs-priority is already present, and the >> priority is better than the transaction's user's priority for that >> node, the commit SHALL fail. >> >> " Additionally, during commit processing" is incorrect because there is > not commit processing. Jeff stated we are still working with both NETCONF > and RESTCONF - so we must allow for a commit process. In the meeting I > noted that the architecture indicates a change is possible only if the > priority is greater than (>) existing priority. (First rather than last). > Therefore this text should read: "Additionally, during the operation > (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where > i2rs-priority is already present, and the priority is equal to or better > than the transaction's user's priority for the node, the operation/commit > SHALL fail." >> >> Do you have any suggestions for modifications to section 5 of Jeff's > document? >> >> Sue >> >> ============================ >> Jeff's document 5.2 states: >> >> To support Multi-Headed Control, I2RS requires that there be a >> decidable means of arbitrating the correct state of data when >> multiple clients attempt to manipulate the same piece of data. This >> is done via a priority mechanism with the highest priority winning. >> This priority may vary on a per-node or sub-tree basis based for a >> given identity. >> >> This further implies that priority is an attribute that is stored in >> the NETCONF Access Control Model [RFC6536] as part of a rule-list. >> E.g.: >> >> Ephemeral configuration state nodes that are created or altered by >> users that match a rule carrying i2rs-priority will have those nodes >> annotated with metadata. Additionally, during commit processing, if >> nodes are found where i2rs-priority is already present, and the >> priority is better than the transaction's user's priority for that >> node, the commit SHALL fail. An appropriate error should be returned >> to the user stating the nodes where the user had insufficient >> priority to override the state. >> > > > The last paragraph sounds like some nodes will be accepted and others > rejected. > If any nodes are rejected, the entire edit should be rejected. > > I don;t think the rule-list should store the client priority. > It should be in the 'group' list, or outside NACM completely. > > > Andy > >> >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 7:40 PM >> To: Susan Hares >> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >>> Andy: >>> >>> Yes - the client with priority and secondary identity are inherently > simple additions. Can you confirm my understanding below based on Jeff's > document? >>> >> >> Not sure what you mean. >> i don't think the client should provide the priority in request messages. >> This is configured on the agent, not requested by the client. >> >> >>> Can you explain your statement "I do not want to change NETCONF or > RESTCONF to use client priority?" What are you proposing that you do not > want to add the NACM list the priority? >> >> I don't want to change NETCONF and RESTCONF so that config=true objects > use priority. Only I2RS should use it. >> >>> >>> Sue >> >> Andy >> >>> =============== >>> >>> Example >>> ------------------------ >>> 1) any multiple TCP sessions from a client application will use a > different ID if they want a different priority for write of an object >>> Application 1: TCP session 1 - priority 1, > secondary-identity "pub-sub monitor" >>> Application 1: TCP session 2 - priority 10, > secondary-identity "tracing monitor" >>> Application 1: TCP session 3 - priority 20, opaque "Weekly > config" >>> Application 1: TCP session 4 - priority 55, opaque "Emergency > config" >>> >>> Jeff's META-data example: >>> >>> >> i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> >>> ... >>> >>> >>> For my example TCP session 1 >>> >> I2rs:i2rs-secondary-identity="pub-sub montior" >>> i2rs:i2rs-priority="1"> >>> >>> Juergen's client example: >>> >>> list i2rs-client { >>> key name; >>> leaf name { >>> description "The client name"; >>> type i2rs:client-name; >>> } >>> leaf priority { >>> description "The priority value assigned to this client."; >>> type i2rs:client-priority; >>> } >>> } >>> >>> +--rw rule-list [name] >>> +--rw name string >>> +--rw group* union >>> +--rw rule [name] >>> +--rw name string >>> +--rw module-name? union >>> +--rw (rule-type)? >>> | +--:(protocol-operation) >>> | | +--rw rpc-name? union >>> | +--:(notification) >>> | | +--rw notification-name? union >>> | +--:(data-node) >>> | +--rw path node-instance-identifier >>> +--rw access-operations? union >>> +--rw action action-type >>> +--rw comment? string >>> +--rw i2rs:i2rs-priority i2rs-priority-type >>> >>> Are you proposing something different than Jeff's proposal? >>> >>> Sue >>> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> Sent: Thursday, May 28, 2015 11:17 AM >>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder > wrote: >>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>>> >>>>> Although I should be promoting use of NACM, I am not so sure it >>>>> should be mandatory for I2RS or required to configure I2RS client > priority. >>>>> >>>>> list i2rs-client { >>>>> key name; >>>>> leaf name { >>>>> description "The client name"; >>>>> type i2rs:client-name; >>>>> } >>>>> leaf priority { >>>>> description "The priority value assigned to this client."; >>>>> type i2rs:client-priority; >>>>> } >>>>> } >>>> >>>> So what is i2rs:client-name - is it any different from a >>>> NETCONF/RESTCONF username? >>>> >>> >>> Is is probably not different. >>> >>> >>>> NACM maps user names into groups and NACM allows to have the mapping >>>> supplied by an external source (e.g. RADIUS). If this priority >>>> mapping is kept separate from NACM, would we need to provision means >>>> to get the priority from AAA as well? >>>> >>> >>> My point showing the 2 item list is that the information needed to > implement I2RS client priority is rather trivial. >>> It can certainly be made really complicated by the IETF, but it is an > inherently trivial configuration. >>> >>>> And the bigger question: Do we create something specific for I2RS or >>>> are we going to extend the generic YANG/NC/RC framework to provide >>>> the tools I2RS needs? This is probably a question the NETCONF WG has >>>> to answer. >>> >>> It is good to make reusable features. >>> I don't want to change NETCONF or RESTCONF to use client priority. >>> Let I2RS prove it is useful first. I am not convinced it will really > help. >>> It seems like an implementation detail that is being turned into ad > administrative task. If multiple clients from multiple vendors are stepping > on each other, then the likely outcome of a priority change by the > administrator will be to select which clients should continue working and > which should be broken. >>> >>> >>>> >>>> /js >>>> >>> >>> Andy >>> >>>> -- >>>> 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 >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri May 29 10:49:54 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 E35FD1B2B9D for ; Fri, 29 May 2015 10:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.254 X-Spam-Level: X-Spam-Status: No, score=-97.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 pcBHDh-T22LI for ; Fri, 29 May 2015 10:49:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 04EFD1B2B1F for ; Fri, 29 May 2015 10:44:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> In-Reply-To: Date: Fri, 29 May 2015 13:44:03 -0400 Message-ID: <03ab01d09a37$0de25580$29a70080$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03AC_01D09A15.86D856A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4p2M6t4w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 17:49:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03AC_01D09A15.86D856A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 I missed the second part of the email = (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my = earlier message:=20 =20 >. " The last paragraph sounds like some nodes will be accepted and = others rejected. >If any nodes are rejected, the entire edit should be rejected. =20 RESTCONF does an atomic action within a http session. NETCONF within a = commit. Section 6.2 of the I2RS architecture document describes state = storage for I2RS, and it does not have the atomic requirement for the = protocol. Instead section 3.3 of the I2RS architecture document calls = for this to be model driver. Let me provide examples from the 2 major = I2RS protocol independent models:=20 =20 The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00 = ) = proposes that each route will be associated with the following: route = preference, active, installed. Notifications for route change will be = given if route is installed, active, and a reason given, or if the route = commit fails. Some routes may be accepted, and some routes rejected for = installation to the RIB. The concept is the client will be able to = detect when a route is rejected. =20 =20 The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses = the challenge that topology models are not: configuration data only or = operational data only =E2=80=93 but a combination of both in ephemeral = state. Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral = topology model which is operational (read-only) that contains data from: = a) only read from operational units, b) a configured topology, and c) = combination topology (operational state and configured). (A second = alternative is to just have =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D, = but for now let=E2=80=99s focus on a, b, and c). The = =E2=80=9CC=E2=80=9D combination topology may be generated based on = priority of configured topology versus operational data. The inclusion = in =E2=80=9Cc=E2=80=9D may also be validated (E.g. interface up, or L3 = link runs on tunnel over interface which is up)). =20 =20 These two model documents show why atomic state may be on a very small = section of the whole change. =20 =20 > I don=E2=80=99t think the rule-list should store the client priority. > It should be in the 'group' list, or outside NACM completely." =20 Your alternate proposal are:=20 =20 1) Moving i2rs-priority to group list=20 2) Adding a i2rs-client [unspecified location]=20 =20 This mail deals with #1. If you have more details on proposal #2, = please suggest them on the list. =20 =20 list i2rs-client { key name; leaf name { description "The client name"; type i2rs:client-name; } leaf priority { description "The priority value assigned to this client."; type i2rs:client-priority; } } =20 Question: Is this i2rs-list to be included in the group list for NACM = (as listed below from RFC6536) as a leaf list below?=20 =20 container groups { description "NETCONF Access Control Groups."; =20 list group { key name; description "One NACM Group Entry. This list will only contain configured entries, not any entries learned from any transport protocols."; =20 leaf name { type group-name-type; description "Group name associated with this entry."; } =20 leaf-list user-name { type user-name-type; description "Each entry identifies the username of a member of the group associated with this entry."; } # add leaf-list I2rs-client here=20 } } Your message: = http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html States: "I think I2RS interaction with NACM needs to be clearly = defined. NACM implementations do not currently check write requests on config=3Dfalse data. It is possible some edits to NACM are needed = even if no objects are added to the data structure." =20 Do you have a proposal for changing the text in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00? =20 Is it sufficient to state: =E2=80=9CNACM implementations for I2RS will = need to check write request on config=3Dfalse, ephemeral =3D true. = =E2=80=9C before the paragraph:=20 =20 =E2=80=9CEphemeral configuration state nodes that are created or altered = by users that match a rule carrying i2rs-priority will have those nodes = annotated with metadata. Additionally, during commit processing, if = nodes are found where i2rs-priority is already present, and the = priority is better than the transaction's user's priority for that node, = the commit SHALL fail. An appropriate error should be returned to the user stating the nodes where the user had insufficient priority to override the state. =20 I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some edits = to NACM are needed even if no objects are added to the data structure." =20 Sue=20 =20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, May 28, 2015 8:23 PM To: Susan Hares Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 =20 On Thu, May 28, 2015 at 5:09 PM, Susan Hares < = shares@ndzh.com> wrote: > Andy: >=20 > Thank you for your question. Let me precise. >=20 > Jeff proposes that clients specify the priority mechanism is an = attribute that is stored in the NACM list on the agent (see Section 5.2 = as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted = below). The client-Agent identities are load in a mechanism which is = out-of-band from the I2RS protocol these values. Into the Client, the = Agent's ID is loaded. Into the Agent, the valid client's identity is = loaded along with the client's priority. AAA (Radius/Diameter) is an = example of an out-of-band mechanism to pass the information with. IMU = (in my understanding), the NACM on the agent is created based on this = AAA loading. The i2rs secondary identity is loaded via an edit-config = mechanism in a config operation (see section 5.1 of Jeff's document.). = Please let me know if my understanding of NACM creation based on AAA = input is correct. >=20 =20 That is an optional mode. There is also a local users table that can be used. =20 =20 > I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent = will be annotated with meta-data with the client-id, priority, and = secondary ID. >=20 > The only proposed change to section 5.2 requirements is to the=20 > sentence "Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. >=20 > " Additionally, during commit processing" is incorrect because there = is not commit processing. Jeff stated we are still working with both = NETCONF and RESTCONF - so we must allow for a commit process. In the = meeting I noted that the architecture indicates a change is possible = only if the priority is greater than (>) existing priority. (First = rather than last). Therefore this text should read: "Additionally, = during the operation (RESTCONF)/Commit (NETCONF) processing, if the = nodes are found where i2rs-priority is already present, and the priority = is equal to or better than the transaction's user's priority for the = node, the operation/commit SHALL fail." >=20 > Do you have any suggestions for modifications to section 5 of Jeff's = document? >=20 > Sue >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Jeff's document 5.2 states: >=20 > To support Multi-Headed Control, I2RS requires that there be a > decidable means of arbitrating the correct state of data when > multiple clients attempt to manipulate the same piece of data. = This > is done via a priority mechanism with the highest priority winning. > This priority may vary on a per-node or sub-tree basis based for a > given identity. >=20 > This further implies that priority is an attribute that is stored = in > the NETCONF Access Control Model [RFC6536] as part of a rule-list. > E.g.: >=20 > Ephemeral configuration state nodes that are created or altered by > users that match a rule carrying i2rs-priority will have those = nodes > annotated with metadata. Additionally, during commit processing, = if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. An appropriate error should be = returned > to the user stating the nodes where the user had insufficient > priority to override the state. >=20 =20 =20 The last paragraph sounds like some nodes will be accepted and others = rejected. If any nodes are rejected, the entire edit should be rejected. =20 I don;t think the rule-list should store the client priority. It should be in the 'group' list, or outside NACM completely. =20 =20 Andy =20 >=20 >=20 > -----Original Message----- > From: Andy Bierman [ = mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 7:40 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;=20 > i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >=20 > On Thu, May 28, 2015 at 4:22 PM, Susan Hares < = shares@ndzh.com> wrote: >> Andy: >>=20 >> Yes - the client with priority and secondary identity are inherently = simple additions. Can you confirm my understanding below based on = Jeff's document? >>=20 >=20 > Not sure what you mean. > i don't think the client should provide the priority in request = messages. > This is configured on the agent, not requested by the client. >=20 >=20 >> Can you explain your statement "I do not want to change NETCONF or = RESTCONF to use client priority?" What are you proposing that you do = not want to add the NACM list the priority? >=20 > I don't want to change NETCONF and RESTCONF so that config=3Dtrue = objects use priority. Only I2RS should use it. >=20 >>=20 >> Sue >=20 > Andy >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Example >> ------------------------ >> 1) any multiple TCP sessions from a client application will use a = different ID if they want a different priority for write of an object >> Application 1: TCP session 1 - priority 1, = secondary-identity "pub-sub monitor" >> Application 1: TCP session 2 - priority 10, = secondary-identity "tracing monitor" >> Application 1: TCP session 3 - priority 20, opaque "Weekly = config" >> Application 1: TCP session 4 - priority 55, opaque = "Emergency config" >>=20 >> Jeff's META-data example: >>=20 >> = https://ietf.example.com/i2rs" >> i2rs:i2rs-secondary-identity=3D"user1" = i2rs:i2rs-priority=3D"47"> >> ... >> >>=20 >> For my example TCP session 1 >> > I2rs:i2rs-secondary-identity=3D"pub-sub montior" >> i2rs:i2rs-priority=3D"1"> >>=20 >> Juergen's client example: >>=20 >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } >>=20 >> +--rw rule-list [name] >> +--rw name string >> +--rw group* union >> +--rw rule [name] >> +--rw name string >> +--rw module-name? union >> +--rw (rule-type)? >> | +--:(protocol-operation) >> | | +--rw rpc-name? union >> | +--:(notification) >> | | +--rw notification-name? union >> | +--:(data-node) >> | +--rw path node-instance-identifier >> +--rw access-operations? union >> +--rw action action-type >> +--rw comment? string >> +--rw i2rs:i2rs-priority i2rs-priority-type >>=20 >> Are you proposing something different than Jeff's proposal? >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Andy Bierman [ = mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 11:17 AM >> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey=20 >> Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas; Susan = Hares >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>=20 >> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder < = = j.schoenwaelder@jacobs-university.de> wrote: >>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>>=20 >>>> Although I should be promoting use of NACM, I am not so sure it=20 >>>> should be mandatory for I2RS or required to configure I2RS client = priority. >>>>=20 >>>> list i2rs-client { >>>> key name; >>>> leaf name { >>>> description "The client name"; >>>> type i2rs:client-name; >>>> } >>>> leaf priority { >>>> description "The priority value assigned to this client."; >>>> type i2rs:client-priority; >>>> } >>>> } >>>=20 >>> So what is i2rs:client-name - is it any different from a=20 >>> NETCONF/RESTCONF username? >>>=20 >>=20 >> Is is probably not different. >>=20 >>=20 >>> NACM maps user names into groups and NACM allows to have the mapping = >>> supplied by an external source (e.g. RADIUS). If this priority=20 >>> mapping is kept separate from NACM, would we need to provision means = >>> to get the priority from AAA as well? >>>=20 >>=20 >> My point showing the 2 item list is that the information needed to = implement I2RS client priority is rather trivial. >> It can certainly be made really complicated by the IETF, but it is an = inherently trivial configuration. >>=20 >>> And the bigger question: Do we create something specific for I2RS or = >>> are we going to extend the generic YANG/NC/RC framework to provide=20 >>> the tools I2RS needs? This is probably a question the NETCONF WG has = >>> to answer. >>=20 >> It is good to make reusable features. >> I don't want to change NETCONF or RESTCONF to use client priority. >> Let I2RS prove it is useful first. I am not convinced it will really = help. >> It seems like an implementation detail that is being turned into ad = administrative task. If multiple clients from multiple vendors are = stepping on each other, then the likely outcome of a priority change by = the administrator will be to select which clients should continue = working and which should be broken. >>=20 >>=20 >>>=20 >>> /js >>>=20 >>=20 >> Andy >>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 ------=_NextPart_000_03AC_01D09A15.86D856A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy: =

 

I missed the second part of the email =C2=A0(= http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in = my earlier message:

 

>. = " The last paragraph sounds like some nodes will be accepted and = others rejected.

>If any nodes = are rejected, the entire edit should be rejected.

 

RESTCONF does an atomic action within a http = session.=C2=A0=C2=A0 NETCONF within a commit.=C2=A0 Section 6.2 of the = I2RS architecture document describes state storage for I2RS, and it does = not have the atomic requirement for the protocol.=C2=A0 Instead section = 3.3 of the I2RS architecture document calls for this to be model = driver.=C2=A0 Let me provide examples from the 2 major I2RS protocol = independent models:

 

The = I2RS RIB yang model (dr= aft-ietf-i2rs-rib-data-model-00) =C2=A0proposes that each route will = be associated with the following: route preference, active, = installed.=C2=A0 Notifications for route change will be given if route = is installed, active, and a reason given, or if the route commit fails. = Some routes may be accepted, and some routes rejected for installation = to the RIB.=C2=A0 =C2=A0The concept is the client will be able to detect = when a route is rejected. =C2=A0

 

The = draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses the = challenge that topology models are not: configuration data only or = operational data only =E2=80=93 but a combination of both in ephemeral = state.=C2=A0 Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral = topology model which is operational (read-only) that contains data from: = a) only read from operational units, b) a configured topology, and c) = combination topology (operational state and configured).=C2=A0 (A second = alternative is to just have =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D, = but for now let=E2=80=99s focus on a, b, and c).=C2=A0 The = =E2=80=9CC=E2=80=9D combination topology may be generated based on = priority of configured topology versus operational data.=C2=A0 The = inclusion in =E2=80=9Cc=E2=80=9D may also be validated (E.g. interface = up, or L3 link runs on tunnel over interface which is up)).=C2=A0 =

 

These two model documents show why atomic state may = be on a very small section of the whole change. =C2=A0

=C2=A0

> I = don=E2=80=99t think the rule-list should store the client = priority.

> It should be in the = 'group' list, or outside NACM completely."

 

Your alternate proposal are: =

 

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Moving i2rs-priority to group list

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Adding a i2rs-client [unspecified location] =

 

This mail deals with #1.=C2=A0 If you have = more details on proposal #2, please suggest them on the list. = =C2=A0

 

list i2rs-client {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key = name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf name = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = description "The client name";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = type i2rs:client-name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf priority = {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = description "The priority value assigned to this = client.";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type = i2rs:client-priority;

=C2=A0=C2=A0=C2=A0=C2=A0 }

=C2=A0 }

 

Question: Is this i2rs-list to be included = in the group list for NACM (as listed below from RFC6536) as a leaf list = below?

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 container = groups {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = description

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 "NETCONF Access Control Groups.";

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0list group {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= key name;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 description

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 "One NACM Group Entry.=C2=A0 This list will only = contain

=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 configured entries, not any entries learned = from

=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 any transport = protocols.";

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 leaf name {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 type group-name-type;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 description

=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 "Group name associated with this = entry.";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 leaf-list user-name {

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 type user-name-type;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 description

=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 "Each entry identifies the username = of

=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 a member of the group associated = with

=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 this entry.";

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 }

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= # add leaf-list I2rs-client here

=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 = }

Your message: = http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html<= /o:p>

States: =C2=A0"I think I2RS = interaction with NACM needs to be clearly defined. NACM implementations = do not currently check write requests

on config=3Dfalse data. It is possible some edits = to NACM are needed even if no objects are added to the data = structure."

 

Do = you have a proposal for changing the text in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00?=C2=A0

Is it sufficient to state: = =C2=A0=C2=A0=E2=80=9CNACM implementations for I2RS will need to check = write request on config=3Dfalse, ephemeral =3D true. = =E2=80=9C

before the paragraph: =

 

=E2=80=9CEphemeral configuration state nodes that are = created or altered by users that match a rule carrying i2rs-priority = will have those nodes annotated with metadata.=C2=A0 Additionally, = during commit processing, if nodes are found where i2rs-priority is = already present, and the=C2=A0 priority is better than the transaction's = user's priority for that node, the commit SHALL fail. An appropriate = error should be returned

=C2=A0=C2=A0 = to the user stating the nodes where the user had = insufficient

=C2=A0=C2=A0 priority to = override the state.

 

I=E2=80=99m unclear what this means: =E2=80=9CIt is = possible some edits to NACM are needed even if no objects are added to = the data structure."

 

Sue =

 

-----Original Message-----
From: Andy Bierman = [mailto:andy@yumaworks.com]
Sent: Thursday, May 28, 2015 8:23 = PM
To: Susan Hares
Cc: Juergen Schoenwaelder; Joel M. Halpern; = Jeffrey Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas
Subject: = Re: [i2rs] draft-chen-i2rs-identifier-management-00

 

On = Thu, May 28, 2015 at 5:09 PM, Susan Hares <shares@ndzh.com> wrote:

> = Andy:

> 

> Thank you for your question.=C2=A0 Let me = precise.

> 

> Jeff proposes that clients specify the = priority mechanism is an attribute that is stored in the NACM list on = the agent (see Section 5.2 as described in the = draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).=C2=A0=C2=A0 The = client-Agent identities are load in a mechanism which is out-of-band = from the I2RS protocol these values.=C2=A0 Into the Client, the Agent's = ID is loaded.=C2=A0 Into the Agent, the valid client's identity is = loaded along with the client's priority.=C2=A0 AAA (Radius/Diameter) is = an example of an out-of-band mechanism to pass the information = with.=C2=A0 IMU (in my understanding), the NACM on the agent is created = based on this AAA loading.=C2=A0 The i2rs secondary identity is loaded = via an edit-config mechanism in a config operation (see section 5.1 of = Jeff's document.).=C2=A0 Please let me know if my understanding of NACM = creation based on AAA input is correct.

> 

 

That = is an optional mode.

There is also = a local users table that can be used.

 

 

> = I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent = will be annotated with meta-data with the client-id, priority, and = secondary ID.

> 

> The only proposed change to section 5.2 = requirements is to the

> = sentence "Additionally, during commit processing, = if

>=C2=A0=C2=A0=C2=A0 nodes = are found where i2rs-priority is already present, and = the

>=C2=A0=C2=A0=C2=A0 = priority is better than the transaction's user's priority for = that

> =C2=A0=C2=A0=C2=A0node, = the commit SHALL fail.

> 

> " Additionally, during commit = processing" is incorrect because there is not commit = processing.=C2=A0=C2=A0 Jeff stated we are still working with both = NETCONF and RESTCONF - so we must allow for a commit process.=C2=A0 In = the meeting I noted that the architecture indicates a change is possible = only if the priority is greater than (>) existing priority.=C2=A0 = (First rather than last).=C2=A0 Therefore this text should read:=C2=A0 = "Additionally, during the operation (RESTCONF)/Commit (NETCONF) = processing, if the nodes are found where i2rs-priority is already = present, and the priority is equal to or better than the transaction's = user's priority for the node, the operation/commit SHALL = fail."

> 

> Do you have any suggestions for modifications = to section 5 of Jeff's document?

> 

> Sue

> 

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

> Jeff's document 5.2 = states:

> 

>=C2=A0=C2=A0 To support Multi-Headed Control, = I2RS requires that there be a

>=C2=A0=C2=A0=C2=A0 decidable means of = arbitrating the correct state of data when

>=C2=A0=C2=A0=C2=A0 multiple clients attempt to = manipulate the same piece of data.=C2=A0 This

>=C2=A0=C2=A0=C2=A0 is done via a priority = mechanism with the highest priority winning.

>=C2=A0=C2=A0=C2=A0 This priority may vary on a = per-node or sub-tree basis based for a

>=C2=A0=C2=A0=C2=A0 given = identity.

> 

>=C2=A0=C2=A0=C2=A0 This further implies that = priority is an attribute that is stored in

>=C2=A0=C2=A0=C2=A0 the NETCONF Access Control = Model [RFC6536] as part of a rule-list.

>=C2=A0=C2=A0=C2=A0 E.g.:

> 

>=C2=A0=C2=A0=C2=A0 Ephemeral configuration = state nodes that are created or altered by

>=C2=A0=C2=A0=C2=A0 users that match a rule = carrying i2rs-priority will have those nodes

>=C2=A0=C2=A0=C2=A0 annotated with = metadata.=C2=A0 Additionally, during commit processing, = if

>=C2=A0=C2=A0=C2=A0 nodes = are found where i2rs-priority is already present, and = the

>=C2=A0=C2=A0=C2=A0 = priority is better than the transaction's user's priority for = that

>=C2=A0=C2=A0=C2=A0 node, = the commit SHALL fail.=C2=A0 An appropriate error should be = returned

>=C2=A0=C2=A0=C2=A0 to = the user stating the nodes where the user had = insufficient

>=C2=A0=C2=A0=C2=A0 priority to override the = state.

> 

 

 

The = last paragraph sounds like some nodes will be accepted and others = rejected.

If any nodes are = rejected, the entire edit should be rejected.

 

I = don;t think the rule-list should store the client = priority.

It should be in the = 'group' list, or outside NACM completely.

 

 

Andy

 

> 

> 

> -----Original Message-----

> From: Andy Bierman [mailto:andy@yumaworks.com= ]

> Sent: Thursday, = May 28, 2015 7:40 PM

> To: = Susan Hares

> Cc: Juergen = Schoenwaelder; Joel M. Halpern; Jeffrey Haas;

> i2rs@ietf.org;= chen.ran@zte.com.cn; Alia Atlas

> Subject: = Re: [i2rs] draft-chen-i2rs-identifier-management-00

> 

> On Thu, May 28, 2015 at 4:22 PM, Susan Hares = <shares@ndzh.com> wrote:

>> = Andy:

>> 

>> Yes - the client with priority and = secondary identity are inherently simple additions.=C2=A0=C2=A0 Can you = confirm my understanding below based on Jeff's = document?

>> 

> 

> Not sure what you mean.

> i don't think the client should provide the = priority in request messages.

> = This is configured on the agent, not requested by the = client.

> 

> 

>> Can you explain=C2=A0 your statement = "I do not want to change NETCONF or RESTCONF to use client = priority?"=C2=A0 What are you proposing that you do not want to add = the NACM list the priority?

> 

> I don't want to change NETCONF and RESTCONF so = that config=3Dtrue objects use priority.=C2=A0 Only I2RS should use = it.

> 

>> 

>> Sue

> 

> Andy

> 

>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>> 

>> Example

>> ------------------------

>> 1) any multiple TCP sessions from a client = application will use a different ID if they want a different priority = for write of an object

>>=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 Application 1:=C2=A0 TCP session 1 = -=C2=A0 priority 1,=C2=A0 secondary-identity=C2=A0 "pub-sub = monitor"

>>=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 Application 1:=C2=A0 TCP session 2 - = priority 10, secondary-identity "tracing = monitor"

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Application 1:=C2=A0 TCP session 3 -=C2=A0 priority 20, opaque = "Weekly config"

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Application 1:=C2=A0 TCP session 4 -=C2=A0 priority 55, opaque = "Emergency config"

>> 

>> Jeff's META-data=C2=A0 = example:

>> 

>>=C2=A0=C2=A0 <foo xmlns:i2rs=3D"https://ietf.example.com/= i2rs"

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 i2rs:i2rs-secondary-identity=3D"user1" = i2rs:i2rs-priority=3D"47">

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = ...

>>=C2=A0=C2=A0=C2=A0 = </foo>

>> 

>> For my example TCP session = 1

>>=C2=A0=C2=A0=C2=A0 = <foo = xmlns:i2rs=3D"http:s//ietf.example.com/i2rs"

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 I2rs:i2rs-secondary-identity=3D"pub-sub = montior"

>> = i2rs:i2rs-priority=3D"1">

>> 

>> Juergen's client example:

>> 

>>=C2=A0=C2=A0=C2=A0=C2=A0 list i2rs-client = {

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = key name;

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf = name {

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 description "The client name";

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 type i2rs:client-name;

>>=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 = leaf priority {

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 description "The priority value assigned to this = client.";

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 type i2rs:client-priority;

>>=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 +--rw rule-list = [name]

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = name=C2=A0=C2=A0=C2=A0=C2=A0 string

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = group*=C2=A0=C2=A0 union

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw = rule [name]

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw name string

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw module-name?=C2=A0 union

>>=C2=A0=C2=A0=C2=A0=C2=A0 = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+--rw (rule-type)?

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 +--:(protocol-operation)

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 |=C2=A0 +--rw rpc-name?=C2=A0 union

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 +--:(notification)

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 |=C2=A0 +--rw notification-name?=C2=A0 = union

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 +--:(data-node)

>>=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 +--rw path = node-instance-identifier

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw access-operations?=C2=A0 union

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw action action-type

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw comment?=C2=A0 string

>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 +--rw i2rs:i2rs-priority i2rs-priority-type

>> 

>> Are you proposing something different than = Jeff's proposal?

>> 

>> Sue

>> 

>> -----Original = Message-----

>> From: Andy = Bierman [mailto:andy@yumaworks.com= ]

>> Sent: = Thursday, May 28, 2015 11:17 AM

>> To: Juergen Schoenwaelder; Andy Bierman; = Joel M. Halpern; Jeffrey

>> = Haas; i2rs@ietf.org;= chen.ran@zte.com.cn; Alia Atlas; Susan Hares

>> Subject: Re: [i2rs] = draft-chen-i2rs-identifier-management-00

>> 

>> On Wed, May 27, 2015 at 11:05 PM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de> wrote:

>>> On Wed, May 27, 2015 at 06:04:58PM = -0700, Andy Bierman wrote:

>>>> 

>>>> Although I should be promoting use = of NACM, I am not so sure it

>>>> should be mandatory for I2RS or = required to configure I2RS client priority.

>>>> 

>>>>=C2=A0=C2=A0=C2=A0 list i2rs-client = {

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= key name;

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= leaf name {

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 description "The client = name";

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 type i2rs:client-name;

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= }

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= leaf priority {

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 description "The priority value assigned to this = client.";

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 type i2rs:client-priority;

>>>>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = }

>>>>=C2=A0=C2=A0 = }

>>> 

>>> So what is i2rs:client-name - is it = any different from a

>>> = NETCONF/RESTCONF username?

>>> 

>> 

>> Is is probably not = different.

>> 

>> 

>>> NACM maps user names into groups and = NACM allows to have the mapping

>>> supplied by an external source (e.g. = RADIUS). If this priority

>>> mapping is kept separate from NACM, = would we need to provision means

>>> to get the priority from AAA as = well?

>>> 

>> 

>> My point showing the 2 item list is that = the information needed to implement I2RS client priority is rather = trivial.

>> It can certainly = be made really complicated by the IETF, but it is an inherently trivial = configuration.

>> 

>>> And the bigger question: Do we create = something specific for I2RS or

>>> are we going to extend the generic = YANG/NC/RC framework to provide

>>> the tools I2RS needs? This is probably = a question the NETCONF WG has

>>> to answer.

>> 

>> It is good to make reusable = features.

>> I don't want to = change NETCONF or RESTCONF to use client priority.

>> Let I2RS prove it is useful first.=C2=A0 I = am not convinced it will really help.

>> It seems like an implementation detail = that is being turned into ad administrative task.=C2=A0 If multiple = clients from multiple vendors are stepping on each other, then the = likely outcome of a priority change by the administrator will be to = select which clients should continue working and which should be = broken.

>> 

>> 

>>> 

>>> /js

>>> 

>> 

>> Andy

>> 

>>> --

>>> Juergen = Schoenwaelder=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Jacobs University Bremen gGmbH

>>> Phone: +49 421 200 = 3587=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Campus Ring 1 | = 28759 Bremen | Germany

>>> Fax:=C2=A0=C2=A0 +49 421 200 = 3103=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <http://www.jacobs-univers= ity.de/>

>> 

>> = _______________________________________________

>> i2rs mailing list

>> i2rs@ietf.org<= o:p>

>> https://www.ietf.org/mail= man/listinfo/i2rs

> 

------=_NextPart_000_03AC_01D09A15.86D856A0-- From nobody Fri May 29 11:18: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 0DDAE1B2BC5 for ; Fri, 29 May 2015 11:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAJl15B_6nnB for ; Fri, 29 May 2015 11:18:55 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7D51B2BB4 for ; Fri, 29 May 2015 11:18:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" , "'Juergen Schoenwaelder'" , , , "'Alia Atlas'" , "'Jeffrey Haas'" , "'Joel M. Halpern'" References: <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> <036601d09a28$faab15f0$f00141d0$@ndzh.com> <20150529162508.GA6146@elstar.local> In-Reply-To: Date: Fri, 29 May 2015 14:18:42 -0400 Message-ID: <03d901d09a3b$e5943df0$b0bcb9d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJfjQnE9Ei0CxLytGvy0CaN1XGyKQLBMjzgASfbTTQB78OurQGWjOdKAuds2LkBdA6PPAHyN7BfAbh0/3ADRzYjZQJ3/FbuAcrTXTGbvVyt4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 18:18:57 -0000 Andy:=20 I agree that priority in draft-haas-i2rs-ephemeral-state-reqs links to = each NACM rule. Jeff states in section 5.2 "this priority may vary on = a per-node or sub-tree basis based for a given identity". =20 Joel states = http://www.ietf.org/mail-archive/web/i2rs/current/msg02522.html states=20 "Priority is associated with a client. A client does not get to change = its priority (although administrators clearly can)."=20 Alia also stated that if an application wants to use an I2RS client to = connect with multiple TCP sessions with different priorities, the client = should utilize a different identity for each different priority. With = this restriction, each client has 1 priority setting whether or not it = utilizes the multiple TCP sessions.=20 If we can reach consensus on this point, then we can suggest change to = Jeff's document in section 5.2 based on that consensus. If you agree, = my next step is to call for consensus on this point, so we can change = Jeff's document based on this consensus. =20 =20 Sue=20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, May 29, 2015 12:47 PM To: Juergen Schoenwaelder; Susan Hares; i2rs@ietf.org; = chen.ran@zte.com.cn; Andy Bierman; Alia Atlas; Jeffrey Haas; Joel M. = Halpern Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Fri, May 29, 2015 at 9:25 AM, Juergen Schoenwaelder = wrote: > Thanks for all the details but I am missing an answer to my question. > Shall I repeat it once more? The proposal is that the priority is a property of each NACM rule. Since NACM rules can be shared by multiple groups this design will not = actually work. As Martin pointed out, rules common to multiple groups = will produce data with the same priority. It should also be noted that = NACM has "default behavior" that is followed even if no rules are = actually configured. IMO priority is associated with the client. A client can be placed in multiple NACM groups. When an edit request is made the client does not indicate which group = should be used. The server will pick the highest priority group that = the user is a member, and use that for the priority. (Therefore priority = is not the property of the group either). It has been suggested that the client can connect multiple times, and = each transport connection will somehow convey a different priority to = the server. I don't see how this will work. It seems that different = client names are needed. This is true whether NACM or a client mapping = table is used. The system must produce a different client name in order = to use a different priority. > > /js Andy > > On Fri, May 29, 2015 at 12:03:18PM -0400, Susan Hares wrote: >> Juergen: >> >> >> >> Thank you for asking the question again. I appreciate your patience=20 >> as I attempt to answer your question carefully. >> >> >> >> Short answer: I2RS strategy is re-use of other protocols rather than=20 >> invent, and this seemed a reasonable place to put it. >> >> >> >> Context: Jeff's document is a proposal for the requirements for I2RS=20 >> to the NETCONF/NETMOD WG on ephemeral state. Feedback on the earlier = >> descriptions from the I2RS group had been "too vague" so Jeff's=20 >> document is providing detailed requirements. I2RS is not designing=20 >> thing for NETCONF only making known in detailed terms our=20 >> requirements to aid the NETCONF group's response on whether the I2RS = design requirements can be met. >> >> >> >> Longer Answer: His proposal arises out of section 4.2 in the I2RS=20 >> architecture document. This section states: >> >> >> >> An approach to a similar access control problem is defined in the=20 >> NetConf Access Control Model (NACM) [RFC6536]; it allows arbitrary=20 >> access to be specified for a data node instance identifier while=20 >> defining meaningful manipulable defaults. The identity within NACM=20 >> [RFC6536] can be specifying as either a user name or a group user=20 >> name (e.g. Root), and this name is linked a scope policy that = contained in a set of access control rules. >> Similarly, it is expected the I2RS identity links to one role which=20 >> has a scope policy specified by a set of access control rules. This=20 >> scope policy is can be provided via Local Config, exposed as an I2RS = Service for >> manipulation by authorized clients, or via some other method (e.g. = AAA >> service). >> >> >> >> You can see in this point that the client identity is being linked to = >> the scope policy controlling read or write. Section 7.8 points out=20 >> that priority "ensures predictability" in write conditions between=20 >> two I2RS Clients trying to write data in one agent, or between an = I2RS client and the >> local config. Jeff's requirements flow out of these two sections in = the >> architecture document. >> >> >> >> What you can do: If you have an alternate suggestion for priority for = >> Jeff's document, please make a suggestion and indicate why you think=20 >> it fits within the I2RS architecture document (please list sections). >> >> >> >> Sue >> >> >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >> Schoenwaelder >> Sent: Friday, May 29, 2015 2:10 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; = >> 'Jeffrey Haas'; 'Joel M. Halpern' >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> >> >> On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: >> >> > Andy: >> >> > >> >> > Thank you for your question. Let me precise. >> >> > >> >> > Jeff proposes that clients specify the priority mechanism is an=20 >> > attribute >> that is stored in the NACM list on the agent (see Section 5.2 as = described >> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >> client-Agent identities are load in a mechanism which is out-of-band=20 >> from the I2RS protocol these values. Into the Client, the Agent's ID = is loaded. >> Into the Agent, the valid client's identity is loaded along with the=20 >> client's priority. AAA (Radius/Diameter) is an example of an=20 >> out-of-band mechanism to pass the information with. IMU (in my=20 >> understanding), the NACM on the agent is created based on this AAA=20 >> loading. The i2rs secondary identity is loaded via an edit-config=20 >> mechanism in a config operation (see section 5.1 of Jeff's=20 >> document.). Please let me know if my understanding of NACM creation = based on AAA input is correct. >> >> > >> >> >> >> So I will ask again: If the priority is a property of the I2RS client = >> (this is how I understand the I2RS architecture document), why would=20 >> it be configured as part of a NACM rule as suggestd in section 5.2 of = >> draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the=20 >> priority a property of the scope of a NACM group. >> >> >> >> /js >> >> >> >> -- >> >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> >> Fax: +49 421 200 3103 < >> http://www.jacobs-university.de/> >> >> >> >> _______________________________________________ >> >> i2rs mailing list >> >> i2rs@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/i2rs >> > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri May 29 12:10:32 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF5C1B2C6A for ; Fri, 29 May 2015 12:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.854 X-Spam-Level: X-Spam-Status: No, score=-97.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 fQawtkEwg-s7 for ; Fri, 29 May 2015 12:10:24 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id DC90C1B2C66 for ; Fri, 29 May 2015 12:10:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <20150529061023.GB1694@elstar.local> In-Reply-To: <20150529061023.GB1694@elstar.local> Date: Fri, 29 May 2015 15:10:03 -0400 Message-ID: <03e401d09a43$11748680$345d9380$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03E5_01D09A21.8A6A87A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8BuHT/cJ2T1rZw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeff Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , 'Alia Atlas' , 'Andy Bierman' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 19:10:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03E5_01D09A21.8A6A87A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: I appreciate your patience as I attempt to answer your question in these three emails: http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html If the priority is a property of the I2RS client (this is how I understand the I2RS architecture document), why would it be configured as part of a NACM rule as suggestd in section 5.2 of draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a property of the scope of a NACM group. http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html "My concern is the server and I like to get an answer whether the priority is a property of a client, a property of a NACM group (of clients), or whether the priority is a property of a NACM access control rule." http://www.ietf.org/mail-archive/web/i2rs/current/msg02536.html Thanks for all the details but I am missing an answer to my question. Shall I repeat it once more? Short Answer: I agree with Andy's message that priority is an property/attribute of a client. Alia and Joel state that 1 client has 1 and only 1 priority. Only an administrator can change the priority associated with a client. No one has specified what occurs when the administrator changes priority. Andy's 3 proposals below do not provide a complete alternate proposal to Jeff proposal. Recommendation: I recommend we call for consensus for a client having 1 and only 1 priority, and determine what happens when the administrator can change the priority. After we agree, we can focus on suggesting a change to section 5.2 of draft-haas-i2rs-ephemeral-state-req. Jeff's statement "This priority may vary on a per-node or sub-tree basis based for a given identity" does not seem to have consensus with the I2RS WG. Longer Answer: Section 5.2 draft-haas-i2rs-ephemeral-state-reqs links this to a NACM that is arbitrating the correct state of data when multiple clients attempt to manipulate the same piece of data. This is done via a priority mechanism with the highest priority winning. Draft-haas-i2rs-ephemeral-state-req states "this priority may vary on a per-node or sub-tree basis based for a given identity." Jeff's proposal arises out of section 4.2 in the I2RS architecture document. This section states: An approach to a similar access control problem is defined in the NetConf Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be specified for a data node instance identifier while defining meaningful manipulable defaults. The identity within NACM [RFC6536] can be specifying as either a user name or a group user name (e.g. Root), and this name is linked a scope policy that contained in a set of access control rules. Similarly, it is expected the I2RS identity links to one role which has a scope policy specified by a set of access control rules. This scope policy is can be provided via Local Config, exposed as an I2RS Service for manipulation by authorized clients, or via some other method (e.g. AAA service). You can see in this point that the client identity is being linked to the scope policy controlling read or write. Section 7.8 points out that priority "ensures predictability" in write conditions between two I2RS Clients trying to write data in one agent, or between an I2RS client and the local config. Jeff's requirements flow out of this section, but he makes the assumption that: "This priority may vary on a per-node or sub-tree basis based for a given identity." (section 5.2) A consensus call will be issue to check to agree that: "A client identity have only 1 priority for all nodes or sub-trees. If a client uses multiple TCP sessions each with a different priority, the client must use multiple identities where each identity is linked to 1 and only 1 priority." ============ Andy's Proposals: Andy's Bierman's suggestion in http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html has been responded to in other email asking for clarification of the proposal. Proposal 1: Moving i2rs-priority to client user This is a Is a change section 5.2 of draft-haas-i2rs-ephemeral-state-reqs to move from NACM +--rw i2rs:i2rs-priority i2rs-priority-type Andy states jeff's change is optional mode of NACM (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) . Andy first indicates Jeff thought the the priority can be on the group-list (http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html), but later he revises his opinion ( http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html) to state this must be associated with the client. He notes Martin mentioned this first. This placement of priority on client aligns with Joel and Alia's comments. Issue regarding this options: Why are we not using NACM rule list to protect against multiple write access by lower priority clients? 1) If we agree that a client can be linked to a single priority - it doesn't matter where it is located. It can be configured by AAA and stored in a location in the I2RS Agent and the I2RS client. 2) Andy states in http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html "I don't think the client should provide the priority in request messages. This is configured on the agent, not requested by the client." IMHO Jeff's proposal suggests it is passed in out-of-band mechanism from netconf or i2RS additions to netconf. 3) Mixing client and groups is problematic: http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html states: " A client can be placed in multiple NACM groups. When an edit request is made the client does not indicate which group should be used. The server will pick the highest priority group that the user is a member, and use that for the priority." Proposal 2) Adding a i2rs-client to local users table (from http://www.ietf.org/mail-archive/web/i2rs/current/msg02541.html) Actually the local user table is in ietf-system.yang: http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.659 The 'user-name' leaf-list in the NACM 'group' list is populated by the administrator. The actual values are irrelevant to NACM. They can be local users, Radius, or anything else. Adding a user-name to this list does not in any way enable the server to accept sessions from that user. This is outside the scope of NACM. Issues with this proposal: 1) This proposal does not use NACM to enforce the I2RS priority mechanism. It requires the I2RS agent to create additional mechanisms to enforce use of priority to resolve multi-headed control writes. 2) Andy states in http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html "I don't think the client should provide the priority in request messages. This is configured on the agent, not requested by the client." Does this propose it is passed in an unsecure way? Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs - implies this is stored in a NACM rule list on the agent. How the NACM rule is generated is not specified IMHO. Proposal 3: Andy states in http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html "I don't want to change NETCONF and RESTCONF so that config=true objects use priority. Only I2RS should use it." Comment: Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs only applies to config=false. Is there some wording that needs to be added to make sure Andy's concern is addressed. Let me know if you have more questions. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Friday, May 29, 2015 2:10 AM To: Susan Hares Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia Atlas'; 'Jeffrey Haas'; 'Joel M. Halpern' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote: > Andy: > > Thank you for your question. Let me precise. > > Jeff proposes that clients specify the priority mechanism is an attribute that is stored in the NACM list on the agent (see Section 5.2 as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The client-Agent identities are load in a mechanism which is out-of-band from the I2RS protocol these values. Into the Client, the Agent's ID is loaded. Into the Agent, the valid client's identity is loaded along with the client's priority. AAA (Radius/Diameter) is an example of an out-of-band mechanism to pass the information with. IMU (in my understanding), the NACM on the agent is created based on this AAA loading. The i2rs secondary identity is loaded via an edit-config mechanism in a config operation (see section 5.1 of Jeff's document.). Please let me know if my understanding of NACM creation based on AAA input is correct. > So I will ask again: If the priority is a property of the I2RS client (this is how I understand the I2RS architecture document), why would it be configured as part of a NACM rule as suggestd in section 5.2 of draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a property of the scope of a NACM group. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_03E5_01D09A21.8A6A87A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen:

 

I = appreciate your patience as I attempt to answer your question in these = three emails:

= http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html<= /o:p>

If the priority is a property =
of the I2RS client
(this is how I understand the I2RS architecture =
document), why would
it be configured as part of a NACM rule as =
suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's =
design makes the
priority a property of the scope of a NACM =
group.

 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html<= /o:p>

“My concern is the server and I like to get an = answer whether the priority

is a property of a client, a property of a NACM group = (of clients), or

whether = the priority is a property of a NACM access control = rule.”

 

= http://www.ietf.org/mail-archive/web/i2rs/current/msg02536.html<= /o:p>

Thanks for all the =
details but I am missing an answer to my =
question.
Shall =
I repeat it once more?

 

 

Short = Answer:   I agree with Andy’s message that priority = is an property/attribute of a client.  Alia and Joel state that 1 = client has 1 and only 1 priority.  Only an administrator can change = the priority associated with a client.  No one has specified what = occurs when the administrator changes priority.  Andy’s 3 = proposals below do not provide a complete alternate proposal to Jeff = proposal.  

 

Recommendation: I recommend we call for = consensus for a client having 1 and only 1 priority, and determine what = happens when the administrator can change the priority.  =  After we agree, we can focus on suggesting a change to section 5.2 = of draft-haas-i2rs-ephemeral-state-req.  Jeff’s statement = “This priority may vary on a per-node or sub-tree basis based for = a given identity” does not seem to have consensus with the I2RS = WG.    

 

Longer Answer:    Section 5.2 = draft-haas-i2rs-ephemeral-state-reqs  links this to a NACM that is = arbitrating the correct state of data when multiple clients attempt to = manipulate the same piece of data.  This is done via a priority = mechanism with the highest priority winning.  = Draft-haas-i2rs-ephemeral-state-req states “this priority may vary = on a per-node or sub-tree basis based for a given identity.”  = Jeff’s  proposal arises out of section 4.2 in the I2RS = architecture document.  This section states:

 

An approach to a similar access control = problem is defined in the NetConf Access Control Model (NACM) [RFC6536]; = it allows arbitrary access to be specified for a data node instance = identifier while defining meaningful manipulable defaults.  The = identity within NACM [RFC6536] can be specifying as either a user name = or a group user name (e.g.  Root), and this name is linked a scope = policy that contained in a set of access control rules.  Similarly, = it is expected the I2RS identity links to one role which has a scope = policy specified by a set of access control rules.  This scope = policy is can be provided via Local Config, exposed as an I2RS Service = for  manipulation by authorized clients, or via some other method = (e.g.   AAA service).

 

You = can see in this point that the client identity is being linked to the = scope policy controlling read or write.  Section 7.8 points out = that priority “ensures predictability” in write conditions = between two I2RS Clients trying to write data in one agent, or between = an I2RS client and the local config.   Jeff’s = requirements flow out of this section, but he makes the assumption that: = “This priority may vary on a per-node = or sub-tree basis based for a given identity.” (section 5.2) =

 

A consensus call will be issue to check to agree = that:

“A client = identity have only 1 priority for all nodes or sub-trees.  If a = client uses multiple TCP sessions each with a different priority, the = client must use multiple identities where each identity is linked to 1 = and only 1 priority.”

 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Andy’s Proposals:  Andy’s = Bierman’s suggestion in = http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html = has been responded to in other email asking for clarification of the = proposal.   

 

Proposal 1: Moving i2rs-priority to client = user

 

  This is a Is a change section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs  to move from = NACM

 

  =
+--rw i2rs:i2rs-priority i2rs-priority-type

 

Andy = states jeff’s change is  optional mode of NACM (= http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) . = Andy first indicates Jeff thought the the priority can be on the = group-list (= http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html), = but later he revises his opinion ( = http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html) to = state this must be associated with the client.  He notes Martin = mentioned this first. This placement of priority on client aligns with = Joel and Alia’s comments.

 

Issue regarding this options:  Why are = we not using NACM rule list to protect against multiple write access by = lower priority clients?

1)      = If we agree that a client can be linked to a = single priority – it doesn’t matter where it is located. =  It can be configured by AAA and stored in a location in the I2RS = Agent and the I2RS client.

 

2)      = Andy states in = http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html<= /o:p>

“I don't think the client should provide =
the priority in request messages. This is configured on the agent, not =
requested by the client.” IMHO Jeff’s proposal suggests it is passed in out-of-band =
mechanism from netconf or i2RS additions to netconf. =

 

3) Mixing client and groups is problematic: =

= http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html = states:

 

“ A client can be placed in multiple NACM =
groups. 
When an =
edit request is made the client does =
not
indicate =
which group should be used.  The server =
will
pick the =
highest priority group that the user is a =
member,
and use =
that for the priority.”  

 

Proposal 2) Adding a i2rs-client to local = users table

 

(from = = http://www.ietf.org/mail-archive/web/i2rs/current/msg02541.html) =

 

Actually the local user table is in =
ietf-system.yang:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.6=
59
 
The 'user-name' leaf-list in the NACM 'group' list =
is populated by
the administrator.  The actual values are =
irrelevant to NACM.
They can be local users, Radius, or anything =
else.  Adding a user-name
to this list does not in any way enable the server =
to accept sessions
from that user.  This is outside the scope of =
NACM.

 

Issues = with this proposal:

1)      = This proposal does not use NACM to enforce the = I2RS priority mechanism.  It requires the I2RS agent to create = additional mechanisms to enforce use of priority to resolve multi-headed = control writes.

 

2)      = Andy states in = http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html<= /o:p>

“I don't think the client should provide =
the priority in request messages. This is configured on the agent, not =
requested by the client.”  Does this propose it is passed in an unsecure way? =

 
Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs – implies =
this is stored in a NACM rule list on the agent.  How the NACM rule =
is generated is not specified IMHO. 
 
 

Proposal = 3: Andy states in = http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html<= /o:p>

 
“I don't want to change NETCONF and RESTCONF =
so that config=3Dtrue objects use priority.  Only I2RS should use =
it.”

 

Comment:  Section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs only applies to = config=3Dfalse.  Is there some wording that

needs to be added to = make sure Andy’s concern is addressed. 

 
Let me know if you have more questions. =

 
Sue

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan = Hares
Cc: i2rs@ietf.org; chen.ran@zte.com.cn; 'Andy Bierman'; 'Alia = Atlas'; 'Jeffrey Haas'; 'Joel M. Halpern'
Subject: Re: [i2rs] = draft-chen-i2rs-identifier-management-00

 

On = Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares = wrote:

> Andy: =

>

> Thank you for your question.  Let me = precise.

>

> Jeff proposes that clients specify the = priority mechanism is an attribute that is stored in the NACM list on = the agent (see Section 5.2 as described in the = draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The = client-Agent identities are load in a mechanism which is out-of-band = from the I2RS protocol these values.  Into the Client, the Agent's = ID is loaded.  Into the Agent, the valid client's identity is = loaded along with the client's priority.  AAA (Radius/Diameter) is = an example of an out-of-band mechanism to pass the information = with.  IMU (in my understanding), the NACM on the agent is created = based on this AAA loading.  The i2rs secondary identity is loaded = via an edit-config mechanism in a config operation (see section 5.1 of = Jeff's document.).  Please let me know if my understanding of NACM = creation based on AAA input is correct. 

> 

 

So I = will ask again: If the priority is a property of the I2RS client (this = is how I understand the I2RS architecture document), why would it be = configured as part of a NACM rule as suggestd in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the = priority a property of the scope of a NACM group.

 

/js

 

-- =

Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

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

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_03E5_01D09A21.8A6A87A0-- From nobody Fri May 29 14:57: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 931881A896D for ; Fri, 29 May 2015 14:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.254 X-Spam-Level: X-Spam-Status: No, score=-97.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 vxZCXg9DLCL7 for ; Fri, 29 May 2015 14:57:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B4B0D1A8993 for ; Fri, 29 May 2015 14:56:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" , "'Jeff Haas'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> In-Reply-To: Date: Fri, 29 May 2015 17:55:42 -0400 Message-ID: <000901d09a5a$36044cd0$a20ce670$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D09A38.AEFBD490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4gHkIGQTnX4bhAA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Fri, 29 May 2015 21:57:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D09A38.AEFBD490 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 On all actions working or not =E2=80=93 you should look at section 7.9 = of the architecture. It allows =E2=80=9Cperform all or none=E2=80=9D, = =E2=80=9Cperform until error=E2=80=9D, and =E2=80=9Cperform all storing = errors.=E2=80=9D I will propose an addition to section 2.4 to = Jeff=E2=80=99s document:=20 =20 2.4 ) Transaction to ephemeral state:=20 =20 The ephemeral state should support a multiple parts of a operation = occurring in a single message, but it does not require multi-message = atomicity and rollback. Three types of error handling should be = supported:=20 =20 Perform all or none: This traditional SNMP semantic indicates that other I2RS agent will keep enough state when handling a single message to roll back the operations within that message. Either all the operations will succeed, or none of them will be applied and an error message will report the single failure which caused them not to be applied. This is useful when there are, for example, mutual dependencies across operations in the message. =20 Perform until error: In this case, the operations in the message are applied in the specified order. When an error occurs, no further operations are applied, and an error is returned indicating the failure. This is useful if there are dependencies among the operations and they can be topologically sorted. =20 Perform all storing errors: In this case, the I2RS Agent will attempt to perform all the operations in the message, and will return error indications for each one that fails. This is useful when there is no dependency across the operation, or where the client would prefer to sort out the effect of errors on its own. =20 In the interest of robustness and clarity of protocol state, the protocol will include an explicit reply to modification or write operations even when they fully succeed. =20 =20 Will this cover the architecture document 7.9 transactions impact on = ephemeral state?=20 =20 Sue Hares =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, May 29, 2015 1:44 PM To: 'Andy Bierman' Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; = 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 =20 Andy:=20 =20 I missed the second part of the email = (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my = earlier message:=20 =20 >. " The last paragraph sounds like some nodes will be accepted and = others rejected. >If any nodes are rejected, the entire edit should be rejected. =20 RESTCONF does an atomic action within a http session. NETCONF within a = commit. Section 6.2 of the I2RS architecture document describes state = storage for I2RS, and it does not have the atomic requirement for the = protocol. Instead section 3.3 of the I2RS architecture document calls = for this to be model driver. Let me provide examples from the 2 major = I2RS protocol independent models:=20 =20 The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00 = ) = proposes that each route will be associated with the following: route = preference, active, installed. Notifications for route change will be = given if route is installed, active, and a reason given, or if the route = commit fails. Some routes may be accepted, and some routes rejected for = installation to the RIB. The concept is the client will be able to = detect when a route is rejected. =20 =20 The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses = the challenge that topology models are not: configuration data only or = operational data only =E2=80=93 but a combination of both in ephemeral = state. Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral = topology model which is operational (read-only) that contains data from: = a) only read from operational units, b) a configured topology, and c) = combination topology (operational state and configured). (A second = alternative is to just have =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D, = but for now let=E2=80=99s focus on a, b, and c). The = =E2=80=9CC=E2=80=9D combination topology may be generated based on = priority of configured topology versus operational data. The inclusion = in =E2=80=9Cc=E2=80=9D may also be validated (E.g. interface up, or L3 = link runs on tunnel over interface which is up)). =20 =20 These two model documents show why atomic state may be on a very small = section of the whole change. =20 =20 > I don=E2=80=99t think the rule-list should store the client priority. > It should be in the 'group' list, or outside NACM completely." =20 Your alternate proposal are:=20 =20 1) Moving i2rs-priority to group list=20 2) Adding a i2rs-client [unspecified location]=20 =20 This mail deals with #1. If you have more details on proposal #2, = please suggest them on the list. =20 =20 list i2rs-client { key name; leaf name { description "The client name"; type i2rs:client-name; } leaf priority { description "The priority value assigned to this client."; type i2rs:client-priority; } } =20 Question: Is this i2rs-list to be included in the group list for NACM = (as listed below from RFC6536) as a leaf list below?=20 =20 container groups { description "NETCONF Access Control Groups."; =20 list group { key name; description "One NACM Group Entry. This list will only contain configured entries, not any entries learned from any transport protocols."; =20 leaf name { type group-name-type; description "Group name associated with this entry."; } =20 leaf-list user-name { type user-name-type; description "Each entry identifies the username of a member of the group associated with this entry."; } # add leaf-list I2rs-client here=20 } } Your message: = http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html States: "I think I2RS interaction with NACM needs to be clearly = defined. NACM implementations do not currently check write requests on config=3Dfalse data. It is possible some edits to NACM are needed = even if no objects are added to the data structure." =20 Do you have a proposal for changing the text in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00? =20 Is it sufficient to state: =E2=80=9CNACM implementations for I2RS will = need to check write request on config=3Dfalse, ephemeral =3D true. = =E2=80=9C before the paragraph:=20 =20 =E2=80=9CEphemeral configuration state nodes that are created or altered = by users that match a rule carrying i2rs-priority will have those nodes = annotated with metadata. Additionally, during commit processing, if = nodes are found where i2rs-priority is already present, and the = priority is better than the transaction's user's priority for that node, = the commit SHALL fail. An appropriate error should be returned to the user stating the nodes where the user had insufficient priority to override the state. =20 I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some edits = to NACM are needed even if no objects are added to the data structure." =20 Sue=20 =20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, May 28, 2015 8:23 PM To: Susan Hares Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 =20 On Thu, May 28, 2015 at 5:09 PM, Susan Hares < = shares@ndzh.com> wrote: > Andy: >=20 > Thank you for your question. Let me precise. >=20 > Jeff proposes that clients specify the priority mechanism is an = attribute that is stored in the NACM list on the agent (see Section 5.2 = as described in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted = below). The client-Agent identities are load in a mechanism which is = out-of-band from the I2RS protocol these values. Into the Client, the = Agent's ID is loaded. Into the Agent, the valid client's identity is = loaded along with the client's priority. AAA (Radius/Diameter) is an = example of an out-of-band mechanism to pass the information with. IMU = (in my understanding), the NACM on the agent is created based on this = AAA loading. The i2rs secondary identity is loaded via an edit-config = mechanism in a config operation (see section 5.1 of Jeff's document.). = Please let me know if my understanding of NACM creation based on AAA = input is correct. >=20 =20 That is an optional mode. There is also a local users table that can be used. =20 =20 > I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent = will be annotated with meta-data with the client-id, priority, and = secondary ID. >=20 > The only proposed change to section 5.2 requirements is to the=20 > sentence "Additionally, during commit processing, if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. >=20 > " Additionally, during commit processing" is incorrect because there = is not commit processing. Jeff stated we are still working with both = NETCONF and RESTCONF - so we must allow for a commit process. In the = meeting I noted that the architecture indicates a change is possible = only if the priority is greater than (>) existing priority. (First = rather than last). Therefore this text should read: "Additionally, = during the operation (RESTCONF)/Commit (NETCONF) processing, if the = nodes are found where i2rs-priority is already present, and the priority = is equal to or better than the transaction's user's priority for the = node, the operation/commit SHALL fail." >=20 > Do you have any suggestions for modifications to section 5 of Jeff's = document? >=20 > Sue >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Jeff's document 5.2 states: >=20 > To support Multi-Headed Control, I2RS requires that there be a > decidable means of arbitrating the correct state of data when > multiple clients attempt to manipulate the same piece of data. = This > is done via a priority mechanism with the highest priority winning. > This priority may vary on a per-node or sub-tree basis based for a > given identity. >=20 > This further implies that priority is an attribute that is stored = in > the NETCONF Access Control Model [RFC6536] as part of a rule-list. > E.g.: >=20 > Ephemeral configuration state nodes that are created or altered by > users that match a rule carrying i2rs-priority will have those = nodes > annotated with metadata. Additionally, during commit processing, = if > nodes are found where i2rs-priority is already present, and the > priority is better than the transaction's user's priority for that > node, the commit SHALL fail. An appropriate error should be = returned > to the user stating the nodes where the user had insufficient > priority to override the state. >=20 =20 =20 The last paragraph sounds like some nodes will be accepted and others = rejected. If any nodes are rejected, the entire edit should be rejected. =20 I don;t think the rule-list should store the client priority. It should be in the 'group' list, or outside NACM completely. =20 =20 Andy =20 >=20 >=20 > -----Original Message----- > From: Andy Bierman [ = mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 7:40 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;=20 > i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >=20 > On Thu, May 28, 2015 at 4:22 PM, Susan Hares < = shares@ndzh.com> wrote: >> Andy: >>=20 >> Yes - the client with priority and secondary identity are inherently = simple additions. Can you confirm my understanding below based on = Jeff's document? >>=20 >=20 > Not sure what you mean. > i don't think the client should provide the priority in request = messages. > This is configured on the agent, not requested by the client. >=20 >=20 >> Can you explain your statement "I do not want to change NETCONF or = RESTCONF to use client priority?" What are you proposing that you do = not want to add the NACM list the priority? >=20 > I don't want to change NETCONF and RESTCONF so that config=3Dtrue = objects use priority. Only I2RS should use it. >=20 >>=20 >> Sue >=20 > Andy >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Example >> ------------------------ >> 1) any multiple TCP sessions from a client application will use a = different ID if they want a different priority for write of an object >> Application 1: TCP session 1 - priority 1, = secondary-identity "pub-sub monitor" >> Application 1: TCP session 2 - priority 10, = secondary-identity "tracing monitor" >> Application 1: TCP session 3 - priority 20, opaque "Weekly = config" >> Application 1: TCP session 4 - priority 55, opaque = "Emergency config" >>=20 >> Jeff's META-data example: >>=20 >> = https://ietf.example.com/i2rs" >> i2rs:i2rs-secondary-identity=3D"user1" = i2rs:i2rs-priority=3D"47"> >> ... >> >>=20 >> For my example TCP session 1 >> > I2rs:i2rs-secondary-identity=3D"pub-sub montior" >> i2rs:i2rs-priority=3D"1"> >>=20 >> Juergen's client example: >>=20 >> list i2rs-client { >> key name; >> leaf name { >> description "The client name"; >> type i2rs:client-name; >> } >> leaf priority { >> description "The priority value assigned to this client."; >> type i2rs:client-priority; >> } >> } >>=20 >> +--rw rule-list [name] >> +--rw name string >> +--rw group* union >> +--rw rule [name] >> +--rw name string >> +--rw module-name? union >> +--rw (rule-type)? >> | +--:(protocol-operation) >> | | +--rw rpc-name? union >> | +--:(notification) >> | | +--rw notification-name? union >> | +--:(data-node) >> | +--rw path node-instance-identifier >> +--rw access-operations? union >> +--rw action action-type >> +--rw comment? string >> +--rw i2rs:i2rs-priority i2rs-priority-type >>=20 >> Are you proposing something different than Jeff's proposal? >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Andy Bierman [ = mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 11:17 AM >> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey=20 >> Haas; i2rs@ietf.org; = chen.ran@zte.com.cn; Alia Atlas; Susan = Hares >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>=20 >> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder < = = j.schoenwaelder@jacobs-university.de> wrote: >>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>>=20 >>>> Although I should be promoting use of NACM, I am not so sure it=20 >>>> should be mandatory for I2RS or required to configure I2RS client = priority. >>>>=20 >>>> list i2rs-client { >>>> key name; >>>> leaf name { >>>> description "The client name"; >>>> type i2rs:client-name; >>>> } >>>> leaf priority { >>>> description "The priority value assigned to this client."; >>>> type i2rs:client-priority; >>>> } >>>> } >>>=20 >>> So what is i2rs:client-name - is it any different from a=20 >>> NETCONF/RESTCONF username? >>>=20 >>=20 >> Is is probably not different. >>=20 >>=20 >>> NACM maps user names into groups and NACM allows to have the mapping = >>> supplied by an external source (e.g. RADIUS). If this priority=20 >>> mapping is kept separate from NACM, would we need to provision means = >>> to get the priority from AAA as well? >>>=20 >>=20 >> My point showing the 2 item list is that the information needed to = implement I2RS client priority is rather trivial. >> It can certainly be made really complicated by the IETF, but it is an = inherently trivial configuration. >>=20 >>> And the bigger question: Do we create something specific for I2RS or = >>> are we going to extend the generic YANG/NC/RC framework to provide=20 >>> the tools I2RS needs? This is probably a question the NETCONF WG has = >>> to answer. >>=20 >> It is good to make reusable features. >> I don't want to change NETCONF or RESTCONF to use client priority. >> Let I2RS prove it is useful first. I am not convinced it will really = help. >> It seems like an implementation detail that is being turned into ad = administrative task. If multiple clients from multiple vendors are = stepping on each other, then the likely outcome of a priority change by = the administrator will be to select which clients should continue = working and which should be broken. >>=20 >>=20 >>>=20 >>> /js >>>=20 >>=20 >> Andy >>=20 >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 < = http://www.jacobs-university.de/> >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> = https://www.ietf.org/mailman/listinfo/i2rs >=20 ------=_NextPart_000_000A_01D09A38.AEFBD490 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

On all actions working = or not =E2=80=93 you should look at section 7.9 of the = architecture.=C2=A0 It allows =E2=80=9Cperform all or none=E2=80=9D, = =E2=80=9Cperform until error=E2=80=9D, and =E2=80=9Cperform all storing = errors.=E2=80=9D=C2=A0 =C2=A0=C2=A0I will propose an addition to section = 2.4 to Jeff=E2=80=99s document:

 

2.4 ) Transaction to = ephemeral state:

 

The = ephemeral state should support a multiple parts of a operation occurring = in a single message, but it does not require multi-message atomicity and = rollback. Three types of error handling should be supported: =

 

=C2=A0=C2=A0 Perform all or none:=C2=A0=C2=A0 This = traditional SNMP semantic indicates that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other I2RS agent will = keep enough state when handling a single

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 message to roll back = the operations within that message.=C2=A0 Either

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 all the operations will = succeed, or none of them will be applied

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and an error message = will report the single failure which caused

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0them not to be = applied.=C2=A0 This is useful when there are, = for

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 example, mutual = dependencies across operations in the message.

 

=C2=A0=C2=A0 Perform until error:=C2=A0=C2=A0 In this = case, the operations in the message

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 are applied in the = specified order.=C2=A0 When an error occurs, no

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 further operations are = applied, and an error is returned

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicating the = failure.=C2=A0 This is useful if there are = dependencies

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 among the operations = and they can be topologically sorted.

 

=C2=A0=C2=A0 Perform all storing errors:=C2=A0=C2=A0 = In this case, the I2RS Agent will

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 attempt to perform all = the operations in the message, and will

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return error = indications for each one that fails.=C2=A0 This is = useful

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 when there is no = dependency across the operation, or where the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client would prefer to = sort out the effect of errors on its own.

 

=C2=A0=C2=A0 In the interest of robustness and clarity = of protocol state, the

=C2=A0=C2=A0 protocol will include an explicit reply = to modification or write

=C2=A0=C2=A0 operations even when they fully = succeed.

 

 

Will this cover the = architecture document 7.9 transactions impact on ephemeral state? =

 

Sue = Hares

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, May 29, = 2015 1:44 PM
To: 'Andy Bierman'
Cc: 'Juergen = Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; 'i2rs@ietf.org'; = 'chen.ran@zte.com.cn'; 'Alia Atlas'
Subject: RE: [i2rs] = draft-chen-i2rs-identifier-management-00

 

Andy: =

 

I missed the second part of the email  (= http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in = my earlier message:

 

>. = " The last paragraph sounds like some nodes will be accepted and = others rejected.

>If any nodes = are rejected, the entire edit should be rejected.

 

RESTCONF does an atomic action within a http = session.   NETCONF within a commit.  Section 6.2 of the = I2RS architecture document describes state storage for I2RS, and it does = not have the atomic requirement for the protocol.  Instead section = 3.3 of the I2RS architecture document calls for this to be model = driver.  Let me provide examples from the 2 major I2RS protocol = independent models:

 

The = I2RS RIB yang model (dr= aft-ietf-i2rs-rib-data-model-00)  proposes that each route will = be associated with the following: route preference, active, = installed.  Notifications for route change will be given if route = is installed, active, and a reason given, or if the route commit fails. = Some routes may be accepted, and some routes rejected for installation = to the RIB.   The concept is the client will be able to detect = when a route is rejected.  

 

The = draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses the = challenge that topology models are not: configuration data only or = operational data only =E2=80=93 but a combination of both in ephemeral = state.  Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral = topology model which is operational (read-only) that contains data from: = a) only read from operational units, b) a configured topology, and c) = combination topology (operational state and configured).  (A second = alternative is to just have =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D, = but for now let=E2=80=99s focus on a, b, and c).  The = =E2=80=9CC=E2=80=9D combination topology may be generated based on = priority of configured topology versus operational data.  The = inclusion in =E2=80=9Cc=E2=80=9D may also be validated (E.g. interface = up, or L3 link runs on tunnel over interface which is up)).  =

 

These two model documents show why atomic state may = be on a very small section of the whole change.  

 

> I = don=E2=80=99t think the rule-list should store the client = priority.

> It should be in the = 'group' list, or outside NACM completely."

 

Your alternate proposal are: =

 

1)        &n= bsp;   Moving i2rs-priority to group list

2)        &n= bsp;   Adding a i2rs-client [unspecified location] =

 

This mail deals with #1.  If you have = more details on proposal #2, please suggest them on the list. =  

 

list i2rs-client {

      key = name;

      leaf name = {

         = description "The client name";

         = type i2rs:client-name;

      }

      leaf priority = {

        = description "The priority value assigned to this = client.";

        type = i2rs:client-priority;

     }

  }

 

Question: Is this i2rs-list to be included = in the group list for NACM (as listed below from RFC6536) as a leaf list = below?

 

       container = groups {

         = description

        &nbs= p;  "NETCONF Access Control Groups.";

 

       =   list group {

        &nbs= p; key name;

        &nbs= p;  description

        &nbs= p;    "One NACM Group Entry.  This list will = only contain

        &nbs= p;     configured entries, not any entries learned = from

        &nbs= p;     any transport = protocols.";

 

        &nbs= p;  leaf name {

        &nbs= p;    type group-name-type;

        &nbs= p;    description

        &nbs= p;      "Group name associated with this = entry.";

        &nbs= p;  }

 

        &nbs= p;  leaf-list user-name {

        &nbs= p;    type user-name-type;

        &nbs= p;    description

        &nbs= p;      "Each entry identifies the = username of

        &nbs= p;       a member of the group associated = with

        &nbs= p;       this = entry.";

        &nbs= p;  }

        &nbs= p; # add leaf-list I2rs-client here

        &nbs= p;}

       = }

Your message: = http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html<= /o:p>

States:  "I think I2RS = interaction with NACM needs to be clearly defined. NACM implementations = do not currently check write requests

on config=3Dfalse data. It is possible some edits = to NACM are needed even if no objects are added to the data = structure."

 

Do = you have a proposal for changing the text in section 5.2 of = draft-haas-i2rs-ephemeral-state-reqs-00? 

Is it sufficient to state: =   =E2=80=9CNACM implementations for I2RS will need to check = write request on config=3Dfalse, ephemeral =3D true. = =E2=80=9C

before the paragraph: =

 

=E2=80=9CEphemeral configuration state nodes that are = created or altered by users that match a rule carrying i2rs-priority = will have those nodes annotated with metadata.  Additionally, = during commit processing, if nodes are found where i2rs-priority is = already present, and the  priority is better than the transaction's = user's priority for that node, the commit SHALL fail. An appropriate = error should be returned

   = to the user stating the nodes where the user had = insufficient

   priority to = override the state.

 

I=E2=80=99m unclear what this means: =E2=80=9CIt is = possible some edits to NACM are needed even if no objects are added to = the data structure."

 

Sue =

 

-----Original Message-----
From: Andy Bierman = [mailto:andy@yumaworks.com] =
Sent: Thursday, May 28, 2015 8:23 PM
To: Susan Hares
Cc: = Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia = Atlas
Subject: Re: [i2rs] = draft-chen-i2rs-identifier-management-00

 

On = Thu, May 28, 2015 at 5:09 PM, Susan Hares <shares@ndzh.com> wrote:

> = Andy:

> 

> Thank you for your question.  Let me = precise.

> 

> Jeff proposes that clients specify the = priority mechanism is an attribute that is stored in the NACM list on = the agent (see Section 5.2 as described in the = draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The = client-Agent identities are load in a mechanism which is out-of-band = from the I2RS protocol these values.  Into the Client, the Agent's = ID is loaded.  Into the Agent, the valid client's identity is = loaded along with the client's priority.  AAA (Radius/Diameter) is = an example of an out-of-band mechanism to pass the information = with.  IMU (in my understanding), the NACM on the agent is created = based on this AAA loading.  The i2rs secondary identity is loaded = via an edit-config mechanism in a config operation (see section 5.1 of = Jeff's document.).  Please let me know if my understanding of NACM = creation based on AAA input is correct.

> 

 

That = is an optional mode.

There is also = a local users table that can be used.

 

 

> = I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent = will be annotated with meta-data with the client-id, priority, and = secondary ID.

> 

> The only proposed change to section 5.2 = requirements is to the

> = sentence "Additionally, during commit processing, = if

>    nodes = are found where i2rs-priority is already present, and = the

>    = priority is better than the transaction's user's priority for = that

>    node, = the commit SHALL fail.

> 

> " Additionally, during commit = processing" is incorrect because there is not commit = processing.   Jeff stated we are still working with both = NETCONF and RESTCONF - so we must allow for a commit process.  In = the meeting I noted that the architecture indicates a change is possible = only if the priority is greater than (>) existing priority.  = (First rather than last).  Therefore this text should read:  = "Additionally, during the operation (RESTCONF)/Commit (NETCONF) = processing, if the nodes are found where i2rs-priority is already = present, and the priority is equal to or better than the transaction's = user's priority for the node, the operation/commit SHALL = fail."

> 

> Do you have any suggestions for modifications = to section 5 of Jeff's document?

> 

> Sue

> 

> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

> Jeff's document 5.2 = states:

> 

>   To support Multi-Headed Control, = I2RS requires that there be a

>    decidable means of = arbitrating the correct state of data when

>    multiple clients attempt to = manipulate the same piece of data.  This

>    is done via a priority = mechanism with the highest priority winning.

>    This priority may vary on a = per-node or sub-tree basis based for a

>    given = identity.

> 

>    This further implies that = priority is an attribute that is stored in

>    the NETCONF Access Control = Model [RFC6536] as part of a rule-list.

>    E.g.:

> 

>    Ephemeral configuration = state nodes that are created or altered by

>    users that match a rule = carrying i2rs-priority will have those nodes

>    annotated with = metadata.  Additionally, during commit processing, = if

>    nodes = are found where i2rs-priority is already present, and = the

>    = priority is better than the transaction's user's priority for = that

>    node, = the commit SHALL fail.  An appropriate error should be = returned

>    to = the user stating the nodes where the user had = insufficient

>    priority to override the = state.

> 

 

 

The = last paragraph sounds like some nodes will be accepted and others = rejected.

If any nodes are = rejected, the entire edit should be rejected.

 

I = don;t think the rule-list should store the client = priority.

It should be in the = 'group' list, or outside NACM completely.

 

 

Andy

 

> 

> 

> -----Original Message-----

> From: Andy Bierman [mailto:andy@yumaworks.com= ]

> Sent: Thursday, = May 28, 2015 7:40 PM

> To: = Susan Hares

> Cc: Juergen = Schoenwaelder; Joel M. Halpern; Jeffrey Haas;

> i2rs@ietf.org;= chen.ran@zte.com.cn; Alia Atlas

> Subject: = Re: [i2rs] draft-chen-i2rs-identifier-management-00

> 

> On Thu, May 28, 2015 at 4:22 PM, Susan Hares = <shares@ndzh.com> wrote:

>> = Andy:

>> 

>> Yes - the client with priority and = secondary identity are inherently simple additions.   Can you = confirm my understanding below based on Jeff's = document?

>> 

> 

> Not sure what you mean.

> i don't think the client should provide the = priority in request messages.

> = This is configured on the agent, not requested by the = client.

> 

> 

>> Can you explain  your statement = "I do not want to change NETCONF or RESTCONF to use client = priority?"  What are you proposing that you do not want to add = the NACM list the priority?

> 

> I don't want to change NETCONF and RESTCONF so = that config=3Dtrue objects use priority.  Only I2RS should use = it.

> 

>> 

>> Sue

> 

> Andy

> 

>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

>> 

>> Example

>> ------------------------

>> 1) any multiple TCP sessions from a client = application will use a different ID if they want a different priority = for write of an object

>>       &n= bsp;      Application 1:  TCP session 1 = -  priority 1,  secondary-identity  "pub-sub = monitor"

>>       &n= bsp;      Application 1:  TCP session 2 - = priority 10, secondary-identity "tracing = monitor"

>>       &n= bsp; Application 1:  TCP session 3 -  priority 20, opaque = "Weekly config"

>>       &n= bsp; Application 1:  TCP session 4 -  priority 55, opaque = "Emergency config"

>> 

>> Jeff's META-data  = example:

>> 

>>   <foo xmlns:i2rs=3D"https://ietf.example.com/= i2rs"

>>       &n= bsp; i2rs:i2rs-secondary-identity=3D"user1" = i2rs:i2rs-priority=3D"47">

>>        = ...

>>    = </foo>

>> 

>> For my example TCP session = 1

>>    = <foo = xmlns:i2rs=3D"http:s//ietf.example.com/i2rs"

>>       &n= bsp; I2rs:i2rs-secondary-identity=3D"pub-sub = montior"

>> = i2rs:i2rs-priority=3D"1">

>> 

>> Juergen's client example:

>> 

>>     list i2rs-client = {

>>        = key name;

>>       leaf = name {

>>       &n= bsp;  description "The client name";

>>       &n= bsp;  type i2rs:client-name;

>>        = }

>>        = leaf priority {

>>       &n= bsp;   description "The priority value assigned to this = client.";

>>       &n= bsp;  type i2rs:client-priority;

>>       = }

>>     = }

>> 

>>    +--rw rule-list = [name]

>>       +--rw = name     string

>>       +--rw = group*   union

>>       +--rw = rule [name]

>>       &n= bsp;  +--rw name string

>>       &n= bsp;  +--rw module-name?  union

>>     =      +--rw (rule-type)?

>>       &n= bsp;  |  +--:(protocol-operation)

>>       &n= bsp;  |  |  +--rw rpc-name?  union

>>       &n= bsp;  |  +--:(notification)

>>       &n= bsp;  |  |  +--rw notification-name?  = union

>>       &n= bsp;  |  +--:(data-node)

>>       &n= bsp;  |     +--rw path = node-instance-identifier

>>       &n= bsp;  +--rw access-operations?  union

>>       &n= bsp;  +--rw action action-type

>>       &n= bsp;  +--rw comment?  string

>>       &n= bsp;  +--rw i2rs:i2rs-priority i2rs-priority-type

>> 

>> Are you proposing something different than = Jeff's proposal?

>> 

>> Sue

>> 

>> -----Original = Message-----

>> From: Andy = Bierman [mailto:andy@yumaworks.com= ]

>> Sent: = Thursday, May 28, 2015 11:17 AM

>> To: Juergen Schoenwaelder; Andy Bierman; = Joel M. Halpern; Jeffrey

>> = Haas; i2rs@ietf.org;= chen.ran@zte.com.cn; Alia Atlas; Susan Hares

>> Subject: Re: [i2rs] = draft-chen-i2rs-identifier-management-00

>> 

>> On Wed, May 27, 2015 at 11:05 PM, Juergen = Schoenwaelder <j.schoenwaelder@jacobs-un= iversity.de> wrote:

>>> On Wed, May 27, 2015 at 06:04:58PM = -0700, Andy Bierman wrote:

>>>> 

>>>> Although I should be promoting use = of NACM, I am not so sure it

>>>> should be mandatory for I2RS or = required to configure I2RS client priority.

>>>> 

>>>>    list i2rs-client = {

>>>>      = key name;

>>>>      = leaf name {

>>>>      =     description "The client = name";

>>>>      =     type i2rs:client-name;

>>>>      = }

>>>>      = leaf priority {

>>>>      =    description "The priority value assigned to this = client.";

>>>>      =    type i2rs:client-priority;

>>>>      = }

>>>>   = }

>>> 

>>> So what is i2rs:client-name - is it = any different from a

>>> = NETCONF/RESTCONF username?

>>> 

>> 

>> Is is probably not = different.

>> 

>> 

>>> NACM maps user names into groups and = NACM allows to have the mapping

>>> supplied by an external source (e.g. = RADIUS). If this priority

>>> mapping is kept separate from NACM, = would we need to provision means

>>> to get the priority from AAA as = well?

>>> 

>> 

>> My point showing the 2 item list is that = the information needed to implement I2RS client priority is rather = trivial.

>> It can certainly = be made really complicated by the IETF, but it is an inherently trivial = configuration.

>> 

>>> And the bigger question: Do we create = something specific for I2RS or

>>> are we going to extend the generic = YANG/NC/RC framework to provide

>>> the tools I2RS needs? This is probably = a question the NETCONF WG has

>>> to answer.

>> 

>> It is good to make reusable = features.

>> I don't want to = change NETCONF or RESTCONF to use client priority.

>> Let I2RS prove it is useful first.  I = am not convinced it will really help.

>> It seems like an implementation detail = that is being turned into ad administrative task.  If multiple = clients from multiple vendors are stepping on each other, then the = likely outcome of a priority change by the administrator will be to = select which clients should continue working and which should be = broken.

>> 

>> 

>>> 

>>> /js

>>> 

>> 

>> Andy

>> 

>>> --

>>> Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

>>> Phone: +49 421 200 = 3587         Campus Ring 1 | = 28759 Bremen | Germany

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

>> 

>> = _______________________________________________

>> i2rs mailing list

>> i2rs@ietf.org<= o:p>

>> https://www.ietf.org/mail= man/listinfo/i2rs

> 

------=_NextPart_000_000A_01D09A38.AEFBD490-- From nobody Fri May 29 17:41:42 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A561ACCE6 for ; Fri, 29 May 2015 17:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S48Bhu0dNTwK for ; Fri, 29 May 2015 17:41:37 -0700 (PDT) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9991ACCE0 for ; Fri, 29 May 2015 17:41:36 -0700 (PDT) Received: by laat2 with SMTP id t2so66998479laa.1 for ; Fri, 29 May 2015 17:41:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A3fR+6V9aJwRcPQgyfxA2BtfGWoDskdj/1wu32LIX5g=; b=hvqy1WHT1VP+DbjFUQw0+KCPBX4RUE8JetvuBhsX4M5m/mKjIH8Y00CXOWCmLqwCiR Gm4vDckdCfkqHPK85aAnfFq5wbkwwnERaOFSvqgZoLDTz4R+qFRe/48SXhlcz7eDRIZT Ec/qIFcg4jmXVohZaLtTDYUWUOpr1hM2jqFyfz9Zyeb8xcdtPMsDZm1Oqi/931xmn5Nj Rn5LMr0yHZV5429z0jUELgEXtrdyXZYA2PT4LGKZGSAJyEsdJUNA7Uz08zBxnCvwWZz9 aB4+bjlbu6zp0nUVO6Qopvic7IdkNgikP/nIhQAwVgpiBeLwatG7PbQWrmX4lSDHzTbC kuYA== X-Gm-Message-State: ALoCoQlajjm4Uc+gOTwoHvmh2GZTCtOohvqxE26rkJPePf7RzVrWxGR0/xwVHOJmv6LDI2czCO7U MIME-Version: 1.0 X-Received: by 10.112.164.66 with SMTP id yo2mr3840763lbb.33.1432946494939; Fri, 29 May 2015 17:41:34 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 29 May 2015 17:41:34 -0700 (PDT) In-Reply-To: <000901d09a5a$36044cd0$a20ce670$@ndzh.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> Date: Fri, 29 May 2015 17:41:34 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , Jeff Haas , chen.ran@zte.com.cn, Juergen Schoenwaelder , Alia Atlas , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 00:41:40 -0000 On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: > Andy: > > > > On all actions working or not =E2=80=93 you should look at section 7.9 of= the > architecture. It allows =E2=80=9Cperform all or none=E2=80=9D, =E2=80=9C= perform until error=E2=80=9D, and > =E2=80=9Cperform all storing errors.=E2=80=9D I will propose an additi= on to section 2.4 > to Jeff=E2=80=99s document: > > OK -- I remember these options now. It should be clear in the document that stopping on error or recording errors does not mean the agent will leave the datastore in an invalid state. Most YANG validation errors can be pruned from the datastore. This may or may not leave the datastore in an operationally useful state. The must/min-elements/unique statements can cause validation errors on nodes outside the edit list. NETCONF does not allow validation errors in the running datastore. I2RS should not allow validation errors in the ephemeral data. Andy > > 2.4 ) Transaction to ephemeral state: > > > > The ephemeral state should support a multiple parts of a operation occurr= ing > in a single message, but it does not require multi-message atomicity and > rollback. Three types of error handling should be supported: > > > > Perform all or none: This traditional SNMP semantic indicates that > > other I2RS agent will keep enough state when handling a single > > message to roll back the operations within that message. Either > > all the operations will succeed, or none of them will be applied > > and an error message will report the single failure which caused > > them not to be applied. This is useful when there are, for > > example, mutual dependencies across operations in the message. > > > > Perform until error: In this case, the operations in the message > > are applied in the specified order. When an error occurs, no > > further operations are applied, and an error is returned > > indicating the failure. This is useful if there are dependencies > > among the operations and they can be topologically sorted. > > > > Perform all storing errors: In this case, the I2RS Agent will > > attempt to perform all the operations in the message, and will > > return error indications for each one that fails. This is useful > > when there is no dependency across the operation, or where the > > client would prefer to sort out the effect of errors on its own. > > > > In the interest of robustness and clarity of protocol state, the > > protocol will include an explicit reply to modification or write > > operations even when they fully succeed. > > > > > > Will this cover the architecture document 7.9 transactions impact on > ephemeral state? > > > > Sue Hares > > > > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Friday, May 29, 2015 1:44 PM > To: 'Andy Bierman' > Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; > 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' > Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 > > > > Andy: > > > > I missed the second part of the email > (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my > earlier message: > > > >>. " The last paragraph sounds like some nodes will be accepted and others >> rejected. > >>If any nodes are rejected, the entire edit should be rejected. > > > > RESTCONF does an atomic action within a http session. NETCONF within a > commit. Section 6.2 of the I2RS architecture document describes state > storage for I2RS, and it does not have the atomic requirement for the > protocol. Instead section 3.3 of the I2RS architecture document calls fo= r > this to be model driver. Let me provide examples from the 2 major I2RS > protocol independent models: > > > > The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes tha= t > each route will be associated with the following: route preference, activ= e, > installed. Notifications for route change will be given if route is > installed, active, and a reason given, or if the route commit fails. Some > routes may be accepted, and some routes rejected for installation to the > RIB. The concept is the client will be able to detect when a route is > rejected. > > > > The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses = the > challenge that topology models are not: configuration data only or > operational data only =E2=80=93 but a combination of both in ephemeral st= ate. > Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology model > which is operational (read-only) that contains data from: a) only read fr= om > operational units, b) a configured topology, and c) combination topology > (operational state and configured). (A second alternative is to just hav= e > =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D, but for now let=E2=80=99s fo= cus on a, b, and c). The =E2=80=9CC=E2=80=9D combination > topology may be generated based on priority of configured topology versus > operational data. The inclusion in =E2=80=9Cc=E2=80=9D may also be valid= ated (E.g. > interface up, or L3 link runs on tunnel over interface which is up)). > > > > These two model documents show why atomic state may be on a very small > section of the whole change. > > > >> I don=E2=80=99t think the rule-list should store the client priority. > >> It should be in the 'group' list, or outside NACM completely." > > > > Your alternate proposal are: > > > > 1) Moving i2rs-priority to group list > > 2) Adding a i2rs-client [unspecified location] > > > > This mail deals with #1. If you have more details on proposal #2, please > suggest them on the list. > > > > list i2rs-client { > > key name; > > leaf name { > > description "The client name"; > > type i2rs:client-name; > > } > > leaf priority { > > description "The priority value assigned to this client."; > > type i2rs:client-priority; > > } > > } > > > > Question: Is this i2rs-list to be included in the group list for NACM (as > listed below from RFC6536) as a leaf list below? > > > > container groups { > > description > > "NETCONF Access Control Groups."; > > > > list group { > > key name; > > description > > "One NACM Group Entry. This list will only contain > > configured entries, not any entries learned from > > any transport protocols."; > > > > leaf name { > > type group-name-type; > > description > > "Group name associated with this entry."; > > } > > > > leaf-list user-name { > > type user-name-type; > > description > > "Each entry identifies the username of > > a member of the group associated with > > this entry."; > > } > > # add leaf-list I2rs-client here > > } > > } > > Your message: > http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html > > States: "I think I2RS interaction with NACM needs to be clearly defined. > NACM implementations do not currently check write requests > > on config=3Dfalse data. It is possible some edits to NACM are needed even= if > no objects are added to the data structure." > > > > Do you have a proposal for changing the text in section 5.2 of > draft-haas-i2rs-ephemeral-state-reqs-00? > > Is it sufficient to state: =E2=80=9CNACM implementations for I2RS will = need to > check write request on config=3Dfalse, ephemeral =3D true. =E2=80=9C > > before the paragraph: > > > > =E2=80=9CEphemeral configuration state nodes that are created or altered = by users > that match a rule carrying i2rs-priority will have those nodes annotated > with metadata. Additionally, during commit processing, if nodes are foun= d > where i2rs-priority is already present, and the priority is better than = the > transaction's user's priority for that node, the commit SHALL fail. An > appropriate error should be returned > > to the user stating the nodes where the user had insufficient > > priority to override the state. > > > > I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some edits t= o NACM are needed > even if no objects are added to the data structure." > > > > Sue > > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 8:23 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; i2rs@ietf.org; > chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > > > On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: > >> Andy: > >> > >> Thank you for your question. Let me precise. > >> > >> Jeff proposes that clients specify the priority mechanism is an attribut= e >> that is stored in the NACM list on the agent (see Section 5.2 as describ= ed >> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >> client-Agent identities are load in a mechanism which is out-of-band fro= m >> the I2RS protocol these values. Into the Client, the Agent's ID is load= ed. >> Into the Agent, the valid client's identity is loaded along with the >> client's priority. AAA (Radius/Diameter) is an example of an out-of-ban= d >> mechanism to pass the information with. IMU (in my understanding), the = NACM >> on the agent is created based on this AAA loading. The i2rs secondary >> identity is loaded via an edit-config mechanism in a config operation (s= ee >> section 5.1 of Jeff's document.). Please let me know if my understandin= g of >> NACM creation based on AAA input is correct. > >> > > > > That is an optional mode. > > There is also a local users table that can be used. > > > > > >> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent wil= l >> be annotated with meta-data with the client-id, priority, and secondary = ID. > >> > >> The only proposed change to section 5.2 requirements is to the > >> sentence "Additionally, during commit processing, if > >> nodes are found where i2rs-priority is already present, and the > >> priority is better than the transaction's user's priority for that > >> node, the commit SHALL fail. > >> > >> " Additionally, during commit processing" is incorrect because there is >> not commit processing. Jeff stated we are still working with both NETC= ONF >> and RESTCONF - so we must allow for a commit process. In the meeting I >> noted that the architecture indicates a change is possible only if the >> priority is greater than (>) existing priority. (First rather than last= ). >> Therefore this text should read: "Additionally, during the operation >> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where >> i2rs-priority is already present, and the priority is equal to or better >> than the transaction's user's priority for the node, the operation/commi= t >> SHALL fail." > >> > >> Do you have any suggestions for modifications to section 5 of Jeff's >> document? > >> > >> Sue > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> Jeff's document 5.2 states: > >> > >> To support Multi-Headed Control, I2RS requires that there be a > >> decidable means of arbitrating the correct state of data when > >> multiple clients attempt to manipulate the same piece of data. This > >> is done via a priority mechanism with the highest priority winning. > >> This priority may vary on a per-node or sub-tree basis based for a > >> given identity. > >> > >> This further implies that priority is an attribute that is stored in > >> the NETCONF Access Control Model [RFC6536] as part of a rule-list. > >> E.g.: > >> > >> Ephemeral configuration state nodes that are created or altered by > >> users that match a rule carrying i2rs-priority will have those nodes > >> annotated with metadata. Additionally, during commit processing, if > >> nodes are found where i2rs-priority is already present, and the > >> priority is better than the transaction's user's priority for that > >> node, the commit SHALL fail. An appropriate error should be returned > >> to the user stating the nodes where the user had insufficient > >> priority to override the state. > >> > > > > > > The last paragraph sounds like some nodes will be accepted and others > rejected. > > If any nodes are rejected, the entire edit should be rejected. > > > > I don;t think the rule-list should store the client priority. > > It should be in the 'group' list, or outside NACM completely. > > > > > > Andy > > > >> > >> > >> -----Original Message----- > >> From: Andy Bierman [mailto:andy@yumaworks.com] > >> Sent: Thursday, May 28, 2015 7:40 PM > >> To: Susan Hares > >> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; > >> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas > >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > >> > >> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: > >>> Andy: > >>> > >>> Yes - the client with priority and secondary identity are inherently >>> simple additions. Can you confirm my understanding below based on Jef= f's >>> document? > >>> > >> > >> Not sure what you mean. > >> i don't think the client should provide the priority in request messages= . > >> This is configured on the agent, not requested by the client. > >> > >> > >>> Can you explain your statement "I do not want to change NETCONF or >>> RESTCONF to use client priority?" What are you proposing that you do n= ot >>> want to add the NACM list the priority? > >> > >> I don't want to change NETCONF and RESTCONF so that config=3Dtrue object= s >> use priority. Only I2RS should use it. > >> > >>> > >>> Sue > >> > >> Andy > >> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> Example > >>> ------------------------ > >>> 1) any multiple TCP sessions from a client application will use a >>> different ID if they want a different priority for write of an object > >>> Application 1: TCP session 1 - priority 1, >>> secondary-identity "pub-sub monitor" > >>> Application 1: TCP session 2 - priority 10, >>> secondary-identity "tracing monitor" > >>> Application 1: TCP session 3 - priority 20, opaque "Weekly >>> config" > >>> Application 1: TCP session 4 - priority 55, opaque "Emergency >>> config" > >>> > >>> Jeff's META-data example: > >>> > >>> >>> i2rs:i2rs-secondary-identity=3D"user1" i2rs:i2rs-priority=3D"47= "> > >>> ... > >>> > >>> > >>> For my example TCP session 1 > >>> >>> I2rs:i2rs-secondary-identity=3D"pub-sub montior" > >>> i2rs:i2rs-priority=3D"1"> > >>> > >>> Juergen's client example: > >>> > >>> list i2rs-client { > >>> key name; > >>> leaf name { > >>> description "The client name"; > >>> type i2rs:client-name; > >>> } > >>> leaf priority { > >>> description "The priority value assigned to this client."; > >>> type i2rs:client-priority; > >>> } > >>> } > >>> > >>> +--rw rule-list [name] > >>> +--rw name string > >>> +--rw group* union > >>> +--rw rule [name] > >>> +--rw name string > >>> +--rw module-name? union > >>> +--rw (rule-type)? > >>> | +--:(protocol-operation) > >>> | | +--rw rpc-name? union > >>> | +--:(notification) > >>> | | +--rw notification-name? union > >>> | +--:(data-node) > >>> | +--rw path node-instance-identifier > >>> +--rw access-operations? union > >>> +--rw action action-type > >>> +--rw comment? string > >>> +--rw i2rs:i2rs-priority i2rs-priority-type > >>> > >>> Are you proposing something different than Jeff's proposal? > >>> > >>> Sue > >>> > >>> -----Original Message----- > >>> From: Andy Bierman [mailto:andy@yumaworks.com] > >>> Sent: Thursday, May 28, 2015 11:17 AM > >>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey > >>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares > >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > >>> > >>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder >>> wrote: > >>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: > >>>>> > >>>>> Although I should be promoting use of NACM, I am not so sure it > >>>>> should be mandatory for I2RS or required to configure I2RS client >>>>> priority. > >>>>> > >>>>> list i2rs-client { > >>>>> key name; > >>>>> leaf name { > >>>>> description "The client name"; > >>>>> type i2rs:client-name; > >>>>> } > >>>>> leaf priority { > >>>>> description "The priority value assigned to this client."; > >>>>> type i2rs:client-priority; > >>>>> } > >>>>> } > >>>> > >>>> So what is i2rs:client-name - is it any different from a > >>>> NETCONF/RESTCONF username? > >>>> > >>> > >>> Is is probably not different. > >>> > >>> > >>>> NACM maps user names into groups and NACM allows to have the mapping > >>>> supplied by an external source (e.g. RADIUS). If this priority > >>>> mapping is kept separate from NACM, would we need to provision means > >>>> to get the priority from AAA as well? > >>>> > >>> > >>> My point showing the 2 item list is that the information needed to >>> implement I2RS client priority is rather trivial. > >>> It can certainly be made really complicated by the IETF, but it is an >>> inherently trivial configuration. > >>> > >>>> And the bigger question: Do we create something specific for I2RS or > >>>> are we going to extend the generic YANG/NC/RC framework to provide > >>>> the tools I2RS needs? This is probably a question the NETCONF WG has > >>>> to answer. > >>> > >>> It is good to make reusable features. > >>> I don't want to change NETCONF or RESTCONF to use client priority. > >>> Let I2RS prove it is useful first. I am not convinced it will really >>> help. > >>> It seems like an implementation detail that is being turned into ad >>> administrative task. If multiple clients from multiple vendors are ste= pping >>> on each other, then the likely outcome of a priority change by the >>> administrator will be to select which clients should continue working a= nd >>> which should be broken. > >>> > >>> > >>>> > >>>> /js > >>>> > >>> > >>> Andy > >>> > >>>> -- > >>>> 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 Fri May 29 19:00: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 32F681AD2EE for ; Fri, 29 May 2015 19:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.255 X-Spam-Level: X-Spam-Status: No, score=-97.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, 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 bspN5C8-6OK9 for ; Fri, 29 May 2015 19:00:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB71AD305 for ; Fri, 29 May 2015 19:00:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> In-Reply-To: Date: Fri, 29 May 2015 21:59:59 -0400 Message-ID: <001501d09a7c$58197530$084c5f90$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4gH00CZbAa2lsVGdcG2SAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Jeff Haas' , chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' , "'Joel M. Halpern'" Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 02:00:32 -0000 Andy:=20 See one question below. If alter to not store invalid values in the = datastore - is my addition to Jeff's 2.4 addition acceptable?=20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Friday, May 29, 2015 8:42 PM To: Susan Hares Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen = Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: >> Andy: >> >> >> >> On all actions working or not =E2=80=93 you should look at section = 7.9 of the=20 >> architecture. It allows =E2=80=9Cperform all or none=E2=80=9D, = =E2=80=9Cperform until error=E2=80=9D, and >> =E2=80=9Cperform all storing errors.=E2=80=9D I will propose an = addition to section 2.4 >> to Jeff=E2=80=99s document: >> >> >>OK -- I remember these options now. >It should be clear in the document that stopping on error or recording = errors does not mean the agent will leave the datastore in an invalid = >state. Most YANG validation errors can be pruned from the datastore. >This may or may not leave the datastore in an operationally useful = state. >The must/min-elements/unique statements can cause validation errors on = nodes outside the edit list. > >NETCONF does not allow validation errors in the running datastore. >I2RS should not allow validation errors in the ephemeral data. [sue]: On case: or if perform and until error / or perform and record = error - you are assuming these are a validation error?=20 You are commending I2RS should not store values with invalid data. Are = you against logging the validation errors?=20 Andy > > 2.4 ) Transaction to ephemeral state: > > > > The ephemeral state should support a multiple parts of a operation=20 > occurring in a single message, but it does not require multi-message=20 > atomicity and rollback. Three types of error handling should be = supported: > > > > Perform all or none: This traditional SNMP semantic indicates = that > > other I2RS agent will keep enough state when handling a single > > message to roll back the operations within that message. Either > > all the operations will succeed, or none of them will be applied > > and an error message will report the single failure which caused > > them not to be applied. This is useful when there are, for > > example, mutual dependencies across operations in the message. > > > > Perform until error: In this case, the operations in the message > > are applied in the specified order. When an error occurs, no > > further operations are applied, and an error is returned > > indicating the failure. This is useful if there are=20 > dependencies > > among the operations and they can be topologically sorted. > > > > Perform all storing errors: In this case, the I2RS Agent will > > attempt to perform all the operations in the message, and will > > return error indications for each one that fails. This is=20 > useful > > when there is no dependency across the operation, or where the > > client would prefer to sort out the effect of errors on its own. > > > > In the interest of robustness and clarity of protocol state, the > > protocol will include an explicit reply to modification or write > > operations even when they fully succeed. > > > > > > Will this cover the architecture document 7.9 transactions impact on=20 > ephemeral state? > > > > Sue Hares > > > > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Friday, May 29, 2015 1:44 PM > To: 'Andy Bierman' > Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';=20 > 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' > Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 > > > > Andy: > > > > I missed the second part of the email > (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in=20 > my earlier message: > > > >>. " The last paragraph sounds like some nodes will be accepted and=20 >>others rejected. > >>If any nodes are rejected, the entire edit should be rejected. > > > > RESTCONF does an atomic action within a http session. NETCONF within = a > commit. Section 6.2 of the I2RS architecture document describes state = > storage for I2RS, and it does not have the atomic requirement for the=20 > protocol. Instead section 3.3 of the I2RS architecture document calls = > for this to be model driver. Let me provide examples from the 2 major = > I2RS protocol independent models: > > > > The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes=20 > that each route will be associated with the following: route=20 > preference, active, installed. Notifications for route change will be = > given if route is installed, active, and a reason given, or if the=20 > route commit fails. Some routes may be accepted, and some routes = rejected for installation to the > RIB. The concept is the client will be able to detect when a route = is > rejected. > > > > The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5=20 > discusses the challenge that topology models are not: configuration=20 > data only or operational data only =E2=80=93 but a combination of both = in ephemeral state. > Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology=20 > model which is operational (read-only) that contains data from: a)=20 > only read from operational units, b) a configured topology, and c)=20 > combination topology (operational state and configured). (A second=20 > alternative is to just have =E2=80=9Ca=E2=80=9D and = =E2=80=9Cb=E2=80=9D, but for now let=E2=80=99s focus on a,=20 > b, and c). The =E2=80=9CC=E2=80=9D combination topology may be = generated based on=20 > priority of configured topology versus operational data. The = inclusion in =E2=80=9Cc=E2=80=9D may also be validated (E.g. > interface up, or L3 link runs on tunnel over interface which is up)). > > > > These two model documents show why atomic state may be on a very small = > section of the whole change. > > > >> I don=E2=80=99t think the rule-list should store the client priority. > >> It should be in the 'group' list, or outside NACM completely." > > > > Your alternate proposal are: > > > > 1) Moving i2rs-priority to group list > > 2) Adding a i2rs-client [unspecified location] > > > > This mail deals with #1. If you have more details on proposal #2,=20 > please suggest them on the list. > > > > list i2rs-client { > > key name; > > leaf name { > > description "The client name"; > > type i2rs:client-name; > > } > > leaf priority { > > description "The priority value assigned to this client."; > > type i2rs:client-priority; > > } > > } > > > > Question: Is this i2rs-list to be included in the group list for NACM=20 > (as listed below from RFC6536) as a leaf list below? > > > > container groups { > > description > > "NETCONF Access Control Groups."; > > > > list group { > > key name; > > description > > "One NACM Group Entry. This list will only contain > > configured entries, not any entries learned from > > any transport protocols."; > > > > leaf name { > > type group-name-type; > > description > > "Group name associated with this entry."; > > } > > > > leaf-list user-name { > > type user-name-type; > > description > > "Each entry identifies the username of > > a member of the group associated with > > this entry."; > > } > > # add leaf-list I2rs-client here > > } > > } > > Your message: > http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html > > States: "I think I2RS interaction with NACM needs to be clearly = defined. > NACM implementations do not currently check write requests > > on config=3Dfalse data. It is possible some edits to NACM are needed=20 > even if no objects are added to the data structure." > > > > Do you have a proposal for changing the text in section 5.2 of=20 > draft-haas-i2rs-ephemeral-state-reqs-00? > > Is it sufficient to state: =E2=80=9CNACM implementations for I2RS = will need to > check write request on config=3Dfalse, ephemeral =3D true. =E2=80=9C > > before the paragraph: > > > > =E2=80=9CEphemeral configuration state nodes that are created or = altered by=20 > users that match a rule carrying i2rs-priority will have those nodes=20 > annotated with metadata. Additionally, during commit processing, if=20 > nodes are found where i2rs-priority is already present, and the =20 > priority is better than the transaction's user's priority for that=20 > node, the commit SHALL fail. An appropriate error should be returned > > to the user stating the nodes where the user had insufficient > > priority to override the state. > > > > I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some = edits to NACM are=20 > needed even if no objects are added to the data structure." > > > > Sue > > > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, May 28, 2015 8:23 PM > To: Susan Hares > Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;=20 > i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > > > On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: > >> Andy: > >> > >> Thank you for your question. Let me precise. > >> > >> Jeff proposes that clients specify the priority mechanism is an=20 >> attribute that is stored in the NACM list on the agent (see Section = 5.2 as described >> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >> client-Agent identities are load in a mechanism which is out-of-band=20 >> from the I2RS protocol these values. Into the Client, the Agent's ID = is loaded. >> Into the Agent, the valid client's identity is loaded along with the=20 >> client's priority. AAA (Radius/Diameter) is an example of an=20 >> out-of-band mechanism to pass the information with. IMU (in my=20 >> understanding), the NACM on the agent is created based on this AAA=20 >> loading. The i2rs secondary identity is loaded via an edit-config=20 >> mechanism in a config operation (see section 5.1 of Jeff's=20 >> document.). Please let me know if my understanding of NACM creation = based on AAA input is correct. > >> > > > > That is an optional mode. > > There is also a local users table that can be used. > > > > > >> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent=20 >> will be annotated with meta-data with the client-id, priority, and = secondary ID. > >> > >> The only proposed change to section 5.2 requirements is to the > >> sentence "Additionally, during commit processing, if > >> nodes are found where i2rs-priority is already present, and the > >> priority is better than the transaction's user's priority for that > >> node, the commit SHALL fail. > >> > >> " Additionally, during commit processing" is incorrect because there = is >> not commit processing. Jeff stated we are still working with both = NETCONF >> and RESTCONF - so we must allow for a commit process. In the meeting = >> I noted that the architecture indicates a change is possible only if=20 >> the priority is greater than (>) existing priority. (First rather = than last). >> Therefore this text should read: "Additionally, during the operation = >> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where=20 >> i2rs-priority is already present, and the priority is equal to or=20 >> better than the transaction's user's priority for the node, the=20 >> operation/commit SHALL fail." > >> > >> Do you have any suggestions for modifications to section 5 of Jeff's=20 >> document? > >> > >> Sue > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > >> Jeff's document 5.2 states: > >> > >> To support Multi-Headed Control, I2RS requires that there be a > >> decidable means of arbitrating the correct state of data when > >> multiple clients attempt to manipulate the same piece of data. =20 >> This > >> is done via a priority mechanism with the highest priority = winning. > >> This priority may vary on a per-node or sub-tree basis based for a > >> given identity. > >> > >> This further implies that priority is an attribute that is stored=20 >> in > >> the NETCONF Access Control Model [RFC6536] as part of a rule-list. > >> E.g.: > >> > >> Ephemeral configuration state nodes that are created or altered by > >> users that match a rule carrying i2rs-priority will have those=20 >> nodes > >> annotated with metadata. Additionally, during commit processing,=20 >> if > >> nodes are found where i2rs-priority is already present, and the > >> priority is better than the transaction's user's priority for that > >> node, the commit SHALL fail. An appropriate error should be=20 >> returned > >> to the user stating the nodes where the user had insufficient > >> priority to override the state. > >> > > > > > > The last paragraph sounds like some nodes will be accepted and others=20 > rejected. > > If any nodes are rejected, the entire edit should be rejected. > > > > I don;t think the rule-list should store the client priority. > > It should be in the 'group' list, or outside NACM completely. > > > > > > Andy > > > >> > >> > >> -----Original Message----- > >> From: Andy Bierman [mailto:andy@yumaworks.com] > >> Sent: Thursday, May 28, 2015 7:40 PM > >> To: Susan Hares > >> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; > >> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas > >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > >> > >> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: > >>> Andy: > >>> > >>> Yes - the client with priority and secondary identity are inherently >>> simple additions. Can you confirm my understanding below based on = Jeff's >>> document? > >>> > >> > >> Not sure what you mean. > >> i don't think the client should provide the priority in request = messages. > >> This is configured on the agent, not requested by the client. > >> > >> > >>> Can you explain your statement "I do not want to change NETCONF or=20 >>> RESTCONF to use client priority?" What are you proposing that you=20 >>> do not want to add the NACM list the priority? > >> > >> I don't want to change NETCONF and RESTCONF so that config=3Dtrue=20 >> objects use priority. Only I2RS should use it. > >> > >>> > >>> Sue > >> > >> Andy > >> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> > >>> Example > >>> ------------------------ > >>> 1) any multiple TCP sessions from a client application will use a=20 >>> different ID if they want a different priority for write of an=20 >>> object > >>> Application 1: TCP session 1 - priority 1,=20 >>> secondary-identity "pub-sub monitor" > >>> Application 1: TCP session 2 - priority 10,=20 >>> secondary-identity "tracing monitor" > >>> Application 1: TCP session 3 - priority 20, opaque "Weekly = >>> config" > >>> Application 1: TCP session 4 - priority 55, opaque=20 >>> "Emergency config" > >>> > >>> Jeff's META-data example: > >>> > >>> >>> i2rs:i2rs-secondary-identity=3D"user1"=20 >>> i2rs:i2rs-priority=3D"47"> > >>> ... > >>> > >>> > >>> For my example TCP session 1 > >>> >>> I2rs:i2rs-secondary-identity=3D"pub-sub montior" > >>> i2rs:i2rs-priority=3D"1"> > >>> > >>> Juergen's client example: > >>> > >>> list i2rs-client { > >>> key name; > >>> leaf name { > >>> description "The client name"; > >>> type i2rs:client-name; > >>> } > >>> leaf priority { > >>> description "The priority value assigned to this client."; > >>> type i2rs:client-priority; > >>> } > >>> } > >>> > >>> +--rw rule-list [name] > >>> +--rw name string > >>> +--rw group* union > >>> +--rw rule [name] > >>> +--rw name string > >>> +--rw module-name? union > >>> +--rw (rule-type)? > >>> | +--:(protocol-operation) > >>> | | +--rw rpc-name? union > >>> | +--:(notification) > >>> | | +--rw notification-name? union > >>> | +--:(data-node) > >>> | +--rw path node-instance-identifier > >>> +--rw access-operations? union > >>> +--rw action action-type > >>> +--rw comment? string > >>> +--rw i2rs:i2rs-priority i2rs-priority-type > >>> > >>> Are you proposing something different than Jeff's proposal? > >>> > >>> Sue > >>> > >>> -----Original Message----- > >>> From: Andy Bierman [mailto:andy@yumaworks.com] > >>> Sent: Thursday, May 28, 2015 11:17 AM > >>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey > >>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares > >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > >>> > >>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder=20 >>> wrote: > >>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: > >>>>> > >>>>> Although I should be promoting use of NACM, I am not so sure it > >>>>> should be mandatory for I2RS or required to configure I2RS client=20 >>>>> priority. > >>>>> > >>>>> list i2rs-client { > >>>>> key name; > >>>>> leaf name { > >>>>> description "The client name"; > >>>>> type i2rs:client-name; > >>>>> } > >>>>> leaf priority { > >>>>> description "The priority value assigned to this client."; > >>>>> type i2rs:client-priority; > >>>>> } > >>>>> } > >>>> > >>>> So what is i2rs:client-name - is it any different from a > >>>> NETCONF/RESTCONF username? > >>>> > >>> > >>> Is is probably not different. > >>> > >>> > >>>> NACM maps user names into groups and NACM allows to have the=20 >>>> mapping > >>>> supplied by an external source (e.g. RADIUS). If this priority > >>>> mapping is kept separate from NACM, would we need to provision=20 >>>> means > >>>> to get the priority from AAA as well? > >>>> > >>> > >>> My point showing the 2 item list is that the information needed to=20 >>> implement I2RS client priority is rather trivial. > >>> It can certainly be made really complicated by the IETF, but it is=20 >>> an inherently trivial configuration. > >>> > >>>> And the bigger question: Do we create something specific for I2RS=20 >>>> or > >>>> are we going to extend the generic YANG/NC/RC framework to provide > >>>> the tools I2RS needs? This is probably a question the NETCONF WG=20 >>>> has > >>>> to answer. > >>> > >>> It is good to make reusable features. > >>> I don't want to change NETCONF or RESTCONF to use client priority. > >>> Let I2RS prove it is useful first. I am not convinced it will=20 >>> really help. > >>> It seems like an implementation detail that is being turned into ad=20 >>> administrative task. If multiple clients from multiple vendors are=20 >>> stepping on each other, then the likely outcome of a priority change = >>> by the administrator will be to select which clients should continue = >>> working and which should be broken. > >>> > >>> > >>>> > >>>> /js > >>>> > >>> > >>> Andy > >>> > >>>> -- > >>>> 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 > >> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri May 29 19:03: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 5A9771AD34C for ; Fri, 29 May 2015 19:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 fY5ZSUnOz20f for ; Fri, 29 May 2015 19:03:19 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F861AD0D1 for ; Fri, 29 May 2015 19:03:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 00A78240673; Fri, 29 May 2015 19:03:19 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 834A22406E2; Fri, 29 May 2015 19:03:15 -0700 (PDT) Message-ID: <55691A51.6010303@joelhalpern.com> Date: Fri, 29 May 2015 22:02:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Susan Hares , 'Andy Bierman' References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> <001501d09a7c$58197530$084c5f90$@ndzh.com> In-Reply-To: <001501d09a7c$58197530$084c5f90$@ndzh.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: i2rs@ietf.org, 'Jeff Haas' , chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 02:03:22 -0000 Some of the discussions in the working group earlier (not formally captured in the archtiecture, and not clarified in discussion) were of the form "If the operator wants to shoot himself in the foot, I2RS' job is to let him." If that is the model that the working group is assuming, then I am not sure that consistency / validity enforcement is desired. I don't have a strong opinion one way or another. I believe at least some people saw the omission of such checks as a path to improvd transaction rates. My only concern is to avoid accidentally chaning a working group agreement. yours, Joel On 5/29/15 9:59 PM, Susan Hares wrote: > Andy: > > See one question below. If alter to not store invalid values in the datastore - is my addition to Jeff's 2.4 addition acceptable? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman > Sent: Friday, May 29, 2015 8:42 PM > To: Susan Hares > Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: >>> Andy: >>> >>> >>> >>> On all actions working or not – you should look at section 7.9 of the >>> architecture. It allows “perform all or none”, “perform until error”, and >>> “perform all storing errors.” I will propose an addition to section 2.4 >>> to Jeff’s document: >>> >>> > >>> OK -- I remember these options now. > >> It should be clear in the document that stopping on error or recording errors does not mean the agent will leave the datastore in an invalid >state. Most YANG validation errors can be pruned from the datastore. >> This may or may not leave the datastore in an operationally useful state. >> The must/min-elements/unique statements can cause validation errors on nodes outside the edit list. >> >> NETCONF does not allow validation errors in the running datastore. >> I2RS should not allow validation errors in the ephemeral data. > > [sue]: On case: or if perform and until error / or perform and record error - you are assuming these are a validation error? > You are commending I2RS should not store values with invalid data. Are you against logging the validation errors? > > Andy > >> >> 2.4 ) Transaction to ephemeral state: >> >> >> >> The ephemeral state should support a multiple parts of a operation >> occurring in a single message, but it does not require multi-message >> atomicity and rollback. Three types of error handling should be supported: >> >> >> >> Perform all or none: This traditional SNMP semantic indicates that >> >> other I2RS agent will keep enough state when handling a single >> >> message to roll back the operations within that message. Either >> >> all the operations will succeed, or none of them will be applied >> >> and an error message will report the single failure which caused >> >> them not to be applied. This is useful when there are, for >> >> example, mutual dependencies across operations in the message. >> >> >> >> Perform until error: In this case, the operations in the message >> >> are applied in the specified order. When an error occurs, no >> >> further operations are applied, and an error is returned >> >> indicating the failure. This is useful if there are >> dependencies >> >> among the operations and they can be topologically sorted. >> >> >> >> Perform all storing errors: In this case, the I2RS Agent will >> >> attempt to perform all the operations in the message, and will >> >> return error indications for each one that fails. This is >> useful >> >> when there is no dependency across the operation, or where the >> >> client would prefer to sort out the effect of errors on its own. >> >> >> >> In the interest of robustness and clarity of protocol state, the >> >> protocol will include an explicit reply to modification or write >> >> operations even when they fully succeed. >> >> >> >> >> >> Will this cover the architecture document 7.9 transactions impact on >> ephemeral state? >> >> >> >> Sue Hares >> >> >> >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Friday, May 29, 2015 1:44 PM >> To: 'Andy Bierman' >> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; >> 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' >> Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> >> >> Andy: >> >> >> >> I missed the second part of the email >> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in >> my earlier message: >> >> >> >>> . " The last paragraph sounds like some nodes will be accepted and >>> others rejected. >> >>> If any nodes are rejected, the entire edit should be rejected. >> >> >> >> RESTCONF does an atomic action within a http session. NETCONF within a >> commit. Section 6.2 of the I2RS architecture document describes state >> storage for I2RS, and it does not have the atomic requirement for the >> protocol. Instead section 3.3 of the I2RS architecture document calls >> for this to be model driver. Let me provide examples from the 2 major >> I2RS protocol independent models: >> >> >> >> The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes >> that each route will be associated with the following: route >> preference, active, installed. Notifications for route change will be >> given if route is installed, active, and a reason given, or if the >> route commit fails. Some routes may be accepted, and some routes rejected for installation to the >> RIB. The concept is the client will be able to detect when a route is >> rejected. >> >> >> >> The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 >> discusses the challenge that topology models are not: configuration >> data only or operational data only – but a combination of both in ephemeral state. >> Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology >> model which is operational (read-only) that contains data from: a) >> only read from operational units, b) a configured topology, and c) >> combination topology (operational state and configured). (A second >> alternative is to just have “a” and “b”, but for now let’s focus on a, >> b, and c). The “C” combination topology may be generated based on >> priority of configured topology versus operational data. The inclusion in “c” may also be validated (E.g. >> interface up, or L3 link runs on tunnel over interface which is up)). >> >> >> >> These two model documents show why atomic state may be on a very small >> section of the whole change. >> >> >> >>> I don’t think the rule-list should store the client priority. >> >>> It should be in the 'group' list, or outside NACM completely." >> >> >> >> Your alternate proposal are: >> >> >> >> 1) Moving i2rs-priority to group list >> >> 2) Adding a i2rs-client [unspecified location] >> >> >> >> This mail deals with #1. If you have more details on proposal #2, >> please suggest them on the list. >> >> >> >> list i2rs-client { >> >> key name; >> >> leaf name { >> >> description "The client name"; >> >> type i2rs:client-name; >> >> } >> >> leaf priority { >> >> description "The priority value assigned to this client."; >> >> type i2rs:client-priority; >> >> } >> >> } >> >> >> >> Question: Is this i2rs-list to be included in the group list for NACM >> (as listed below from RFC6536) as a leaf list below? >> >> >> >> container groups { >> >> description >> >> "NETCONF Access Control Groups."; >> >> >> >> list group { >> >> key name; >> >> description >> >> "One NACM Group Entry. This list will only contain >> >> configured entries, not any entries learned from >> >> any transport protocols."; >> >> >> >> leaf name { >> >> type group-name-type; >> >> description >> >> "Group name associated with this entry."; >> >> } >> >> >> >> leaf-list user-name { >> >> type user-name-type; >> >> description >> >> "Each entry identifies the username of >> >> a member of the group associated with >> >> this entry."; >> >> } >> >> # add leaf-list I2rs-client here >> >> } >> >> } >> >> Your message: >> http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html >> >> States: "I think I2RS interaction with NACM needs to be clearly defined. >> NACM implementations do not currently check write requests >> >> on config=false data. It is possible some edits to NACM are needed >> even if no objects are added to the data structure." >> >> >> >> Do you have a proposal for changing the text in section 5.2 of >> draft-haas-i2rs-ephemeral-state-reqs-00? >> >> Is it sufficient to state: “NACM implementations for I2RS will need to >> check write request on config=false, ephemeral = true. “ >> >> before the paragraph: >> >> >> >> “Ephemeral configuration state nodes that are created or altered by >> users that match a rule carrying i2rs-priority will have those nodes >> annotated with metadata. Additionally, during commit processing, if >> nodes are found where i2rs-priority is already present, and the >> priority is better than the transaction's user's priority for that >> node, the commit SHALL fail. An appropriate error should be returned >> >> to the user stating the nodes where the user had insufficient >> >> priority to override the state. >> >> >> >> I’m unclear what this means: “It is possible some edits to NACM are >> needed even if no objects are added to the data structure." >> >> >> >> Sue >> >> >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Thursday, May 28, 2015 8:23 PM >> To: Susan Hares >> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> >> >> On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: >> >>> Andy: >> >>> >> >>> Thank you for your question. Let me precise. >> >>> >> >>> Jeff proposes that clients specify the priority mechanism is an >>> attribute that is stored in the NACM list on the agent (see Section 5.2 as described >>> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >>> client-Agent identities are load in a mechanism which is out-of-band >>> from the I2RS protocol these values. Into the Client, the Agent's ID is loaded. >>> Into the Agent, the valid client's identity is loaded along with the >>> client's priority. AAA (Radius/Diameter) is an example of an >>> out-of-band mechanism to pass the information with. IMU (in my >>> understanding), the NACM on the agent is created based on this AAA >>> loading. The i2rs secondary identity is loaded via an edit-config >>> mechanism in a config operation (see section 5.1 of Jeff's >>> document.). Please let me know if my understanding of NACM creation based on AAA input is correct. >> >>> >> >> >> >> That is an optional mode. >> >> There is also a local users table that can be used. >> >> >> >> >> >>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent >>> will be annotated with meta-data with the client-id, priority, and secondary ID. >> >>> >> >>> The only proposed change to section 5.2 requirements is to the >> >>> sentence "Additionally, during commit processing, if >> >>> nodes are found where i2rs-priority is already present, and the >> >>> priority is better than the transaction's user's priority for that >> >>> node, the commit SHALL fail. >> >>> >> >>> " Additionally, during commit processing" is incorrect because there is >>> not commit processing. Jeff stated we are still working with both NETCONF >>> and RESTCONF - so we must allow for a commit process. In the meeting >>> I noted that the architecture indicates a change is possible only if >>> the priority is greater than (>) existing priority. (First rather than last). >>> Therefore this text should read: "Additionally, during the operation >>> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where >>> i2rs-priority is already present, and the priority is equal to or >>> better than the transaction's user's priority for the node, the >>> operation/commit SHALL fail." >> >>> >> >>> Do you have any suggestions for modifications to section 5 of Jeff's >>> document? >> >>> >> >>> Sue >> >>> >> >>> ============================ >> >>> Jeff's document 5.2 states: >> >>> >> >>> To support Multi-Headed Control, I2RS requires that there be a >> >>> decidable means of arbitrating the correct state of data when >> >>> multiple clients attempt to manipulate the same piece of data. >>> This >> >>> is done via a priority mechanism with the highest priority winning. >> >>> This priority may vary on a per-node or sub-tree basis based for a >> >>> given identity. >> >>> >> >>> This further implies that priority is an attribute that is stored >>> in >> >>> the NETCONF Access Control Model [RFC6536] as part of a rule-list. >> >>> E.g.: >> >>> >> >>> Ephemeral configuration state nodes that are created or altered by >> >>> users that match a rule carrying i2rs-priority will have those >>> nodes >> >>> annotated with metadata. Additionally, during commit processing, >>> if >> >>> nodes are found where i2rs-priority is already present, and the >> >>> priority is better than the transaction's user's priority for that >> >>> node, the commit SHALL fail. An appropriate error should be >>> returned >> >>> to the user stating the nodes where the user had insufficient >> >>> priority to override the state. >> >>> >> >> >> >> >> >> The last paragraph sounds like some nodes will be accepted and others >> rejected. >> >> If any nodes are rejected, the entire edit should be rejected. >> >> >> >> I don;t think the rule-list should store the client priority. >> >> It should be in the 'group' list, or outside NACM completely. >> >> >> >> >> >> Andy >> >> >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Andy Bierman [mailto:andy@yumaworks.com] >> >>> Sent: Thursday, May 28, 2015 7:40 PM >> >>> To: Susan Hares >> >>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >> >>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >> >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >>> >> >>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >> >>>> Andy: >> >>>> >> >>>> Yes - the client with priority and secondary identity are inherently >>>> simple additions. Can you confirm my understanding below based on Jeff's >>>> document? >> >>>> >> >>> >> >>> Not sure what you mean. >> >>> i don't think the client should provide the priority in request messages. >> >>> This is configured on the agent, not requested by the client. >> >>> >> >>> >> >>>> Can you explain your statement "I do not want to change NETCONF or >>>> RESTCONF to use client priority?" What are you proposing that you >>>> do not want to add the NACM list the priority? >> >>> >> >>> I don't want to change NETCONF and RESTCONF so that config=true >>> objects use priority. Only I2RS should use it. >> >>> >> >>>> >> >>>> Sue >> >>> >> >>> Andy >> >>> >> >>>> =============== >> >>>> >> >>>> Example >> >>>> ------------------------ >> >>>> 1) any multiple TCP sessions from a client application will use a >>>> different ID if they want a different priority for write of an >>>> object >> >>>> Application 1: TCP session 1 - priority 1, >>>> secondary-identity "pub-sub monitor" >> >>>> Application 1: TCP session 2 - priority 10, >>>> secondary-identity "tracing monitor" >> >>>> Application 1: TCP session 3 - priority 20, opaque "Weekly >>>> config" >> >>>> Application 1: TCP session 4 - priority 55, opaque >>>> "Emergency config" >> >>>> >> >>>> Jeff's META-data example: >> >>>> >> >>>> > >>>> i2rs:i2rs-secondary-identity="user1" >>>> i2rs:i2rs-priority="47"> >> >>>> ... >> >>>> >> >>>> >> >>>> For my example TCP session 1 >> >>>> > >>>> I2rs:i2rs-secondary-identity="pub-sub montior" >> >>>> i2rs:i2rs-priority="1"> >> >>>> >> >>>> Juergen's client example: >> >>>> >> >>>> list i2rs-client { >> >>>> key name; >> >>>> leaf name { >> >>>> description "The client name"; >> >>>> type i2rs:client-name; >> >>>> } >> >>>> leaf priority { >> >>>> description "The priority value assigned to this client."; >> >>>> type i2rs:client-priority; >> >>>> } >> >>>> } >> >>>> >> >>>> +--rw rule-list [name] >> >>>> +--rw name string >> >>>> +--rw group* union >> >>>> +--rw rule [name] >> >>>> +--rw name string >> >>>> +--rw module-name? union >> >>>> +--rw (rule-type)? >> >>>> | +--:(protocol-operation) >> >>>> | | +--rw rpc-name? union >> >>>> | +--:(notification) >> >>>> | | +--rw notification-name? union >> >>>> | +--:(data-node) >> >>>> | +--rw path node-instance-identifier >> >>>> +--rw access-operations? union >> >>>> +--rw action action-type >> >>>> +--rw comment? string >> >>>> +--rw i2rs:i2rs-priority i2rs-priority-type >> >>>> >> >>>> Are you proposing something different than Jeff's proposal? >> >>>> >> >>>> Sue >> >>>> >> >>>> -----Original Message----- >> >>>> From: Andy Bierman [mailto:andy@yumaworks.com] >> >>>> Sent: Thursday, May 28, 2015 11:17 AM >> >>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >> >>>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >> >>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >>>> >> >>>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder >>>> wrote: >> >>>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >> >>>>>> >> >>>>>> Although I should be promoting use of NACM, I am not so sure it >> >>>>>> should be mandatory for I2RS or required to configure I2RS client >>>>>> priority. >> >>>>>> >> >>>>>> list i2rs-client { >> >>>>>> key name; >> >>>>>> leaf name { >> >>>>>> description "The client name"; >> >>>>>> type i2rs:client-name; >> >>>>>> } >> >>>>>> leaf priority { >> >>>>>> description "The priority value assigned to this client."; >> >>>>>> type i2rs:client-priority; >> >>>>>> } >> >>>>>> } >> >>>>> >> >>>>> So what is i2rs:client-name - is it any different from a >> >>>>> NETCONF/RESTCONF username? >> >>>>> >> >>>> >> >>>> Is is probably not different. >> >>>> >> >>>> >> >>>>> NACM maps user names into groups and NACM allows to have the >>>>> mapping >> >>>>> supplied by an external source (e.g. RADIUS). If this priority >> >>>>> mapping is kept separate from NACM, would we need to provision >>>>> means >> >>>>> to get the priority from AAA as well? >> >>>>> >> >>>> >> >>>> My point showing the 2 item list is that the information needed to >>>> implement I2RS client priority is rather trivial. >> >>>> It can certainly be made really complicated by the IETF, but it is >>>> an inherently trivial configuration. >> >>>> >> >>>>> And the bigger question: Do we create something specific for I2RS >>>>> or >> >>>>> are we going to extend the generic YANG/NC/RC framework to provide >> >>>>> the tools I2RS needs? This is probably a question the NETCONF WG >>>>> has >> >>>>> to answer. >> >>>> >> >>>> It is good to make reusable features. >> >>>> I don't want to change NETCONF or RESTCONF to use client priority. >> >>>> Let I2RS prove it is useful first. I am not convinced it will >>>> really help. >> >>>> It seems like an implementation detail that is being turned into ad >>>> administrative task. If multiple clients from multiple vendors are >>>> stepping on each other, then the likely outcome of a priority change >>>> by the administrator will be to select which clients should continue >>>> working and which should be broken. >> >>>> >> >>>> >> >>>>> >> >>>>> /js >> >>>>> >> >>>> >> >>>> Andy >> >>>> >> >>>>> -- >> >>>>> 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 >> >>> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Fri May 29 20:13:37 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 7C0951A1BE4 for ; Fri, 29 May 2015 20:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.179 X-Spam-Level: X-Spam-Status: No, score=-0.179 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXVLSYn8l59R for ; Fri, 29 May 2015 20:13:31 -0700 (PDT) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) (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 EE6A01A01F7 for ; Fri, 29 May 2015 20:13:30 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so58931713lbc.1 for ; Fri, 29 May 2015 20:13:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3OOuD3W03lns1lJyjqzhSjbQoLJSeVXcaVP4twaUlD8=; b=U6OwtCMIGgL6cbKLF/Ycy4+51nuf5qSfCRyqX4WYeUtqGc9RIBFKt+u6exUcWClaDk Z6gK9IS18Vc629m+/9pROQSQ5yBBCniBxAcT5cJLt88gGtkh4CA909qTLfwJP2nmebO0 0LoTAhCOEpf/JHZosIyxLQSs/VOdGIUp5icxqORlRhpDC+QP605cw7BPozsyvTM41Z3O mtP9KGx4c9mxIsbSCY3WtIsJ+MetDo9e79JXfNkZQ6D3oMUgrhU5yndwwvhgxqV6Kyli UDtMLVH2K22HBlUMda9ht3wLB2rDYdNE+CCldREoz07Kl0JR4YhFQ7qa86gEqaZ77vQG VsVQ== X-Gm-Message-State: ALoCoQlR5+obv9pUTiEAIpM58ubIyrjBStK31XdRGm/5hygMHxvf2sTvXJEtbxWack3d+MSHi23A MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr10926688lbb.82.1432955609231; Fri, 29 May 2015 20:13:29 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 29 May 2015 20:13:29 -0700 (PDT) In-Reply-To: <55691A51.6010303@joelhalpern.com> References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> <001501d09a7c$58197530$084c5f90$@ndzh.com> <55691A51.6010303@joelhalpern.com> Date: Fri, 29 May 2015 20:13:29 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , Jeff Haas , chen.ran@zte.com.cn, Juergen Schoenwaelder , Alia Atlas , Jeffrey Haas , Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 03:13:35 -0000 On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern wrot= e: > Some of the discussions in the working group earlier (not formally captur= ed > in the archtiecture, and not clarified in discussion) were of the form > "If the operator wants to shoot himself in the foot, I2RS' job is to let > him." > If that is the model that the working group is assuming, then I am not su= re > that consistency / validity enforcement is desired. > > I don't have a strong opinion one way or another. I believe at least som= e > people saw the omission of such checks as a path to improvd transaction > rates. > > My only concern is to avoid accidentally chaning a working group agreemen= t. > IMO it is extremely difficult to implement a datastore that is allowed to have schema-invalid contents. It is one thing to accept the good edits and reject the bad edits. It is quite another to force the server to accept bad edits. I don't think the text is very clear at all. Let's say I have an edit list with 5 edits. Edits 1, 3, and 5 are good and edits 2 and 4 are bad: 1) all-or-none: (NETCONF: rollback-on-error) - no changes to datastore; - errors logged for #2 and #4 (or maybe just #2) 2) until-error: (NETCONF stop-on-error) - edit #1 applied to datastore; - error logged for #2 3) all storing errors: (NETCONF continue-on-error) - edits #1 and #3 and #5 applied - errors logged for #2 and #4 This is my understanding of the 3 options. > yours, > Joel Andy > > On 5/29/15 9:59 PM, Susan Hares wrote: >> >> Andy: >> >> See one question below. If alter to not store invalid values in the >> datastore - is my addition to Jeff's 2.4 addition acceptable? >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, May 29, 2015 8:42 PM >> To: Susan Hares >> Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen Schoenwaelder= ; >> Alia Atlas; Jeffrey Haas; Joel M. Halpern >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: >>>> >>>> Andy: >>>> >>>> >>>> >>>> On all actions working or not =E2=80=93 you should look at section 7.9= of the >>>> architecture. It allows =E2=80=9Cperform all or none=E2=80=9D, =E2=80= =9Cperform until error=E2=80=9D, >>>> and >>>> =E2=80=9Cperform all storing errors.=E2=80=9D I will propose an add= ition to section >>>> 2.4 >>>> to Jeff=E2=80=99s document: >>>> >>>> >> >>>> OK -- I remember these options now. >> >> >>> It should be clear in the document that stopping on error or recording >>> errors does not mean the agent will leave the datastore in an invalid >>> >state. Most YANG validation errors can be pruned from the datastore. >>> This may or may not leave the datastore in an operationally useful stat= e. >>> The must/min-elements/unique statements can cause validation errors on >>> nodes outside the edit list. >>> >>> NETCONF does not allow validation errors in the running datastore. >>> I2RS should not allow validation errors in the ephemeral data. >> >> >> [sue]: On case: or if perform and until error / or perform and record >> error - you are assuming these are a validation error? >> You are commending I2RS should not store values with invalid data. Are >> you against logging the validation errors? >> >> Andy >> >>> >>> 2.4 ) Transaction to ephemeral state: >>> >>> >>> >>> The ephemeral state should support a multiple parts of a operation >>> occurring in a single message, but it does not require multi-message >>> atomicity and rollback. Three types of error handling should be >>> supported: >>> >>> >>> >>> Perform all or none: This traditional SNMP semantic indicates tha= t >>> >>> other I2RS agent will keep enough state when handling a single >>> >>> message to roll back the operations within that message. Either >>> >>> all the operations will succeed, or none of them will be applied >>> >>> and an error message will report the single failure which caused >>> >>> them not to be applied. This is useful when there are, for >>> >>> example, mutual dependencies across operations in the message. >>> >>> >>> >>> Perform until error: In this case, the operations in the message >>> >>> are applied in the specified order. When an error occurs, no >>> >>> further operations are applied, and an error is returned >>> >>> indicating the failure. This is useful if there are >>> dependencies >>> >>> among the operations and they can be topologically sorted. >>> >>> >>> >>> Perform all storing errors: In this case, the I2RS Agent will >>> >>> attempt to perform all the operations in the message, and will >>> >>> return error indications for each one that fails. This is >>> useful >>> >>> when there is no dependency across the operation, or where the >>> >>> client would prefer to sort out the effect of errors on its own. >>> >>> >>> >>> In the interest of robustness and clarity of protocol state, the >>> >>> protocol will include an explicit reply to modification or write >>> >>> operations even when they fully succeed. >>> >>> >>> >>> >>> >>> Will this cover the architecture document 7.9 transactions impact on >>> ephemeral state? >>> >>> >>> >>> Sue Hares >>> >>> >>> >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Friday, May 29, 2015 1:44 PM >>> To: 'Andy Bierman' >>> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; >>> 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' >>> Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>> >>> Andy: >>> >>> >>> >>> I missed the second part of the email >>> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in >>> my earlier message: >>> >>> >>> >>>> . " The last paragraph sounds like some nodes will be accepted and >>>> others rejected. >>> >>> >>>> If any nodes are rejected, the entire edit should be rejected. >>> >>> >>> >>> >>> RESTCONF does an atomic action within a http session. NETCONF within = a >>> commit. Section 6.2 of the I2RS architecture document describes state >>> storage for I2RS, and it does not have the atomic requirement for the >>> protocol. Instead section 3.3 of the I2RS architecture document calls >>> for this to be model driver. Let me provide examples from the 2 major >>> I2RS protocol independent models: >>> >>> >>> >>> The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes >>> that each route will be associated with the following: route >>> preference, active, installed. Notifications for route change will be >>> given if route is installed, active, and a reason given, or if the >>> route commit fails. Some routes may be accepted, and some routes reject= ed >>> for installation to the >>> RIB. The concept is the client will be able to detect when a route is >>> rejected. >>> >>> >>> >>> The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 >>> discusses the challenge that topology models are not: configuration >>> data only or operational data only =E2=80=93 but a combination of both = in >>> ephemeral state. >>> Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology >>> model which is operational (read-only) that contains data from: a) >>> only read from operational units, b) a configured topology, and c) >>> combination topology (operational state and configured). (A second >>> alternative is to just have =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D= , but for now let=E2=80=99s focus on a, >>> b, and c). The =E2=80=9CC=E2=80=9D combination topology may be generat= ed based on >>> priority of configured topology versus operational data. The inclusion >>> in =E2=80=9Cc=E2=80=9D may also be validated (E.g. >>> interface up, or L3 link runs on tunnel over interface which is up)). >>> >>> >>> >>> These two model documents show why atomic state may be on a very small >>> section of the whole change. >>> >>> >>> >>>> I don=E2=80=99t think the rule-list should store the client priority. >>> >>> >>>> It should be in the 'group' list, or outside NACM completely." >>> >>> >>> >>> >>> Your alternate proposal are: >>> >>> >>> >>> 1) Moving i2rs-priority to group list >>> >>> 2) Adding a i2rs-client [unspecified location] >>> >>> >>> >>> This mail deals with #1. If you have more details on proposal #2, >>> please suggest them on the list. >>> >>> >>> >>> list i2rs-client { >>> >>> key name; >>> >>> leaf name { >>> >>> description "The client name"; >>> >>> type i2rs:client-name; >>> >>> } >>> >>> leaf priority { >>> >>> description "The priority value assigned to this client."; >>> >>> type i2rs:client-priority; >>> >>> } >>> >>> } >>> >>> >>> >>> Question: Is this i2rs-list to be included in the group list for NACM >>> (as listed below from RFC6536) as a leaf list below? >>> >>> >>> >>> container groups { >>> >>> description >>> >>> "NETCONF Access Control Groups."; >>> >>> >>> >>> list group { >>> >>> key name; >>> >>> description >>> >>> "One NACM Group Entry. This list will only contain >>> >>> configured entries, not any entries learned from >>> >>> any transport protocols."; >>> >>> >>> >>> leaf name { >>> >>> type group-name-type; >>> >>> description >>> >>> "Group name associated with this entry."; >>> >>> } >>> >>> >>> >>> leaf-list user-name { >>> >>> type user-name-type; >>> >>> description >>> >>> "Each entry identifies the username of >>> >>> a member of the group associated with >>> >>> this entry."; >>> >>> } >>> >>> # add leaf-list I2rs-client here >>> >>> } >>> >>> } >>> >>> Your message: >>> http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html >>> >>> States: "I think I2RS interaction with NACM needs to be clearly define= d. >>> NACM implementations do not currently check write requests >>> >>> on config=3Dfalse data. It is possible some edits to NACM are needed >>> even if no objects are added to the data structure." >>> >>> >>> >>> Do you have a proposal for changing the text in section 5.2 of >>> draft-haas-i2rs-ephemeral-state-reqs-00? >>> >>> Is it sufficient to state: =E2=80=9CNACM implementations for I2RS wil= l need to >>> check write request on config=3Dfalse, ephemeral =3D true. =E2=80=9C >>> >>> before the paragraph: >>> >>> >>> >>> =E2=80=9CEphemeral configuration state nodes that are created or altere= d by >>> users that match a rule carrying i2rs-priority will have those nodes >>> annotated with metadata. Additionally, during commit processing, if >>> nodes are found where i2rs-priority is already present, and the >>> priority is better than the transaction's user's priority for that >>> node, the commit SHALL fail. An appropriate error should be returned >>> >>> to the user stating the nodes where the user had insufficient >>> >>> priority to override the state. >>> >>> >>> >>> I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some edits= to NACM are >>> needed even if no objects are added to the data structure." >>> >>> >>> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> Sent: Thursday, May 28, 2015 8:23 PM >>> To: Susan Hares >>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>> >>> On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: >>> >>>> Andy: >>> >>> >>>> >>> >>>> Thank you for your question. Let me precise. >>> >>> >>>> >>> >>>> Jeff proposes that clients specify the priority mechanism is an >>>> attribute that is stored in the NACM list on the agent (see Section 5.= 2 >>>> as described >>>> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >>>> client-Agent identities are load in a mechanism which is out-of-band >>>> from the I2RS protocol these values. Into the Client, the Agent's ID = is >>>> loaded. >>>> Into the Agent, the valid client's identity is loaded along with the >>>> client's priority. AAA (Radius/Diameter) is an example of an >>>> out-of-band mechanism to pass the information with. IMU (in my >>>> understanding), the NACM on the agent is created based on this AAA >>>> loading. The i2rs secondary identity is loaded via an edit-config >>>> mechanism in a config operation (see section 5.1 of Jeff's >>>> document.). Please let me know if my understanding of NACM creation >>>> based on AAA input is correct. >>> >>> >>>> >>> >>> >>> >>> That is an optional mode. >>> >>> There is also a local users table that can be used. >>> >>> >>> >>> >>> >>>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent >>>> will be annotated with meta-data with the client-id, priority, and >>>> secondary ID. >>> >>> >>>> >>> >>>> The only proposed change to section 5.2 requirements is to the >>> >>> >>>> sentence "Additionally, during commit processing, if >>> >>> >>>> nodes are found where i2rs-priority is already present, and the >>> >>> >>>> priority is better than the transaction's user's priority for that >>> >>> >>>> node, the commit SHALL fail. >>> >>> >>>> >>> >>>> " Additionally, during commit processing" is incorrect because there i= s >>>> not commit processing. Jeff stated we are still working with both >>>> NETCONF >>>> and RESTCONF - so we must allow for a commit process. In the meeting >>>> I noted that the architecture indicates a change is possible only if >>>> the priority is greater than (>) existing priority. (First rather tha= n >>>> last). >>>> Therefore this text should read: "Additionally, during the operation >>>> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where >>>> i2rs-priority is already present, and the priority is equal to or >>>> better than the transaction's user's priority for the node, the >>>> operation/commit SHALL fail." >>> >>> >>>> >>> >>>> Do you have any suggestions for modifications to section 5 of Jeff's >>>> document? >>> >>> >>>> >>> >>>> Sue >>> >>> >>>> >>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> >>> >>>> Jeff's document 5.2 states: >>> >>> >>>> >>> >>>> To support Multi-Headed Control, I2RS requires that there be a >>> >>> >>>> decidable means of arbitrating the correct state of data when >>> >>> >>>> multiple clients attempt to manipulate the same piece of data. >>>> This >>> >>> >>>> is done via a priority mechanism with the highest priority winning= . >>> >>> >>>> This priority may vary on a per-node or sub-tree basis based for a >>> >>> >>>> given identity. >>> >>> >>>> >>> >>>> This further implies that priority is an attribute that is stored >>>> in >>> >>> >>>> the NETCONF Access Control Model [RFC6536] as part of a rule-list. >>> >>> >>>> E.g.: >>> >>> >>>> >>> >>>> Ephemeral configuration state nodes that are created or altered by >>> >>> >>>> users that match a rule carrying i2rs-priority will have those >>>> nodes >>> >>> >>>> annotated with metadata. Additionally, during commit processing, >>>> if >>> >>> >>>> nodes are found where i2rs-priority is already present, and the >>> >>> >>>> priority is better than the transaction's user's priority for that >>> >>> >>>> node, the commit SHALL fail. An appropriate error should be >>>> returned >>> >>> >>>> to the user stating the nodes where the user had insufficient >>> >>> >>>> priority to override the state. >>> >>> >>>> >>> >>> >>> >>> >>> >>> The last paragraph sounds like some nodes will be accepted and others >>> rejected. >>> >>> If any nodes are rejected, the entire edit should be rejected. >>> >>> >>> >>> I don;t think the rule-list should store the client priority. >>> >>> It should be in the 'group' list, or outside NACM completely. >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>> >>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >>> >>>> Sent: Thursday, May 28, 2015 7:40 PM >>> >>> >>>> To: Susan Hares >>> >>> >>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >>> >>> >>>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>> >>> >>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>>> >>> >>>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >>> >>> >>>>> Andy: >>> >>> >>>>> >>> >>>>> Yes - the client with priority and secondary identity are inherently >>>>> simple additions. Can you confirm my understanding below based on >>>>> Jeff's >>>>> document? >>> >>> >>>>> >>> >>>> >>> >>>> Not sure what you mean. >>> >>> >>>> i don't think the client should provide the priority in request >>>> messages. >>> >>> >>>> This is configured on the agent, not requested by the client. >>> >>> >>>> >>> >>>> >>> >>>>> Can you explain your statement "I do not want to change NETCONF or >>>>> RESTCONF to use client priority?" What are you proposing that you >>>>> do not want to add the NACM list the priority? >>> >>> >>>> >>> >>>> I don't want to change NETCONF and RESTCONF so that config=3Dtrue >>>> objects use priority. Only I2RS should use it. >>> >>> >>>> >>> >>>>> >>> >>>>> Sue >>> >>> >>>> >>> >>>> Andy >>> >>> >>>> >>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>>>> >>> >>>>> Example >>> >>> >>>>> ------------------------ >>> >>> >>>>> 1) any multiple TCP sessions from a client application will use a >>>>> different ID if they want a different priority for write of an >>>>> object >>> >>> >>>>> Application 1: TCP session 1 - priority 1, >>>>> secondary-identity "pub-sub monitor" >>> >>> >>>>> Application 1: TCP session 2 - priority 10, >>>>> secondary-identity "tracing monitor" >>> >>> >>>>> Application 1: TCP session 3 - priority 20, opaque "Weekly >>>>> config" >>> >>> >>>>> Application 1: TCP session 4 - priority 55, opaque >>>>> "Emergency config" >>> >>> >>>>> >>> >>>>> Jeff's META-data example: >>> >>> >>>>> >>> >>>>> >> >>> >>>>> i2rs:i2rs-secondary-identity=3D"user1" >>>>> i2rs:i2rs-priority=3D"47"> >>> >>> >>>>> ... >>> >>> >>>>> >>> >>> >>>>> >>> >>>>> For my example TCP session 1 >>> >>> >>>>> >> >>> >>>>> I2rs:i2rs-secondary-identity=3D"pub-sub montior" >>> >>> >>>>> i2rs:i2rs-priority=3D"1"> >>> >>> >>>>> >>> >>>>> Juergen's client example: >>> >>> >>>>> >>> >>>>> list i2rs-client { >>> >>> >>>>> key name; >>> >>> >>>>> leaf name { >>> >>> >>>>> description "The client name"; >>> >>> >>>>> type i2rs:client-name; >>> >>> >>>>> } >>> >>> >>>>> leaf priority { >>> >>> >>>>> description "The priority value assigned to this client."; >>> >>> >>>>> type i2rs:client-priority; >>> >>> >>>>> } >>> >>> >>>>> } >>> >>> >>>>> >>> >>>>> +--rw rule-list [name] >>> >>> >>>>> +--rw name string >>> >>> >>>>> +--rw group* union >>> >>> >>>>> +--rw rule [name] >>> >>> >>>>> +--rw name string >>> >>> >>>>> +--rw module-name? union >>> >>> >>>>> +--rw (rule-type)? >>> >>> >>>>> | +--:(protocol-operation) >>> >>> >>>>> | | +--rw rpc-name? union >>> >>> >>>>> | +--:(notification) >>> >>> >>>>> | | +--rw notification-name? union >>> >>> >>>>> | +--:(data-node) >>> >>> >>>>> | +--rw path node-instance-identifier >>> >>> >>>>> +--rw access-operations? union >>> >>> >>>>> +--rw action action-type >>> >>> >>>>> +--rw comment? string >>> >>> >>>>> +--rw i2rs:i2rs-priority i2rs-priority-type >>> >>> >>>>> >>> >>>>> Are you proposing something different than Jeff's proposal? >>> >>> >>>>> >>> >>>>> Sue >>> >>> >>>>> >>> >>>>> -----Original Message----- >>> >>> >>>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >>> >>>>> Sent: Thursday, May 28, 2015 11:17 AM >>> >>> >>>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >>> >>> >>>>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >>> >>> >>>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>>>> >>> >>>>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder >>>>> wrote: >>> >>> >>>>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>> >>> >>>>>>> >>> >>>>>>> Although I should be promoting use of NACM, I am not so sure it >>> >>> >>>>>>> should be mandatory for I2RS or required to configure I2RS client >>>>>>> priority. >>> >>> >>>>>>> >>> >>>>>>> list i2rs-client { >>> >>> >>>>>>> key name; >>> >>> >>>>>>> leaf name { >>> >>> >>>>>>> description "The client name"; >>> >>> >>>>>>> type i2rs:client-name; >>> >>> >>>>>>> } >>> >>> >>>>>>> leaf priority { >>> >>> >>>>>>> description "The priority value assigned to this client."; >>> >>> >>>>>>> type i2rs:client-priority; >>> >>> >>>>>>> } >>> >>> >>>>>>> } >>> >>> >>>>>> >>> >>>>>> So what is i2rs:client-name - is it any different from a >>> >>> >>>>>> NETCONF/RESTCONF username? >>> >>> >>>>>> >>> >>>>> >>> >>>>> Is is probably not different. >>> >>> >>>>> >>> >>>>> >>> >>>>>> NACM maps user names into groups and NACM allows to have the >>>>>> mapping >>> >>> >>>>>> supplied by an external source (e.g. RADIUS). If this priority >>> >>> >>>>>> mapping is kept separate from NACM, would we need to provision >>>>>> means >>> >>> >>>>>> to get the priority from AAA as well? >>> >>> >>>>>> >>> >>>>> >>> >>>>> My point showing the 2 item list is that the information needed to >>>>> implement I2RS client priority is rather trivial. >>> >>> >>>>> It can certainly be made really complicated by the IETF, but it is >>>>> an inherently trivial configuration. >>> >>> >>>>> >>> >>>>>> And the bigger question: Do we create something specific for I2RS >>>>>> or >>> >>> >>>>>> are we going to extend the generic YANG/NC/RC framework to provide >>> >>> >>>>>> the tools I2RS needs? This is probably a question the NETCONF WG >>>>>> has >>> >>> >>>>>> to answer. >>> >>> >>>>> >>> >>>>> It is good to make reusable features. >>> >>> >>>>> I don't want to change NETCONF or RESTCONF to use client priority. >>> >>> >>>>> Let I2RS prove it is useful first. I am not convinced it will >>>>> really help. >>> >>> >>>>> It seems like an implementation detail that is being turned into ad >>>>> administrative task. If multiple clients from multiple vendors are >>>>> stepping on each other, then the likely outcome of a priority change >>>>> by the administrator will be to select which clients should continue >>>>> working and which should be broken. >>> >>> >>>>> >>> >>>>> >>> >>>>>> >>> >>>>>> /js >>> >>> >>>>>> >>> >>>>> >>> >>>>> Andy >>> >>> >>>>> >>> >>>>>> -- >>> >>> >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> >>> >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >>> >>> >>>>>> Fax: +49 421 200 3103 >>> >>> >>>>> >>> >>>>> _______________________________________________ >>> >>> >>>>> i2rs mailing list >>> >>> >>>>> i2rs@ietf.org >>> >>> >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >>>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > From nobody Fri May 29 20:34:36 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8403A1A702D for ; Fri, 29 May 2015 20:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 0PymOCqb0q22 for ; Fri, 29 May 2015 20:34:30 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD36B1A6FEE for ; Fri, 29 May 2015 20:34:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id ADBB0240495; Fri, 29 May 2015 20:34:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 6D9B4240063; Fri, 29 May 2015 20:34:29 -0700 (PDT) Message-ID: <55692FB3.5090606@joelhalpern.com> Date: Fri, 29 May 2015 23:34:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Bierman References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> <001501d09a7c$58197530$084c5f90$@ndzh.com> <55691A51.6010303@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , Jeff Haas , chen.ran@zte.com.cn, Juergen Schoenwaelder , Alia Atlas , Jeffrey Haas , Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 03:34:34 -0000 Your examples match my understanding of the intent of the draft. The assumption is that if there is mutual dependence, the client will use all-or-none if there is an ordering constraint, the client will use until-error if there is no ordering coupling, but just a bundling for convenience, the client can use all storing errors. The text does not specify what consistency checks are applied in cases 2 and 3. Classic network management would lead one to expect full consistency checks. Modeling as individual api operations (and some people's view of cli) would lead to no consistency checks. Yours, Joel On 5/29/15 11:13 PM, Andy Bierman wrote: > On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern wrote: >> Some of the discussions in the working group earlier (not formally captured >> in the archtiecture, and not clarified in discussion) were of the form >> "If the operator wants to shoot himself in the foot, I2RS' job is to let >> him." >> If that is the model that the working group is assuming, then I am not sure >> that consistency / validity enforcement is desired. >> >> I don't have a strong opinion one way or another. I believe at least some >> people saw the omission of such checks as a path to improvd transaction >> rates. >> >> My only concern is to avoid accidentally chaning a working group agreement. >> > > > IMO it is extremely difficult to implement a datastore that is allowed > to have schema-invalid contents. It is one thing to accept the good > edits and reject the bad edits. It is quite another to force the server > to accept bad edits. > > I don't think the text is very clear at all. > Let's say I have an edit list with 5 edits. > Edits 1, 3, and 5 are good and edits 2 and 4 are bad: > > 1) all-or-none: (NETCONF: rollback-on-error) > - no changes to datastore; > - errors logged for #2 and #4 (or maybe just #2) > > 2) until-error: (NETCONF stop-on-error) > - edit #1 applied to datastore; > - error logged for #2 > > 3) all storing errors: (NETCONF continue-on-error) > - edits #1 and #3 and #5 applied > - errors logged for #2 and #4 > > This is my understanding of the 3 options. > > > >> yours, >> Joel > > Andy > >> >> On 5/29/15 9:59 PM, Susan Hares wrote: >>> >>> Andy: >>> >>> See one question below. If alter to not store invalid values in the >>> datastore - is my addition to Jeff's 2.4 addition acceptable? >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman >>> Sent: Friday, May 29, 2015 8:42 PM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen Schoenwaelder; >>> Alia Atlas; Jeffrey Haas; Joel M. Halpern >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: >>>>> >>>>> Andy: >>>>> >>>>> >>>>> >>>>> On all actions working or not – you should look at section 7.9 of the >>>>> architecture. It allows “perform all or none”, “perform until error”, >>>>> and >>>>> “perform all storing errors.” I will propose an addition to section >>>>> 2.4 >>>>> to Jeff’s document: >>>>> >>>>> >>> >>>>> OK -- I remember these options now. >>> >>> >>>> It should be clear in the document that stopping on error or recording >>>> errors does not mean the agent will leave the datastore in an invalid >>>>> state. Most YANG validation errors can be pruned from the datastore. >>>> This may or may not leave the datastore in an operationally useful state. >>>> The must/min-elements/unique statements can cause validation errors on >>>> nodes outside the edit list. >>>> >>>> NETCONF does not allow validation errors in the running datastore. >>>> I2RS should not allow validation errors in the ephemeral data. >>> >>> >>> [sue]: On case: or if perform and until error / or perform and record >>> error - you are assuming these are a validation error? >>> You are commending I2RS should not store values with invalid data. Are >>> you against logging the validation errors? >>> >>> Andy >>> >>>> >>>> 2.4 ) Transaction to ephemeral state: >>>> >>>> >>>> >>>> The ephemeral state should support a multiple parts of a operation >>>> occurring in a single message, but it does not require multi-message >>>> atomicity and rollback. Three types of error handling should be >>>> supported: >>>> >>>> >>>> >>>> Perform all or none: This traditional SNMP semantic indicates that >>>> >>>> other I2RS agent will keep enough state when handling a single >>>> >>>> message to roll back the operations within that message. Either >>>> >>>> all the operations will succeed, or none of them will be applied >>>> >>>> and an error message will report the single failure which caused >>>> >>>> them not to be applied. This is useful when there are, for >>>> >>>> example, mutual dependencies across operations in the message. >>>> >>>> >>>> >>>> Perform until error: In this case, the operations in the message >>>> >>>> are applied in the specified order. When an error occurs, no >>>> >>>> further operations are applied, and an error is returned >>>> >>>> indicating the failure. This is useful if there are >>>> dependencies >>>> >>>> among the operations and they can be topologically sorted. >>>> >>>> >>>> >>>> Perform all storing errors: In this case, the I2RS Agent will >>>> >>>> attempt to perform all the operations in the message, and will >>>> >>>> return error indications for each one that fails. This is >>>> useful >>>> >>>> when there is no dependency across the operation, or where the >>>> >>>> client would prefer to sort out the effect of errors on its own. >>>> >>>> >>>> >>>> In the interest of robustness and clarity of protocol state, the >>>> >>>> protocol will include an explicit reply to modification or write >>>> >>>> operations even when they fully succeed. >>>> >>>> >>>> >>>> >>>> >>>> Will this cover the architecture document 7.9 transactions impact on >>>> ephemeral state? >>>> >>>> >>>> >>>> Sue Hares >>>> >>>> >>>> >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Friday, May 29, 2015 1:44 PM >>>> To: 'Andy Bierman' >>>> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas'; >>>> 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' >>>> Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 >>>> >>>> >>>> >>>> Andy: >>>> >>>> >>>> >>>> I missed the second part of the email >>>> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in >>>> my earlier message: >>>> >>>> >>>> >>>>> . " The last paragraph sounds like some nodes will be accepted and >>>>> others rejected. >>>> >>>> >>>>> If any nodes are rejected, the entire edit should be rejected. >>>> >>>> >>>> >>>> >>>> RESTCONF does an atomic action within a http session. NETCONF within a >>>> commit. Section 6.2 of the I2RS architecture document describes state >>>> storage for I2RS, and it does not have the atomic requirement for the >>>> protocol. Instead section 3.3 of the I2RS architecture document calls >>>> for this to be model driver. Let me provide examples from the 2 major >>>> I2RS protocol independent models: >>>> >>>> >>>> >>>> The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) proposes >>>> that each route will be associated with the following: route >>>> preference, active, installed. Notifications for route change will be >>>> given if route is installed, active, and a reason given, or if the >>>> route commit fails. Some routes may be accepted, and some routes rejected >>>> for installation to the >>>> RIB. The concept is the client will be able to detect when a route is >>>> rejected. >>>> >>>> >>>> >>>> The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 >>>> discusses the challenge that topology models are not: configuration >>>> data only or operational data only – but a combination of both in >>>> ephemeral state. >>>> Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology >>>> model which is operational (read-only) that contains data from: a) >>>> only read from operational units, b) a configured topology, and c) >>>> combination topology (operational state and configured). (A second >>>> alternative is to just have “a” and “b”, but for now let’s focus on a, >>>> b, and c). The “C” combination topology may be generated based on >>>> priority of configured topology versus operational data. The inclusion >>>> in “c” may also be validated (E.g. >>>> interface up, or L3 link runs on tunnel over interface which is up)). >>>> >>>> >>>> >>>> These two model documents show why atomic state may be on a very small >>>> section of the whole change. >>>> >>>> >>>> >>>>> I don’t think the rule-list should store the client priority. >>>> >>>> >>>>> It should be in the 'group' list, or outside NACM completely." >>>> >>>> >>>> >>>> >>>> Your alternate proposal are: >>>> >>>> >>>> >>>> 1) Moving i2rs-priority to group list >>>> >>>> 2) Adding a i2rs-client [unspecified location] >>>> >>>> >>>> >>>> This mail deals with #1. If you have more details on proposal #2, >>>> please suggest them on the list. >>>> >>>> >>>> >>>> list i2rs-client { >>>> >>>> key name; >>>> >>>> leaf name { >>>> >>>> description "The client name"; >>>> >>>> type i2rs:client-name; >>>> >>>> } >>>> >>>> leaf priority { >>>> >>>> description "The priority value assigned to this client."; >>>> >>>> type i2rs:client-priority; >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> Question: Is this i2rs-list to be included in the group list for NACM >>>> (as listed below from RFC6536) as a leaf list below? >>>> >>>> >>>> >>>> container groups { >>>> >>>> description >>>> >>>> "NETCONF Access Control Groups."; >>>> >>>> >>>> >>>> list group { >>>> >>>> key name; >>>> >>>> description >>>> >>>> "One NACM Group Entry. This list will only contain >>>> >>>> configured entries, not any entries learned from >>>> >>>> any transport protocols."; >>>> >>>> >>>> >>>> leaf name { >>>> >>>> type group-name-type; >>>> >>>> description >>>> >>>> "Group name associated with this entry."; >>>> >>>> } >>>> >>>> >>>> >>>> leaf-list user-name { >>>> >>>> type user-name-type; >>>> >>>> description >>>> >>>> "Each entry identifies the username of >>>> >>>> a member of the group associated with >>>> >>>> this entry."; >>>> >>>> } >>>> >>>> # add leaf-list I2rs-client here >>>> >>>> } >>>> >>>> } >>>> >>>> Your message: >>>> http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html >>>> >>>> States: "I think I2RS interaction with NACM needs to be clearly defined. >>>> NACM implementations do not currently check write requests >>>> >>>> on config=false data. It is possible some edits to NACM are needed >>>> even if no objects are added to the data structure." >>>> >>>> >>>> >>>> Do you have a proposal for changing the text in section 5.2 of >>>> draft-haas-i2rs-ephemeral-state-reqs-00? >>>> >>>> Is it sufficient to state: “NACM implementations for I2RS will need to >>>> check write request on config=false, ephemeral = true. “ >>>> >>>> before the paragraph: >>>> >>>> >>>> >>>> “Ephemeral configuration state nodes that are created or altered by >>>> users that match a rule carrying i2rs-priority will have those nodes >>>> annotated with metadata. Additionally, during commit processing, if >>>> nodes are found where i2rs-priority is already present, and the >>>> priority is better than the transaction's user's priority for that >>>> node, the commit SHALL fail. An appropriate error should be returned >>>> >>>> to the user stating the nodes where the user had insufficient >>>> >>>> priority to override the state. >>>> >>>> >>>> >>>> I’m unclear what this means: “It is possible some edits to NACM are >>>> needed even if no objects are added to the data structure." >>>> >>>> >>>> >>>> Sue >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>>> Sent: Thursday, May 28, 2015 8:23 PM >>>> To: Susan Hares >>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >>>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>>> >>>> >>>> >>>> On Thu, May 28, 2015 at 5:09 PM, Susan Hares wrote: >>>> >>>>> Andy: >>>> >>>> >>>>> >>>> >>>>> Thank you for your question. Let me precise. >>>> >>>> >>>>> >>>> >>>>> Jeff proposes that clients specify the priority mechanism is an >>>>> attribute that is stored in the NACM list on the agent (see Section 5.2 >>>>> as described >>>>> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). The >>>>> client-Agent identities are load in a mechanism which is out-of-band >>>>> from the I2RS protocol these values. Into the Client, the Agent's ID is >>>>> loaded. >>>>> Into the Agent, the valid client's identity is loaded along with the >>>>> client's priority. AAA (Radius/Diameter) is an example of an >>>>> out-of-band mechanism to pass the information with. IMU (in my >>>>> understanding), the NACM on the agent is created based on this AAA >>>>> loading. The i2rs secondary identity is loaded via an edit-config >>>>> mechanism in a config operation (see section 5.1 of Jeff's >>>>> document.). Please let me know if my understanding of NACM creation >>>>> based on AAA input is correct. >>>> >>>> >>>>> >>>> >>>> >>>> >>>> That is an optional mode. >>>> >>>> There is also a local users table that can be used. >>>> >>>> >>>> >>>> >>>> >>>>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an Agent >>>>> will be annotated with meta-data with the client-id, priority, and >>>>> secondary ID. >>>> >>>> >>>>> >>>> >>>>> The only proposed change to section 5.2 requirements is to the >>>> >>>> >>>>> sentence "Additionally, during commit processing, if >>>> >>>> >>>>> nodes are found where i2rs-priority is already present, and the >>>> >>>> >>>>> priority is better than the transaction's user's priority for that >>>> >>>> >>>>> node, the commit SHALL fail. >>>> >>>> >>>>> >>>> >>>>> " Additionally, during commit processing" is incorrect because there is >>>>> not commit processing. Jeff stated we are still working with both >>>>> NETCONF >>>>> and RESTCONF - so we must allow for a commit process. In the meeting >>>>> I noted that the architecture indicates a change is possible only if >>>>> the priority is greater than (>) existing priority. (First rather than >>>>> last). >>>>> Therefore this text should read: "Additionally, during the operation >>>>> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found where >>>>> i2rs-priority is already present, and the priority is equal to or >>>>> better than the transaction's user's priority for the node, the >>>>> operation/commit SHALL fail." >>>> >>>> >>>>> >>>> >>>>> Do you have any suggestions for modifications to section 5 of Jeff's >>>>> document? >>>> >>>> >>>>> >>>> >>>>> Sue >>>> >>>> >>>>> >>>> >>>>> ============================ >>>> >>>> >>>>> Jeff's document 5.2 states: >>>> >>>> >>>>> >>>> >>>>> To support Multi-Headed Control, I2RS requires that there be a >>>> >>>> >>>>> decidable means of arbitrating the correct state of data when >>>> >>>> >>>>> multiple clients attempt to manipulate the same piece of data. >>>>> This >>>> >>>> >>>>> is done via a priority mechanism with the highest priority winning. >>>> >>>> >>>>> This priority may vary on a per-node or sub-tree basis based for a >>>> >>>> >>>>> given identity. >>>> >>>> >>>>> >>>> >>>>> This further implies that priority is an attribute that is stored >>>>> in >>>> >>>> >>>>> the NETCONF Access Control Model [RFC6536] as part of a rule-list. >>>> >>>> >>>>> E.g.: >>>> >>>> >>>>> >>>> >>>>> Ephemeral configuration state nodes that are created or altered by >>>> >>>> >>>>> users that match a rule carrying i2rs-priority will have those >>>>> nodes >>>> >>>> >>>>> annotated with metadata. Additionally, during commit processing, >>>>> if >>>> >>>> >>>>> nodes are found where i2rs-priority is already present, and the >>>> >>>> >>>>> priority is better than the transaction's user's priority for that >>>> >>>> >>>>> node, the commit SHALL fail. An appropriate error should be >>>>> returned >>>> >>>> >>>>> to the user stating the nodes where the user had insufficient >>>> >>>> >>>>> priority to override the state. >>>> >>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>>> The last paragraph sounds like some nodes will be accepted and others >>>> rejected. >>>> >>>> If any nodes are rejected, the entire edit should be rejected. >>>> >>>> >>>> >>>> I don;t think the rule-list should store the client priority. >>>> >>>> It should be in the 'group' list, or outside NACM completely. >>>> >>>> >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> -----Original Message----- >>>> >>>> >>>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>>> >>>> >>>>> Sent: Thursday, May 28, 2015 7:40 PM >>>> >>>> >>>>> To: Susan Hares >>>> >>>> >>>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >>>> >>>> >>>>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>>> >>>> >>>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>>> >>>> >>>>> >>>> >>>>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares wrote: >>>> >>>> >>>>>> Andy: >>>> >>>> >>>>>> >>>> >>>>>> Yes - the client with priority and secondary identity are inherently >>>>>> simple additions. Can you confirm my understanding below based on >>>>>> Jeff's >>>>>> document? >>>> >>>> >>>>>> >>>> >>>>> >>>> >>>>> Not sure what you mean. >>>> >>>> >>>>> i don't think the client should provide the priority in request >>>>> messages. >>>> >>>> >>>>> This is configured on the agent, not requested by the client. >>>> >>>> >>>>> >>>> >>>>> >>>> >>>>>> Can you explain your statement "I do not want to change NETCONF or >>>>>> RESTCONF to use client priority?" What are you proposing that you >>>>>> do not want to add the NACM list the priority? >>>> >>>> >>>>> >>>> >>>>> I don't want to change NETCONF and RESTCONF so that config=true >>>>> objects use priority. Only I2RS should use it. >>>> >>>> >>>>> >>>> >>>>>> >>>> >>>>>> Sue >>>> >>>> >>>>> >>>> >>>>> Andy >>>> >>>> >>>>> >>>> >>>>>> =============== >>>> >>>> >>>>>> >>>> >>>>>> Example >>>> >>>> >>>>>> ------------------------ >>>> >>>> >>>>>> 1) any multiple TCP sessions from a client application will use a >>>>>> different ID if they want a different priority for write of an >>>>>> object >>>> >>>> >>>>>> Application 1: TCP session 1 - priority 1, >>>>>> secondary-identity "pub-sub monitor" >>>> >>>> >>>>>> Application 1: TCP session 2 - priority 10, >>>>>> secondary-identity "tracing monitor" >>>> >>>> >>>>>> Application 1: TCP session 3 - priority 20, opaque "Weekly >>>>>> config" >>>> >>>> >>>>>> Application 1: TCP session 4 - priority 55, opaque >>>>>> "Emergency config" >>>> >>>> >>>>>> >>>> >>>>>> Jeff's META-data example: >>>> >>>> >>>>>> >>>> >>>>>> >>> >>>> >>>>>> i2rs:i2rs-secondary-identity="user1" >>>>>> i2rs:i2rs-priority="47"> >>>> >>>> >>>>>> ... >>>> >>>> >>>>>> >>>> >>>> >>>>>> >>>> >>>>>> For my example TCP session 1 >>>> >>>> >>>>>> >>> >>>> >>>>>> I2rs:i2rs-secondary-identity="pub-sub montior" >>>> >>>> >>>>>> i2rs:i2rs-priority="1"> >>>> >>>> >>>>>> >>>> >>>>>> Juergen's client example: >>>> >>>> >>>>>> >>>> >>>>>> list i2rs-client { >>>> >>>> >>>>>> key name; >>>> >>>> >>>>>> leaf name { >>>> >>>> >>>>>> description "The client name"; >>>> >>>> >>>>>> type i2rs:client-name; >>>> >>>> >>>>>> } >>>> >>>> >>>>>> leaf priority { >>>> >>>> >>>>>> description "The priority value assigned to this client."; >>>> >>>> >>>>>> type i2rs:client-priority; >>>> >>>> >>>>>> } >>>> >>>> >>>>>> } >>>> >>>> >>>>>> >>>> >>>>>> +--rw rule-list [name] >>>> >>>> >>>>>> +--rw name string >>>> >>>> >>>>>> +--rw group* union >>>> >>>> >>>>>> +--rw rule [name] >>>> >>>> >>>>>> +--rw name string >>>> >>>> >>>>>> +--rw module-name? union >>>> >>>> >>>>>> +--rw (rule-type)? >>>> >>>> >>>>>> | +--:(protocol-operation) >>>> >>>> >>>>>> | | +--rw rpc-name? union >>>> >>>> >>>>>> | +--:(notification) >>>> >>>> >>>>>> | | +--rw notification-name? union >>>> >>>> >>>>>> | +--:(data-node) >>>> >>>> >>>>>> | +--rw path node-instance-identifier >>>> >>>> >>>>>> +--rw access-operations? union >>>> >>>> >>>>>> +--rw action action-type >>>> >>>> >>>>>> +--rw comment? string >>>> >>>> >>>>>> +--rw i2rs:i2rs-priority i2rs-priority-type >>>> >>>> >>>>>> >>>> >>>>>> Are you proposing something different than Jeff's proposal? >>>> >>>> >>>>>> >>>> >>>>>> Sue >>>> >>>> >>>>>> >>>> >>>>>> -----Original Message----- >>>> >>>> >>>>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>>> >>>> >>>>>> Sent: Thursday, May 28, 2015 11:17 AM >>>> >>>> >>>>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >>>> >>>> >>>>>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >>>> >>>> >>>>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>>> >>>> >>>>>> >>>> >>>>>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder >>>>>> wrote: >>>> >>>> >>>>>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>>> >>>> >>>>>>>> >>>> >>>>>>>> Although I should be promoting use of NACM, I am not so sure it >>>> >>>> >>>>>>>> should be mandatory for I2RS or required to configure I2RS client >>>>>>>> priority. >>>> >>>> >>>>>>>> >>>> >>>>>>>> list i2rs-client { >>>> >>>> >>>>>>>> key name; >>>> >>>> >>>>>>>> leaf name { >>>> >>>> >>>>>>>> description "The client name"; >>>> >>>> >>>>>>>> type i2rs:client-name; >>>> >>>> >>>>>>>> } >>>> >>>> >>>>>>>> leaf priority { >>>> >>>> >>>>>>>> description "The priority value assigned to this client."; >>>> >>>> >>>>>>>> type i2rs:client-priority; >>>> >>>> >>>>>>>> } >>>> >>>> >>>>>>>> } >>>> >>>> >>>>>>> >>>> >>>>>>> So what is i2rs:client-name - is it any different from a >>>> >>>> >>>>>>> NETCONF/RESTCONF username? >>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> Is is probably not different. >>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> NACM maps user names into groups and NACM allows to have the >>>>>>> mapping >>>> >>>> >>>>>>> supplied by an external source (e.g. RADIUS). If this priority >>>> >>>> >>>>>>> mapping is kept separate from NACM, would we need to provision >>>>>>> means >>>> >>>> >>>>>>> to get the priority from AAA as well? >>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> My point showing the 2 item list is that the information needed to >>>>>> implement I2RS client priority is rather trivial. >>>> >>>> >>>>>> It can certainly be made really complicated by the IETF, but it is >>>>>> an inherently trivial configuration. >>>> >>>> >>>>>> >>>> >>>>>>> And the bigger question: Do we create something specific for I2RS >>>>>>> or >>>> >>>> >>>>>>> are we going to extend the generic YANG/NC/RC framework to provide >>>> >>>> >>>>>>> the tools I2RS needs? This is probably a question the NETCONF WG >>>>>>> has >>>> >>>> >>>>>>> to answer. >>>> >>>> >>>>>> >>>> >>>>>> It is good to make reusable features. >>>> >>>> >>>>>> I don't want to change NETCONF or RESTCONF to use client priority. >>>> >>>> >>>>>> Let I2RS prove it is useful first. I am not convinced it will >>>>>> really help. >>>> >>>> >>>>>> It seems like an implementation detail that is being turned into ad >>>>>> administrative task. If multiple clients from multiple vendors are >>>>>> stepping on each other, then the likely outcome of a priority change >>>>>> by the administrator will be to select which clients should continue >>>>>> working and which should be broken. >>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>>> >>>> >>>>>>> /js >>>> >>>> >>>>>>> >>>> >>>>>> >>>> >>>>>> Andy >>>> >>>> >>>>>> >>>> >>>>>>> -- >>>> >>>> >>>>>>> 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 >>>> >>>> >>>>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> >> From nobody Sat May 30 00:11:11 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 4A7201A9308 for ; Sat, 30 May 2015 00:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jmLemOLkkw3 for ; Sat, 30 May 2015 00:11:08 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3C1A92E1 for ; Sat, 30 May 2015 00:11:07 -0700 (PDT) Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id B93C91AE0714; Sat, 30 May 2015 09:11:05 +0200 (CEST) Date: Sat, 30 May 2015 09:11:20 +0200 (CEST) Message-Id: <20150530.091120.101983915778236087.mbj@tail-f.com> To: jmh@joelhalpern.com From: Martin Bjorklund In-Reply-To: <55691A51.6010303@joelhalpern.com> References: <001501d09a7c$58197530$084c5f90$@ndzh.com> <55691A51.6010303@joelhalpern.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: i2rs@ietf.org, jhaas@juniper.net, chen.ran@zte.com.cn, j.schoenwaelder@jacobs-university.de, andy@yumaworks.com, akatlas@juniper.net, jhaas@pfrc.org, shares@ndzh.com Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 07:11:09 -0000 "Joel M. Halpern" wrote: > Some of the discussions in the working group earlier (not formally > captured in the archtiecture, and not clarified in discussion) were of > the form > "If the operator wants to shoot himself in the foot, I2RS' job is to > let him." > If that is the model that the working group is assuming, then I am not > sure that consistency / validity enforcement is desired. > > I don't have a strong opinion one way or another. I believe at least > some people saw the omission of such checks as a path to improvd > transaction rates. Yes, semantic constraints means additional processing on the server. How much is implementation dependent, and obviously dependent on the constraint (must ../foo; is cheaper than must //*[contains(., "a")]). If the WG is moving towards a solution where the ephemeral I2RS data is explicitly modelled, you can simply choose to not put semantic constraints into the model in most cases (and explain what the implementation is supposed to do with seemingly invalid data). /martin From nobody Sat May 30 07:47: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 AD8121A1AE1 for ; Sat, 30 May 2015 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -77.255 X-Spam-Level: X-Spam-Status: No, score=-77.255 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, URIBL_BLACK=20, 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 vUmEBHZOCMMm for ; Sat, 30 May 2015 07:47:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 6745E1A1A90 for ; Sat, 30 May 2015 07:47:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.178.112; From: "Susan Hares" To: "'Andy Bierman'" , "'Joel M. Halpern'" References: <011e01d098ae$4e254060$ea6fc120$@ndzh.com> <20150527220901.GA67473@elstar.local> <556654AB.9030206@joelhalpern.com> <20150528060502.GA68091@elstar.local> <020101d0999d$26fe2750$74fa75f0$@ndzh.com> <022701d099a3$b822c5f0$286851d0$@ndzh.com> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> <001501d09a7c$58197530$084c5f90$@ndzh.com> <55691A51.6010303@joelhalpern.com> In-Reply-To: Date: Sat, 30 May 2015 10:46:45 -0400 Message-ID: <008901d09ae7$73a7e410$5af7ac30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGI6C04Ci0f96gPWxVoZalfyv/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4gH00CZbAa2lsVEBP9reuAG8G6FKAVP3lF6dTsX3wA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Jeff Haas' , chen.ran@zte.com.cn, 'Juergen Schoenwaelder' , 'Alia Atlas' , 'Jeffrey Haas' Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-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: Sat, 30 May 2015 14:47:10 -0000 Andy and Joel: Andy's examples seem reasonable to me. Let me try to put together text = for Jeff's document that represents Andy's examples. =20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Friday, May 29, 2015 11:13 PM To: Joel M. Halpern Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen = Schoenwaelder; Alia Atlas; Jeffrey Haas; Susan Hares Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Fri, May 29, 2015 at 7:02 PM, Joel M. Halpern = wrote: > Some of the discussions in the working group earlier (not formally=20 > captured in the archtiecture, and not clarified in discussion) were of = > the form "If the operator wants to shoot himself in the foot, I2RS'=20 > job is to let him." > If that is the model that the working group is assuming, then I am not = > sure that consistency / validity enforcement is desired. > > I don't have a strong opinion one way or another. I believe at least=20 > some people saw the omission of such checks as a path to improvd=20 > transaction rates. > > My only concern is to avoid accidentally chaning a working group = agreement. > IMO it is extremely difficult to implement a datastore that is allowed = to have schema-invalid contents. It is one thing to accept the good = edits and reject the bad edits. It is quite another to force the server = to accept bad edits. I don't think the text is very clear at all. Let's say I have an edit list with 5 edits. Edits 1, 3, and 5 are good and edits 2 and 4 are bad: 1) all-or-none: (NETCONF: rollback-on-error) - no changes to datastore; - errors logged for #2 and #4 (or maybe just #2) 2) until-error: (NETCONF stop-on-error) - edit #1 applied to datastore; - error logged for #2 3) all storing errors: (NETCONF continue-on-error) - edits #1 and #3 and #5 applied - errors logged for #2 and #4 This is my understanding of the 3 options. > yours, > Joel Andy > > On 5/29/15 9:59 PM, Susan Hares wrote: >> >> Andy: >> >> See one question below. If alter to not store invalid values in the=20 >> datastore - is my addition to Jeff's 2.4 addition acceptable? >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman >> Sent: Friday, May 29, 2015 8:42 PM >> To: Susan Hares >> Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen=20 >> Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern >> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >> >> On Fri, May 29, 2015 at 2:55 PM, Susan Hares wrote: >>>> >>>> Andy: >>>> >>>> >>>> >>>> On all actions working or not =E2=80=93 you should look at section = 7.9 of=20 >>>> the architecture. It allows =E2=80=9Cperform all or none=E2=80=9D, = =E2=80=9Cperform until=20 >>>> error=E2=80=9D, and >>>> =E2=80=9Cperform all storing errors.=E2=80=9D I will propose an = addition to section >>>> 2.4 >>>> to Jeff=E2=80=99s document: >>>> >>>> >> >>>> OK -- I remember these options now. >> >> >>> It should be clear in the document that stopping on error or=20 >>> recording errors does not mean the agent will leave the datastore in = >>> an invalid >>> >state. Most YANG validation errors can be pruned from the = datastore. >>> This may or may not leave the datastore in an operationally useful = state. >>> The must/min-elements/unique statements can cause validation errors=20 >>> on nodes outside the edit list. >>> >>> NETCONF does not allow validation errors in the running datastore. >>> I2RS should not allow validation errors in the ephemeral data. >> >> >> [sue]: On case: or if perform and until error / or perform and=20 >> record error - you are assuming these are a validation error? >> You are commending I2RS should not store values with invalid data. = Are >> you against logging the validation errors? >> >> Andy >> >>> >>> 2.4 ) Transaction to ephemeral state: >>> >>> >>> >>> The ephemeral state should support a multiple parts of a operation=20 >>> occurring in a single message, but it does not require multi-message = >>> atomicity and rollback. Three types of error handling should be >>> supported: >>> >>> >>> >>> Perform all or none: This traditional SNMP semantic indicates = that >>> >>> other I2RS agent will keep enough state when handling a=20 >>> single >>> >>> message to roll back the operations within that message. =20 >>> Either >>> >>> all the operations will succeed, or none of them will be=20 >>> applied >>> >>> and an error message will report the single failure which=20 >>> caused >>> >>> them not to be applied. This is useful when there are, for >>> >>> example, mutual dependencies across operations in the = message. >>> >>> >>> >>> Perform until error: In this case, the operations in the = message >>> >>> are applied in the specified order. When an error occurs, no >>> >>> further operations are applied, and an error is returned >>> >>> indicating the failure. This is useful if there are=20 >>> dependencies >>> >>> among the operations and they can be topologically sorted. >>> >>> >>> >>> Perform all storing errors: In this case, the I2RS Agent will >>> >>> attempt to perform all the operations in the message, and=20 >>> will >>> >>> return error indications for each one that fails. This is=20 >>> useful >>> >>> when there is no dependency across the operation, or where=20 >>> the >>> >>> client would prefer to sort out the effect of errors on its = own. >>> >>> >>> >>> In the interest of robustness and clarity of protocol state, the >>> >>> protocol will include an explicit reply to modification or write >>> >>> operations even when they fully succeed. >>> >>> >>> >>> >>> >>> Will this cover the architecture document 7.9 transactions impact on = >>> ephemeral state? >>> >>> >>> >>> Sue Hares >>> >>> >>> >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Friday, May 29, 2015 1:44 PM >>> To: 'Andy Bierman' >>> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';=20 >>> 'i2rs@ietf.org'; 'chen.ran@zte.com.cn'; 'Alia Atlas' >>> Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>> >>> Andy: >>> >>> >>> >>> I missed the second part of the email >>> (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in = >>> my earlier message: >>> >>> >>> >>>> . " The last paragraph sounds like some nodes will be accepted and=20 >>>> others rejected. >>> >>> >>>> If any nodes are rejected, the entire edit should be rejected. >>> >>> >>> >>> >>> RESTCONF does an atomic action within a http session. NETCONF = within a >>> commit. Section 6.2 of the I2RS architecture document describes=20 >>> state storage for I2RS, and it does not have the atomic requirement=20 >>> for the protocol. Instead section 3.3 of the I2RS architecture=20 >>> document calls for this to be model driver. Let me provide examples = >>> from the 2 major I2RS protocol independent models: >>> >>> >>> >>> The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00) =20 >>> proposes that each route will be associated with the following:=20 >>> route preference, active, installed. Notifications for route change = >>> will be given if route is installed, active, and a reason given, or=20 >>> if the route commit fails. Some routes may be accepted, and some=20 >>> routes rejected for installation to the >>> RIB. The concept is the client will be able to detect when a route = is >>> rejected. >>> >>> >>> >>> The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5=20 >>> discusses the challenge that topology models are not: configuration=20 >>> data only or operational data only =E2=80=93 but a combination of = both in=20 >>> ephemeral state. >>> Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology=20 >>> model which is operational (read-only) that contains data from: a)=20 >>> only read from operational units, b) a configured topology, and c)=20 >>> combination topology (operational state and configured). (A second=20 >>> alternative is to just have =E2=80=9Ca=E2=80=9D and = =E2=80=9Cb=E2=80=9D, but for now let=E2=80=99s focus on=20 >>> a, b, and c). The =E2=80=9CC=E2=80=9D combination topology may be = generated based=20 >>> on priority of configured topology versus operational data. The=20 >>> inclusion in =E2=80=9Cc=E2=80=9D may also be validated (E.g. >>> interface up, or L3 link runs on tunnel over interface which is = up)). >>> >>> >>> >>> These two model documents show why atomic state may be on a very=20 >>> small section of the whole change. >>> >>> >>> >>>> I don=E2=80=99t think the rule-list should store the client = priority. >>> >>> >>>> It should be in the 'group' list, or outside NACM completely." >>> >>> >>> >>> >>> Your alternate proposal are: >>> >>> >>> >>> 1) Moving i2rs-priority to group list >>> >>> 2) Adding a i2rs-client [unspecified location] >>> >>> >>> >>> This mail deals with #1. If you have more details on proposal #2,=20 >>> please suggest them on the list. >>> >>> >>> >>> list i2rs-client { >>> >>> key name; >>> >>> leaf name { >>> >>> description "The client name"; >>> >>> type i2rs:client-name; >>> >>> } >>> >>> leaf priority { >>> >>> description "The priority value assigned to this client."; >>> >>> type i2rs:client-priority; >>> >>> } >>> >>> } >>> >>> >>> >>> Question: Is this i2rs-list to be included in the group list for=20 >>> NACM (as listed below from RFC6536) as a leaf list below? >>> >>> >>> >>> container groups { >>> >>> description >>> >>> "NETCONF Access Control Groups."; >>> >>> >>> >>> list group { >>> >>> key name; >>> >>> description >>> >>> "One NACM Group Entry. This list will only contain >>> >>> configured entries, not any entries learned from >>> >>> any transport protocols."; >>> >>> >>> >>> leaf name { >>> >>> type group-name-type; >>> >>> description >>> >>> "Group name associated with this entry."; >>> >>> } >>> >>> >>> >>> leaf-list user-name { >>> >>> type user-name-type; >>> >>> description >>> >>> "Each entry identifies the username of >>> >>> a member of the group associated with >>> >>> this entry."; >>> >>> } >>> >>> # add leaf-list I2rs-client here >>> >>> } >>> >>> } >>> >>> Your message: >>> http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html >>> >>> States: "I think I2RS interaction with NACM needs to be clearly = defined. >>> NACM implementations do not currently check write requests >>> >>> on config=3Dfalse data. It is possible some edits to NACM are needed = >>> even if no objects are added to the data structure." >>> >>> >>> >>> Do you have a proposal for changing the text in section 5.2 of=20 >>> draft-haas-i2rs-ephemeral-state-reqs-00? >>> >>> Is it sufficient to state: =E2=80=9CNACM implementations for I2RS = will need to >>> check write request on config=3Dfalse, ephemeral =3D true. =E2=80=9C >>> >>> before the paragraph: >>> >>> >>> >>> =E2=80=9CEphemeral configuration state nodes that are created or = altered by=20 >>> users that match a rule carrying i2rs-priority will have those nodes = >>> annotated with metadata. Additionally, during commit processing, if = >>> nodes are found where i2rs-priority is already present, and the=20 >>> priority is better than the transaction's user's priority for that=20 >>> node, the commit SHALL fail. An appropriate error should be returned >>> >>> to the user stating the nodes where the user had insufficient >>> >>> priority to override the state. >>> >>> >>> >>> I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some = edits to NACM are=20 >>> needed even if no objects are added to the data structure." >>> >>> >>> >>> Sue >>> >>> >>> >>> -----Original Message----- >>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> Sent: Thursday, May 28, 2015 8:23 PM >>> To: Susan Hares >>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas;=20 >>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>> >>> On Thu, May 28, 2015 at 5:09 PM, Susan Hares = wrote: >>> >>>> Andy: >>> >>> >>>> >>> >>>> Thank you for your question. Let me precise. >>> >>> >>>> >>> >>>> Jeff proposes that clients specify the priority mechanism is an=20 >>>> attribute that is stored in the NACM list on the agent (see Section = >>>> 5.2 as described >>>> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below). = The >>>> client-Agent identities are load in a mechanism which is=20 >>>> out-of-band from the I2RS protocol these values. Into the Client,=20 >>>> the Agent's ID is loaded. >>>> Into the Agent, the valid client's identity is loaded along with=20 >>>> the client's priority. AAA (Radius/Diameter) is an example of an=20 >>>> out-of-band mechanism to pass the information with. IMU (in my=20 >>>> understanding), the NACM on the agent is created based on this AAA=20 >>>> loading. The i2rs secondary identity is loaded via an edit-config=20 >>>> mechanism in a config operation (see section 5.1 of Jeff's=20 >>>> document.). Please let me know if my understanding of NACM=20 >>>> creation based on AAA input is correct. >>> >>> >>>> >>> >>> >>> >>> That is an optional mode. >>> >>> There is also a local users table that can be used. >>> >>> >>> >>> >>> >>>> I2RS Module Nodes (E.g. I2RS RIB routes) are written within an=20 >>>> Agent will be annotated with meta-data with the client-id,=20 >>>> priority, and secondary ID. >>> >>> >>>> >>> >>>> The only proposed change to section 5.2 requirements is to the >>> >>> >>>> sentence "Additionally, during commit processing, if >>> >>> >>>> nodes are found where i2rs-priority is already present, and the >>> >>> >>>> priority is better than the transaction's user's priority for=20 >>>> that >>> >>> >>>> node, the commit SHALL fail. >>> >>> >>>> >>> >>>> " Additionally, during commit processing" is incorrect because = there is >>>> not commit processing. Jeff stated we are still working with both >>>> NETCONF >>>> and RESTCONF - so we must allow for a commit process. In the=20 >>>> meeting I noted that the architecture indicates a change is=20 >>>> possible only if the priority is greater than (>) existing=20 >>>> priority. (First rather than last). >>>> Therefore this text should read: "Additionally, during the=20 >>>> operation (RESTCONF)/Commit (NETCONF) processing, if the nodes are=20 >>>> found where i2rs-priority is already present, and the priority is=20 >>>> equal to or better than the transaction's user's priority for the=20 >>>> node, the operation/commit SHALL fail." >>> >>> >>>> >>> >>>> Do you have any suggestions for modifications to section 5 of=20 >>>> Jeff's document? >>> >>> >>>> >>> >>>> Sue >>> >>> >>>> >>> >>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >>> >>> >>>> Jeff's document 5.2 states: >>> >>> >>>> >>> >>>> To support Multi-Headed Control, I2RS requires that there be a >>> >>> >>>> decidable means of arbitrating the correct state of data when >>> >>> >>>> multiple clients attempt to manipulate the same piece of data. >>>> This >>> >>> >>>> is done via a priority mechanism with the highest priority = winning. >>> >>> >>>> This priority may vary on a per-node or sub-tree basis based=20 >>>> for a >>> >>> >>>> given identity. >>> >>> >>>> >>> >>>> This further implies that priority is an attribute that is=20 >>>> stored in >>> >>> >>>> the NETCONF Access Control Model [RFC6536] as part of a = rule-list. >>> >>> >>>> E.g.: >>> >>> >>>> >>> >>>> Ephemeral configuration state nodes that are created or altered = >>>> by >>> >>> >>>> users that match a rule carrying i2rs-priority will have those=20 >>>> nodes >>> >>> >>>> annotated with metadata. Additionally, during commit=20 >>>> processing, if >>> >>> >>>> nodes are found where i2rs-priority is already present, and the >>> >>> >>>> priority is better than the transaction's user's priority for=20 >>>> that >>> >>> >>>> node, the commit SHALL fail. An appropriate error should be=20 >>>> returned >>> >>> >>>> to the user stating the nodes where the user had insufficient >>> >>> >>>> priority to override the state. >>> >>> >>>> >>> >>> >>> >>> >>> >>> The last paragraph sounds like some nodes will be accepted and=20 >>> others rejected. >>> >>> If any nodes are rejected, the entire edit should be rejected. >>> >>> >>> >>> I don;t think the rule-list should store the client priority. >>> >>> It should be in the 'group' list, or outside NACM completely. >>> >>> >>> >>> >>> >>> Andy >>> >>> >>> >>>> >>> >>>> >>> >>>> -----Original Message----- >>> >>> >>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >>> >>>> Sent: Thursday, May 28, 2015 7:40 PM >>> >>> >>>> To: Susan Hares >>> >>> >>>> Cc: Juergen Schoenwaelder; Joel M. Halpern; Jeffrey Haas; >>> >>> >>>> i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas >>> >>> >>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>>> >>> >>>> On Thu, May 28, 2015 at 4:22 PM, Susan Hares = wrote: >>> >>> >>>>> Andy: >>> >>> >>>>> >>> >>>>> Yes - the client with priority and secondary identity are = inherently >>>>> simple additions. Can you confirm my understanding below based = on >>>>> Jeff's >>>>> document? >>> >>> >>>>> >>> >>>> >>> >>>> Not sure what you mean. >>> >>> >>>> i don't think the client should provide the priority in request=20 >>>> messages. >>> >>> >>>> This is configured on the agent, not requested by the client. >>> >>> >>>> >>> >>>> >>> >>>>> Can you explain your statement "I do not want to change NETCONF=20 >>>>> or RESTCONF to use client priority?" What are you proposing that=20 >>>>> you do not want to add the NACM list the priority? >>> >>> >>>> >>> >>>> I don't want to change NETCONF and RESTCONF so that config=3Dtrue=20 >>>> objects use priority. Only I2RS should use it. >>> >>> >>>> >>> >>>>> >>> >>>>> Sue >>> >>> >>>> >>> >>>> Andy >>> >>> >>>> >>> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> >>>>> >>> >>>>> Example >>> >>> >>>>> ------------------------ >>> >>> >>>>> 1) any multiple TCP sessions from a client application will use a=20 >>>>> different ID if they want a different priority for write of an=20 >>>>> object >>> >>> >>>>> Application 1: TCP session 1 - priority 1,=20 >>>>> secondary-identity "pub-sub monitor" >>> >>> >>>>> Application 1: TCP session 2 - priority 10,=20 >>>>> secondary-identity "tracing monitor" >>> >>> >>>>> Application 1: TCP session 3 - priority 20, opaque=20 >>>>> "Weekly config" >>> >>> >>>>> Application 1: TCP session 4 - priority 55, opaque=20 >>>>> "Emergency config" >>> >>> >>>>> >>> >>>>> Jeff's META-data example: >>> >>> >>>>> >>> >>>>> >> >>> >>>>> i2rs:i2rs-secondary-identity=3D"user1" >>>>> i2rs:i2rs-priority=3D"47"> >>> >>> >>>>> ... >>> >>> >>>>> >>> >>> >>>>> >>> >>>>> For my example TCP session 1 >>> >>> >>>>> >> >>> >>>>> I2rs:i2rs-secondary-identity=3D"pub-sub montior" >>> >>> >>>>> i2rs:i2rs-priority=3D"1"> >>> >>> >>>>> >>> >>>>> Juergen's client example: >>> >>> >>>>> >>> >>>>> list i2rs-client { >>> >>> >>>>> key name; >>> >>> >>>>> leaf name { >>> >>> >>>>> description "The client name"; >>> >>> >>>>> type i2rs:client-name; >>> >>> >>>>> } >>> >>> >>>>> leaf priority { >>> >>> >>>>> description "The priority value assigned to this=20 >>>>> client."; >>> >>> >>>>> type i2rs:client-priority; >>> >>> >>>>> } >>> >>> >>>>> } >>> >>> >>>>> >>> >>>>> +--rw rule-list [name] >>> >>> >>>>> +--rw name string >>> >>> >>>>> +--rw group* union >>> >>> >>>>> +--rw rule [name] >>> >>> >>>>> +--rw name string >>> >>> >>>>> +--rw module-name? union >>> >>> >>>>> +--rw (rule-type)? >>> >>> >>>>> | +--:(protocol-operation) >>> >>> >>>>> | | +--rw rpc-name? union >>> >>> >>>>> | +--:(notification) >>> >>> >>>>> | | +--rw notification-name? union >>> >>> >>>>> | +--:(data-node) >>> >>> >>>>> | +--rw path node-instance-identifier >>> >>> >>>>> +--rw access-operations? union >>> >>> >>>>> +--rw action action-type >>> >>> >>>>> +--rw comment? string >>> >>> >>>>> +--rw i2rs:i2rs-priority i2rs-priority-type >>> >>> >>>>> >>> >>>>> Are you proposing something different than Jeff's proposal? >>> >>> >>>>> >>> >>>>> Sue >>> >>> >>>>> >>> >>>>> -----Original Message----- >>> >>> >>>>> From: Andy Bierman [mailto:andy@yumaworks.com] >>> >>> >>>>> Sent: Thursday, May 28, 2015 11:17 AM >>> >>> >>>>> To: Juergen Schoenwaelder; Andy Bierman; Joel M. Halpern; Jeffrey >>> >>> >>>>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan Hares >>> >>> >>>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >>> >>> >>>>> >>> >>>>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaelder=20 >>>>> wrote: >>> >>> >>>>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bierman wrote: >>> >>> >>>>>>> >>> >>>>>>> Although I should be promoting use of NACM, I am not so sure it >>> >>> >>>>>>> should be mandatory for I2RS or required to configure I2RS=20 >>>>>>> client priority. >>> >>> >>>>>>> >>> >>>>>>> list i2rs-client { >>> >>> >>>>>>> key name; >>> >>> >>>>>>> leaf name { >>> >>> >>>>>>> description "The client name"; >>> >>> >>>>>>> type i2rs:client-name; >>> >>> >>>>>>> } >>> >>> >>>>>>> leaf priority { >>> >>> >>>>>>> description "The priority value assigned to this=20 >>>>>>> client."; >>> >>> >>>>>>> type i2rs:client-priority; >>> >>> >>>>>>> } >>> >>> >>>>>>> } >>> >>> >>>>>> >>> >>>>>> So what is i2rs:client-name - is it any different from a >>> >>> >>>>>> NETCONF/RESTCONF username? >>> >>> >>>>>> >>> >>>>> >>> >>>>> Is is probably not different. >>> >>> >>>>> >>> >>>>> >>> >>>>>> NACM maps user names into groups and NACM allows to have the=20 >>>>>> mapping >>> >>> >>>>>> supplied by an external source (e.g. RADIUS). If this priority >>> >>> >>>>>> mapping is kept separate from NACM, would we need to provision=20 >>>>>> means >>> >>> >>>>>> to get the priority from AAA as well? >>> >>> >>>>>> >>> >>>>> >>> >>>>> My point showing the 2 item list is that the information needed to = >>>>> implement I2RS client priority is rather trivial. >>> >>> >>>>> It can certainly be made really complicated by the IETF, but it is = >>>>> an inherently trivial configuration. >>> >>> >>>>> >>> >>>>>> And the bigger question: Do we create something specific for I2RS = >>>>>> or >>> >>> >>>>>> are we going to extend the generic YANG/NC/RC framework to=20 >>>>>> provide >>> >>> >>>>>> the tools I2RS needs? This is probably a question the NETCONF WG=20 >>>>>> has >>> >>> >>>>>> to answer. >>> >>> >>>>> >>> >>>>> It is good to make reusable features. >>> >>> >>>>> I don't want to change NETCONF or RESTCONF to use client priority. >>> >>> >>>>> Let I2RS prove it is useful first. I am not convinced it will=20 >>>>> really help. >>> >>> >>>>> It seems like an implementation detail that is being turned into=20 >>>>> ad administrative task. If multiple clients from multiple vendors = >>>>> are stepping on each other, then the likely outcome of a priority=20 >>>>> change by the administrator will be to select which clients should = >>>>> continue working and which should be broken. >>> >>> >>>>> >>> >>>>> >>> >>>>>> >>> >>>>>> /js >>> >>> >>>>>> >>> >>>>> >>> >>>>> Andy >>> >>> >>>>> >>> >>>>>> -- >>> >>> >>>>>> 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 >>> >>> >>>> >> >> _______________________________________________ >> 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