From nobody Wed Jun 3 10:03:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B3A1ACC87 for ; Wed, 3 Jun 2015 10:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.199 X-Spam-Level: X-Spam-Status: No, score=-100.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-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 2713yJdSjoiX for ; Wed, 3 Jun 2015 10:02:55 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55051AC419 for ; Wed, 3 Jun 2015 10:02:54 -0700 (PDT) Received: by oifu123 with SMTP id u123so12202636oif.1 for ; Wed, 03 Jun 2015 10:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JIRYyh+NE+Mky44MzWPNZWSjb0P8FJzwxIp/d2YcPLE=; b=TtZi3x9LlFZcx2bb3SMMTbF3eW8/SN3Fa9+2rB0fcnu1R/0FIr+zOKlR2yU33Os5GA LQBrs1QaapUCNJMkv3M/r9su/fXnX3ZWylzYJtPM03GSSYf6B0EOa8urdFRJ8jKqmF0o v3fYH3dM5FhpQ8SUuwIomkmhIgYhNeZiegvh1eSPJbbGS5AUGEwGN8exS2C9eKlnubO3 9SsQomALjFGO2bFXi0n/cyllZWb0UZw5XuqAYWiM1MxPKO6EisyccqyHloUVu7UO9Rlw qTa7f5dn3+WfyNMD472ZdwysZeFYcI0mlN/5aptvNelpo37qOVyxO5D3DIVdC1MHxZ0t zj8Q== MIME-Version: 1.0 X-Received: by 10.60.123.83 with SMTP id ly19mr28056031oeb.13.1433350974382; Wed, 03 Jun 2015 10:02:54 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Wed, 3 Jun 2015 10:02:54 -0700 (PDT) In-Reply-To: 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: Wed, 3 Jun 2015 13:02:54 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b5d5498aaa89e0517a0073a Archived-At: Cc: "i2rs@ietf.org" , Jeff Haas , chen.ran@zte.com.cn, Juergen Schoenwaelder , 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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 17:03:01 -0000 --047d7b5d5498aaa89e0517a0073a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Andy, On Fri, May 29, 2015 at 8:41 PM, Andy Bierman wrote: > 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 addi= tion 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. I agree. For the stop-on-error, when one operation in the message causes an error, that operation is not done (can't b/c of error) AND no operations after that in the message are done. For recording errors, all operations in the message are attempted in order and any errors are recorded to send back to the client. If an operation caused an error, then the operation isn't completed. Does that make sense? Regards, Alia > > 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 an= d > > 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 othe= rs > >> 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. So= me > > routes may be accepted, and some routes rejected for installation to th= e > > 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 discusse= s > 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 mod= el > > which is operational (read-only) that contains data from: a) only read > from > > operational units, b) a configured topology, and c) combination topolog= y > > (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 vers= us > > operational data. The inclusion in =E2=80=9Cc=E2=80=9D may also be val= idated (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, plea= se > > 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 ev= en > 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 annotate= d > > with metadata. Additionally, during commit processing, if nodes are > found > > where i2rs-priority is already present, and the priority is better tha= n > 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), th= e > 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 secondar= y > 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 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 bett= er > >> 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. Thi= s > > > >> 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 i= n > > > >> 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 node= s > > > >> annotated with metadata. Additionally, during commit processing, i= f > > > >> 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 return= ed > > > >> 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 obje= cts > >> 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 "Emergen= cy > >>> 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 > --047d7b5d5498aaa89e0517a0073a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andy,

On Fri, May 29, 2015 at 8:41 PM, Andy Bierman &l= t;andy@yumaworks.co= m> wrote:
= On Fri, May 29, 2015 at 2:55 PM, Susan Hares <shares@ndzh.com> wrote:
> Andy:
>
>
>
> On all actions working or not =E2=80=93 you sh= ould 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 I will prop= ose 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.=C2=A0 Most YANG validation errors can be pruned from the datastore.<= br> 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.
=

I agree.=C2=A0 For the stop-on-error, when one operatio= n in the message causes an error,
that operation is not done (can= 't b/c of error) AND no operations after that =C2=A0in the
me= ssage are done.=C2=A0 For recording errors, all operations in the message a= re
attempted in order and any errors are recorded to send back to= the client.
If an operation caused an error, then the operation = isn't completed.

Does that make sense?

Regards,
Alia

=C2=A0

Andy

>
> 2.4 ) Transaction to ephemeral state:
>
>
>
> The ephemeral state should support a multiple parts of a operation occ= urring
> in a single message, but it does not require multi-message atomicity a= nd
> rollback. Three types of error handling should be supported:
>
>
>
>=C2=A0 =C2=A0 Perform all or none:=C2=A0 =C2=A0This traditional SNMP se= mantic indicates that
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0other I2RS agent will keep enough state when= handling a single
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0message to roll back the operations within t= hat message.=C2=A0 Either
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0all the operations will succeed, or none of = them will be applied
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and an error message will report the single = failure which caused
>
>=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=A0example, mutual dependencies across operatio= ns in the message.
>
>
>
>=C2=A0 =C2=A0 Perform until error:=C2=A0 =C2=A0In this case, the operat= ions in the message
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0are applied in the specified order.=C2=A0 Wh= en an error occurs, no
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0further operations are applied, and an error= is returned
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0indicating the failure.=C2=A0 This is useful= if there are dependencies
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0among the operations and they can be topolog= ically sorted.
>
>
>
>=C2=A0 =C2=A0 Perform all storing errors:=C2=A0 =C2=A0In this case, the= I2RS Agent will
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0attempt to perform all the operations in the= message, and will
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return error indications for each one that f= ails.=C2=A0 This is useful
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0when there is no dependency across the opera= tion, or where the
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0client would prefer to sort out the effect o= f errors on its own.
>
>
>
>=C2=A0 =C2=A0 In the interest of robustness and clarity of protocol sta= te, the
>
>=C2=A0 =C2=A0 protocol will include an explicit reply to modification o= r 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@nd= zh.com]
> Sent: Friday, May 29, 2015 1:44 PM
> To: 'Andy Bierman'
> Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'J= effrey 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.=C2=A0 =C2=A0NETC= ONF 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<= br> > 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 majo= r I2RS
> protocol independent models:
>
>
>
> The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00)=C2=A0 prop= oses that
> each route will be associated with the following: route preference, ac= tive,
> 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. S= ome
> routes may be accepted, and some routes rejected for installation to t= he
> RIB.=C2=A0 =C2=A0The 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 discuss= es 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 mo= del
> which is operational (read-only) that contains data from: a) only read= from
> operational units, b) a configured topology, and c) combination topolo= gy
> (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 ver= sus
> 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)).<= br> >
>
>
> 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 priori= ty.
>
>> It should be in the 'group' list, or outside NACM complete= ly."
>
>
>
> Your alternate proposal are:
>
>
>
> 1)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Moving i2rs-priority to gr= oup list
>
> 2)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adding a i2rs-client [unsp= ecified location]
>
>
>
> This mail deals with #1.=C2=A0 If you have more details on proposal #2= , please
> suggest them on the list.
>
>
>
> list i2rs-client {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "The client name&qu= ot;;
>
>=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=A0leaf priority {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The priority value = assigned to this client.";
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type 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 container groups {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>
>=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 list group {
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>
>=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 "One NACM Group E= ntry.=C2=A0 This list will only contain
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configured entri= es, not any entries learned from
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any transport pr= otocols.";
>
>
>
>=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 type group-name-type;<= br> >
>=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 "Group nam= e 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 leaf-list user-name {
>
>=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 description
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "Each entr= y identifies the username of
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a member = of the group associated with
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this entr= y.";
>
>=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 he= re
>
>=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/m= sg02523.html
>
> States:=C2=A0 "I think I2RS interaction with NACM needs to be cle= arly defined.
> NACM implementations do not currently check write requests
>
> on config=3Dfalse data. It is possible some edits to NACM are needed e= ven 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:=C2=A0 =C2=A0=E2=80=9CNACM implementations f= or 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 alter= ed by users
> that match a rule carrying i2rs-priority will have those nodes annotat= ed
> with metadata.=C2=A0 Additionally, during commit processing, if nodes = are found
> where i2rs-priority is already present, and the=C2=A0 priority is bett= er 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 insuffic= ient
>
>=C2=A0 =C2=A0 priority to override the state.
>
>
>
> I=E2=80=99m unclear what this means: =E2=80=9CIt is possible some edit= s 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 A= tlas
> 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 at= tribute
>> that is stored in the NACM list on the agent (see Section 5.2 as d= escribed
>> in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).=C2= =A0 =C2=A0The
>> client-Agent identities are load in a mechanism which is out-of-ba= nd from
>> the I2RS protocol these values.=C2=A0 Into the Client, the Agent&#= 39;s ID is loaded.
>> Into the Agent, the valid client's identity is loaded along wi= th the
>> client's priority.=C2=A0 AAA (Radius/Diameter) is an example o= f an out-of-band
>> mechanism to pass the information with.=C2=A0 IMU (in my understan= ding), 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 operat= ion (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 Age= nt will
>> be annotated with meta-data with the client-id, priority, and seco= ndary ID.
>
>>
>
>> The only proposed change to section 5.2 requirements is to the
>
>> sentence "Additionally, during commit processing, if
>
>>=C2=A0 =C2=A0 nodes are found where i2rs-priority is already presen= t, and the
>
>>=C2=A0 =C2=A0 priority is better than the transaction's user= 9;s priority for that
>
>>=C2=A0 =C2=A0 node, the commit SHALL fail.
>
>>
>
>> " Additionally, during commit processing" is incorrect b= ecause there is
>> not commit processing.=C2=A0 =C2=A0Jeff stated we are still workin= g 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 ra= ther than last).
>> Therefore this text should read:=C2=A0 "Additionally, during = the operation
>> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found whe= re
>> i2rs-priority is already present, and the priority is equal to or = better
>> than the transaction's user's priority for the node, the o= peration/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=A0To support Multi-Headed Control, I2RS requires that th= ere be a
>
>>=C2=A0 =C2=A0 decidable means of arbitrating the correct state of d= ata when
>
>>=C2=A0 =C2=A0 multiple clients attempt to manipulate the same piece= of data.=C2=A0 This
>
>>=C2=A0 =C2=A0 is done via a priority mechanism with the highest pri= ority winning.
>
>>=C2=A0 =C2=A0 This priority may vary on a per-node or sub-tree basi= s based for a
>
>>=C2=A0 =C2=A0 given identity.
>
>>
>
>>=C2=A0 =C2=A0 This further implies that priority is an attribute th= at is stored in
>
>>=C2=A0 =C2=A0 the NETCONF Access Control Model [RFC6536] as part of= a rule-list.
>
>>=C2=A0 =C2=A0 E.g.:
>
>>
>
>>=C2=A0 =C2=A0 Ephemeral configuration state nodes that are created = or altered by
>
>>=C2=A0 =C2=A0 users that match a rule carrying i2rs-priority will h= ave those nodes
>
>>=C2=A0 =C2=A0 annotated with metadata.=C2=A0 Additionally, during c= ommit processing, if
>
>>=C2=A0 =C2=A0 nodes are found where i2rs-priority is already presen= t, and the
>
>>=C2=A0 =C2=A0 priority is better than the transaction's user= 9;s priority for that
>
>>=C2=A0 =C2=A0 node, the commit SHALL fail.=C2=A0 An appropriate err= or should be returned
>
>>=C2=A0 =C2=A0 to the user stating the nodes where the user had insu= fficient
>
>>=C2=A0 =C2=A0 priority to override the state.
>
>>
>
>
>
>
>
> The last paragraph sounds like some nodes will be accepted and others<= br> > 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.<= br> >
>
>
>
>
> Andy
>
>
>
>>
>
>>
>
>> -----Original Message-----
>
>> From: Andy Bierman [mailto:a= ndy@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 inhe= rently
>>> simple additions.=C2=A0 =C2=A0Can 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 reques= t messages.
>
>> This is configured on the agent, not requested by the client.
>
>>
>
>>
>
>>> Can you explain=C2=A0 your statement "I do not want to ch= ange NETCONF or
>>> RESTCONF to use client priority?"=C2=A0 What are you prop= osing that you do not
>>> want to add the NACM list the priority?
>
>>
>
>> I don't want to change NETCONF and RESTCONF so that config=3Dt= rue 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 us= e 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 Application 1:= =C2=A0 TCP session 1 -=C2=A0 priority 1,
>>> secondary-identity=C2=A0 "pub-sub monitor"
>
>>>=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=A0Application 1:=C2=A0 TCP sess= ion 3 -=C2=A0 priority 20, opaque "Weekly
>>> config"
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Application 1:=C2=A0 TCP sess= ion 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=A0i2rs:i2rs-secondary-identity= =3D"user1" i2rs:i2rs-priority=3D"47">
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>
>>>=C2=A0 =C2=A0 </foo>
>
>>>
>
>>> For my example TCP session 1
>
>>>=C2=A0 =C2=A0 <foo xmlns:i2rs=3D"http:s//ietf.example.com/i2rs"= ;
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I2rs:i2rs-secondary-identity= =3D"pub-sub montior"
>
>>> i2rs:i2rs-priority=3D"1">
>
>>>
>
>>> Juergen's client example:
>
>>>
>
>>>=C2=A0 =C2=A0 =C2=A0list i2rs-client {
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "The client= name";
>
>>>=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 leaf priority {
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The = priority value assigned to this client.";
>
>>>=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 +--rw rule-list [name]
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2=A0string=
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw group*=C2=A0 =C2=A0union
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rule [name]
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name string
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw module-name?=C2=A0 uni= on
>
>>>=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 +--:(protocol-operat= ion)
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 |=C2=A0 +--rw rpc-na= me?=C2=A0 union
>
>>>=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 +--rw notifi= cation-name?=C2=A0 union
>
>>>=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+--rw p= ath node-instance-identifier
>
>>>=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 +--rw action action-type
>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw comment?=C2=A0 string<= br> >
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw i2rs:i2rs-priority i2r= s-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; Jeff= rey
>
>>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Sus= an Hares
>
>>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 >
>>>
>
>>> 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 wro= te:
>
>>>>>
>
>>>>> Although I should be promoting use of NACM, I am not s= o sure it
>
>>>>> should be mandatory for I2RS or required to configure = I2RS client
>>>>> priority.
>
>>>>>
>
>>>>>=C2=A0 =C2=A0 list i2rs-client {
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "Th= e client name";
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type i2rs:client-nam= e;
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf priority {
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The= priority value assigned to this client.";
>
>>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type i2rs:client-prio= rity;
>
>>>>>=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 t= he mapping
>
>>>> supplied by an external source (e.g. RADIUS). If this prio= rity
>
>>>> mapping is kept separate from NACM, would we need to provi= sion means
>
>>>> to get the priority from AAA as well?
>
>>>>
>
>>>
>
>>> My point showing the 2 item list is that the information neede= d to
>>> implement I2RS client priority is rather trivial.
>
>>> It can certainly be made really complicated by the IETF, but i= t is an
>>> inherently trivial configuration.
>
>>>
>
>>>> And the bigger question: Do we create something specific f= or 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 NETC= ONF WG has
>
>>>> to answer.
>
>>>
>
>>> It is good to make reusable features.
>
>>> I don't want to change NETCONF or RESTCONF to use client p= riority.
>
>>> 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 in= to ad
>>> administrative task.=C2=A0 If multiple clients from multiple v= endors 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=A0Jacobs University Bremen gGmbH
>
>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= ampus Ring 1 | 28759 Bremen | Germany
>
>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
>
>>>
>
>>> _______________________________________________
>
>>> i2rs mailing list
>
>>> i2rs@ietf.org
>
>>> https://www.ietf.org/mailman/listinfo/i2rs
>
>>

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--047d7b5d5498aaa89e0517a0073a-- From nobody Wed Jun 3 10:15: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 5D8751ACD2F for ; Wed, 3 Jun 2015 10:15:49 -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 TsMNCqoOMxSF for ; Wed, 3 Jun 2015 10:15:45 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 C023D1ACD05 for ; Wed, 3 Jun 2015 10:15:44 -0700 (PDT) Received: by lbcmx3 with SMTP id mx3so11574582lbc.1 for ; Wed, 03 Jun 2015 10:15:43 -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=ym5P7Re1qWa3bMYtqS8Wr6XSGVwVBR4U3RNDC3by+K8=; b=LkvKNaSU7w/pVJVUE+TynP+C1kLvzBBNphw5sP28WOaq9d26QVt07lTLJql33wdVow dTWt3itQ6AbNUCb5zvPG1WtXSm5j56mRCIqnX8zf21R8eNm3OKmB6sp4pr7xBGHytKxl eQcMBo947fTIoueafGDweANQ08xM9ZAlZXNUChy/kLU61ZQdZLabcOZVntl8vNEs7GyX hM0oklN63Gf2zMUHNSMwj3vVCe9PJ+ocO+SLH0HqK57dRy9/BPleLitvRTBAvQoGngTp VxFIGWEOMiBlcVvAcdLcC99VxGjkXcLzdk2ILg38wKehBlOhANupcN+I1W1G1S/Uv9e1 mKKw== X-Gm-Message-State: ALoCoQlzw71vWXs+ULgWemNisDq60PXgOgM8bOM8A2A/OlRm0WwLcX7hGDaigO+YrbVhX6GhCtuj MIME-Version: 1.0 X-Received: by 10.112.56.42 with SMTP id x10mr33275583lbp.123.1433351743287; Wed, 03 Jun 2015 10:15:43 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 3 Jun 2015 10:15:43 -0700 (PDT) In-Reply-To: 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: Wed, 3 Jun 2015 10:15:43 -0700 Message-ID: From: Andy Bierman To: Alia Atlas 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" , 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: Wed, 03 Jun 2015 17:15:49 -0000 On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas wrote: > Andy, > > On Fri, May 29, 2015 at 8:41 PM, Andy Bierman wrote: >> >> 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 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. > > > I agree. For the stop-on-error, when one operation in the message causes= an > error, > that operation is not done (can't b/c of error) AND no operations after t= hat > in the > message are done. For recording errors, all operations in the message ar= e > attempted in order and any errors are recorded to send back to the client= . > If an operation caused an error, then the operation isn't completed. > > Does that make sense? > I think so. This is a sharp knife. Developers using anything except 'all-or-none' will need to be very knowledgeable about the data models in use in order for partial edits to be practical. But I think the draft makes this clear. > Regards, > Alia > > Andy >> >> >> 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 a= nd >> > 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 dependencie= s >> > >> > 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 usefu= l >> > >> > 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 m= y >> > 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 I2R= S >> > 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 t= he >> > RIB. The concept is the client will be able to detect when a route i= s >> > rejected. >> > >> > >> > >> > The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discuss= es >> > 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 topolo= gy >> > (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 va= lidated (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 e= ven >> > 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 wi= ll 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 alter= ed by >> > users >> > that match a rule carrying i2rs-priority will have those nodes annotat= ed >> > with metadata. Additionally, during commit processing, if nodes are >> > found >> > where i2rs-priority is already present, and the priority is better th= an >> > 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 edit= s 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.or= g; >> > 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), t= he >> >> NACM >> >> on the agent is created based on this AAA loading. The i2rs secondar= y >> >> 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 seconda= ry >> >> 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 th= e >> >> 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. Th= is >> > >> >> 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 nod= es >> > >> >> 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 d= o >> >>> not >> >>> want to add the NACM list the priority? >> > >> >> >> > >> >> I don't want to change NETCONF and RESTCONF so that config=3Dtrue obj= ects >> >> 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 objec= t >> > >> >>> 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 mappin= g >> > >> >>>> supplied by an external source (e.g. RADIUS). If this priority >> > >> >>>> mapping is kept separate from NACM, would we need to provision mean= s >> > >> >>>> 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 a= n >> >>> inherently trivial configuration. >> > >> >>> >> > >> >>>> And the bigger question: Do we create something specific for I2RS o= r >> > >> >>>> 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 ha= s >> > >> >>>> 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 reall= y >> >>> 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 workin= g >> >>> 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 Wed Jun 3 10:19:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614DA1A9308 for ; Wed, 3 Jun 2015 10:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.199 X-Spam-Level: X-Spam-Status: No, score=-100.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-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 hGv14P4paiHs for ; Wed, 3 Jun 2015 10:18:56 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4694C1ACD15 for ; Wed, 3 Jun 2015 10:18:56 -0700 (PDT) Received: by oihd6 with SMTP id d6so12538304oih.2 for ; Wed, 03 Jun 2015 10:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=myVybJv2QiCkOVZKGT9vsOZwYbOgp+1f1aiixuyZo8w=; b=DOzL6EAsvEAl/vdoGVf39HaK5hxlZSDqW7R5JUYQsPY6WN0YnYl0w0sodZIW3qeQHR VYX7MD6sK+JS8R60pOppm2IvYhLubAdJCfhsAB80EXdtNBC5SydhqdU4r+4woCJB9SEj j3XiwHBR3Tk/lW7dseHXj3CBziqfa9PwaLh/MGwcndwpRkWeHMRSsmwRAcTeHMXF86Mg HR7ZilVCJPwaT45izx7d3xj01flsf0ieUulAtt5Eo6HJFkIQmf/2+qnMoI/o2AYyWHFd fhnpa1h/qK5Gj+JHLqrDqRMmvg3aBcqvYK83kOr46KBvXcC8QaCIzvp0gLNaDcHDrZig It5A== MIME-Version: 1.0 X-Received: by 10.182.68.13 with SMTP id r13mr28603456obt.20.1433351935722; Wed, 03 Jun 2015 10:18:55 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Wed, 3 Jun 2015 10:18:55 -0700 (PDT) In-Reply-To: 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: Wed, 3 Jun 2015 13:18:55 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=e89a8fb1f60ef78aeb0517a040e5 Archived-At: Cc: "i2rs@ietf.org" , Jeff Haas , chen.ran@zte.com.cn, Juergen Schoenwaelder , 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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 17:19:03 -0000 --e89a8fb1f60ef78aeb0517a040e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 3, 2015 at 1:15 PM, Andy Bierman wrote: > On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas wrote: > > Andy, > > > > On Fri, May 29, 2015 at 8:41 PM, Andy Bierman > wrote: > >> > >> 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 a= ddition 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. > > > > > > I agree. For the stop-on-error, when one operation in the message > causes an > > error, > > that operation is not done (can't b/c of error) AND no operations after > that > > in the > > message are done. For recording errors, all operations in the message > are > > attempted in order and any errors are recorded to send back to the > client. > > If an operation caused an error, then the operation isn't completed. > > > > Does that make sense? > > > > > I think so. This is a sharp knife. Developers using anything > except 'all-or-none' will need to be very knowledgeable about the > data models in use in order for partial edits to be practical. > But I think the draft makes this clear. > I should have read further in the thread before responding. I saw that you gave exactly this with good clear examples. Alia > > > Regards, > > Alia > > > > > > Andy > > >> > >> > >> 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. Eith= er > >> > > >> > all the operations will succeed, or none of them will be appli= ed > >> > > >> > and an error message will report the single failure which caus= ed > >> > > >> > 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 messag= e > >> > > >> > 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 ow= n. > >> > > >> > > >> > > >> > 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 sta= te > >> > storage for I2RS, and it does not have the atomic requirement for th= e > >> > protocol. Instead section 3.3 of the I2RS architecture document cal= ls > >> > 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) propose= s > >> > 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 ephemer= al state. > >> > Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral topology > >> > model > >> > which is operational (read-only) that contains data from: a) only re= ad > >> > from > >> > operational units, b) a configured topology, and c) combination > topology > >> > (operational state and configured). (A second alternative is to jus= t > >> > 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 sma= ll > >> > section of the whole change. > >> > > >> > > >> > > >> >> I don=E2=80=99t think the rule-list should store the client priorit= y. > >> > > >> >> 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 NAC= M > >> > (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 alt= ered 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 ed= its 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). Th= e > >> >> client-Agent identities are load in a mechanism which is out-of-ban= d > >> >> 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 th= e > >> >> 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 operati= on > >> >> (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 Agen= t > >> >> 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 th= at > >> > > >> >> node, the commit SHALL fail. > >> > > >> >> > >> > > >> >> " Additionally, during commit processing" is incorrect because ther= e > 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 operati= on > >> >> (RESTCONF)/Commit (NETCONF) processing, if the nodes are found wher= e > >> >> 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 store= d > in > >> > > >> >> the NETCONF Access Control Model [RFC6536] as part of a rule-lis= t. > >> > > >> >> 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 th= at > >> > > >> >> 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 other= s > >> > 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 inherent= ly > >> >>> simple additions. Can you confirm my understanding below based o= n > >> >>> 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 o= r > >> >>> 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 "Week= ly > >> >>> 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 clien= t > >> >>>>> 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 provid= e > >> > > >> >>>> 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 a= d > >> >>> administrative task. If multiple clients from multiple vendors ar= e > >> >>> 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 > > > > > --e89a8fb1f60ef78aeb0517a040e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 3, 2015 at 1:15 PM, Andy Bierman <andy@yumaworks.com&= gt; wrote:
<= div class=3D"h5">On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas <akatlas@gmail.com> wrote:
> Andy,
>
> On Fri, May 29, 2015 at 8:41 PM, Andy Bierman <andy@yumaworks.com> wrote:
>>
>> On Fri, May 29, 2015 at 2:55 PM, Susan Hares <shares@ndzh.com> wrote:
>> > Andy:
>> >
>> >
>> >
>> > On all actions working or not =E2=80=93 you should look at se= ction 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 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 recor= ding
>> errors does not mean the agent will leave the datastore in an inva= lid
>> state.=C2=A0 Most YANG validation errors can be pruned from the da= tastore.
>> This may or may not leave the datastore in an operationally useful= state.
>> The must/min-elements/unique statements can cause validation error= s
>> 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.
>
>
> I agree.=C2=A0 For the stop-on-error, when one operation in the messag= e causes an
> error,
> that operation is not done (can't b/c of error) AND no operations = after that
> in the
> message are done.=C2=A0 For recording errors, all operations in the me= ssage are
> attempted in order and any errors are recorded to send back to the cli= ent.
> If an operation caused an error, then the operation isn't complete= d.
>
> Does that make sense?
>


I think so. This is a sharp knife. Developers using anything except 'all-or-none' will need to be very knowledgeable about the data models in use in order for partial edits to be practical.
But I think the draft makes this clear.

I should have read further in the thread before responding. I saw that you=
gave exactly this with good clear examples.

=
Alia=C2=A0

=C2=A0

> Regards,
> Alia
>
>

Andy

>>
>>
>> Andy
>>
>> >
>> > 2.4 ) Transaction to ephemeral state:
>> >
>> >
>> >
>> > The ephemeral state should support a multiple parts of a oper= ation
>> > occurring
>> > in a single message, but it does not require multi-message at= omicity and
>> > rollback. Three types of error handling should be supported:<= br> >> >
>> >
>> >
>> >=C2=A0 =C2=A0 Perform all or none:=C2=A0 =C2=A0This traditiona= l SNMP semantic indicates that
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0other I2RS agent will keep enough s= tate when handling a single
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0message to roll back the operations= within that message.=C2=A0 Either
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0all the operations will succeed, or= none of them will be applied
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0and an error message will report th= e single failure which caused
>> >
>> >=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=A0example, mutual dependencies across= operations in the message.
>> >
>> >
>> >
>> >=C2=A0 =C2=A0 Perform until error:=C2=A0 =C2=A0In this case, t= he operations in the message
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0are applied in the specified order.= =C2=A0 When an error occurs, no
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0further operations are applied, and= an error is returned
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0indicating the failure.=C2=A0 This = is useful if there are dependencies
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0among the operations and they can b= e topologically sorted.
>> >
>> >
>> >
>> >=C2=A0 =C2=A0 Perform all storing errors:=C2=A0 =C2=A0In this = case, the I2RS Agent will
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0attempt to perform all the operatio= ns in the message, and will
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0return error indications for each o= ne that fails.=C2=A0 This is useful
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0when there is no dependency across = the operation, or where the
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0client would prefer to sort out the= effect of errors on its own.
>> >
>> >
>> >
>> >=C2=A0 =C2=A0 In the interest of robustness and clarity of pro= tocol state, the
>> >
>> >=C2=A0 =C2=A0 protocol will include an explicit reply to modif= ication or write
>> >
>> >=C2=A0 =C2=A0 operations even when they fully succeed.
>> >
>> >
>> >
>> >
>> >
>> > Will this cover the architecture document 7.9 transactions im= pact 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<= br> >> >
>> >
>> >
>> > 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 rejec= ted.
>> >
>> >
>> >
>> > RESTCONF does an atomic action within a http session.=C2=A0 = =C2=A0NETCONF within a
>> > commit.=C2=A0 Section 6.2 of the I2RS architecture document d= escribes 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 t= he 2 major I2RS
>> > protocol independent models:
>> >
>> >
>> >
>> > The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00)= =C2=A0 proposes
>> > that
>> > each route will be associated with the following: route prefe= rence,
>> > 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 installa= tion to the
>> > RIB.=C2=A0 =C2=A0The concept is the client will be able to de= tect 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 on= ly 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 to= pology
>> > model
>> > which is operational (read-only) that contains data from: a) = only read
>> > from
>> > operational units, b) a configured topology, and c) combinati= on topology
>> > (operational state and configured).=C2=A0 (A second alternati= ve 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 top= ology
>> > 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)).
>> >
>> >
>> >
>> > These two model documents show why atomic state may be on a v= ery small
>> > section of the whole change.
>> >
>> >
>> >
>> >> I don=E2=80=99t think the rule-list should store the clie= nt 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 Moving i2rs-prior= ity to group list
>> >
>> > 2)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Adding a i2rs-cli= ent [unspecified location]
>> >
>> >
>> >
>> > This mail deals with #1.=C2=A0 If you have more details on pr= oposal #2,
>> > please
>> > suggest them on the list.
>> >
>> >
>> >
>> > list i2rs-client {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "The clien= t name";
>> >
>> >=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=A0leaf priority {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "The priori= ty value assigned to this client.";
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type 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 container groups {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>> >
>> >=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 list group {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>> >
>> >=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 "One NAC= M Group Entry.=C2=A0 This list will only contain
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0configu= red entries, not any entries learned from
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any tra= nsport protocols.";
>> >
>> >
>> >
>> >=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 type group-na= me-type;
>> >
>> >=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 "= 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 leaf-list user-name = {
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type user-nam= e-type;
>> >
>> >=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 "= Each entry identifies the username of
>> >
>> >=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= 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# add leaf-list I2rs-= client here
>> >
>> >=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
>> >
>> > 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 o= f
>> > draft-haas-i2rs-ephemeral-state-reqs-00?
>> >
>> > Is it sufficient to state:=C2=A0 =C2=A0=E2=80=9CNACM implemen= tations 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 node= s annotated
>> > with metadata.=C2=A0 Additionally, during commit processing, = if nodes are
>> > found
>> > where i2rs-priority is already present, and the=C2=A0 priorit= y is better than
>> > the
>> > transaction's user's priority for that node, the comm= it 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<= br> >> >
>> >
>> >
>> > 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 be= low).=C2=A0 =C2=A0The
>> >> client-Agent identities are load in a mechanism which is = out-of-band
>> >> from
>> >> the I2RS protocol these values.=C2=A0 Into the Client, th= e Agent's ID is
>> >> loaded.
>> >> 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 conf= ig 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 with= in 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 t= o the
>> >
>> >> sentence "Additionally, during commit processing, if=
>> >
>> >>=C2=A0 =C2=A0 nodes are found where i2rs-priority is alrea= dy present, and the
>> >
>> >>=C2=A0 =C2=A0 priority is better than the transaction'= s user's priority for that
>> >
>> >>=C2=A0 =C2=A0 node, the commit SHALL fail.
>> >
>> >>
>> >
>> >> " Additionally, during commit processing" is in= correct because there is
>> >> not commit processing.=C2=A0 =C2=A0Jeff stated we are sti= ll 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 possibl= e only if the
>> >> priority is greater than (>) existing priority.=C2=A0 = (First rather than
>> >> last).
>> >> 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 equ= al to or
>> >> better
>> >> than the transaction's user's priority for the no= de, 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=A0To support Multi-Headed Control, I2RS require= s that there be a
>> >
>> >>=C2=A0 =C2=A0 decidable means of arbitrating the correct s= tate of data when
>> >
>> >>=C2=A0 =C2=A0 multiple clients attempt to manipulate the s= ame piece of data.=C2=A0 This
>> >
>> >>=C2=A0 =C2=A0 is done via a priority mechanism with the hi= ghest priority winning.
>> >
>> >>=C2=A0 =C2=A0 This priority may vary on a per-node or sub-= tree basis based for a
>> >
>> >>=C2=A0 =C2=A0 given identity.
>> >
>> >>
>> >
>> >>=C2=A0 =C2=A0 This further implies that priority is an att= ribute that is stored in
>> >
>> >>=C2=A0 =C2=A0 the NETCONF Access Control Model [RFC6536] a= s part of a rule-list.
>> >
>> >>=C2=A0 =C2=A0 E.g.:
>> >
>> >>
>> >
>> >>=C2=A0 =C2=A0 Ephemeral configuration state nodes that are= created or altered by
>> >
>> >>=C2=A0 =C2=A0 users that match a rule carrying i2rs-priori= ty will have those nodes
>> >
>> >>=C2=A0 =C2=A0 annotated with metadata.=C2=A0 Additionally,= during commit processing, if
>> >
>> >>=C2=A0 =C2=A0 nodes are found where i2rs-priority is alrea= dy present, and the
>> >
>> >>=C2=A0 =C2=A0 priority is better than the transaction'= s user's priority for that
>> >
>> >>=C2=A0 =C2=A0 node, the commit SHALL fail.=C2=A0 An approp= riate 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.
>> >
>> >>
>> >
>> >
>> >
>> >
>> >
>> > The last paragraph sounds like some nodes will be accepted an= d 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 com= pletely.
>> >
>> >
>> >
>> >
>> >
>> > 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=A0Can you confirm my unde= rstanding 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 cli= ent.
>> >
>> >>
>> >
>> >>
>> >
>> >>> Can you explain=C2=A0 your statement "I do not w= ant 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 c= onfig=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 applicatio= n will use a
>> >>> different ID if they want a different priority for wr= ite of an object
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Appli= cation 1:=C2=A0 TCP session 1 -=C2=A0 priority 1,
>> >>> secondary-identity=C2=A0 "pub-sub monitor"<= br> >> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Appli= cation 1:=C2=A0 TCP session 2 - priority 10,
>> >>> secondary-identity "tracing monitor"
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Application 1:=C2=A0= TCP session 3 -=C2=A0 priority 20, opaque "Weekly
>> >>> config"
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Application 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=A0i2rs:i2rs-secondary-= identity=3D"user1" i2rs:i2rs-priority=3D"47">
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
>> >
>> >>>=C2=A0 =C2=A0 </foo>
>> >
>> >>>
>> >
>> >>> For my example TCP session 1
>> >
>> >>>=C2=A0 =C2=A0 <foo xmlns:i2rs=3D"http:s//ietf.example.com/i2rs= "
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I2rs:i2rs-secondary-= identity=3D"pub-sub montior"
>> >
>> >>> i2rs:i2rs-priority=3D"1">
>> >
>> >>>
>> >
>> >>> Juergen's client example:
>> >
>> >>>
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0list i2rs-client {
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 key name;
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "T= he client name";
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type i2rs:client-na= me;
>> >
>> >>>=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=A0description &= quot;The priority value assigned to this client.";
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type i2rs:client-pr= iority;
>> >
>> >>>=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+--rw name=C2=A0 =C2=A0 =C2= =A0string
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw group*=C2=A0 =C2=A0un= ion
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw rule [name]
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name string >> >
>> >>>=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 +--rw (rule-type)?<= br> >> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +--:(protoc= ol-operation)
>> >
>> >>>=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 +--:(notifi= cation)
>> >
>> >>>=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 +--:(data-n= ode)
>> >
>> >>>=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 +--rw access-operat= ions?=C2=A0 union
>> >
>> >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw action action= -type
>> >
>> >>>=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 +--rw i2rs:i2rs-pri= ority 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. Halp= ern; Jeffrey
>> >
>> >>> Haas; i2rs@ietf.org<= /a>; chen.ran@zte.com.cn; Alia A= tlas; Susan Hares
>> >
>> >>> Subject: Re: [i2rs] draft-chen-i2rs-identifier-manage= ment-00
>> >
>> >>>
>> >
>> >>> On Wed, May 27, 2015 at 11:05 PM, Juergen Schoenwaeld= er
>> >>> <j.schoenwaelder@jacobs-university.de> wrote:
>> >
>> >>>> On Wed, May 27, 2015 at 06:04:58PM -0700, Andy Bi= erman wrote:
>> >
>> >>>>>
>> >
>> >>>>> Although I should be promoting use of NACM, I= am not so sure it
>> >
>> >>>>> should be mandatory for I2RS or required to c= onfigure I2RS client
>> >>>>> priority.
>> >
>> >>>>>
>> >
>> >>>>>=C2=A0 =C2=A0 list i2rs-client {
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0key name;
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf name {
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description= "The client name";
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type i2rs:c= lient-name;
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf priority {
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description = "The priority value assigned to this client.";
>> >
>> >>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type i2rs:cl= ient-priority;
>> >
>> >>>>>=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 informat= ion needed to
>> >>> implement I2RS client priority is rather trivial.
>> >
>> >>> It can certainly be made really complicated by the IE= TF, but it is an
>> >>> inherently trivial configuration.
>> >
>> >>>
>> >
>> >>>> And the bigger question: Do we create something s= pecific for I2RS or
>> >
>> >>>> are we going to extend the generic YANG/NC/RC fra= mework 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 con= vinced it will really
>> >>> help.
>> >
>> >>> It seems like an implementation detail that is being = turned into ad
>> >>> administrative task.=C2=A0 If multiple clients from m= ultiple 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=A0Jacobs University Bremen gGmbH
>> >
>> >>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Campus Ring 1 | 28759 Bremen |
>> >>>> Germany
>> >
>> >>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>> >
>> >>>
>> >
>> >>> _______________________________________________
>> >
>> >>> 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
>
>

--e89a8fb1f60ef78aeb0517a040e5-- From nobody Wed Jun 3 17:50:05 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42271B30E9; Wed, 3 Jun 2015 17:50:03 -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 SruhHkSSKWGw; Wed, 3 Jun 2015 17:50:01 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id CABC41B30F1; Wed, 3 Jun 2015 17:49:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: Date: Wed, 3 Jun 2015 20:49:41 -0400 Message-ID: <000e01d09e60$57db6730$07923590$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01D09E3E.D0CE5B10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCeXSaGCIO6ib4/SoSSV0U3LuPcfw== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Thu, 04 Jun 2015 00:50:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000F_01D09E3E.D0CE5B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The minutes for the I2RS meeting are at: www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-201 5-i2rs-8 These minute provide a lengthy of issues in the requirements. From these minutes, there are the following 6 conclusions on the protocol requirements that Jeff stated: 1) There will be no consideration of an overlay model unless a fully formed proposal is presented. Jeff and I appreciate Ken Watsen's comments on the list, but we have had lots of suggestions regarding an overlay proposal - but no full proposal. At this time, the WG will only consider full proposals and not suggestions toward a proposal. 2) Jeff's document provides details on ephemeral state requirements that have not changed. These requirements include: a. Highly reliable notifications (but not perfectly reliable notifications) b. High bandwidth, asynchronous interface, with real-time guarantees on getting data, c. Node identification of clients that write by client identity, secondary identity, and priority. Data models will determine what is the "node" unit. For example, the I2RS RIB node unit is the route. d. There is one priority per client. e. Priority is kept in the NACM at the client level [rather than path level (5/27 meeting) or group level (list discussion). 3) Joel suggests that large data write may be best done in netconf with guarantees a. I2RS will be focused on highly asynchronous interfaces with less than full routing tables. b. A client whose large data is interrupted by a notification has a difficult time determine when the notification happened in the stream - so the I2RS client must ask the agent again. c. Logging for traceability is different than event notification. 4) Secondary identity data is meta-data that is stored in the agent. Agent does not do anything with the meta-data. The client has to do one edit per secondary at a time. 5) Secondary identity data is read-only meta-data that is stored in the agent associated with a data model node that is being created or updated (write-access) in the data store. 6) I2RS Client and Agent Identities are mutually authenticated by Authentication server (AAA), The values of identities are originally set by operators. Does anyone have any concerns regarding these requirements? Sue Hares ------=_NextPart_000_000F_01D09E3E.D0CE5B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = minutes for the I2RS meeting are at:

 

www.ietf.org/proceedings/interim/2015/05/27/i= 2rs/minutes/minutes-interim-2015-i2rs-8

 

These minute = provide a lengthy of issues in the requirements.  From these = minutes, there are the following 6 conclusions on the protocol = requirements that Jeff stated:

 

1)      = There will be no consideration of an overlay = model unless a fully formed proposal is presented.

Jeff and I appreciate Ken = Watsen’s comments on the list, but we have had lots of suggestions = regarding

an overlay proposal – but no full = proposal.  At this time, the WG will only consider full proposals = and not

suggestions toward a proposal. =

 

2)      = Jeff’s document provides details on = ephemeral state requirements that have not changed.  These = requirements include:

a.       = Highly reliable notifications (but not perfectly = reliable notifications)

b.      = High bandwidth, asynchronous interface, with = real-time guarantees on getting data,

c.       = Node identification of clients that write by = client identity, secondary identity, and priority.  Data models = will determine what is the “node” unit.  For example, = the I2RS RIB node unit is the route.

d.      = There is one priority per client. =

e.      = Priority is kept in the NACM at the client level = [rather than path level (5/27 meeting) or group level (list discussion). =  

 

3)      = Joel suggests that large data write may be best = done in netconf with guarantees

a.       = I2RS will be focused on highly asynchronous = interfaces with less than full routing tables.

b.      = A client whose large data is interrupted by a = notification has a difficult time determine when the notification = happened in the stream – so the I2RS client must ask the agent = again.

c.       = Logging for traceability is different than event = notification.

 

4)      = Secondary identity data is meta-data that is = stored in the agent.  Agent does not do anything with the = meta-data. The client has to do one edit per secondary at a = time.

 

5)      = Secondary identity data is read-only meta-data = that is stored in the agent associated with a data model node that is = being created or updated (write-access) in the data store.  =

 

 

6)      = I2RS Client and Agent Identities are mutually = authenticated by Authentication server (AAA),

The values of identities are originally set by = operators.   

 

 

D= oes anyone have any concerns regarding these requirements? =

<= o:p> 

S= ue Hares

 

------=_NextPart_000_000F_01D09E3E.D0CE5B10-- From nobody Wed Jun 3 18:10:34 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C871B3117 for ; Wed, 3 Jun 2015 18:10:33 -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 gBwwIGqHfUXs for ; Wed, 3 Jun 2015 18:10:24 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 5CCBF1B2AFE for ; Wed, 3 Jun 2015 18:10:24 -0700 (PDT) Received: by laei3 with SMTP id i3so20797099lae.3 for ; Wed, 03 Jun 2015 18:10:22 -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=zdt3wGkMAIbcYu7OWoNBa6hw+LaePBYW1QyFeW+fIxA=; b=DRf6fCSIC4T9NfgfZqFlCzdLU2uhUkCUmT+YMTkXoZqHU6rUD/5v6fbByWK0YTIxIo vATqqsgDQmz9jtW3DHmQhRlGTiOWMIRZBofHrxDveLDAg34+SXagAjOTgqq75l+UxkCy jMBb9I0LEqMf4M9aZG8PkIJiV5eow8Ovw/AjjWnSoTb1yfi54lkLNKAnzZaRp7PymfU7 QiTJdYWvHCgQ1JiVe88KpiPprGRQ7tjsr9fbgEQUNLrXU08nByBuAs7ji4y4Pa/Q59VT ZMXmhWAPlUyzBAqrTr2VdqWfRjDbywJchLLARvA8SGEG9YcmLF85a/iJTXzAMW+GKKab vJ3A== X-Gm-Message-State: ALoCoQmAdMSTjrZzMDDciogUNUwGxJiSK7LEtt9kbnvlDieJlqtbH+O6NtOiDtiSliXQgP/kXW+M MIME-Version: 1.0 X-Received: by 10.112.97.194 with SMTP id ec2mr18334537lbb.88.1433380222875; Wed, 03 Jun 2015 18:10:22 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 3 Jun 2015 18:10:22 -0700 (PDT) In-Reply-To: <000e01d09e60$57db6730$07923590$@ndzh.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> Date: Wed, 3 Jun 2015 18:10:22 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , i2rs-chairs@ietf.org, Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Thu, 04 Jun 2015 01:10:34 -0000 Hi, Re 2(a) and (b): Are changes to RFC 5277 being proposed to make notifications highly reliable, or is there an assumption that implementations will just provide adequate memory to buffer notifications? Real time guarantees on getting data sounds like RAI work is needed? Are any changes needed to RESTCONF or NETCONF to support this requirement? Or is there just an expectation that implementations will be fast. IMO, the standard should be silent on response times and packets per second issues. Unless a certain speed is required for interoperability, then it seems inappropriate to mention in an RFC. Andy On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-= 2015-i2rs-8 > > > > These minute provide a lengthy of issues in the requirements. From these > minutes, there are the following 6 conclusions on the protocol requiremen= ts > that Jeff stated: > > > > 1) There will be no consideration of an overlay model unless a fully > formed proposal is presented. > > Jeff and I appreciate Ken Watsen=E2=80=99s comments on the list, but we h= ave had > lots of suggestions regarding > > an overlay proposal =E2=80=93 but no full proposal. At this time, the WG= will only > consider full proposals and not > > suggestions toward a proposal. > > > > 2) Jeff=E2=80=99s document provides details on ephemeral state requi= rements > that have not changed. These requirements include: > > a. Highly reliable notifications (but not perfectly reliable > notifications) > > b. High bandwidth, asynchronous interface, with real-time guarantees= on > getting data, > > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is the > =E2=80=9Cnode=E2=80=9D unit. For example, the I2RS RIB node unit is the = route. > > d. There is one priority per client. > > e. Priority is kept in the NACM at the client level [rather than pat= h > level (5/27 meeting) or group level (list discussion). > > > > 3) Joel suggests that large data write may be best done in netconf w= ith > guarantees > > a. I2RS will be focused on highly asynchronous interfaces with less > than full routing tables. > > b. A client whose large data is interrupted by a notification has a > difficult time determine when the notification happened in the stream =E2= =80=93 so > the I2RS client must ask the agent again. > > c. Logging for traceability is different than event notification. > > > > 4) Secondary identity data is meta-data that is stored in the agent. > Agent does not do anything with the meta-data. The client has to do one e= dit > per secondary at a time. > > > > 5) Secondary identity data is read-only meta-data that is stored in = the > agent associated with a data model node that is being created or updated > (write-access) in the data store. > > > > > > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > > > > > > Does anyone have any concerns regarding these requirements? > > > > Sue Hares > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Jun 3 23:24: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 892EF1A6F07; Wed, 3 Jun 2015 23:24:55 -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 4RQ5ZCUE7YDa; Wed, 3 Jun 2015 23:24:53 -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 DCAAF1A6EEC; Wed, 3 Jun 2015 23:24:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3669813DC; Thu, 4 Jun 2015 08:24:51 +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 X_XeykPek44B; Thu, 4 Jun 2015 08:24:20 +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, 4 Jun 2015 08:24:39 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 52D4720038; Thu, 4 Jun 2015 08:24:31 +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 PGbsG9DBbtW4; Thu, 4 Jun 2015 08:24:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DCB82002B; Thu, 4 Jun 2015 08:24:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8D0DA34286A3; Thu, 4 Jun 2015 08:24:26 +0200 (CEST) Date: Thu, 4 Jun 2015 08:24:26 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150604062424.GA40773@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, jhaas@pfrc.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000e01d09e60$57db6730$07923590$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) 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, 04 Jun 2015 06:24:55 -0000 On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-201 > 5-i2rs-8 > > > > These minute provide a lengthy of issues in the requirements. From these > minutes, there are the following 6 conclusions on the protocol requirements > that Jeff stated: > > > > 1) There will be no consideration of an overlay model unless a fully > formed proposal is presented. > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > had lots of suggestions regarding an overlay proposal - but no full > proposal. At this time, the WG will only consider full proposals > and not suggestions toward a proposal. For the record: I am highly concerned about solutions that require (i) separate data models for ephemeral state and (ii) data model specific merge logic. While this may work for I2RS, this approach does not scale or has a very high cost of scaling to other ephemeral state editing needs. > 2) Jeff's document provides details on ephemeral state requirements > that have not changed. These requirements include: > > a. Highly reliable notifications (but not perfectly reliable > notifications) > > b. High bandwidth, asynchronous interface, with real-time guarantees on > getting data, > > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is the > "node" unit. For example, the I2RS RIB node unit is the route. I am concerned about adding protocol mechanisms that are specific to a certain data model. It is unclear what a "node" unit it, terms like 'highly reliable notifications' and 'high bandwidth, asynchronous interface, with real-time guarantees' are somewhat unclear - how do we determine we have met any of these requirements? > d. There is one priority per client. > > e. Priority is kept in the NACM at the client level [rather than path > level (5/27 meeting) or group level (list discussion). Why does this mapping of username to priority have to be maintained in NACM? > 3) Joel suggests that large data write may be best done in netconf with > guarantees > > a. I2RS will be focused on highly asynchronous interfaces with less > than full routing tables. > > b. A client whose large data is interrupted by a notification has a > difficult time determine when the notification happened in the stream - so > the I2RS client must ask the agent again. > > c. Logging for traceability is different than event notification. Except c), I do not understand this. What are these 'guarantees' 3) is about? > 5) Secondary identity data is read-only meta-data that is stored in the > agent associated with a data model node that is being created or updated > (write-access) in the data store. Ehem, what is read-only data that is created or written? Did you want to say that the identity meta-data is immutable once a data node has been created? And if so, has priority the same property: Is priority of a data node is determined at creation time and then immutable? > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > I am not sure how agent identity authentication via AAA works. Can someone point me to the right direction if I assume a secure transport such as SSH or TLS? /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 Jun 4 12:32: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 D8CFF1A8ADB for ; Thu, 4 Jun 2015 12:32:30 -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 heRqxwRzJOqi for ; Thu, 4 Jun 2015 12:32:27 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 604961A8A99 for ; Thu, 4 Jun 2015 12:32:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Andy Bierman'" , "'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> <000901d09a5a$36044cd0$a20ce670$@ndzh.com> In-Reply-To: Date: Thu, 4 Jun 2015 15:32:06 -0400 Message-ID: <01d301d09efd$2a31ddd0$7e959970$@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/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4gH00CZbAa2lsVECRhuE8AEu2l+nnV3IoPA= 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: Thu, 04 Jun 2015 19:32:31 -0000 Andy: Just to check - are these acceptable to add as 2.4 to Jeff's document. = [I added in perform all or none] to Alia's list:=20 For perform all or none, when one operations in the message causes an = error,=20 all previous operations are rolled back to the pre-operation state.=20 For the stop-on-error, when one operation in the message=20 causes an error, that operation is not done (can't b/c of error) AND=20 no operations after that in the message are done. =20 For recording errors, all operations in the message are attempted in = order and any=20 errors are recorded to send back to the client. If an operation caused an error, then the operation isn't completed. Sue=20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Wednesday, June 03, 2015 1:16 PM To: Alia Atlas Cc: Susan Hares; 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 Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas wrote: > Andy, > > On Fri, May 29, 2015 at 8:41 PM, Andy Bierman = wrote: >> >> 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=20 >> 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. > > > I agree. For the stop-on-error, when one operation in the message=20 > causes an error, that operation is not done (can't b/c of error) AND=20 > no operations after that in the message are done. For recording=20 > errors, all operations in the message are attempted in order and any=20 > errors are recorded to send back to the client. > If an operation caused an error, then the operation isn't completed. > > Does that make sense? > I think so. This is a sharp knife. Developers using anything except = 'all-or-none' will need to be very knowledgeable about the data models = in use in order for partial edits to be practical. But I think the draft makes this clear. > Regards, > Alia > > Andy >> >> >> 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=20 >> > 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=20 >> > 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)=20 >> > 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=20 >> > state storage for I2RS, and it does not have the atomic requirement = >> > for the protocol. Instead section 3.3 of the I2RS architecture=20 >> > document calls for this to be model driver. Let me provide=20 >> > 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=20 >> > change will be given if route is installed, active, and a reason=20 >> > 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=20 >> > discusses the challenge that topology models are not: configuration = >> > 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 = >> > 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 = >> > 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 on priority of configured topology=20 >> > versus operational data. The inclusion in =E2=80=9Cc=E2=80=9D may = also be=20 >> > 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=20 >> > 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=20 >> > nodes annotated with metadata. Additionally, during commit=20 >> > processing, if nodes are found where i2rs-priority is already=20 >> > present, and the priority is better than the transaction's user's=20 >> > 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=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=20 >> >> 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, = >> >> 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 = >> >> loading. The i2rs secondary identity is loaded via an edit-config = >> >> 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 = >> >> 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 = >> >>> 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 = >> >>> 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"=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=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=20 >> >>> to implement I2RS client priority is rather trivial. >> > >> >>> It can certainly be made really complicated by the IETF, but it=20 >> >>> is an inherently trivial configuration. >> > >> >>> >> > >> >>>> And the bigger question: Do we create something specific for=20 >> >>>> 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 = >> >>>> 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=20 >> >>> vendors are stepping on each other, then the likely outcome of a=20 >> >>> priority change by the administrator will be to select which=20 >> >>> 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 Thu Jun 4 12:41: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 CBEE11A8911; Thu, 4 Jun 2015 12:41: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 TSvILcpM0ESM; Thu, 4 Jun 2015 12:41: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 57F5E1A873E; Thu, 4 Jun 2015 12:41:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Andy Bierman'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> In-Reply-To: Date: Thu, 4 Jun 2015 15:41:49 -0400 Message-ID: <01f101d09efe$801d25a0$805770e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01F2_01D09EDC.F911A020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQEd4FbCnr5GqOA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Thu, 04 Jun 2015 19:41:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01F2_01D09EDC.F911A020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 2a and 2b: =20 =C2=B7 This is just a highly reliable requirement as we talked = about in the interim. It is not perfect, but highly reliable.=20 =20 =C2=B7 No specific changes are being suggested to RFC 5277, but = setting this requirement will cause the NETCONF group to consider = changes need to be made or can be made. Implementations must be fast = and highly reliable for the normal I2RS data. We expect the NETCONF = group to provide some details on what =E2=80=9Cfast and highly = reliable=E2=80=9D means for their protocols. In the past FORCES = proponents gave those numbers.=20 =20 =C2=B7 Joel mentioned that large RIB pulls were not the normal = I2RS data.=20 =20 I will ask the working group the larger question =E2=80=93 Do we need to = specify =E2=80=9Cfast and highly reliable=E2=80=9D in terms of response = time or packets per second?=20 =20 Sue=20 =20 =20 =20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Wednesday, June 03, 2015 9:10 PM To: Susan Hares Cc: i2rs@ietf.org; Jeffrey Haas; Joel M. Halpern; i2rs-chairs@ietf.org; = Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) =20 Hi, =20 Re 2(a) and (b): =20 Are changes to RFC 5277 being proposed to make notifications highly = reliable, or is there an assumption that implementations will just = provide adequate memory to buffer notifications? =20 Real time guarantees on getting data sounds like RAI work is needed? = Are any changes needed to RESTCONF or NETCONF to support this = requirement? Or is there just an expectation that implementations will = be fast. =20 IMO, the standard should be silent on response times and packets per = second issues. Unless a certain speed is required for interoperability, = then it seems inappropriate to mention in an RFC. =20 =20 Andy =20 =20 On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares < = shares@ndzh.com> wrote: > The minutes for the I2RS meeting are at: >=20 >=20 >=20 > = = www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter > im-2015-i2rs-8 >=20 >=20 >=20 > These minute provide a lengthy of issues in the requirements. From=20 > these minutes, there are the following 6 conclusions on the protocol=20 > requirements that Jeff stated: >=20 >=20 >=20 > 1) There will be no consideration of an overlay model unless a = fully > formed proposal is presented. >=20 > Jeff and I appreciate Ken Watsen=E2=80=99s comments on the list, but = we have=20 > had lots of suggestions regarding >=20 > an overlay proposal =E2=80=93 but no full proposal. At this time, the = WG will=20 > only consider full proposals and not >=20 > suggestions toward a proposal. >=20 >=20 >=20 > 2) Jeff=E2=80=99s document provides details on ephemeral state = requirements > that have not changed. These requirements include: >=20 > a. Highly reliable notifications (but not perfectly reliable > notifications) >=20 > b. High bandwidth, asynchronous interface, with real-time = guarantees on > getting data, >=20 > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is=20 > the =E2=80=9Cnode=E2=80=9D unit. For example, the I2RS RIB node unit = is the route. >=20 > d. There is one priority per client. >=20 > e. Priority is kept in the NACM at the client level [rather than = path > level (5/27 meeting) or group level (list discussion). >=20 >=20 >=20 > 3) Joel suggests that large data write may be best done in = netconf with > guarantees >=20 > a. I2RS will be focused on highly asynchronous interfaces with = less > than full routing tables. >=20 > b. A client whose large data is interrupted by a notification has = a > difficult time determine when the notification happened in the stream=20 > =E2=80=93 so the I2RS client must ask the agent again. >=20 > c. Logging for traceability is different than event = notification. >=20 >=20 >=20 > 4) Secondary identity data is meta-data that is stored in the = agent. > Agent does not do anything with the meta-data. The client has to do=20 > one edit per secondary at a time. >=20 >=20 >=20 > 5) Secondary identity data is read-only meta-data that is stored = in the > agent associated with a data model node that is being created or=20 > updated > (write-access) in the data store. >=20 >=20 >=20 >=20 >=20 > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), >=20 > The values of identities are originally set by operators. >=20 >=20 >=20 >=20 >=20 > Does anyone have any concerns regarding these requirements? >=20 >=20 >=20 > Sue Hares >=20 >=20 >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > = https://www.ietf.org/mailman/listinfo/i2rs >=20 ------=_NextPart_000_01F2_01D09EDC.F911A020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy: =

 

2a and 2b:

 

=C2=B7         = This is just a highly reliable = requirement as we talked about in the interim.=C2=A0 =C2=A0It is not = perfect, but highly reliable.

 

=C2=B7         = No specific changes are being suggested = to RFC 5277, but setting this requirement will cause the NETCONF group = to consider changes need to be made or can be made. = =C2=A0Implementations must be fast and highly reliable for the normal = I2RS data.=C2=A0 We expect the NETCONF group to provide some details on = what =E2=80=9Cfast and highly reliable=E2=80=9D means for their = protocols.=C2=A0 In the past FORCES proponents gave those numbers. =

 

=C2=B7         = Joel mentioned that large RIB pulls were = not the normal I2RS data.

 

I will = ask the working group the larger question =E2=80=93 Do we need to = specify =E2=80=9Cfast and highly reliable=E2=80=9D in terms of response = time or packets per second?

 

Sue =

 

 

 

-----Original Message-----
From: Andy Bierman = [mailto:andy@yumaworks.com]
Sent: Wednesday, June 03, 2015 9:10 = PM
To: Susan Hares
Cc: i2rs@ietf.org; Jeffrey Haas; Joel M. = Halpern; i2rs-chairs@ietf.org; Alia Atlas
Subject: Re: [i2rs] I2RS = minutes for the I2RS Interim (5/27/2015)

 

Hi,

 

Re = 2(a) and (b):

 

Are = changes to RFC 5277 being proposed to make notifications highly = reliable, or is there an assumption that implementations will just = provide adequate memory to buffer notifications?

 

Real = time guarantees on getting data sounds like RAI work is needed?=C2=A0 = Are any changes needed to RESTCONF or NETCONF to support this = requirement?=C2=A0 Or is there just an expectation that implementations = will be fast.

 

IMO, = the standard should be silent on response times and packets per second = issues.=C2=A0 Unless a certain speed is required for interoperability, = then it seems inappropriate to mention in an RFC.

 

 

Andy

 

 

On = Wed, Jun 3, 2015 at 5:49 PM, Susan Hares <shares@ndzh.com> wrote:

> The minutes for = the I2RS meeting are at:

> 

> 

> 

> www.ietf.org/proceedings/= interim/2015/05/27/i2rs/minutes/minutes-inter

> im-2015-i2rs-8

> 

> 

> 

> These minute provide a lengthy of issues in = the requirements.=C2=A0 From

> = these minutes, there are the following 6 conclusions on the protocol =

> requirements that Jeff = stated:

> 

> 

> 

> 1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There will be = no consideration of an overlay model unless a fully

> formed proposal is presented.

> 

> Jeff and I appreciate Ken Watsen=E2=80=99s = comments on the list, but we have

> had lots of suggestions = regarding

> 

> an overlay proposal =E2=80=93 but no full = proposal.=C2=A0 At this time, the WG will

> only consider full proposals and = not

> 

> suggestions toward a = proposal.

> 

> 

> 

> 2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Jeff=E2=80=99s document provides details on ephemeral state = requirements

> that have not = changed.=C2=A0 These requirements include:

> 

> a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Highly = reliable notifications (but not perfectly reliable

> notifications)

> 

> b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 High = bandwidth, asynchronous interface, with real-time guarantees = on

> getting = data,

> 

> c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Node = identification of clients that write by client = identity,

> secondary identity, = and priority.=C2=A0 Data models will determine what is

> the =E2=80=9Cnode=E2=80=9D unit.=C2=A0 For = example, the I2RS RIB node unit is the route.

> 

> d.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 There is one = priority per client.

> 

> e.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Priority is = kept in the NACM at the client level [rather than path

> level (5/27 meeting) or group level (list = discussion).

> 

> 

> 

> 3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Joel suggests = that large data write may be best done in netconf with

> guarantees

> 

> a.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2RS = will be focused on highly asynchronous interfaces with = less

> than full routing = tables.

> 

> b.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A client = whose large data is interrupted by a notification has a

> difficult time determine when the notification = happened in the stream

> = =E2=80=93 so the I2RS client must ask the agent again.

> 

> c.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Logging = for traceability is different than event notification.

> 

> 

> 

> 4)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Secondary = identity data is meta-data that is stored in the agent.

> Agent does not do anything with the meta-data. = The client has to do

> one = edit per secondary at a time.

> 

> 

> 

> 5)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Secondary = identity data is read-only meta-data that is stored in = the

> agent associated with a = data model node that is being created or

> updated

> (write-access) in the data = store.

> 

> 

> 

> 

> 

> 6)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I2RS Client = and Agent Identities are mutually authenticated by

> Authentication server (AAA),

> 

> The values of identities are originally set by = operators.

> 

> 

> 

> 

> 

> Does anyone have any concerns regarding these = requirements?

> 

> 

> 

> Sue Hares

> 

> 

> 

> 

> = _______________________________________________

> i2rs mailing list

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

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

> 

------=_NextPart_000_01F2_01D09EDC.F911A020-- From nobody Thu Jun 4 12:45:09 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C106E1A8BB1 for ; Thu, 4 Jun 2015 12:45:07 -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 vYS0hJGBV5pT for ; Thu, 4 Jun 2015 12:45:03 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 575F71A8AC2 for ; Thu, 4 Jun 2015 12:45:03 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so33599590lbb.3 for ; Thu, 04 Jun 2015 12:45:02 -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=zJLFk0Wsqqf9aA8GMRH4RgzK041TKy5srVJPGN3okeg=; b=WpmKenpkoN7jkKLxn6xMIGKObW+LL8GKrc6FAfmtWJCbCC0vu6l+hsl4FkiErrZmmI EIT4Ll/Uae9xBXyN4aUeBo673ui31Tzx7+gFs3P6KBvyavGZCijODnvCIpkfLiGsDEJ2 l3EDoEhoBREQu+zEaUlotnkylDs96Q0Bm0CsB0E79YYwW4ET5QAs4FNOhLSTyLCBLZ9R Z+hT586uEGWsEBhc1fmmSyUMjkyxrAENvXE3o5G+f1FCsFi+NtDf0mekiEU0nBiF+ZeO 4kRsUkhT7N9Nu6O8DUcQIdHMIn26JJLQ82Zxw/LHmrs0oZoqjLcbUXbLM1Q36C02WKTZ BM3w== X-Gm-Message-State: ALoCoQnYzp+UnzDqTMPcZnYewWKxA2oZ5LpI5WSuvCp9T3tNRarHqoY8/hdZyAxp5Zom3ffcw6p6 MIME-Version: 1.0 X-Received: by 10.152.9.71 with SMTP id x7mr8711685laa.119.1433447101900; Thu, 04 Jun 2015 12:45:01 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 4 Jun 2015 12:45:01 -0700 (PDT) In-Reply-To: <01d301d09efd$2a31ddd0$7e959970$@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> <01d301d09efd$2a31ddd0$7e959970$@ndzh.com> Date: Thu, 4 Jun 2015 12:45:01 -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 , 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, 04 Jun 2015 19:45:07 -0000 On Thu, Jun 4, 2015 at 12:32 PM, Susan Hares wrote: > Andy: > > Just to check - are these acceptable to add as 2.4 to Jeff's document. [I= added in perform all or none] to Alia's list: > > For perform all or none, when one operations in the message causes an err= or, > all previous operations are rolled back to the pre-operation state. > Yes, but rollback is an implementation detail. Typically, the server will attempt to validate the edits before applying any of them. This is required by YANG Patch. It is possible for everything to validate and the internal commit of an edit to still fail. Then a real rollback happens on the server. >From the client POV, all-or-none does not change the resource unless all edits are applied successfully. Whether nodes were temporarily applied and then removed is not visible to the client. Andy > For the stop-on-error, when one operation in the message > causes an error, that operation is not done (can't b/c of error) AND > no operations after that in the message are done. > > For recording errors, all operations in the message are attempted in orde= r and any > errors are recorded to send back to the client. > If an operation caused an error, then the operation isn't completed. > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Wednesday, June 03, 2015 1:16 PM > To: Alia Atlas > Cc: Susan Hares; i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen S= choenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas wrote: >> Andy, >> >> On Fri, May 29, 2015 at 8:41 PM, Andy Bierman wrote= : >>> >>> 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 ad= dition 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 d= atastore. >>> 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. >> >> >> I agree. For the stop-on-error, when one operation in the message >> causes an error, that operation is not done (can't b/c of error) AND >> no operations after that in the message are done. For recording >> errors, all operations in the message are attempted in order and any >> errors are recorded to send back to the client. >> If an operation caused an error, then the operation isn't completed. >> >> Does that make sense? >> > > > I think so. This is a sharp knife. Developers using anything except 'all-= or-none' will need to be very knowledgeable about the data models in use in= order for partial edits to be practical. > But I think the draft makes this clear. > > >> Regards, >> Alia >> >> > > Andy > >>> >>> >>> 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 th= at >>> > >>> > 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 withi= n 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 =E2=80=93 but a combination of bot= h 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 al= so 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 >>> > 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 w= ill 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 alte= red 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 edi= ts 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 >>> > >>> >> >>> > >>> >> =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 winnin= g. >>> > >>> >> 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 inherentl= y >>> >>> 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 | >>> >>>> 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 Thu Jun 4 12:52: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 5D1661A8FD2; Thu, 4 Jun 2015 12:52:16 -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 CH-8wjCcPUma; Thu, 4 Jun 2015 12:52:14 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 27FBE1A8F4B; Thu, 4 Jun 2015 12:52:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> In-Reply-To: <20150604062424.GA40773@elstar.local> Date: Thu, 4 Jun 2015 15:52:15 -0400 Message-ID: <01fe01d09eff$f51d4690$df57d3b0$@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: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipnrM0arA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Thu, 04 Jun 2015 19:52:16 -0000 Juergen: I understand your technical point on being concerned about "solutions that require (i) separate data models for ephemeral state and (ii) data model specific merge logic. While this may work for I2RS, this approach does not scale or has a very high cost of scaling to other ephemeral state editing needs." If you have full overlay model proposal, we would be glad to receive it. However, no one else has proposed a full overlay model. Other answers are below. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, June 04, 2015 2:24 AM To: Susan Hares Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter > im-201 > 5-i2rs-8 > > > > These minute provide a lengthy of issues in the requirements. From > these minutes, there are the following 6 conclusions on the protocol > requirements that Jeff stated: > > > > 1) There will be no consideration of an overlay model unless a fully > formed proposal is presented. > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > had lots of suggestions regarding an overlay proposal - but no full > proposal. At this time, the WG will only consider full proposals and > not suggestions toward a proposal. For the record: I am highly concerned about solutions that require (i) separate data models for ephemeral state and (ii) data model specific merge logic. While this may work for I2RS, this approach does not scale or has a very high cost of scaling to other ephemeral state editing needs. > 2) Jeff's document provides details on ephemeral state requirements > that have not changed. These requirements include: > > a. Highly reliable notifications (but not perfectly reliable > notifications) > > b. High bandwidth, asynchronous interface, with real-time guarantees on > getting data, > > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is > the "node" unit. For example, the I2RS RIB node unit is the route. I am concerned about adding protocol mechanisms that are specific to a certain data model. It is unclear what a "node" unit it, terms like 'highly reliable notifications' and 'high bandwidth, asynchronous interface, with real-time guarantees' are somewhat unclear - how do we determine we have met any of these requirements? > d. There is one priority per client. > > e. Priority is kept in the NACM at the client level [rather than path > level (5/27 meeting) or group level (list discussion). Why does this mapping of username to priority have to be maintained in NACM? > 3) Joel suggests that large data write may be best done in netconf with > guarantees > > a. I2RS will be focused on highly asynchronous interfaces with less > than full routing tables. > > b. A client whose large data is interrupted by a notification has a > difficult time determine when the notification happened in the stream > - so the I2RS client must ask the agent again. > > c. Logging for traceability is different than event notification. Except c), I do not understand this. What are these 'guarantees' 3) is about? [Sue]: The large database pulls of a I2RS RIB (1 million routes) may receive a change notification for one of the routes while the rest of the stream is in progress. If the change notification does not include the data, the I2RS client must poll the I2RS agent to determine if the route change notification occurred before or after that route's data was sent. Change notifications are reliable, but not perfectly reliable. Logging is different than change notifications as logging for tracing includes all change data reliably. > 5) Secondary identity data is read-only meta-data that is stored in the > agent associated with a data model node that is being created or > updated (write-access) in the data store. Ehem, what is read-only data that is created or written? Did you want to say that the identity meta-data is immutable once a data node has been created? And if so, has priority the same property: Is priority of a data node is determined at creation time and then immutable? [sue]: Secondary identity data is read-only meta-data that is only changed when created or written. It is immutable unless the whole node is changed. Priority is linked to I2RS client. Priority remains unchanged with the identity of the client. Priority of an entry (route1 from client-1, priority2) remains immutable with the writing of this entry from this client. If a new client (route-1 from client-2, pririty3), then the node and the meta-data changes. > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > I am not sure how agent identity authentication via AAA works. Can someone point me to the right direction if I assume a secure transport such as SSH or TLS? The identities used in SSH are passed via AAA (diameter or radius). The identities are not standardized but sent in AAA (diameter or radius) messages based on operator assignment. /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 Jun 4 12:56: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 1A6A41A906F for ; Thu, 4 Jun 2015 12:56:07 -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 xTxeqpLbZB3V for ; Thu, 4 Jun 2015 12:56:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 57D831A9070 for ; Thu, 4 Jun 2015 12:56:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; 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> <01d301d09efd$2a31ddd0$7e959970$@ndzh.com> In-Reply-To: Date: Thu, 4 Jun 2015 15:55:56 -0400 Message-ID: <020001d09f00$78f409e0$6adc1da0$@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/7wwJfjQnEAsEyPOABJ9tNNAHvw66tAZaM50oC52zYuQF0Do88AfI3sF8CmAVz4gH00CZbAa2lsVECRhuE8AEu2l+nAlXu/OoCq9gkkJ01wPRg 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' , '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, 04 Jun 2015 19:56:07 -0000 Andy:=20 I would take a set of sample language on the perform all or none. Any = suggestions or edits? Other answers below. Here's what I think we have=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >From the client POV, all-or-none does not change the resource unless all edits are applied successfully. For the stop-on-error, when one operation in the message causes an=20 error, that operation is not done (can't b/c of error) AND no=20 operations after that in the message are done. For recording errors, all operations in the message are attempted in=20 order and any errors are recorded to send back to the client. If an operation caused an error, then the operation isn't completed. Sue Hares=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Thursday, June 04, 2015 3:45 PM To: Susan Hares Cc: i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn; Juergen = Schoenwaelder; Alia Atlas; Alia Atlas; Jeffrey Haas; Joel M. Halpern Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 On Thu, Jun 4, 2015 at 12:32 PM, Susan Hares wrote: > Andy: > > Just to check - are these acceptable to add as 2.4 to Jeff's document. = [I added in perform all or none] to Alia's list: > > For perform all or none, when one operations in the message causes an=20 > error, all previous operations are rolled back to the pre-operation = state. > Yes, but rollback is an implementation detail. Typically, the server will attempt to validate the edits before applying = any of them. This is required by YANG Patch. It is possible for everything to validate and the internal commit of an = edit to still fail. Then a real rollback happens on the server. [OK. It is obvious I step on the text here. Please provide = alternative. ]=20 >From the client POV, all-or-none does not change the resource unless all edits are applied successfully. Whether nodes were temporarily applied and then removed is not visible = to the client. =20 > For the stop-on-error, when one operation in the message causes an=20 > error, that operation is not done (can't b/c of error) AND no=20 > operations after that in the message are done. > > For recording errors, all operations in the message are attempted in=20 > order and any errors are recorded to send back to the client. > If an operation caused an error, then the operation isn't completed. > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Wednesday, June 03, 2015 1:16 PM > To: Alia Atlas > Cc: Susan Hares; i2rs@ietf.org; Jeff Haas; chen.ran@zte.com.cn;=20 > Juergen Schoenwaelder; Alia Atlas; Jeffrey Haas; Joel M. Halpern > Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00 > > On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas wrote: >> Andy, >> >> On Fri, May 29, 2015 at 8:41 PM, Andy Bierman = wrote: >>> >>> 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. >> >> >> I agree. For the stop-on-error, when one operation in the message=20 >> causes an error, that operation is not done (can't b/c of error) AND=20 >> no operations after that in the message are done. For recording=20 >> errors, all operations in the message are attempted in order and any=20 >> errors are recorded to send back to the client. >> If an operation caused an error, then the operation isn't completed. >> >> Does that make sense? >> > > > I think so. This is a sharp knife. Developers using anything except = 'all-or-none' will need to be very knowledgeable about the data models = in use in order for partial edits to be practical. > But I think the draft makes this clear. > > >> Regards, >> Alia >> >> > > Andy > >>> >>> >>> 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=20 >>> > multi-message atomicity and rollback. Three types of error=20 >>> > 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. >>> > 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,=20 >>> > 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,=20 >>> > the >>> > >>> > protocol will include an explicit reply to modification or=20 >>> > write >>> > >>> > operations even when they fully succeed. >>> > >>> > >>> > >>> > >>> > >>> > Will this cover the architecture document 7.9 transactions impact=20 >>> > 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 = >>> >>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=20 >>> > requirement for the protocol. Instead section 3.3 of the I2RS=20 >>> > architecture document calls for this to be model driver. Let me=20 >>> > 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=20 >>> > change will be given if route is installed, active, and a reason=20 >>> > 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=20 >>> > discusses the challenge that topology models are not:=20 >>> > configuration data only or operational data only =E2=80=93 but a=20 >>> > combination of both in ephemeral state. >>> > Draft-ietf-i2rs-yang-network-topo-00 suggests an ephemeral=20 >>> > topology model which is operational (read-only) that contains data = >>> > from: a) only read from operational units, b) a configured=20 >>> > topology, and c) combination topology (operational state and=20 >>> > configured). (A second alternative is to just have = =E2=80=9Ca=E2=80=9D and =E2=80=9Cb=E2=80=9D,=20 >>> > 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=20 >>> > 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, = >>> > 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=20 >>> > 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=20 >>> > 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=20 >>> > present, and the priority is better than the transaction's user's = >>> > priority for that node, the commit SHALL fail. An appropriate=20 >>> > 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=20 >>> > 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;=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=20 >>> >> 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=20 >>> >> Client, 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 = >>> >> out-of-band mechanism to pass the information with. IMU (in my=20 >>> >> understanding), the NACM on the agent is created based on this=20 >>> >> AAA loading. The i2rs secondary identity is loaded via an=20 >>> >> edit-config mechanism in a config operation (see section 5.1 of=20 >>> >> Jeff's document.). Please let me know if my understanding of=20 >>> >> 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=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=20 >>> >> 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=20 >>> >> are found where i2rs-priority is already present, and the=20 >>> >> priority is equal to or better than the transaction's user's=20 >>> >> priority for the 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=20 >>> >> altered by >>> > >>> >> users that match a rule carrying i2rs-priority will have those = >>> >> nodes >>> > >>> >> annotated with metadata. Additionally, during commit=20 >>> >> processing, if >>> > >>> >> nodes are found where i2rs-priority is already present, and=20 >>> >> 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 = >>> >>> or RESTCONF to use client priority?" What are you proposing=20 >>> >>> 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=20 >>> >>> a different ID if they want a different priority for write of an = >>> >>> 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;=20 >>> >>> Jeffrey >>> > >>> >>> Haas; i2rs@ietf.org; chen.ran@zte.com.cn; Alia Atlas; Susan=20 >>> >>> 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=20 >>> >>>>> 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=20 >>> >>> to implement I2RS client priority is rather trivial. >>> > >>> >>> It can certainly be made really complicated by the IETF, but it=20 >>> >>> is an inherently trivial configuration. >>> > >>> >>> >>> > >>> >>>> And the bigger question: Do we create something specific for=20 >>> >>>> 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=20 >>> >>>> 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=20 >>> >>> really help. >>> > >>> >>> It seems like an implementation detail that is being turned into = >>> >>> ad administrative task. If multiple clients from multiple=20 >>> >>> vendors are stepping on each other, then the likely outcome of a = >>> >>> priority change by the administrator will be to select which=20 >>> >>> 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 From nobody Fri Jun 5 05:35: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 700001B2D0E; Fri, 5 Jun 2015 05:35:47 -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 yYiw1YNRf83s; Fri, 5 Jun 2015 05:35:44 -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 179A81A1B05; Fri, 5 Jun 2015 05:35:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 82A2A14E5; Fri, 5 Jun 2015 14:35:42 +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 OwF-fN0ibgdC; Fri, 5 Jun 2015 14:35:09 +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, 5 Jun 2015 14:35:40 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7598C2002B; Fri, 5 Jun 2015 14:35:40 +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 HjrSsTq2-ush; Fri, 5 Jun 2015 14:35:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4524920013; Fri, 5 Jun 2015 14:35:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 763CD3429FD0; Fri, 5 Jun 2015 14:35:34 +0200 (CEST) Date: Fri, 5 Jun 2015 14:35:33 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150605123533.GA55279@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, jhaas@pfrc.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) 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, 05 Jun 2015 12:35:47 -0000 On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: > Juergen: > > I understand your technical point on being concerned about > > "solutions that require (i) separate data models for ephemeral state and > (ii) data model specific merge logic. While this may work for I2RS, this > approach does not scale or has a very high cost of scaling to other > ephemeral state editing needs." > > If you have full overlay model proposal, we would be glad to receive it. > However, no one else has proposed a full overlay model. Frankly, there is no full alternate proposal either. The overlay model has been discussed at quite some detail at a NETMOD interim. I am happy to point at the meeting minutes. The question perhaps really is whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a solution into stone to be run through the NETCONF working group or whether (c) creates a solution on its own independently of any other NETMOD/NETCONF requirements. > Other answers are below. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, June 04, 2015 2:24 AM > To: Susan Hares > Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; > 'Alia Atlas' > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > > The minutes for the I2RS meeting are at: > > > > > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter > > im-201 > > 5-i2rs-8 > > > > > > > > These minute provide a lengthy of issues in the requirements. From > > these minutes, there are the following 6 conclusions on the protocol > > requirements that Jeff stated: > > > > > > > > 1) There will be no consideration of an overlay model unless a fully > > formed proposal is presented. > > > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > > had lots of suggestions regarding an overlay proposal - but no full > > proposal. At this time, the WG will only consider full proposals and > > not suggestions toward a proposal. > > For the record: I am highly concerned about solutions that require (i) > separate data models for ephemeral state and (ii) data model specific merge > logic. While this may work for I2RS, this approach does not scale or has a > very high cost of scaling to other ephemeral state editing needs. > > > 2) Jeff's document provides details on ephemeral state requirements > > that have not changed. These requirements include: > > > > a. Highly reliable notifications (but not perfectly reliable > > notifications) > > > > b. High bandwidth, asynchronous interface, with real-time guarantees > on > > getting data, > > > > c. Node identification of clients that write by client identity, > > secondary identity, and priority. Data models will determine what is > > the "node" unit. For example, the I2RS RIB node unit is the route. > > I am concerned about adding protocol mechanisms that are specific to a > certain data model. It is unclear what a "node" unit it, terms like 'highly > reliable notifications' and 'high bandwidth, asynchronous interface, with > real-time guarantees' are somewhat unclear - how do we determine we have met > any of these requirements? Apparently no answer here... > > d. There is one priority per client. > > > > e. Priority is kept in the NACM at the client level [rather than path > > level (5/27 meeting) or group level (list discussion). > > Why does this mapping of username to priority have to be maintained in NACM? Apparently no answer here... > > 3) Joel suggests that large data write may be best done in netconf > with > > guarantees > > > > a. I2RS will be focused on highly asynchronous interfaces with less > > than full routing tables. > > > > b. A client whose large data is interrupted by a notification has a > > difficult time determine when the notification happened in the stream > > - so the I2RS client must ask the agent again. > > > > c. Logging for traceability is different than event notification. > > Except c), I do not understand this. What are these 'guarantees' 3) is > about? > > [Sue]: The large database pulls of a I2RS RIB (1 million routes) may receive > a change notification for one of the routes while the rest of the stream is > in progress. If the change notification does not include the data, the I2RS > client must poll the I2RS agent to determine if the route change > notification occurred before or after that route's data was sent. > Change notifications are reliable, but not perfectly reliable. Logging is > different than change notifications as logging for tracing includes all > change data reliably. I am still confused what the requirement here is. > > 5) Secondary identity data is read-only meta-data that is stored in > the > > agent associated with a data model node that is being created or > > updated (write-access) in the data store. > > Ehem, what is read-only data that is created or written? Did you want to say > that the identity meta-data is immutable once a data node has been created? > And if so, has priority the same property: Is priority of a data node is > determined at creation time and then immutable? > > [sue]: Secondary identity data is read-only meta-data that is only changed > when created or written. It is immutable unless the whole node is changed. > Priority is linked to I2RS client. Priority remains unchanged with the > identity of the client. You can't ever change the priority of a client? I doubt this is practical. > Priority of an entry (route1 from client-1, priority2) remains > immutable with the writing of this entry from this client. If a new > client (route-1 from client-2, pririty3), then the node and the > meta-data changes. So I understand the priority is determined at write time but then sticking until the next write. Or in other words, to change the priority I have to write the data again using a client with a different priority (or using the same client in case priority of a client turns out to be configurable). > > 6) I2RS Client and Agent Identities are mutually authenticated by > > Authentication server (AAA), > > > > The values of identities are originally set by operators. > > > I am not sure how agent identity authentication via AAA works. Can someone > point me to the right direction if I assume a secure transport such as SSH > or TLS? > > The identities used in SSH are passed via AAA (diameter or radius). The > identities are not standardized but sent in AAA (diameter or radius) > messages based on operator assignment. I know how I can pass the client identity via AAA using SSH, I like to see an explanation how that is supposed to work for server identities (and which operational problem that solves). /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 Jun 5 05:39:10 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9CE1B2EF7; Fri, 5 Jun 2015 05:39:08 -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 H6eEt81GZqdR; Fri, 5 Jun 2015 05:39:06 -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 459891B2EF4; Fri, 5 Jun 2015 05:39:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 30E5625110C; Fri, 5 Jun 2015 05:39:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [88.128.80.69]) (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 8A23E2510AB; Fri, 5 Jun 2015 05:39:04 -0700 (PDT) Message-ID: <55719868.2030306@joelhalpern.com> Date: Fri, 05 Jun 2015 08:39:04 -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, jhaas@pfrc.org, i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> In-Reply-To: <20150605123533.GA55279@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 05 Jun 2015 12:39:08 -0000 I would describe it somewhat differently from any of the choices you list. A) I2RS has some a set of architectural requirements. These were not as cleanly described as one might like but they were very clearly accepted by the working group and understood to be needed for the protocol choice. B) The working group has decided that it will use NetConf/RestConf if that can meet the requirements. The corrolary is that if neither NetConf nor RestConf can meet the requirements, then the working group will, in my opinion, have to do something else. Yours, Joel On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: > On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >> Juergen: >> >> I understand your technical point on being concerned about >> >> "solutions that require (i) separate data models for ephemeral state and >> (ii) data model specific merge logic. While this may work for I2RS, this >> approach does not scale or has a very high cost of scaling to other >> ephemeral state editing needs." >> >> If you have full overlay model proposal, we would be glad to receive it. >> However, no one else has proposed a full overlay model. > > Frankly, there is no full alternate proposal either. The overlay model > has been discussed at quite some detail at a NETMOD interim. I am > happy to point at the meeting minutes. The question perhaps really is > whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF > looks at solutions or whether (b) I2RS casts a solution into stone to > be run through the NETCONF working group or whether (c) creates a > solution on its own independently of any other NETMOD/NETCONF > requirements. > >> Other answers are below. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, June 04, 2015 2:24 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; >> 'Alia Atlas' >> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >> >> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>> The minutes for the I2RS meeting are at: >>> >>> >>> >>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter >>> im-201 >>> 5-i2rs-8 >>> >>> >>> >>> These minute provide a lengthy of issues in the requirements. From >>> these minutes, there are the following 6 conclusions on the protocol >>> requirements that Jeff stated: >>> >>> >>> >>> 1) There will be no consideration of an overlay model unless a fully >>> formed proposal is presented. >>> >>> Jeff and I appreciate Ken Watsen's comments on the list, but we have >>> had lots of suggestions regarding an overlay proposal - but no full >>> proposal. At this time, the WG will only consider full proposals and >>> not suggestions toward a proposal. >> >> For the record: I am highly concerned about solutions that require (i) >> separate data models for ephemeral state and (ii) data model specific merge >> logic. While this may work for I2RS, this approach does not scale or has a >> very high cost of scaling to other ephemeral state editing needs. >> >>> 2) Jeff's document provides details on ephemeral state requirements >>> that have not changed. These requirements include: >>> >>> a. Highly reliable notifications (but not perfectly reliable >>> notifications) >>> >>> b. High bandwidth, asynchronous interface, with real-time guarantees >> on >>> getting data, >>> >>> c. Node identification of clients that write by client identity, >>> secondary identity, and priority. Data models will determine what is >>> the "node" unit. For example, the I2RS RIB node unit is the route. >> >> I am concerned about adding protocol mechanisms that are specific to a >> certain data model. It is unclear what a "node" unit it, terms like 'highly >> reliable notifications' and 'high bandwidth, asynchronous interface, with >> real-time guarantees' are somewhat unclear - how do we determine we have met >> any of these requirements? > > Apparently no answer here... > >>> d. There is one priority per client. >>> >>> e. Priority is kept in the NACM at the client level [rather than path >>> level (5/27 meeting) or group level (list discussion). >> >> Why does this mapping of username to priority have to be maintained in NACM? > > Apparently no answer here... > >>> 3) Joel suggests that large data write may be best done in netconf >> with >>> guarantees >>> >>> a. I2RS will be focused on highly asynchronous interfaces with less >>> than full routing tables. >>> >>> b. A client whose large data is interrupted by a notification has a >>> difficult time determine when the notification happened in the stream >>> - so the I2RS client must ask the agent again. >>> >>> c. Logging for traceability is different than event notification. >> >> Except c), I do not understand this. What are these 'guarantees' 3) is >> about? >> >> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may receive >> a change notification for one of the routes while the rest of the stream is >> in progress. If the change notification does not include the data, the I2RS >> client must poll the I2RS agent to determine if the route change >> notification occurred before or after that route's data was sent. >> Change notifications are reliable, but not perfectly reliable. Logging is >> different than change notifications as logging for tracing includes all >> change data reliably. > > I am still confused what the requirement here is. > >>> 5) Secondary identity data is read-only meta-data that is stored in >> the >>> agent associated with a data model node that is being created or >>> updated (write-access) in the data store. >> >> Ehem, what is read-only data that is created or written? Did you want to say >> that the identity meta-data is immutable once a data node has been created? >> And if so, has priority the same property: Is priority of a data node is >> determined at creation time and then immutable? >> >> [sue]: Secondary identity data is read-only meta-data that is only changed >> when created or written. It is immutable unless the whole node is changed. >> Priority is linked to I2RS client. Priority remains unchanged with the >> identity of the client. > > You can't ever change the priority of a client? I doubt this is > practical. > >> Priority of an entry (route1 from client-1, priority2) remains >> immutable with the writing of this entry from this client. If a new >> client (route-1 from client-2, pririty3), then the node and the >> meta-data changes. > > So I understand the priority is determined at write time but then > sticking until the next write. Or in other words, to change the > priority I have to write the data again using a client with a > different priority (or using the same client in case priority of a > client turns out to be configurable). > >>> 6) I2RS Client and Agent Identities are mutually authenticated by >>> Authentication server (AAA), >>> >>> The values of identities are originally set by operators. >>> >> I am not sure how agent identity authentication via AAA works. Can someone >> point me to the right direction if I assume a secure transport such as SSH >> or TLS? >> >> The identities used in SSH are passed via AAA (diameter or radius). The >> identities are not standardized but sent in AAA (diameter or radius) >> messages based on operator assignment. > > I know how I can pass the client identity via AAA using SSH, I like to > see an explanation how that is supposed to work for server identities > (and which operational problem that solves). > > /js > From nobody Fri Jun 5 05:55:14 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 BAD091B2F12; Fri, 5 Jun 2015 05:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im6QTWcIN5Hf; Fri, 5 Jun 2015 05:55:09 -0700 (PDT) Received: from server.riw.us (server.riw.us [162.144.32.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB1341B2F13; Fri, 5 Jun 2015 05:55:09 -0700 (PDT) Received: from 162-229-180-77.lightspeed.rlghnc.sbcglobal.net ([162.229.180.77]:56897 helo=RussPC) by server.riw.us with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85) (envelope-from ) id 1Z0r9C-0006Oy-7C; Fri, 05 Jun 2015 12:54:54 +0000 From: "Russ White" To: "'Joel M. Halpern'" , "'Susan Hares'" , , , , "'Alia Atlas'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> In-Reply-To: <55719868.2030306@joelhalpern.com> Date: Fri, 5 Jun 2015 08:54:49 -0400 Message-ID: <01d901d09f8e$cf9c8c20$6ed5a460$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fgJ/cqsgnnzG4CA= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.riw.us X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - riw.us X-Get-Message-Sender-Via: server.riw.us: authenticated_id: russw@riw.us X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 05 Jun 2015 12:55:11 -0000 > A) I2RS has some a set of architectural requirements. These were not as > cleanly described as one might like but they were very clearly accepted by > the working group and understood to be needed for the protocol choice. > B) The working group has decided that it will use NetConf/RestConf if that > can meet the requirements. > > The corrolary is that if neither NetConf nor RestConf can meet the > requirements, then the working group will, in my opinion, have to do > something else. Agreed. Russ From nobody Fri Jun 5 09:38: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 65FAE1A8A9C for ; Fri, 5 Jun 2015 09:38: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_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 UytYOru-3nP2 for ; Fri, 5 Jun 2015 09:38:39 -0700 (PDT) Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) (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 CA3221A8AA1 for ; Fri, 5 Jun 2015 09:38:06 -0700 (PDT) Received: by labpy14 with SMTP id py14so58282675lab.0 for ; Fri, 05 Jun 2015 09:38:05 -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=pnkZX7FXxqRngyqoiDgqWeMQJHOG/6TqbopE0ebQVHQ=; b=YA0aXyffgm0alNV70lzmyLBE6grA/mcfKvBesrw8Gov506aPcHt/JQQQmDXtI3fCNV CX6n7xjCpI8ST2RseFVy0DAKCdfWXsIe9NE5EBSQjPuyrwoHrEoRxTz9nNzhQJykFvzt U7eo3WOJNr9CEuWYaN+FDGLIDCdxQHWpTrAO8FhzYiH1ED8LnZ6WuTWO2n0+nyFH5Hb9 gqv+oCnIIKJaWtu6XuTBYQIbmXc+nYNm8vVtj4OO22wor3BGqxfwq00oH7xk5yyNVZP/ +ILlUynVsWQTl3dwAZqN+7El4B0XaaL4TB7RojIeDwpivu43LHQX8/aymGcsboqLeJ1/ +nlw== X-Gm-Message-State: ALoCoQnir8m4npD+PDduk3Vs3/R6qSUQN4ypTFJ8ixqsvwQLwpEdqJ2zmcRijhq1wTT063Ue97+J MIME-Version: 1.0 X-Received: by 10.112.124.71 with SMTP id mg7mr4204912lbb.38.1433522285309; Fri, 05 Jun 2015 09:38:05 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 5 Jun 2015 09:38:05 -0700 (PDT) In-Reply-To: <55719868.2030306@joelhalpern.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> Date: Fri, 5 Jun 2015 09:38:05 -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" , i2rs-chairs@ietf.org, Susan Hares , Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 05 Jun 2015 16:38:41 -0000 On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern wrote: > I would describe it somewhat differently from any of the choices you list. > > A) I2RS has some a set of architectural requirements. These were not as > cleanly described as one might like but they were very clearly accepted by > the working group and understood to be needed for the protocol choice. > B) The working group has decided that it will use NetConf/RestConf if that > can meet the requirements. > I would say the arch is a mixture of architecture and functional requirements. Almost as if the authors had a design in mind and reverse-engineered the requirements from the design. As Juergen pointed out, the requirement to assign a priority to a client does not require NACM. NACM is a design choice for that requirement. I have some concerns about the tight notification control loop that is proposed. IMO, this is going to be too slow and too complicated. It seems to me that the only company that has implemented something close to I2RS is using a design that does not rely on a near real-time reliable notification loop. I don't have a strong preference for ephemeral datastore vs. tagging non-config data. The current NETCONF datastores only apply to config=true objects. YANG design allows for the config=false data to be further partitioned, but this is not required for I2RS to work. > The corrolary is that if neither NetConf nor RestConf can meet the > requirements, then the working group will, in my opinion, have to do > something else. That would be OK too, if you want to completely decouple I2RS from configuration. This simplifies some things if was invisible to NETCONF/RESTCONF and YANG. > > Yours, > Joel Andy > > On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >> >> On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >>> >>> Juergen: >>> >>> I understand your technical point on being concerned about >>> >>> "solutions that require (i) separate data models for ephemeral state and >>> (ii) data model specific merge logic. While this may work for I2RS, this >>> approach does not scale or has a very high cost of scaling to other >>> ephemeral state editing needs." >>> >>> If you have full overlay model proposal, we would be glad to receive it. >>> However, no one else has proposed a full overlay model. >> >> >> Frankly, there is no full alternate proposal either. The overlay model >> has been discussed at quite some detail at a NETMOD interim. I am >> happy to point at the meeting minutes. The question perhaps really is >> whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF >> looks at solutions or whether (b) I2RS casts a solution into stone to >> be run through the NETCONF working group or whether (c) creates a >> solution on its own independently of any other NETMOD/NETCONF >> requirements. >> >>> Other answers are below. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, June 04, 2015 2:24 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; >>> i2rs-chairs@ietf.org; >>> 'Alia Atlas' >>> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >>> >>> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>>> >>>> The minutes for the I2RS meeting are at: >>>> >>>> >>>> >>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter >>>> im-201 >>>> 5-i2rs-8 >>>> >>>> >>>> >>>> These minute provide a lengthy of issues in the requirements. From >>>> these minutes, there are the following 6 conclusions on the protocol >>>> requirements that Jeff stated: >>>> >>>> >>>> >>>> 1) There will be no consideration of an overlay model unless a >>>> fully >>>> formed proposal is presented. >>>> >>>> Jeff and I appreciate Ken Watsen's comments on the list, but we have >>>> had lots of suggestions regarding an overlay proposal - but no full >>>> proposal. At this time, the WG will only consider full proposals and >>>> not suggestions toward a proposal. >>> >>> >>> For the record: I am highly concerned about solutions that require (i) >>> separate data models for ephemeral state and (ii) data model specific >>> merge >>> logic. While this may work for I2RS, this approach does not scale or has >>> a >>> very high cost of scaling to other ephemeral state editing needs. >>> >>>> 2) Jeff's document provides details on ephemeral state requirements >>>> that have not changed. These requirements include: >>>> >>>> a. Highly reliable notifications (but not perfectly reliable >>>> notifications) >>>> >>>> b. High bandwidth, asynchronous interface, with real-time >>>> guarantees >>> >>> on >>>> >>>> getting data, >>>> >>>> c. Node identification of clients that write by client identity, >>>> secondary identity, and priority. Data models will determine what is >>>> the "node" unit. For example, the I2RS RIB node unit is the route. >>> >>> >>> I am concerned about adding protocol mechanisms that are specific to a >>> certain data model. It is unclear what a "node" unit it, terms like >>> 'highly >>> reliable notifications' and 'high bandwidth, asynchronous interface, with >>> real-time guarantees' are somewhat unclear - how do we determine we have >>> met >>> any of these requirements? >> >> >> Apparently no answer here... >> >>>> d. There is one priority per client. >>>> >>>> e. Priority is kept in the NACM at the client level [rather than >>>> path >>>> level (5/27 meeting) or group level (list discussion). >>> >>> >>> Why does this mapping of username to priority have to be maintained in >>> NACM? >> >> >> Apparently no answer here... >> >>>> 3) Joel suggests that large data write may be best done in netconf >>> >>> with >>>> >>>> guarantees >>>> >>>> a. I2RS will be focused on highly asynchronous interfaces with >>>> less >>>> than full routing tables. >>>> >>>> b. A client whose large data is interrupted by a notification has a >>>> difficult time determine when the notification happened in the stream >>>> - so the I2RS client must ask the agent again. >>>> >>>> c. Logging for traceability is different than event notification. >>> >>> >>> Except c), I do not understand this. What are these 'guarantees' 3) is >>> about? >>> >>> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may >>> receive >>> a change notification for one of the routes while the rest of the stream >>> is >>> in progress. If the change notification does not include the data, the >>> I2RS >>> client must poll the I2RS agent to determine if the route change >>> notification occurred before or after that route's data was sent. >>> Change notifications are reliable, but not perfectly reliable. Logging >>> is >>> different than change notifications as logging for tracing includes all >>> change data reliably. >> >> >> I am still confused what the requirement here is. >> >>>> 5) Secondary identity data is read-only meta-data that is stored in >>> >>> the >>>> >>>> agent associated with a data model node that is being created or >>>> updated (write-access) in the data store. >>> >>> >>> Ehem, what is read-only data that is created or written? Did you want to >>> say >>> that the identity meta-data is immutable once a data node has been >>> created? >>> And if so, has priority the same property: Is priority of a data node is >>> determined at creation time and then immutable? >>> >>> [sue]: Secondary identity data is read-only meta-data that is only >>> changed >>> when created or written. It is immutable unless the whole node is >>> changed. >>> Priority is linked to I2RS client. Priority remains unchanged with the >>> identity of the client. >> >> >> You can't ever change the priority of a client? I doubt this is >> practical. >> >>> Priority of an entry (route1 from client-1, priority2) remains >>> immutable with the writing of this entry from this client. If a new >>> client (route-1 from client-2, pririty3), then the node and the >>> meta-data changes. >> >> >> So I understand the priority is determined at write time but then >> sticking until the next write. Or in other words, to change the >> priority I have to write the data again using a client with a >> different priority (or using the same client in case priority of a >> client turns out to be configurable). >> >>>> 6) I2RS Client and Agent Identities are mutually authenticated by >>>> Authentication server (AAA), >>>> >>>> The values of identities are originally set by operators. >>>> >>> I am not sure how agent identity authentication via AAA works. Can >>> someone >>> point me to the right direction if I assume a secure transport such as >>> SSH >>> or TLS? >>> >>> The identities used in SSH are passed via AAA (diameter or radius). The >>> identities are not standardized but sent in AAA (diameter or radius) >>> messages based on operator assignment. >> >> >> I know how I can pass the client identity via AAA using SSH, I like to >> see an explanation how that is supposed to work for server identities >> (and which operational problem that solves). >> >> /js >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 5 11:47:01 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FD1A1BFE; Fri, 5 Jun 2015 11:46:59 -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 tmq33HMt5Rj9; Fri, 5 Jun 2015 11:46:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 153961A1BFC; Fri, 5 Jun 2015 11:46:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> In-Reply-To: <20150605123533.GA55279@elstar.local> Date: Fri, 5 Jun 2015 14:46:53 -0400 Message-ID: <02b401d09fbf$fdd578a0$f98069e0$@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: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fp6RHq0w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 05 Jun 2015 18:46:59 -0000 Juergen: The agreement with the NETCONF WG chairs was to bring requirements to NETCONF. The I2RS is working to bring a full-set of requirements for I2RS protocol based on draft-ietf-i2rs-traceability-03 (WG LC) draft-haas-i2rs-ephemeral-state-reqs-00 (WG Adoption) draft-ietf-i2rs-pub-sub-requirements-02 (WG LC) and mutual-authentication/transport text from draft-haas-i2rs-netmod-netconf-requirements-01 (draft forthcoming). This work is based on technology proposed by authors of traceability, pub-sub, and Jeff's co-workers on ephemeral state (Juniper). While draft-haas-i2rs-ephemeral-state-req-00 is not 100% complete, it has gotten a lot of discussion and has the form of a proposal. I2RS is taking choice (a) below - to state its requirements to the NETCONF/NETMOD group and to evaluate the solutions they propose. Based on feedback from members of the NETCONF WG, the I2RS WG is trying to a best effort in specifying its requirements including the I2RS ideas of solutions so that we may transmit as much information to NETCONF/NETMOD as possible. We are not adopting choice b or c at this time. Choice (a) does not constrain I2RS to accept the solution NETCONF/NETMOD proposes, but says the I2RS will review the resulting technology from NETCONF/NETMOD based on the I2RS requirements. If you feel the overlay model discussed at the NETMOD interim is a viable candidate, I suggest you write a draft outlining the details for I2RS WG. If you publish draft, I will put you on the agenda on 6/10/2015 for the WG to consider before we close on the ephemeral state. As you know from being a WG chair, the floor is open now for the overlay alternative but the adoption call of Jeff's draft (draft-haas-i2rs-ephemeral-state-reqs-00) signals a direction that the WG will take. It would please me personally if you had time to published a draft with details for the overlay model published in a draft prior to 6/9/2015 so we can consider overlay model concepts. Perhaps you can chat with Kent Watsen about creating the draft together. Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, June 05, 2015 8:36 AM To: Susan Hares Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: > Juergen: > > I understand your technical point on being concerned about > > "solutions that require (i) separate data models for ephemeral state > and > (ii) data model specific merge logic. While this may work for I2RS, > this approach does not scale or has a very high cost of scaling to > other ephemeral state editing needs." > > If you have full overlay model proposal, we would be glad to receive it. > However, no one else has proposed a full overlay model. Frankly, there is no full alternate proposal either. The overlay model has been discussed at quite some detail at a NETMOD interim. I am happy to point at the meeting minutes. The question perhaps really is whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a solution into stone to be run through the NETCONF working group or whether (c) creates a solution on its own independently of any other NETMOD/NETCONF requirements. > Other answers are below. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, June 04, 2015 2:24 AM > To: Susan Hares > Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; > i2rs-chairs@ietf.org; 'Alia Atlas' > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > > The minutes for the I2RS meeting are at: > > > > > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-int > > er > > im-201 > > 5-i2rs-8 > > > > > > > > These minute provide a lengthy of issues in the requirements. From > > these minutes, there are the following 6 conclusions on the protocol > > requirements that Jeff stated: > > > > > > > > 1) There will be no consideration of an overlay model unless a fully > > formed proposal is presented. > > > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > > had lots of suggestions regarding an overlay proposal - but no full > > proposal. At this time, the WG will only consider full proposals > > and not suggestions toward a proposal. > > For the record: I am highly concerned about solutions that require (i) > separate data models for ephemeral state and (ii) data model specific > merge logic. While this may work for I2RS, this approach does not > scale or has a very high cost of scaling to other ephemeral state editing needs. > > > 2) Jeff's document provides details on ephemeral state requirements > > that have not changed. These requirements include: > > > > a. Highly reliable notifications (but not perfectly reliable > > notifications) > > > > b. High bandwidth, asynchronous interface, with real-time guarantees > on > > getting data, > > > > c. Node identification of clients that write by client identity, > > secondary identity, and priority. Data models will determine what > > is the "node" unit. For example, the I2RS RIB node unit is the route. > > I am concerned about adding protocol mechanisms that are specific to a > certain data model. It is unclear what a "node" unit it, terms like > 'highly reliable notifications' and 'high bandwidth, asynchronous > interface, with real-time guarantees' are somewhat unclear - how do we > determine we have met any of these requirements? Apparently no answer here... > > d. There is one priority per client. > > > > e. Priority is kept in the NACM at the client level [rather than path > > level (5/27 meeting) or group level (list discussion). > > Why does this mapping of username to priority have to be maintained in NACM? Apparently no answer here... > > 3) Joel suggests that large data write may be best done in netconf > with > > guarantees > > > > a. I2RS will be focused on highly asynchronous interfaces with less > > than full routing tables. > > > > b. A client whose large data is interrupted by a notification has a > > difficult time determine when the notification happened in the > > stream > > - so the I2RS client must ask the agent again. > > > > c. Logging for traceability is different than event notification. > > Except c), I do not understand this. What are these 'guarantees' 3) is > about? > > [Sue]: The large database pulls of a I2RS RIB (1 million routes) may > receive a change notification for one of the routes while the rest of > the stream is in progress. If the change notification does not include > the data, the I2RS client must poll the I2RS agent to determine if > the route change notification occurred before or after that route's data was sent. > Change notifications are reliable, but not perfectly reliable. > Logging is different than change notifications as logging for tracing > includes all change data reliably. I am still confused what the requirement here is. > > 5) Secondary identity data is read-only meta-data that is stored in > the > > agent associated with a data model node that is being created or > > updated (write-access) in the data store. > > Ehem, what is read-only data that is created or written? Did you want > to say that the identity meta-data is immutable once a data node has been created? > And if so, has priority the same property: Is priority of a data node > is determined at creation time and then immutable? > > [sue]: Secondary identity data is read-only meta-data that is only > changed when created or written. It is immutable unless the whole node is changed. > Priority is linked to I2RS client. Priority remains unchanged with > the identity of the client. You can't ever change the priority of a client? I doubt this is practical. > Priority of an entry (route1 from client-1, priority2) remains > immutable with the writing of this entry from this client. If a new > client (route-1 from client-2, pririty3), then the node and the > meta-data changes. So I understand the priority is determined at write time but then sticking until the next write. Or in other words, to change the priority I have to write the data again using a client with a different priority (or using the same client in case priority of a client turns out to be configurable). > > 6) I2RS Client and Agent Identities are mutually authenticated by > > Authentication server (AAA), > > > > The values of identities are originally set by operators. > > > I am not sure how agent identity authentication via AAA works. Can > someone point me to the right direction if I assume a secure transport > such as SSH or TLS? > > The identities used in SSH are passed via AAA (diameter or radius). > The identities are not standardized but sent in AAA (diameter or > radius) messages based on operator assignment. I know how I can pass the client identity via AAA using SSH, I like to see an explanation how that is supposed to work for server identities (and which operational problem that solves). /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 Jun 5 12:28: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 2446B1A87C3; Fri, 5 Jun 2015 12:28:04 -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 og6SYRgopOeB; Fri, 5 Jun 2015 12:28:00 -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 5FDF81A8769; Fri, 5 Jun 2015 12:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29478; q=dns/txt; s=iport; t=1433532481; x=1434742081; h=from:to:cc:subject:date:message-id:mime-version; bh=83BQGCOHgjXGleF7aGVwMFJYDnNwUgahp1twuO8Le0w=; b=WDtbv94WAKVUI36FThGNQeQ2+E/nmUeRiq6cdL4RnHkSnOqlUMUEBRLa VAWKjK5orXu8CqLRewRHa1MwlFLs5LWptMLP/9jpzRs7lHscbmCkWiDbs F3Bzbp4KLehcOiqRtyh+XUMuKzahYFT+0qK4tJSzrwJC2K2N0sITCZnn/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AYBwDr9nFV/40NJK1SCYMQVF4GglJGumU8gg6Fdx6BGkwBAQEBAQGBC4QlBAwXVhIBBhQCEAoUAgQwFxAECgSIMg2aaJ0ZpAcBAQEBAQEBAQEBAQEBAQEBAQEBGY9cERE6DQQZDYJJL4EWBYtfhQCCQIQ/gR2FS4EvPoM6gn+LVoNZEROCCRyBUm8BAYEKOoEBAQEB X-IronPort-AV: E=Sophos;i="5.13,560,1427760000"; d="scan'208,217";a="422591918" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP; 05 Jun 2015 19:28:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t55JRx11008289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Jun 2015 19:27:59 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Fri, 5 Jun 2015 14:27:58 -0500 From: "Carlos Pignataro (cpignata)" To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-i2rs-architecture-09 Thread-Index: AQHQn8W6rvwY+AJuVk+0B+kfuDjiVw== Date: Fri, 5 Jun 2015 19:27:57 +0000 Message-ID: <184B72FD-2B4A-4BBA-956B-54AC32431C4C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.52] Content-Type: multipart/alternative; boundary="_000_184B72FD2B4A4BBA956B54AC32431C4Cciscocom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-i2rs-architecture.all@tools.ietf.org" , "rtg-dir@ietf.org" , "i2rs@ietf.org" Subject: [i2rs] RtgDir review: draft-ietf-i2rs-architecture-09 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, 05 Jun 2015 19:28:04 -0000 --_000_184B72FD2B4A4BBA956B54AC32431C4Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIOKAi2h0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL2FyZWEvcnRnL3RyYWMvd2lraS9SdGdEaXINCg0KQWx0aG91Z2ggdGhlc2Ug Y29tbWVudHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0 IHdvdWxkIGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBh bnkgb3RoZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0 cml2ZSB0byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRo ZSBkcmFmdC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMDkNClJl dmlld2VyOiBDYXJsb3MgUGlnbmF0YXJvDQpSZXZpZXcgRGF0ZTogSnVuZSA1LCAyMDE1DQpJbnRl bmRlZCBTdGF0dXM6IEluZm9ybWF0aW9uYWwNCg0KU3VtbWFyeToNCg0K4oCiIEkgaGF2ZSBzb21l ICptaW5vciogY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhpbmsgc2hvdWxk IGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi4NCg0KQ29tbWVudHM6DQoNClRoaXMgaXMg YW4gZXh0cmVtZWx5IHdlbGwgd3JpdHRlbiBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyB0aGUgYmFz aWMgYXJjaGl0ZWN0dXJlLCBtb2R1bGVzLCBhbmQgaW50ZXJmYWNlcyBmb3IgaW50ZXJmYWNpbmcg d2l0aCB0aGUgcm91dGluZyBzeXN0ZW0uIEl0cyBzdGF0dXMgdGFyZ2V0cyBJbmZvcm1hdGlvbmFs LiBpZG5pdHMgcmVwb3J0cyBubyByZWFsIG5pdHMsIG9ubHkgc29tZSBub2lzZS4NCg0KVGhhbmsg eW91IGZvciB0aGlzIGRvY3VtZW50ISEhIEkgaG9wZSB5b3UgZmluZCB0aGVzZSBjb21tZW50cyB1 c2VmdWwuDQoNCk1ham9yIElzc3VlczoNCg0KTm9uZS4NCg0KTWlub3IgSXNzdWVzOg0KDQpBbiBB cmNoaXRlY3R1cmUgZm9yIHRoZSBJbnRlcmZhY2UgdG8gdGhlIFJvdXRpbmcgU3lzdGVtDQrigKYN CkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBm b3IgYSBzdGFuZGFyZCwgcHJvZ3JhbW1hdGljDQogICBpbnRlcmZhY2UgZm9yIHN0YXRlIHRyYW5z ZmVyIGluIGFuZCBvdXQgb2YgdGhlIEludGVybmV0IHJvdXRpbmcNCiAgIHN5c3RlbS4NCg0KQ01Q OiBJcyB0aGlzIOKAnGFuIGFyY2hpdGVjdHVyZeKAnSwgYW5kIHRoZXJlIGFyZSBvdGhlciBhcmNo aXRlY3R1cmVzIGZvciB0aGUgSTJSUz8gSSBoYXZlIG5vIGlzc3VlcyB3aXRoIOKAnGFuIGFyY2hp dGVjdHVyZeKAnSwgYnV0IGl0IGludml0ZXMgdGhlc2UgcXVlc3Rpb25zLCBpbmNsdWRpbmcg4oCY aXMgdGhlcmUgYW4gYXV0aG9yaXRhdGl2ZSBhcmNoaXRlY3R1cmUsIGFuZCBpcyBpdCB0aGlzIG9u ZT8g4oCcVGhlIElFVEYgZGVmaW5lZCBhcmNoaXRlY3R1cmXigJ0/IEhvdyBhYm91dCByZW1vdmlu ZyB0aGUg4oCcQW7igJ0gZnJvbSB0aGUgdGl0bGUsIGFuZCBxdWFsaWZ5aW5nIHRoZSBBYnN0cmFj dCBhbmQgSW50cm8gd2l0aCDigJxhcyBzcGVjaWZpZWQgaW4gdGhlIElFVEbigJ0/DQoNCjEuICBJ bnRyb2R1Y3Rpb24NCg0KICAgTmV0d29yay1vcmllbnRlZCBhcHBsaWNhdGlvbnMgcmVxdWlyZQ0K ICAgZWFzeSBhY2Nlc3MgdG8gdGhpcyBpbmZvcm1hdGlvbg0KDQpDTVA6IFRoZSBjb25jZXB0IG9m IGEg4oCcbmV0d29yay1vcmllbnRlZCBhcHBsaWNhdGlvbuKAnSBpcyBhIHN1cGVyIGltcG9ydGFu dCBwaWVjZSBvZiB0aGUgd2hvbGUgcGljdHVyZS4gV2hpbGUgdGhlIGFwcGxpY2F0aW9ucyBhcmUg b3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIGFyY2hpdGVjdHVyZSBpdHNlbGYsIHRoZSBuZXR3b3Jr LW9yaWVudGVkbmVzcyBuYXR1cmUgaXMgYSBrZXkgZHJpdmVyLCB1bmFja25vd2xlZGdlZCBhcyBh IGtleSBhcmNoaXRlY3R1cmFsIHByb3BlcnR5LCBhbmQgb25seSByZXZpc2l0ZWQgaGFsZiB3YXkg ZG93biB0aGUgZG9jdW1lbnQgaW4gU2VjdGlvbiA1LiBPbmUgdGhvdWdodCBmb3IgeW91ciBjb25z aWRlcmF0aW9uOiBkb2VzIGl0IG1ha2Ugc2Vuc2UgdG8gbWFrZSB0aGlzIGV4cGxpY2l0IGluIFNl Y3Rpb24gMS4yLCBBcmNoaXRlY3R1cmFsIE92ZXJ2aWV3LCB3aGljaCBvbmx5IGRlZmluZXMg4oCc QXBwbGljYXRpb27igJ0sIG9yIGFzIGEgZHJpdmVyIGluIFMxLjE/IEp1c3QgYSB0aG91Z2h0Lg0K DQpHZW5lcmFsOg0KDQpDTVA6IE1vZGVscyDigJQgd2Mgc2F5cyB0aGVyZSBhcmUgMTggaW5zdGFu Y2VzIG9mIOKAnGRhdGEgbW9kZWzigJ0gYW5kIDEzIG9mIOKAnGluZm9ybWF0aW9uIG1vZGVs4oCd LiBXaGlsZSB0aGVyZSBhcmUgc3RhdGVtZW50cyBpbiB0aGUgSW50cm8gbGlrZSDigJxGdW5kYW1l bnRhbCB0byB0aGUgSTJSUyBhcmUgY2xlYXIgZGF0YSBtb2RlbHPigJ0sIEkgdGhpbmsgdGhlIHRl eHQgd291bGQgYmVuZWZpdCBmcm9tIGEgY2VudHJhbGl6ZWQgc21hbGwgc2VudGVuY2UgdGhhdCBl eHBsYWlucyB0aGUgcmVxdWlyZW1lbnRzIGZvciBpbmZvcm1hdGlvbiBhcyB3ZWxsIGFzIGRhdGEg bW9kZWxzIGZvciBJMlJTIG1vZHVsZXMgYW5kIHNlcnZpY2VzLiBUaGUgY2xvc2VzdCBpcyB0aGUg MXN0IHNlbnRlbmNlIG9mIFMzLjMsIHBlcmhhcHMsIGJ1dCB3aGF04oCZcyByZXF1aXJlZD8NCg0K MS4yLiAgQXJjaGl0ZWN0dXJhbCBPdmVydmlldyAoYW5kIEZpZ3VyZSAxKQ0KDQogICBJbiB0aGUN CiAgIGZpZ3VyZSwgQ2xpZW50cyBBIGFuZCBCIHByb3ZpZGUgYWNjZXNzIHRvIGEgc2luZ2xlIGFw cGxpY2F0aW9uLCB3aGlsZQ0KICAgQ2xpZW50IFAgcHJvdmlkZXMgYWNjZXNzIHRvIG11bHRpcGxl IGFwcGxpY2F0aW9ucy4NCg0KQ01QOiDigJxDbGllbnRzIEEgYW5kIEIgcHJvdmlkZSBhY2Nlc3Mg dG8gYSBzaW5nbGUgYXBwbGljYXRpb27igJ0gdGhpcyBjYW4gYmUgaW50ZXJwcmV0ZWQgYXMgYSBz aW5nbGUgQXBwbGljYXRpb24g4oCcWOKAnSBhY2Nlc3NpbmcgYm90aCBDbGllbnRzIEEgYW5kIEIu IEkgd291bGQgYWRkIGEg4oCcLCByZXNwZWN0aXZlbHnigJ0gZm9yIGV4YW1wZWwgdG8gZGlzYW1i aWd1YXRlLg0KDQpDTVA6IEFsc28sIHRoZXJlIGlzIG5vIHRleHQgc3BlY2lmeWluZyB3aGV0aGVy IGFuIGFwcGxpY2F0aW9uIGNhbiBhY2Nlc3MgSTJSUyBzZXJ2aWNlcyB2aWEgbW9yZSB0aGFuIG9u ZSBBZ2VudHMuDQoNCjYuNC4xLiAgUm91dGluZyBhbmQgTGFiZWwgSW5mb3JtYXRpb24gQmFzZXMN Cg0KICAgUm91dGluZyBlbGVtZW50cyBtYXkgbWFpbnRhaW4gb25lIG9yIG1vcmUgSW5mb3JtYXRp b24gQmFzZXMuDQogICBFeGFtcGxlcyBpbmNsdWRlIFJvdXRpbmcgSW5mb3JtYXRpb24gQmFzZXMg c3VjaCBhcyBJUHY0L0lQdjYgVW5pY2FzdA0KICAgb3IgSVB2NC9JUHY2IE11bHRpY2FzdC4gIEFu b3RoZXIgc3VjaCBleGFtcGxlIGluY2x1ZGVzIHRoZSBNUExTIExhYmVsDQogICBJbmZvcm1hdGlv biBCYXNlcywgcGVyLXBsYXRmb3JtIG9yIHBlci1pbnRlcmZhY2UuDQoNCkNNUDogb3IgcGVyLWNv bnRleHQgKGluc3RlYWQgb2YvaW4gYWRkaXRpb24gdG8gcGVyLWludGVyZmFjZSk/DQoNCjguICBP cGVyYXRpb25hbCBhbmQgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9ucw0KDQpDTVA6IE1pZ2h0 IGJlIHVzZWZ1bCB0byBhZGQgdHJhY2VhYmlsaXR5IG9mIGludGVyYWN0aW9ucyBvZiBJMlJTIGFz IGEgY29uc2lkZXJhdGlvbi4NCg0KTml0czoNCg0KQ01QOiBTb21lIG5pdHMsIHNtYWxsIGVkaXRv cmlhbHMsIGFuZCBzdWdnZXN0aW9ucyBmb3IgeW91ciBjb25zaWRlcmF0aW9uczoNCg0KMS4gIElu dHJvZHVjdGlvbg0KDQogICBSb3V0ZXJzIHRoYXQgZm9ybSB0aGUgaW50ZXJuZXQgcm91dGluZyBp bmZyYXN0cnVjdHVyZSBtYWludGFpbiBzdGF0ZQ0KICAgYXQgdmFyaW91cyBsYXllcnMgb2YgZGV0 YWlsIGFuZCBmdW5jdGlvbi4gIEZvciBleGFtcGxlLCBhIHR5cGljYWwNCg0K4oCmIFthbmRdDQoN CiAgIHRvZGF5J3Mgcm91dGVkIG5ldHdvcmtzLiAgVGhlIEkyUlMgaXMgYSBwcm9ncmFtbWF0aWMg YXN5bmNocm9ub3VzDQogICBpbnRlcmZhY2UgZm9yIHRyYW5zZmVycmluZyBzdGF0ZSBpbnRvIGFu ZCBvdXQgb2YgdGhlIGludGVybmV0IHJvdXRpbmcNCg0K4oCmIFthbmRdDQoNCiAgIFJvdXRpbmcg YW5kIFNpZ25hbGluZzogICBUaGlzIGJsb2NrIHJlcHJlc2VudHMgdGhhdCBwb3J0aW9uIG9mIHRo ZQ0KICAgICAgUm91dGluZyBFbGVtZW50IHRoYXQgaW1wbGVtZW50cyBwYXJ0IG9mIHRoZSBpbnRl cm5ldCByb3V0aW5nDQoNCkNNUDogcy90aGUgaW50ZXJuZXQvdGhlIEludGVybmV0LyAob3IgYW4g aW50ZXJuZXQ/IEkgdGhpbmsgdGhlIG1lYW5pbmcgaXMg4oCcdGhlIEludGVybmV04oCdKQ0KDQox LjEuICBEcml2ZXJzIGZvciB0aGUgSTJSUyBBcmNoaXRlY3R1cmUNCg0KICAgVGhlIEkyUlMgYXJj aGl0ZWN0dXJlIGZhY2lsaXRhdGVzIG9idGFpbmluZyBpbmZvcm1hdGlvbiBmcm9tIHRoZQ0KICAg cm91dGVyLiAgVGhlIEkyUlMgYXJjaGl0ZWN0dXJlIHByb3ZpZGVzIHRoZSBhYmlsaXR5IHRvIG5v dCBvbmx5IHJlYWQNCiAgIHNwZWNpZmljIGluZm9ybWF0aW9uLCBidXQgYWxzbyB0byBzdWJzY3Jp YmUgdG8gdGFyZ2V0ZWQgaW5mb3JtYXRpb24NCiAgIHN0cmVhbXMgYW5kIGZpbHRlcmVkIGFuZCB0 aHJlc2hvbGRlZCBldmVudHMuDQoNCkNNUDogcy9zdHJlYW1zIGFuZCBmaWx0ZXJlZCBhbmQgdGhy ZXNob2xkZWQgZXZlbnRzL3N0cmVhbXMsIGZpbHRlcmVkIGV2ZW50cywgYW5kIGV2ZW50cyBzdWJq ZWN0IHRvIGEgdGhyZXNob2xkLw0KDQoxLjIuICBBcmNoaXRlY3R1cmFsIE92ZXJ2aWV3DQoNCiAg ICAgICogIEFuIExTUiB0aGF0IGltcGxlbWVudHMgUlNWUC1URSwgT1NQRi1URSwgYW5kIFBDRVAg YW5kIGhhcyBhDQogICAgICAgICBmb3J3YXJkaW5nIHBsYW5lIGFuZCBhc3NvY2lhdGVkIFJJQiBN YW5hZ2VyLA0KDQogICAgICAqICBBIHNlcnZlciB0aGF0IHJ1bnMgSVNJUywgT1NQRiwgQkdQIGFu ZCB1c2VzIEZvckNFUyB0byBjb250cm9sIGENCiAgICAgICAgIHJlbW90ZSBmb3J3YXJkaW5nIHBs YW5lLA0KDQogICAgICBBIFJvdXRpbmcgRWxlbWVudCBtYXkgYmUgbG9jYWxseSBtYW5hZ2VkLCB3 aGV0aGVyIHZpYSBDTEksIFNOTVAsDQogICAgICBvciBORVRDT05GLg0KDQpDTVA6IFNvbWUgb2Yg dGhlc2UgYWNyb255bXMgcmVxdWlyZSBleHBhbnNpb24gb24gZmlyc3QgdXNlLiBTZWUgaHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxlLWd1aWRlL2FiYnJldi5leHBhbnNpb24udHh0 DQoNCjEuMi4gIEFyY2hpdGVjdHVyYWwgT3ZlcnZpZXcNCg0KICAgSTJSUyBBZ2VudDogICBTZWUg dGhlIGRlZmluaXRpb24gaW4gU2VjdGlvbiAyLg0KDQogICBJMlJTIENsaWVudDogICBTZWUgdGhl IGRlZmluaXRpb24gaW4gU2VjdGlvbiAyLg0KDQpDTVA6IFRoaXMgc2VjdGlvbiBkZXNjcmliZXMg dGhlIGFyY2hpdGVjdHVyYWwgZWxlbWVudHMuIFNlY3Rpb24gMiwgaG93ZXZlciwgZGVmaW5lcyDi gJx0ZXJtaW5vbG9neeKAnS4gSSB3b3VsZCBtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiBhZ2VudCBh bmQgY2xpZW50IHRvIHRoaXMgcGxhY2UuDQoNCg0KICAgU3RhdGljIFN5c3RlbSBTdGF0ZTogICBB biBJMlJTIGFnZW50IG5lZWRzIGFjY2VzcyB0byBzdGF0aWMgc3RhdGUgb24NCiAgICAgIGEgcm91 dGluZyBlbGVtZW50IGJleW9uZCB3aGF0IGlzIGNvbnRhaW5lZCBpbiB0aGUgcm91dGluZw0KICAg ICAgc3Vic3lzdGVtLiAgQW4gZXhhbXBsZSBvZiBzdWNoIHN0YXRlIGlzIHNwZWNpZnlpbmcgcXVl dWVpbmcNCg0KQ01QOiBzL3F1ZXVlaW5nL3F1ZXVpbmcvID8gTm90IHN1cmUgOi0pDQoNCiAgIHJl YWQgc2NvcGU6ICAgVGhlIHNldCBvZiBpbmZvcm1hdGlvbiB3aGljaCB0aGUgSTJSUyBjbGllbnQg aXMNCiAgICAgIGF1dGhvcml6ZWQgdG8gcmVhZC4gIFRoZSByZWFkIHNjb3BlIHNwZWNpZmllcyB0 aGUgYWNjZXNzDQoNCkNNUDogcy93aGljaC90aGF0Lw0KDQogICBub3QgeWV0IGF2YWlsYWJsZS4g IEluc3RlYWQsIGVhY2ggcm91dGVyIHVzZXMgZGlmZmVyZW50IGluZm9ybWF0aW9uLA0KICAgZGlm ZmVyZW50IG1lY2hhbmlzbXMsIGFuZCBkaWZmZXJlbnQgQ0xJIHdoaWNoIG1ha2VzIGEgc3RhbmRh cmQNCiAgIGludGVyZmFjZSBmb3IgdXNlIGJ5IGFwcGxpY2F0aW9ucyBleHRyZW1lbHkgY3VtYmVy c29tZSB0byBkZXZlbG9wIGFuZA0KICAgbWFpbnRhaW4uDQoNCnMvd2hpY2gvLCBhbGwgb2Ygd2hp Y2gvDQoNCiAgVGhlDQogICBpZGVudGl0eSB3aXRoaW4gTkFDTSBbUkZDNjUzNl0gY2FuIGJlIHNw ZWNpZnkgYXMgZWl0aGVyIGEgdXNlciBuYW1lDQogICBvciBhIGdyb3VwIHVzZXIgbmFtZSAoZS5n LiAgUm9vdCksIGFuZCB0aGlzIG5hbWUgaXMgbGlua2VkIGEgc2NvcGUNCiAgIHBvbGljeSB0aGF0 IGNvbnRhaW5lZCBpbiBhIGEgc2V0IG9mIGFjY2VzcyBjb250cm9sIHJ1bGVzLg0KDQpDTVA6IER1 cGxpY2F0ZSDigJxh4oCdDQoNCiAgIHNjb3BlIHBvbGljeS4gIE11bHRpcGxlIGlkZW50aXRpZXMg bWF5IGxpbmsgdG8gdGhlIHNhbWUgcm9sZSAoZS5nDQogICBhYmlsaXR5IHRvIHJlYWQgSTJSUyBS SUIpLg0KDQpDTVA6IHMvZS5nL2UuZy4sLw0KDQo2LjQuNS4xLiAgTWFuYWdpbmcgVmFyaWF0aW9u OiBPYmplY3QgQ2xhc3Nlcy9UeXBlcyBhbmQgSW5oZXJpdGFuY2UNCg0KICBDbGllbnRzIHdoaWNo IG9ubHkgd2FudA0KICAgYmFzaWMgY2FwYWJpbGl0aWVzIGNhbiBvcGVyYXRlIHB1cmVseSBpbiB0 ZXJtcyBvZiBiYXNlIG9yIHBhcmVudA0KICAgY2xhc3Nlcywgd2hpbGUgYSBjbGllbnQgbmVlZGlu ZyBtb3JlIGRldGFpbHMgb3IgZmVhdHVyZXMgY2FuIHdvcmsNCiAgIHdpdGggdGhlIHN1cHBvcnRl ZCBzdWItY2xhc3MoZXMpLg0KDQpDTVA6IHMvd2hpY2gvdGhhdC8NCg0KNy40LiAgU2NvcGUgUG9s aWN5IFNwZWNpZmljYXRpb25zDQoNCiAgIEFzIHNlY3Rpb24gNC4xIGFuZCA0LjIgZGVzY3JpYmUs IGVhY2ggSTJSUyBDbGllbnQgd2lsbCBoYXZlIGEgdW5pcXVlDQogICBpZGVudGl0eSBhbmQgaXQg bWF5IGhhdmUgYSBzZWNvbmRhcnkgaWRlbnRpdHkgKHNlZSBzZWN0aW9uIDIpIHRvIGFpZA0KICAg aW4gdHJvdWJsZXNob290aW5nLiAgQXMgc2VjdGlvbiA0IGluZGljYXRlcywgYWxsIGF1dGhlbnRp Y2F0aW9uIGFuZA0KICAgYXV0aG9yaXphdGlvbiBtZWNoYW5pc21zIGFyZSBiYXNlZCBvbiB0aGUg cHJpbWFyeSBJZGVudGl0eSB3aGljaA0KICAgbGlua3MgdG8gYSByb2xlIHdpdGggc2NvcGUgcG9s aWN5IGZvciBmb3IgcmVhZGluZyBkYXRhLCBmb3Igd3JpdGluZw0KDQpDTVA6IER1cGxpY2F0ZSDi gJxmb3LigJ0NCg0KR2VuZXJhbDoNCg0KQ01QOiBzL2RhdGEtbW9kZWwvZGF0YSBtb2RlbC9nICh1 bmxlc3MgdXNlZCBhcyBhbiBhZGplY3RpdmUgOi0pDQoNCuKAlCBDYXJsb3MuDQoNCg0K --_000_184B72FD2B4A4BBA956B54AC32431C4Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3BAD998FBFBE154B82BB42971BCD5582@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGVsbG8sPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0 b3JhdGUgcmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNl ZWtzIHRvIHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRo ZXkgcGFzcyB0aHJvdWdoIElFVEYmbmJzcDtsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LCBhbmQg c29tZXRpbWVzIG9uIHNwZWNpYWwgcmVxdWVzdC4gVGhlIHB1cnBvc2Ugb2YgdGhlDQogcmV2aWV3 IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGlu Zm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nJm5ic3A7RGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg 4oCLPGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtp L1J0Z0RpciIgY2xhc3M9IiI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJh Yy93aWtpL1J0Z0RpcjwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbHRob3VnaCB0 aGVzZSBjb21tZW50cyBhcmUgcHJpbWFyaWx5IGZvciB0aGUgdXNlIG9mIHRoZSBSb3V0aW5nIEFE cywgaXQgd291bGQgYmUgaGVscGZ1bCBpZiB5b3UgY291bGQgY29uc2lkZXIgdGhlbSBhbG9uZyB3 aXRoIGFueSBvdGhlciBJRVRGIExhc3QgQ2FsbCBjb21tZW50cyB0aGF0IHlvdSZuYnNwO3JlY2Vp dmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1 cGRhdGluZyB0aGUgZHJhZnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGkgY2xhc3M9 IiI+RG9jdW1lbnQ6IGRyYWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUtMDkmbmJzcDs8YnIgY2xh c3M9IiI+DQpSZXZpZXdlcjogQ2FybG9zIFBpZ25hdGFybyZuYnNwOzxiciBjbGFzcz0iIj4NClJl dmlldyBEYXRlOiBKdW5lIDUsIDIwMTUmbmJzcDs8YnIgY2xhc3M9IiI+DQpJbnRlbmRlZCBTdGF0 dXM6IEluZm9ybWF0aW9uYWw8YnIgY2xhc3M9IiI+DQo8L2k+PGJyIGNsYXNzPSIiPg0KPGIgY2xh c3M9IiI+U3VtbWFyeTo8YnIgY2xhc3M9IiI+DQo8L2I+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xh c3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+4oCiIEkg aGF2ZSBzb21lICptaW5vciogY29uY2VybnMgYWJvdXQgdGhpcyBkb2N1bWVudCB0aGF0IEkgdGhp bmsgc2hvdWxkIGJlIHJlc29sdmVkIGJlZm9yZSBwdWJsaWNhdGlvbi48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5Db21tZW50czo8YnIgY2xhc3M9IiI+DQo8L2I+PGJy IGNsYXNzPSIiPg0KVGhpcyBpcyBhbiBleHRyZW1lbHkgd2VsbCB3cml0dGVuIGRvY3VtZW50IHRo YXQgZGVzY3JpYmVzIHRoZSBiYXNpYyBhcmNoaXRlY3R1cmUsIG1vZHVsZXMsIGFuZCBpbnRlcmZh Y2VzIGZvciBpbnRlcmZhY2luZyB3aXRoIHRoZSByb3V0aW5nIHN5c3RlbS4gSXRzIHN0YXR1cyB0 YXJnZXRzIEluZm9ybWF0aW9uYWwuIGlkbml0cyByZXBvcnRzIG5vIHJlYWwgbml0cywgb25seSBz b21lIG5vaXNlLg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VGhhbmsgeW91IGZvciB0aGlzIGRvY3VtZW50ISEhIEkgaG9wZSB5b3UgZmluZCB0aGVz ZSBjb21tZW50cyB1c2VmdWwuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+TWFqb3IgSXNzdWVzOjxiciBjbGFzcz0iIj4NCjwvYj48YnIgY2xhc3M9IiI+DQpOb25lLg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5NaW5vciBJc3N1ZXM6PGJy IGNsYXNzPSIiPg0KPC9iPjxiciBjbGFzcz0iIj4NCkFuIEFyY2hpdGVjdHVyZSBmb3IgdGhlIElu dGVyZmFjZSB0byB0aGUgUm91dGluZyBTeXN0ZW08YnIgY2xhc3M9IiI+DQrigKY8YnIgY2xhc3M9 IiI+DQpBYnN0cmFjdDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtU aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIGEgc3RhbmRhcmQsIHBy b2dyYW1tYXRpYzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtpbnRlcmZhY2UgZm9yIHN0YXRl IHRyYW5zZmVyIGluIGFuZCBvdXQgb2YgdGhlIEludGVybmV0IHJvdXRpbmc8YnIgY2xhc3M9IiI+ DQombmJzcDsgJm5ic3A7c3lzdGVtLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNNUDog SXMgdGhpcyDigJxhbiBhcmNoaXRlY3R1cmXigJ0sIGFuZCB0aGVyZSBhcmUgb3RoZXIgYXJjaGl0 ZWN0dXJlcyBmb3IgdGhlIEkyUlM/IEkgaGF2ZSBubyBpc3N1ZXMgd2l0aCDigJxhbiBhcmNoaXRl Y3R1cmXigJ0sIGJ1dCBpdCBpbnZpdGVzIHRoZXNlIHF1ZXN0aW9ucywgaW5jbHVkaW5nIOKAmGlz IHRoZXJlIGFuIGF1dGhvcml0YXRpdmUgYXJjaGl0ZWN0dXJlLCBhbmQgaXMgaXQgdGhpcyBvbmU/ IOKAnFRoZSBJRVRGIGRlZmluZWQgYXJjaGl0ZWN0dXJl4oCdPw0KIEhvdyBhYm91dCByZW1vdmlu ZyB0aGUg4oCcQW7igJ0gZnJvbSB0aGUgdGl0bGUsIGFuZCBxdWFsaWZ5aW5nIHRoZSBBYnN0cmFj dCBhbmQgSW50cm8gd2l0aCDigJxhcyBzcGVjaWZpZWQgaW4gdGhlIElFVEbigJ0/PGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KMS4gJm5ic3A7SW50cm9kdWN0aW9uDQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwO05ldHdvcmstb3JpZW50ZWQgYXBwbGljYXRpb25zIHJlcXVpcmU8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2Vhc3kgYWNjZXNzIHRvIHRoaXMgaW5mb3JtYXRpb24m bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkNNUDogVGhlIGNvbmNlcHQgb2YgYSDigJxuZXR3b3JrLW9yaWVudGVkIGFwcGxpY2F0 aW9u4oCdIGlzIGEgc3VwZXIgaW1wb3J0YW50IHBpZWNlIG9mIHRoZSB3aG9sZSBwaWN0dXJlLiBX aGlsZSB0aGUgYXBwbGljYXRpb25zIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgYXJjaGl0 ZWN0dXJlIGl0c2VsZiwgdGhlIG5ldHdvcmstb3JpZW50ZWRuZXNzIG5hdHVyZSBpcyBhIGtleSBk cml2ZXIsIHVuYWNrbm93bGVkZ2VkIGFzIGENCiBrZXkgYXJjaGl0ZWN0dXJhbCBwcm9wZXJ0eSwg YW5kIG9ubHkgcmV2aXNpdGVkIGhhbGYgd2F5IGRvd24gdGhlIGRvY3VtZW50IGluIFNlY3Rpb24g NS4gT25lIHRob3VnaHQgZm9yIHlvdXIgY29uc2lkZXJhdGlvbjogZG9lcyBpdCBtYWtlIHNlbnNl IHRvIG1ha2UgdGhpcyBleHBsaWNpdCBpbiBTZWN0aW9uIDEuMiwgQXJjaGl0ZWN0dXJhbCBPdmVy dmlldywgd2hpY2ggb25seSBkZWZpbmVzIOKAnEFwcGxpY2F0aW9u4oCdLCBvciBhcyBhIGRyaXZl ciBpbg0KIFMxLjE/IEp1c3QgYSB0aG91Z2h0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+R2VuZXJhbDo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogTW9kZWxzIOKAlCB3 YyBzYXlzIHRoZXJlIGFyZSAxOCBpbnN0YW5jZXMgb2Yg4oCcZGF0YSBtb2RlbOKAnSBhbmQgMTMg b2Yg4oCcaW5mb3JtYXRpb24gbW9kZWzigJ0uIFdoaWxlIHRoZXJlIGFyZSBzdGF0ZW1lbnRzIGlu IHRoZSBJbnRybyBsaWtlIOKAnEZ1bmRhbWVudGFsIHRvIHRoZSBJMlJTIGFyZSBjbGVhciBkYXRh IG1vZGVsc+KAnSwgSSB0aGluayB0aGUgdGV4dCB3b3VsZCBiZW5lZml0IGZyb20gYSBjZW50cmFs aXplZCBzbWFsbCBzZW50ZW5jZQ0KIHRoYXQgZXhwbGFpbnMgdGhlIHJlcXVpcmVtZW50cyBmb3Ig aW5mb3JtYXRpb24gYXMgd2VsbCBhcyBkYXRhIG1vZGVscyBmb3IgSTJSUyBtb2R1bGVzIGFuZCBz ZXJ2aWNlcy4gVGhlIGNsb3Nlc3QgaXMgdGhlIDFzdCBzZW50ZW5jZSBvZiBTMy4zLCBwZXJoYXBz LCBidXQgd2hhdOKAmXMgcmVxdWlyZWQ/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLjIuICZuYnNwO0FyY2hpdGVjdHVyYWwgT3ZlcnZp ZXcgKGFuZCBGaWd1cmUgMSk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7SW4gdGhlPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtmaWd1cmUsIENsaWVudHMgQSBhbmQgQiBw cm92aWRlIGFjY2VzcyB0byBhIHNpbmdsZSBhcHBsaWNhdGlvbiwgd2hpbGU8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwO0NsaWVudCBQIHByb3ZpZGVzIGFjY2VzcyB0byBtdWx0aXBs ZSBhcHBsaWNhdGlvbnMuPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDog4oCcQ2xpZW50cyBBIGFuZCBCIHByb3ZpZGUg YWNjZXNzIHRvIGEgc2luZ2xlIGFwcGxpY2F0aW9u4oCdIHRoaXMgY2FuIGJlIGludGVycHJldGVk IGFzIGEgc2luZ2xlIEFwcGxpY2F0aW9uIOKAnFjigJ0gYWNjZXNzaW5nIGJvdGggQ2xpZW50cyBB IGFuZCBCLiBJIHdvdWxkIGFkZCBhIOKAnCwgcmVzcGVjdGl2ZWx54oCdIGZvciBleGFtcGVsIHRv IGRpc2FtYmlndWF0ZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPkNNUDogQWxzbywgdGhlcmUgaXMgbm8gdGV4dCBzcGVjaWZ5aW5nIHdo ZXRoZXIgYW4gYXBwbGljYXRpb24gY2FuIGFjY2VzcyBJMlJTIHNlcnZpY2VzIHZpYSBtb3JlIHRo YW4gb25lIEFnZW50cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjYuNC4xLiAmbmJzcDtSb3V0aW5nIGFuZCBMYWJlbCBJbmZvcm1hdGlv biBCYXNlczxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwO1JvdXRpbmcgZWxlbWVudHMgbWF5IG1haW50YWluIG9uZSBvciBtb3JlIEluZm9ybWF0 aW9uIEJhc2VzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7RXhhbXBsZXMgaW5j bHVkZSBSb3V0aW5nIEluZm9ybWF0aW9uIEJhc2VzIHN1Y2ggYXMgSVB2NC9JUHY2IFVuaWNhc3Q8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO29yIElQdjQvSVB2NiBNdWx0aWNhc3Qu ICZuYnNwO0Fub3RoZXIgc3VjaCBleGFtcGxlIGluY2x1ZGVzIHRoZSBNUExTIExhYmVsPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtJbmZvcm1hdGlvbiBCYXNlcywgcGVyLXBsYXRm b3JtIG9yIHBlci1pbnRlcmZhY2UuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogb3IgcGVyLWNvbnRleHQg KGluc3RlYWQgb2YvaW4gYWRkaXRpb24gdG8gcGVyLWludGVyZmFjZSk/PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj44LiAmbmJzcDtPcGVy YXRpb25hbCBhbmQgTWFuYWdlYWJpbGl0eSBDb25zaWRlcmF0aW9uczwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBNaWdodCBiZSB1 c2VmdWwgdG8gYWRkIHRyYWNlYWJpbGl0eSBvZiBpbnRlcmFjdGlvbnMgb2YgSTJSUyBhcyBhIGNv bnNpZGVyYXRpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGIgY2xhc3M9IiI+Tml0czo8YnIgY2xhc3M9IiI+DQo8L2I+PGJyIGNsYXNzPSIiPg0KQ01QOiBT b21lIG5pdHMsIHNtYWxsIGVkaXRvcmlhbHMsIGFuZCBzdWdnZXN0aW9ucyBmb3IgeW91ciBjb25z aWRlcmF0aW9uczo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQoxLiAmbmJzcDtJbnRyb2R1 Y3Rpb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDtSb3V0ZXJzIHRoYXQgZm9ybSB0aGUgaW50ZXJuZXQgcm91dGluZyBpbmZyYXN0cnVjdHVy ZSBtYWludGFpbiBzdGF0ZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7YXQgdmFy aW91cyBsYXllcnMgb2YgZGV0YWlsIGFuZCBmdW5jdGlvbi4gJm5ic3A7Rm9yIGV4YW1wbGUsIGEg dHlwaWNhbDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+4oCmIFthbmRdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3RvZGF5J3Mg cm91dGVkIG5ldHdvcmtzLiAmbmJzcDtUaGUgSTJSUyBpcyBhIHByb2dyYW1tYXRpYyBhc3luY2hy b25vdXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2ludGVyZmFjZSBmb3IgdHJh bnNmZXJyaW5nIHN0YXRlIGludG8gYW5kIG91dCBvZiB0aGUgaW50ZXJuZXQgcm91dGluZzwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj7igKYgW2FuZF08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7Um91dGluZyBhbmQg U2lnbmFsaW5nOiAmbmJzcDsgVGhpcyBibG9jayByZXByZXNlbnRzIHRoYXQgcG9ydGlvbiBvZiB0 aGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUm91dGluZyBFbGVt ZW50IHRoYXQgaW1wbGVtZW50cyBwYXJ0IG9mIHRoZSBpbnRlcm5ldCByb3V0aW5nPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkNNUDogcy90aGUgaW50ZXJuZXQvdGhlIEludGVybmV0LyAob3IgYW4gaW50ZXJuZXQ/IEkgdGhp bmsgdGhlIG1lYW5pbmcgaXMg4oCcdGhlIEludGVybmV04oCdKTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4xLiAmbmJzcDtEcml2ZXJz IGZvciB0aGUgSTJSUyBBcmNoaXRlY3R1cmU8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtUaGUgSTJSUyBhcmNoaXRlY3R1cmUgZmFjaWxpdGF0 ZXMgb2J0YWluaW5nIGluZm9ybWF0aW9uIGZyb20gdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDtyb3V0ZXIuICZuYnNwO1RoZSBJMlJTIGFyY2hpdGVjdHVyZSBwcm92aWRlcyB0 aGUgYWJpbGl0eSB0byBub3Qgb25seSByZWFkPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDtzcGVjaWZpYyBpbmZvcm1hdGlvbiwgYnV0IGFsc28gdG8gc3Vic2NyaWJlIHRvIHRhcmdl dGVkIGluZm9ybWF0aW9uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtzdHJlYW1z IGFuZCBmaWx0ZXJlZCBhbmQgdGhyZXNob2xkZWQgZXZlbnRzLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IHMvc3Ry ZWFtcyBhbmQgZmlsdGVyZWQgYW5kIHRocmVzaG9sZGVkIGV2ZW50cy9zdHJlYW1zLCBmaWx0ZXJl ZCBldmVudHMsIGFuZCBldmVudHMgc3ViamVjdCB0byBhIHRocmVzaG9sZC88L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuMi4gJm5ic3A7 QXJjaGl0ZWN0dXJhbCBPdmVydmlldzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICogJm5ic3A7QW4gTFNSIHRoYXQgaW1wbGVtZW50cyBSU1ZQLVRFLCBPU1BGLVRFLCBhbmQg UENFUCBhbmQgaGFzIGE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2ZvcndhcmRpbmcgcGxhbmUgYW5kIGFzc29jaWF0ZWQgUklCIE1hbmFnZXIs PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAqICZuYnNwO0Egc2VydmVyIHRoYXQgcnVucyBJU0lTLCBP U1BGLCBCR1AgYW5kIHVzZXMgRm9yQ0VTIHRvIGNvbnRyb2wgYTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVtb3RlIGZvcndhcmRpbmcgcGxh bmUsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBBIFJvdXRpbmcgRWxlbWVudCBtYXkgYmUgbG9jYWxs eSBtYW5hZ2VkLCB3aGV0aGVyIHZpYSBDTEksIFNOTVAsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDsgJm5ic3A7IG9yIE5FVENPTkYuPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogU29tZSBvZiB0aGVz ZSBhY3JvbnltcyByZXF1aXJlIGV4cGFuc2lvbiBvbiBmaXJzdCB1c2UuIFNlZSZuYnNwOzxhIGhy ZWY9Imh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy1zdHlsZS1ndWlkZS9hYmJyZXYuZXhw YW5zaW9uLnR4dCIgY2xhc3M9IiI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLXN0eWxl LWd1aWRlL2FiYnJldi5leHBhbnNpb24udHh0PC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4yLiAmbmJzcDtBcmNoaXRlY3R1cmFs IE92ZXJ2aWV3PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7STJSUyBBZ2VudDogJm5ic3A7IFNlZSB0aGUgZGVmaW5p dGlvbiBpbiZuYnNwO1NlY3Rpb24gMi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7STJSUyBDbGllbnQ6ICZuYnNwOyBTZWUgdGhl IGRlZmluaXRpb24gaW4gU2VjdGlvbiAyLjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IFRoaXMgc2VjdGlvbiBkZXNj cmliZXMgdGhlIGFyY2hpdGVjdHVyYWwgZWxlbWVudHMuIFNlY3Rpb24gMiwgaG93ZXZlciwgZGVm aW5lcyDigJx0ZXJtaW5vbG9neeKAnS4gSSB3b3VsZCBtb3ZlIHRoZSBkZWZpbml0aW9ucyBvZiBh Z2VudCBhbmQgY2xpZW50IHRvIHRoaXMgcGxhY2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtTdGF0aWMgU3lzdGVtIFN0 YXRlOiAmbmJzcDsgQW4gSTJSUyBhZ2VudCBuZWVkcyBhY2Nlc3MgdG8gc3RhdGljIHN0YXRlIG9u PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGEgcm91dGluZyBlbGVt ZW50IGJleW9uZCB3aGF0IGlzIGNvbnRhaW5lZCBpbiB0aGUgcm91dGluZzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBzdWJzeXN0ZW0uICZuYnNwO0FuIGV4YW1wbGUg b2Ygc3VjaCBzdGF0ZSBpcyBzcGVjaWZ5aW5nIHF1ZXVlaW5nPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkNNUDogcy9xdWV1 ZWluZy9xdWV1aW5nLyA/IE5vdCBzdXJlIDotKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJz cDtyZWFkIHNjb3BlOiAmbmJzcDsgVGhlIHNldCBvZiBpbmZvcm1hdGlvbiB3aGljaCB0aGUgSTJS UyBjbGllbnQgaXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYXV0 aG9yaXplZCB0byByZWFkLiAmbmJzcDtUaGUgcmVhZCBzY29wZSBzcGVjaWZpZXMgdGhlIGFjY2Vz czwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5DTVA6IHMvd2hpY2gvdGhhdC88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5i c3A7bm90IHlldCBhdmFpbGFibGUuICZuYnNwO0luc3RlYWQsIGVhY2ggcm91dGVyIHVzZXMgZGlm ZmVyZW50IGluZm9ybWF0aW9uLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ZGlm ZmVyZW50IG1lY2hhbmlzbXMsIGFuZCBkaWZmZXJlbnQgQ0xJIHdoaWNoIG1ha2VzIGEgc3RhbmRh cmQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2ludGVyZmFjZSBmb3IgdXNlIGJ5 IGFwcGxpY2F0aW9ucyBleHRyZW1lbHkgY3VtYmVyc29tZSB0byBkZXZlbG9wIGFuZDwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7bWFpbnRhaW4uPC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnMvd2hpY2gvLCBh bGwgb2Ygd2hpY2gvPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4mbmJzcDsmbmJzcDtUaGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 aWRlbnRpdHkgd2l0aGluJm5ic3A7TkFDTSBbUkZDNjUzNl0gY2FuIGJlIHNwZWNpZnkgYXMgZWl0 aGVyIGEgdXNlciBuYW1lPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO29yIGEgZ3JvdXAgdXNl ciZuYnNwO25hbWUgKGUuZy4mbmJzcDsmbmJzcDtSb290KSwgYW5kIHRoaXMgbmFtZSBpcyZuYnNw O2xpbmtlZCBhIHNjb3BlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3BvbGljeSZuYnNwO3Ro YXQgY29udGFpbmVkIGluIGEgYSBzZXQgb2YgYWNjZXNzIGNvbnRyb2wgcnVsZXMuPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IER1 cGxpY2F0ZSDigJxh4oCdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7c2NvcGUmbmJzcDtwb2xpY3kuJm5ic3A7Jm5i c3A7TXVsdGlwbGUgaWRlbnRpdGllcyBtYXkgbGluayB0byZuYnNwO3RoZSBzYW1lIHJvbGUgKGUu ZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthYmlsaXR5IHRvIHJlYWQmbmJzcDtJMlJTIFJJ QikuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5DTVA6IHMvZS5nL2UuZy4sLzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ni40LjUuMS4gJm5ic3A7TWFuYWdpbmcgVmFyaWF0aW9u OiBPYmplY3QgQ2xhc3Nlcy9UeXBlcyBhbmQgSW5oZXJpdGFuY2U8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4m bmJzcDsgQ2xpZW50cyB3aGljaCBvbmx5IHdhbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwO2Jhc2ljIGNhcGFiaWxpdGllcyBjYW4gb3BlcmF0ZSBwdXJlbHkgaW4gdGVybXMgb2Yg YmFzZSBvciBwYXJlbnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2NsYXNzZXMs IHdoaWxlIGEgY2xpZW50IG5lZWRpbmcgbW9yZSBkZXRhaWxzIG9yIGZlYXR1cmVzIGNhbiB3b3Jr PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDt3aXRoIHRoZSBzdXBwb3J0ZWQgc3Vi LWNsYXNzKGVzKS48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q01QOiBzL3doaWNoL3RoYXQvPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj43LjQuJm5ic3A7Jm5ic3A7 U2NvcGUgUG9saWN5Jm5ic3A7U3BlY2lmaWNhdGlvbnM8YnIgY2xhc3M9IiI+DQombmJzcDs8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7QXMgc2VjdGlvbiA0LjEmbmJzcDthbmQgNC4yIGRlc2Ny aWJlLCBlYWNoIEkyUlMgQ2xpZW50IHdpbGwgaGF2ZSBhIHVuaXF1ZTxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtpZGVudGl0eSBhbmQgaXQmbmJzcDttYXkgaGF2ZSBhIHNlY29uZGFyeSBpZGVu dGl0eSAoc2VlIHNlY3Rpb24gMikgdG8gYWlkPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO2lu Jm5ic3A7dHJvdWJsZXNob290aW5nLiZuYnNwOyZuYnNwO0FzIHNlY3Rpb24gNCBpbmRpY2F0ZXMs Jm5ic3A7YWxsIGF1dGhlbnRpY2F0aW9uIGFuZDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDth dXRob3JpemF0aW9uJm5ic3A7bWVjaGFuaXNtcyBhcmUgYmFzZWQgb24gdGhlIHByaW1hcnkgSWRl bnRpdHkgd2hpY2g8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7bGlua3MgdG8gYSByb2xlJm5i c3A7d2l0aCBzY29wZSBwb2xpY3kgZm9yIGZvciByZWFkaW5nIGRhdGEsIGZvciB3cml0aW5nPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5D TVA6IER1cGxpY2F0ZSDigJxmb3LigJ08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdlbmVyYWw6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DTVA6IHMvZGF0YS1tb2RlbC9kYXRh IG1vZGVsL2cgKHVubGVzcyB1c2VkIGFzIGFuIGFkamVjdGl2ZSA6LSk8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlCBDYXJsb3MuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_184B72FD2B4A4BBA956B54AC32431C4Cciscocom_-- From nobody Fri Jun 5 12:31:56 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F71F1A882D; Fri, 5 Jun 2015 12:31:55 -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 kQSL4_a3eMUe; Fri, 5 Jun 2015 12:31:52 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 45F471A8826; Fri, 5 Jun 2015 12:31:52 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Carlos Pignataro \(cpignata\)'" , References: <184B72FD-2B4A-4BBA-956B-54AC32431C4C@cisco.com> In-Reply-To: <184B72FD-2B4A-4BBA-956B-54AC32431C4C@cisco.com> Date: Fri, 5 Jun 2015 15:32:00 -0400 Message-ID: <032e01d09fc6$4b3e00c0$e1ba0240$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_032F_01D09FA4.C4327B40" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFgbWH5K+IAX7OmT6kEtpmv8PdHNZ5+sakg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-architecture.all@tools.ietf.org, rtg-dir@ietf.org, i2rs@ietf.org Subject: Re: [i2rs] RtgDir review: draft-ietf-i2rs-architecture-09 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, 05 Jun 2015 19:31:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_032F_01D09FA4.C4327B40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Carlos:=20 =20 Let me review these minor comments. I will send you a response and = diffs for an updated architecture documents.=20 =20 Sue=20 =20 From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]=20 Sent: Friday, June 05, 2015 3:28 PM To: rtg-ads@tools.ietf.org Cc: rtg-dir@ietf.org; draft-ietf-i2rs-architecture.all@tools.ietf.org; = i2rs@ietf.org Subject: RtgDir review: draft-ietf-i2rs-architecture-09 =20 Hello, I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = =E2=80=8Bhttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. Document: draft-ietf-i2rs-architecture-09=20 Reviewer: Carlos Pignataro=20 Review Date: June 5, 2015=20 Intended Status: Informational Summary: =E2=80=A2 I have some *minor* concerns about this document that I think = should be resolved before publication. Comments: This is an extremely well written document that describes the basic = architecture, modules, and interfaces for interfacing with the routing = system. Its status targets Informational. idnits reports no real nits, = only some noise.=20 =20 Thank you for this document!!! I hope you find these comments useful. Major Issues: None.=20 Minor Issues: An Architecture for the Interface to the Routing System =E2=80=A6 Abstract This document describes an architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. CMP: Is this =E2=80=9Can architecture=E2=80=9D, and there are other = architectures for the I2RS? I have no issues with =E2=80=9Can = architecture=E2=80=9D, but it invites these questions, including = =E2=80=98is there an authoritative architecture, and is it this one? = =E2=80=9CThe IETF defined architecture=E2=80=9D? How about removing the = =E2=80=9CAn=E2=80=9D from the title, and qualifying the Abstract and = Intro with =E2=80=9Cas specified in the IETF=E2=80=9D? 1. Introduction=20 =20 Network-oriented applications require easy access to this information=20 =20 CMP: The concept of a =E2=80=9Cnetwork-oriented application=E2=80=9D is = a super important piece of the whole picture. While the applications are = outside the scope of the architecture itself, the network-orientedness = nature is a key driver, unacknowledged as a key architectural property, = and only revisited half way down the document in Section 5. One thought = for your consideration: does it make sense to make this explicit in = Section 1.2, Architectural Overview, which only defines = =E2=80=9CApplication=E2=80=9D, or as a driver in S1.1? Just a thought. =20 General: =20 CMP: Models =E2=80=94 wc says there are 18 instances of =E2=80=9Cdata = model=E2=80=9D and 13 of =E2=80=9Cinformation model=E2=80=9D. While = there are statements in the Intro like =E2=80=9CFundamental to the I2RS = are clear data models=E2=80=9D, I think the text would benefit from a = centralized small sentence that explains the requirements for = information as well as data models for I2RS modules and services. The = closest is the 1st sentence of S3.3, perhaps, but what=E2=80=99s = required? =20 1.2. Architectural Overview (and Figure 1) =20 In the figure, Clients A and B provide access to a single application, while Client P provides access to multiple applications. =20 CMP: =E2=80=9CClients A and B provide access to a single = application=E2=80=9D this can be interpreted as a single Application = =E2=80=9CX=E2=80=9D accessing both Clients A and B. I would add a = =E2=80=9C, respectively=E2=80=9D for exampel to disambiguate. =20 CMP: Also, there is no text specifying whether an application can access = I2RS services via more than one Agents. =20 6.4.1. Routing and Label Information Bases Routing elements may maintain one or more Information Bases. Examples include Routing Information Bases such as IPv4/IPv6 Unicast or IPv4/IPv6 Multicast. Another such example includes the MPLS Label Information Bases, per-platform or per-interface.=20 =20 CMP: or per-context (instead of/in addition to per-interface)? =20 8. Operational and Manageability Considerations =20 CMP: Might be useful to add traceability of interactions of I2RS as a = consideration. =20 Nits: CMP: Some nits, small editorials, and suggestions for your = considerations: 1. Introduction Routers that form the internet routing infrastructure maintain state at various layers of detail and function. For example, a typical =20 =E2=80=A6 [and] =20 today's routed networks. The I2RS is a programmatic asynchronous interface for transferring state into and out of the internet routing =20 =E2=80=A6 [and] =20 Routing and Signaling: This block represents that portion of the Routing Element that implements part of the internet routing =20 CMP: s/the internet/the Internet/ (or an internet? I think the meaning = is =E2=80=9Cthe Internet=E2=80=9D) =20 1.1. Drivers for the I2RS Architecture The I2RS architecture facilitates obtaining information from the router. The I2RS architecture provides the ability to not only read specific information, but also to subscribe to targeted information streams and filtered and thresholded events. =20 CMP: s/streams and filtered and thresholded events/streams, filtered = events, and events subject to a threshold/ =20 1.2. Architectural Overview =20 * An LSR that implements RSVP-TE, OSPF-TE, and PCEP and has a forwarding plane and associated RIB Manager, =20 * A server that runs ISIS, OSPF, BGP and uses ForCES to control a remote forwarding plane, =20 A Routing Element may be locally managed, whether via CLI, SNMP, or NETCONF. =20 CMP: Some of these acronyms require expansion on first use. See = https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt =20 1.2. Architectural Overview =20 I2RS Agent: See the definition in Section 2. =20 I2RS Client: See the definition in Section 2. =20 CMP: This section describes the architectural elements. Section 2, = however, defines =E2=80=9Cterminology=E2=80=9D. I would move the = definitions of agent and client to this place. =20 =20 Static System State: An I2RS agent needs access to static state on a routing element beyond what is contained in the routing subsystem. An example of such state is specifying queueing =20 CMP: s/queueing/queuing/ ? Not sure :-) =20 read scope: The set of information which the I2RS client is authorized to read. The read scope specifies the access =20 CMP: s/which/that/ =20 not yet available. Instead, each router uses different information, different mechanisms, and different CLI which makes a standard interface for use by applications extremely cumbersome to develop and maintain. =20 s/which/, all of which/ =20 The identity within NACM [RFC6536] can be specify 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 a set of access control rules. =20 CMP: Duplicate =E2=80=9Ca=E2=80=9D =20 scope policy. Multiple identities may link to the same role (e.g ability to read I2RS RIB). =20 CMP: s/e.g/e.g.,/ =20 6.4.5.1. Managing Variation: Object Classes/Types and Inheritance =20 Clients which only want basic capabilities can operate purely in terms of base or parent classes, while a client needing more details or features can work with the supported sub-class(es). =20 CMP: s/which/that/ =20 7.4. Scope Policy Specifications =20 As section 4.1 and 4.2 describe, each I2RS Client will have a unique identity and it may have a secondary identity (see section 2) to aid in troubleshooting. As section 4 indicates, all authentication and authorization mechanisms are based on the primary Identity which links to a role with scope policy for for reading data, for writing =20 CMP: Duplicate =E2=80=9Cfor=E2=80=9D =20 General: =20 CMP: s/data-model/data model/g (unless used as an adjective :-) =20 =E2=80=94 Carlos. =20 =20 ------=_NextPart_000_032F_01D09FA4.C4327B40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Carlos:

 

Let me review these minor comments.=C2=A0 I will send you a response = and diffs for an updated architecture documents. =

 

Sue

 

From:= = Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: = Friday, June 05, 2015 3:28 PM
To: = rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; = draft-ietf-i2rs-architecture.all@tools.ietf.org; = i2rs@ietf.org
Subject: RtgDir review: = draft-ietf-i2rs-architecture-09

 

Hello,

I have been selected as the Routing = Directorate reviewer for this draft. The Routing Directorate seeks to = review all routing or routing-related drafts as they pass through = IETF last call and IESG review, and sometimes on special request. = The purpose of the review is to provide assistance to the Routing ADs. = For more information about the Routing Directorate, please see = =E2=80=8Bhttp://trac= .tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these = comments are primarily for the use of the Routing ADs, it would be = helpful if you could consider them along with any other IETF Last Call = comments that you receive, and strive to resolve them through = discussion or by updating the draft.

Document: = draft-ietf-i2rs-architecture-09 
Reviewer: Carlos = Pignataro 
Review Date: June 5, 2015 
Intended Status: = Informational

Summary:

=E2=80=A2 I have some = *minor* concerns about this document that I think should be resolved = before publication.

Comments:

This is an extremely = well written document that describes the basic architecture, modules, = and interfaces for interfacing with the routing system. Its status = targets Informational. idnits reports no real nits, only some noise. =

 

Thank you for this document!!! I hope you find these = comments useful.

Major Issues:

None. =


Minor = Issues:

An Architecture for the Interface to the Routing = System
=E2=80=A6
Abstract

   This document = describes an architecture for a standard, programmatic
  =  interface for state transfer in and out of the Internet = routing
   system.

CMP: Is this =E2=80=9Can = architecture=E2=80=9D, and there are other architectures for the I2RS? I = have no issues with =E2=80=9Can architecture=E2=80=9D, but it invites = these questions, including =E2=80=98is there an authoritative = architecture, and is it this one? =E2=80=9CThe IETF defined = architecture=E2=80=9D? How about removing the =E2=80=9CAn=E2=80=9D from = the title, and qualifying the Abstract and Intro with =E2=80=9Cas = specified in the IETF=E2=80=9D?

1.  Introduction =

 

   Network-oriented applications = require

   easy = access to this information 

 

CMP: The concept of a =E2=80=9Cnetwork-oriented = application=E2=80=9D is a super important piece of the whole picture. = While the applications are outside the scope of the architecture itself, = the network-orientedness nature is a key driver, unacknowledged as a key = architectural property, and only revisited half way down the document in = Section 5. One thought for your consideration: does it make sense to = make this explicit in Section 1.2, Architectural Overview, which only = defines =E2=80=9CApplication=E2=80=9D, or as a driver in S1.1? Just a = thought.

 

General:

 

CMP: Models =E2=80=94 wc says there are 18 instances = of =E2=80=9Cdata model=E2=80=9D and 13 of =E2=80=9Cinformation = model=E2=80=9D. While there are statements in the Intro like = =E2=80=9CFundamental to the I2RS are clear data models=E2=80=9D, I think = the text would benefit from a centralized small sentence that explains = the requirements for information as well as data models for I2RS modules = and services. The closest is the 1st sentence of S3.3, perhaps, but = what=E2=80=99s required?

 

1.2.  Architectural Overview (and Figure = 1)

 

   In the

   figure, Clients A and B provide access to = a single application, while

   Client P provides access to multiple = applications.

 

CMP: =E2=80=9CClients A and B provide access to a = single application=E2=80=9D this can be interpreted as a single = Application =E2=80=9CX=E2=80=9D accessing both Clients A and B. I would = add a =E2=80=9C, respectively=E2=80=9D for exampel to = disambiguate.

 

CMP: Also, there is no text specifying whether an = application can access I2RS services via more than one = Agents.

 

6.4.1.  Routing and Label = Information Bases

  =  Routing elements may maintain one or more Information = Bases.

  =  Examples include Routing Information Bases such as IPv4/IPv6 = Unicast

   or = IPv4/IPv6 Multicast.  Another such example includes the MPLS = Label

  =  Information Bases, per-platform or = per-interface. 

 

CMP: or per-context (instead of/in addition to = per-interface)?

 

8.  Operational and Manageability = Considerations

 

CMP: Might be useful to add traceability of = interactions of I2RS as a consideration.

 

Nits:

CMP: Some nits, small = editorials, and suggestions for your considerations:

1. =  Introduction

  =  Routers that form the internet routing infrastructure maintain = state

   at = various layers of detail and function.  For example, a = typical

 

=E2=80=A6 [and]

 

   today's routed networks.  The I2RS = is a programmatic asynchronous

   interface for transferring state into and = out of the internet routing

 

=E2=80=A6 [and]

 

   Routing and Signaling:   This block = represents that portion of the

      Routing Element that implements = part of the internet routing

 

CMP: s/the internet/the Internet/ (or an internet? I = think the meaning is =E2=80=9Cthe = Internet=E2=80=9D)

 

1.1.  Drivers for the I2RS = Architecture

   The = I2RS architecture facilitates obtaining information from = the

   router. =  The I2RS architecture provides the ability to not only = read

   specific = information, but also to subscribe to targeted = information

  =  streams and filtered and thresholded = events.

 

CMP: s/streams and filtered and thresholded = events/streams, filtered events, and events subject to a = threshold/

 

1.2.  Architectural = Overview

 

      *  An LSR that implements = RSVP-TE, OSPF-TE, and PCEP and has a

         forwarding plane and = associated RIB Manager,

 

      *  A server that runs ISIS, = OSPF, BGP and uses ForCES to control a

         remote forwarding = plane,

 

      A Routing Element may be locally = managed, whether via CLI, SNMP,

      or = NETCONF.

 

CMP: Some of these acronyms require expansion on first = use. See = https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt<= /o:p>

 

1.2.  Architectural = Overview

 

   I2RS Agent:   See the definition = in Section 2.

 

  =  I2RS Client:   See the definition in Section = 2.

 

CMP: This section describes the architectural = elements. Section 2, however, defines =E2=80=9Cterminology=E2=80=9D. I = would move the definitions of agent and client to this = place.

 

 

   Static System State:   An I2RS agent = needs access to static state on

      a routing element beyond what is = contained in the routing

      subsystem.  An example of = such state is specifying queueing

 

CMP: s/queueing/queuing/ ? Not sure = :-)

 

   read scope:   The set of information = which the I2RS client is

      authorized to read.  The = read scope specifies the access

 

CMP: s/which/that/

 

   not yet available.  Instead, each = router uses different information,

   different mechanisms, and different CLI = which makes a standard

   interface for use by applications = extremely cumbersome to develop and

  =  maintain.

 

s/which/, all of which/

 

  The
   identity = within NACM [RFC6536] can be specify 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 a set of access control = rules.

 

CMP: Duplicate = =E2=80=9Ca=E2=80=9D

 

   scope policy.  Multiple = identities may link to the same role (e.g
   ability = to read I2RS RIB).

 

CMP: s/e.g/e.g.,/

 

6.4.5.1.  Managing Variation: Object = Classes/Types and Inheritance

 

  Clients which only = want

   basic = capabilities can operate purely in terms of base or = parent

  =  classes, while a client needing more details or features can = work

   with the = supported sub-class(es).

 

CMP: s/which/that/

 

7.4.  Scope = Policy Specifications
 
   As section = 4.1 and 4.2 describe, each I2RS Client will have a unique
  =  identity and it may have a secondary identity (see section 2) = to aid
   in troubleshooting.  As section 4 = indicates, all authentication and
  =  authorization mechanisms are based on the primary Identity = which
   links to a role with scope policy for for = reading data, for writing

 

CMP: Duplicate = =E2=80=9Cfor=E2=80=9D

 

General:

 

CMP: s/data-model/data model/g (unless used as an = adjective :-)

 

=E2=80=94 Carlos.

 

 

------=_NextPart_000_032F_01D09FA4.C4327B40-- From nobody Fri Jun 5 12:43: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 6F9AB1A913A; Fri, 5 Jun 2015 12:43:40 -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_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 WEMAHiKfPX_e; Fri, 5 Jun 2015 12:43:38 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF541A9134; Fri, 5 Jun 2015 12:43:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.80.157; From: "Susan Hares" To: "'Andy Bierman'" , "'Joel M. Halpern'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> In-Reply-To: Date: Fri, 5 Jun 2015 15:43:42 -0400 Message-ID: <035401d09fc7$ee49b2e0$cadd18a0$@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: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fgJ/cqsgAc7vEHiebr+34A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 05 Jun 2015 19:43:40 -0000 Andy and Joel:=20 As my chair note stated, the chairs know they are providing extra = details with the requirements. However, in the past the feedback from = various NETMOD/NETCONF participants has been not enough detail. The use = of NACM to control input to a I2RS agent and assign priority to a client = - is one of those extra info. I believe the tight notification = guarantees to support a I2RS control loop is a requirement rather than = extra suggestions.=20 Hopefully, that the NETMOD/NETCONF chairs will review through the = initial ephemeral state document and describe what they feel is = requirements versus added suggestions. The I2RS chairs will clean-up = that requirements document next week.=20 Sue=20 -----Original Message----- From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, June 05, 2015 12:38 PM To: Joel M. Halpern Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; Alia = Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern = wrote: > I would describe it somewhat differently from any of the choices you = list. > > A) I2RS has some a set of architectural requirements. These were not=20 > as cleanly described as one might like but they were very clearly=20 > accepted by the working group and understood to be needed for the = protocol choice. > B) The working group has decided that it will use NetConf/RestConf if=20 > that can meet the requirements. > I would say the arch is a mixture of architecture and functional = requirements. Almost as if the authors had a design in mind and reverse-engineered the = requirements from the design. As Juergen pointed out, the requirement to assign a priority to a client = does not require NACM. NACM is a design choice for that requirement. I have some concerns about the tight notification control loop that is = proposed. IMO, this is going to be too slow and too complicated. It = seems to me that the only company that has implemented something close = to I2RS is using a design that does not rely on a near real-time = reliable notification loop. I don't have a strong preference for ephemeral datastore vs. tagging = non-config data. The current NETCONF datastores only apply to = config=3Dtrue objects. YANG design allows for the config=3Dfalse data = to be further partitioned, but this is not required for I2RS to work. > The corrolary is that if neither NetConf nor RestConf can meet the=20 > requirements, then the working group will, in my opinion, have to do=20 > something else. That would be OK too, if you want to completely decouple I2RS from configuration. This simplifies some things if was invisible to NETCONF/RESTCONF and YANG. > > Yours, > Joel Andy > > On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >> >> On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >>> >>> Juergen: >>> >>> I understand your technical point on being concerned about >>> >>> "solutions that require (i) separate data models for ephemeral state = >>> and >>> (ii) data model specific merge logic. While this may work for I2RS,=20 >>> this approach does not scale or has a very high cost of scaling to=20 >>> other ephemeral state editing needs." >>> >>> If you have full overlay model proposal, we would be glad to receive = it. >>> However, no one else has proposed a full overlay model. >> >> >> Frankly, there is no full alternate proposal either. The overlay=20 >> model has been discussed at quite some detail at a NETMOD interim. I=20 >> am happy to point at the meeting minutes. The question perhaps really = >> is whether (a) I2RS has requirements to be addresses and=20 >> NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a=20 >> solution into stone to be run through the NETCONF working group or=20 >> whether (c) creates a solution on its own independently of any other=20 >> NETMOD/NETCONF requirements. >> >>> Other answers are below. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder=20 >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, June 04, 2015 2:24 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern';=20 >>> i2rs-chairs@ietf.org; 'Alia Atlas' >>> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >>> >>> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>>> >>>> The minutes for the I2RS meeting are at: >>>> >>>> >>>> >>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in >>>> ter >>>> im-201 >>>> 5-i2rs-8 >>>> >>>> >>>> >>>> These minute provide a lengthy of issues in the requirements. From = >>>> these minutes, there are the following 6 conclusions on the=20 >>>> protocol requirements that Jeff stated: >>>> >>>> >>>> >>>> 1) There will be no consideration of an overlay model unless a >>>> fully >>>> formed proposal is presented. >>>> >>>> Jeff and I appreciate Ken Watsen's comments on the list, but we=20 >>>> have had lots of suggestions regarding an overlay proposal - but no = >>>> full proposal. At this time, the WG will only consider full=20 >>>> proposals and not suggestions toward a proposal. >>> >>> >>> For the record: I am highly concerned about solutions that require=20 >>> (i) separate data models for ephemeral state and (ii) data model=20 >>> specific merge logic. While this may work for I2RS, this approach=20 >>> does not scale or has a very high cost of scaling to other ephemeral = >>> state editing needs. >>> >>>> 2) Jeff's document provides details on ephemeral state = requirements >>>> that have not changed. These requirements include: >>>> >>>> a. Highly reliable notifications (but not perfectly reliable >>>> notifications) >>>> >>>> b. High bandwidth, asynchronous interface, with real-time >>>> guarantees >>> >>> on >>>> >>>> getting data, >>>> >>>> c. Node identification of clients that write by client = identity, >>>> secondary identity, and priority. Data models will determine what=20 >>>> is the "node" unit. For example, the I2RS RIB node unit is the = route. >>> >>> >>> I am concerned about adding protocol mechanisms that are specific to = >>> a certain data model. It is unclear what a "node" unit it, terms=20 >>> like 'highly reliable notifications' and 'high bandwidth,=20 >>> asynchronous interface, with real-time guarantees' are somewhat=20 >>> unclear - how do we determine we have met any of these requirements? >> >> >> Apparently no answer here... >> >>>> d. There is one priority per client. >>>> >>>> e. Priority is kept in the NACM at the client level [rather = than >>>> path >>>> level (5/27 meeting) or group level (list discussion). >>> >>> >>> Why does this mapping of username to priority have to be maintained=20 >>> in NACM? >> >> >> Apparently no answer here... >> >>>> 3) Joel suggests that large data write may be best done in = netconf >>> >>> with >>>> >>>> guarantees >>>> >>>> a. I2RS will be focused on highly asynchronous interfaces = with >>>> less >>>> than full routing tables. >>>> >>>> b. A client whose large data is interrupted by a notification = has a >>>> difficult time determine when the notification happened in the=20 >>>> stream >>>> - so the I2RS client must ask the agent again. >>>> >>>> c. Logging for traceability is different than event = notification. >>> >>> >>> Except c), I do not understand this. What are these 'guarantees' 3)=20 >>> is about? >>> >>> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may = >>> receive a change notification for one of the routes while the rest=20 >>> of the stream is in progress. If the change notification does not=20 >>> include the data, the I2RS client must poll the I2RS agent to=20 >>> determine if the route change notification occurred before or after=20 >>> that route's data was sent. >>> Change notifications are reliable, but not perfectly reliable. =20 >>> Logging is different than change notifications as logging for=20 >>> tracing includes all change data reliably. >> >> >> I am still confused what the requirement here is. >> >>>> 5) Secondary identity data is read-only meta-data that is = stored in >>> >>> the >>>> >>>> agent associated with a data model node that is being created or=20 >>>> updated (write-access) in the data store. >>> >>> >>> Ehem, what is read-only data that is created or written? Did you=20 >>> want to say that the identity meta-data is immutable once a data=20 >>> node has been created? >>> And if so, has priority the same property: Is priority of a data=20 >>> node is determined at creation time and then immutable? >>> >>> [sue]: Secondary identity data is read-only meta-data that is only=20 >>> changed when created or written. It is immutable unless the whole=20 >>> node is changed. >>> Priority is linked to I2RS client. Priority remains unchanged with=20 >>> the identity of the client. >> >> >> You can't ever change the priority of a client? I doubt this is=20 >> practical. >> >>> Priority of an entry (route1 from client-1, priority2) remains=20 >>> immutable with the writing of this entry from this client. If a new = >>> client (route-1 from client-2, pririty3), then the node and the=20 >>> meta-data changes. >> >> >> So I understand the priority is determined at write time but then=20 >> sticking until the next write. Or in other words, to change the=20 >> priority I have to write the data again using a client with a=20 >> different priority (or using the same client in case priority of a=20 >> client turns out to be configurable). >> >>>> 6) I2RS Client and Agent Identities are mutually authenticated = by >>>> Authentication server (AAA), >>>> >>>> The values of identities are originally set by operators. >>>> >>> I am not sure how agent identity authentication via AAA works. Can=20 >>> someone point me to the right direction if I assume a secure=20 >>> transport such as SSH or TLS? >>> >>> The identities used in SSH are passed via AAA (diameter or radius). = >>> The identities are not standardized but sent in AAA (diameter or=20 >>> radius) messages based on operator assignment. >> >> >> I know how I can pass the client identity via AAA using SSH, I like=20 >> to see an explanation how that is supposed to work for server=20 >> identities (and which operational problem that solves). >> >> /js >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Jun 5 15:56: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 AFC8A1A89A7; Fri, 5 Jun 2015 15:56:27 -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 iG5paL5TJWon; Fri, 5 Jun 2015 15:56:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8984E1A89B5; Fri, 5 Jun 2015 15:56:25 -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.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150605225625.10608.85742.idtracker@ietfa.amsl.com> Date: Fri, 05 Jun 2015 15:56:25 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-network-topo-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: Fri, 05 Jun 2015 22:56:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : A Data Model for Network Topologies Authors : Alexander Clemm Jan Medved Robert Varga Tony Tkacik Nitin Bahadur Hariharan Ananthakrishnan Filename : draft-ietf-i2rs-yang-network-topo-01.txt Pages : 26 Date : 2015-06-05 Abstract: This document defines an abstract (generic) YANG data model for network/service topologies and inventories. The model serves as a base model which is augmented with technology-specific details in other, more specific topology and inventory models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-network-topo-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-network-topo-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 Fri Jun 5 19:28: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 3FC721A8F49 for ; Fri, 5 Jun 2015 19:28:22 -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_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 2Gh5Fcyt3nje for ; Fri, 5 Jun 2015 19:28:19 -0700 (PDT) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (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 9EC201A9025 for ; Fri, 5 Jun 2015 19:28:18 -0700 (PDT) Received: by labpy14 with SMTP id py14so65380216lab.0 for ; Fri, 05 Jun 2015 19:28:17 -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=SVKxpS41179zAKzDlzTvybvn2+WF5IUVUV1jzB6tGOA=; b=brgmIq7yfEUWGmHc15126GK5/7Gh5ZmvA8bU4hQ5cApySWEBhKFaRPzLHy417e68lw X1sqC33q9pzxtjYG8XVxd0D7FRIrdqMiBZjPsiaYQrA2DpS5PfzioCAGqesm5Kmi1/UC tMxEnxxN0mUWB9TbV/VArQNfSYUyTqNQi69nMoCeubwctUZgIBP1ahBEXqVCa+soo1mm IcfhJaH9wFZE9sgFm1quVu3UQeOlEC4EZX8Uw0sQmQpdt230fryO2uceJFu4mymWsLlC VDLW5IMQ7q46y+QRv9BW4I+VITjk2lVqu3UDgkHXKz/E1mRDn5RgeTst44YgsmZ0JzFA rOYw== X-Gm-Message-State: ALoCoQkZgjRzY/hWNoovI/PVVLh6ADZinConjjZYnDrHYZW05JHmIQgPXd5Wq3KhUv2pjpJGxDlj MIME-Version: 1.0 X-Received: by 10.112.124.71 with SMTP id mg7mr6056672lbb.38.1433557696999; Fri, 05 Jun 2015 19:28:16 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 5 Jun 2015 19:28:16 -0700 (PDT) In-Reply-To: <035401d09fc7$ee49b2e0$cadd18a0$@ndzh.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> <035401d09fc7$ee49b2e0$cadd18a0$@ndzh.com> Date: Fri, 5 Jun 2015 19:28:16 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , i2rs-chairs@ietf.org, Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Sat, 06 Jun 2015 02:28:22 -0000 Hi, IMO NETCONF notifications are probably not the best choice for the high-performance low-latency signalling that I2RS wants between agent and client. There is a lot of overhead in the filtering, replay, YANG schema processing, XML encoding, etc. Binary notifications that contain hard-wired standard messages specially written to implement the I2RS protocol would be much faster and less expensive to implement. If this is to be as fast as a signalling protocol then it would be wise to consider protocol performance issues. Andy On Fri, Jun 5, 2015 at 12:43 PM, Susan Hares wrote: > Andy and Joel: > > As my chair note stated, the chairs know they are providing extra details= with the requirements. However, in the past the feedback from various NET= MOD/NETCONF participants has been not enough detail. The use of NACM to co= ntrol input to a I2RS agent and assign priority to a client - is one of tho= se extra info. I believe the tight notification guarantees to support a I2= RS control loop is a requirement rather than extra suggestions. > > Hopefully, that the NETMOD/NETCONF chairs will review through the initial= ephemeral state document and describe what they feel is requirements versu= s added suggestions. The I2RS chairs will clean-up that requirements docu= ment next week. > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, June 05, 2015 12:38 PM > To: Joel M. Halpern > Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; Alia = Atlas > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern wro= te: >> I would describe it somewhat differently from any of the choices you lis= t. >> >> A) I2RS has some a set of architectural requirements. These were not >> as cleanly described as one might like but they were very clearly >> accepted by the working group and understood to be needed for the protoc= ol choice. >> B) The working group has decided that it will use NetConf/RestConf if >> that can meet the requirements. >> > > I would say the arch is a mixture of architecture and functional requirem= ents. > Almost as if the authors had a design in mind and reverse-engineered the = requirements from the design. > > As Juergen pointed out, the requirement to assign a priority to a client = does not require NACM. NACM is a design choice for that requirement. > > I have some concerns about the tight notification control loop that is pr= oposed. IMO, this is going to be too slow and too complicated. It seems t= o me that the only company that has implemented something close to I2RS is = using a design that does not rely on a near real-time reliable notification= loop. > > I don't have a strong preference for ephemeral datastore vs. tagging non-= config data. The current NETCONF datastores only apply to config=3Dtrue ob= jects. YANG design allows for the config=3Dfalse data to be further partit= ioned, but this is not required for I2RS to work. > > >> The corrolary is that if neither NetConf nor RestConf can meet the >> requirements, then the working group will, in my opinion, have to do >> something else. > > That would be OK too, if you want to completely > decouple I2RS from configuration. This simplifies some > things if was invisible to NETCONF/RESTCONF and YANG. > > >> >> Yours, >> Joel > > Andy > >> >> On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >>> >>> On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >>>> >>>> Juergen: >>>> >>>> I understand your technical point on being concerned about >>>> >>>> "solutions that require (i) separate data models for ephemeral state >>>> and >>>> (ii) data model specific merge logic. While this may work for I2RS, >>>> this approach does not scale or has a very high cost of scaling to >>>> other ephemeral state editing needs." >>>> >>>> If you have full overlay model proposal, we would be glad to receive i= t. >>>> However, no one else has proposed a full overlay model. >>> >>> >>> Frankly, there is no full alternate proposal either. The overlay >>> model has been discussed at quite some detail at a NETMOD interim. I >>> am happy to point at the meeting minutes. The question perhaps really >>> is whether (a) I2RS has requirements to be addresses and >>> NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a >>> solution into stone to be run through the NETCONF working group or >>> whether (c) creates a solution on its own independently of any other >>> NETMOD/NETCONF requirements. >>> >>>> Other answers are below. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, June 04, 2015 2:24 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; >>>> i2rs-chairs@ietf.org; 'Alia Atlas' >>>> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >>>> >>>> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>>>> >>>>> The minutes for the I2RS meeting are at: >>>>> >>>>> >>>>> >>>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in >>>>> ter >>>>> im-201 >>>>> 5-i2rs-8 >>>>> >>>>> >>>>> >>>>> These minute provide a lengthy of issues in the requirements. From >>>>> these minutes, there are the following 6 conclusions on the >>>>> protocol requirements that Jeff stated: >>>>> >>>>> >>>>> >>>>> 1) There will be no consideration of an overlay model unless a >>>>> fully >>>>> formed proposal is presented. >>>>> >>>>> Jeff and I appreciate Ken Watsen's comments on the list, but we >>>>> have had lots of suggestions regarding an overlay proposal - but no >>>>> full proposal. At this time, the WG will only consider full >>>>> proposals and not suggestions toward a proposal. >>>> >>>> >>>> For the record: I am highly concerned about solutions that require >>>> (i) separate data models for ephemeral state and (ii) data model >>>> specific merge logic. While this may work for I2RS, this approach >>>> does not scale or has a very high cost of scaling to other ephemeral >>>> state editing needs. >>>> >>>>> 2) Jeff's document provides details on ephemeral state requireme= nts >>>>> that have not changed. These requirements include: >>>>> >>>>> a. Highly reliable notifications (but not perfectly reliable >>>>> notifications) >>>>> >>>>> b. High bandwidth, asynchronous interface, with real-time >>>>> guarantees >>>> >>>> on >>>>> >>>>> getting data, >>>>> >>>>> c. Node identification of clients that write by client identity= , >>>>> secondary identity, and priority. Data models will determine what >>>>> is the "node" unit. For example, the I2RS RIB node unit is the route= . >>>> >>>> >>>> I am concerned about adding protocol mechanisms that are specific to >>>> a certain data model. It is unclear what a "node" unit it, terms >>>> like 'highly reliable notifications' and 'high bandwidth, >>>> asynchronous interface, with real-time guarantees' are somewhat >>>> unclear - how do we determine we have met any of these requirements? >>> >>> >>> Apparently no answer here... >>> >>>>> d. There is one priority per client. >>>>> >>>>> e. Priority is kept in the NACM at the client level [rather than >>>>> path >>>>> level (5/27 meeting) or group level (list discussion). >>>> >>>> >>>> Why does this mapping of username to priority have to be maintained >>>> in NACM? >>> >>> >>> Apparently no answer here... >>> >>>>> 3) Joel suggests that large data write may be best done in netco= nf >>>> >>>> with >>>>> >>>>> guarantees >>>>> >>>>> a. I2RS will be focused on highly asynchronous interfaces with >>>>> less >>>>> than full routing tables. >>>>> >>>>> b. A client whose large data is interrupted by a notification ha= s a >>>>> difficult time determine when the notification happened in the >>>>> stream >>>>> - so the I2RS client must ask the agent again. >>>>> >>>>> c. Logging for traceability is different than event notificatio= n. >>>> >>>> >>>> Except c), I do not understand this. What are these 'guarantees' 3) >>>> is about? >>>> >>>> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may >>>> receive a change notification for one of the routes while the rest >>>> of the stream is in progress. If the change notification does not >>>> include the data, the I2RS client must poll the I2RS agent to >>>> determine if the route change notification occurred before or after >>>> that route's data was sent. >>>> Change notifications are reliable, but not perfectly reliable. >>>> Logging is different than change notifications as logging for >>>> tracing includes all change data reliably. >>> >>> >>> I am still confused what the requirement here is. >>> >>>>> 5) Secondary identity data is read-only meta-data that is stored= in >>>> >>>> the >>>>> >>>>> agent associated with a data model node that is being created or >>>>> updated (write-access) in the data store. >>>> >>>> >>>> Ehem, what is read-only data that is created or written? Did you >>>> want to say that the identity meta-data is immutable once a data >>>> node has been created? >>>> And if so, has priority the same property: Is priority of a data >>>> node is determined at creation time and then immutable? >>>> >>>> [sue]: Secondary identity data is read-only meta-data that is only >>>> changed when created or written. It is immutable unless the whole >>>> node is changed. >>>> Priority is linked to I2RS client. Priority remains unchanged with >>>> the identity of the client. >>> >>> >>> You can't ever change the priority of a client? I doubt this is >>> practical. >>> >>>> Priority of an entry (route1 from client-1, priority2) remains >>>> immutable with the writing of this entry from this client. If a new >>>> client (route-1 from client-2, pririty3), then the node and the >>>> meta-data changes. >>> >>> >>> So I understand the priority is determined at write time but then >>> sticking until the next write. Or in other words, to change the >>> priority I have to write the data again using a client with a >>> different priority (or using the same client in case priority of a >>> client turns out to be configurable). >>> >>>>> 6) I2RS Client and Agent Identities are mutually authenticated b= y >>>>> Authentication server (AAA), >>>>> >>>>> The values of identities are originally set by operators. >>>>> >>>> I am not sure how agent identity authentication via AAA works. Can >>>> someone point me to the right direction if I assume a secure >>>> transport such as SSH or TLS? >>>> >>>> The identities used in SSH are passed via AAA (diameter or radius). >>>> The identities are not standardized but sent in AAA (diameter or >>>> radius) messages based on operator assignment. >>> >>> >>> I know how I can pass the client identity via AAA using SSH, I like >>> to see an explanation how that is supposed to work for server >>> identities (and which operational problem that solves). >>> >>> /js >>> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > From nobody Sun Jun 7 13:38: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 699401A0037; Sun, 7 Jun 2015 13:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbvVjInKSGhq; Sun, 7 Jun 2015 13:38:38 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA1C1ACDD4; Sun, 7 Jun 2015 13:38:38 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t57KcYWU005678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Jun 2015 16:38:35 -0400 Received: from ATL-SRV-MBX2.advaoptical.com (172.16.5.46) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 7 Jun 2015 16:38:34 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX2.advaoptical.com (172.16.5.46) with Microsoft SMTP Server (TLS) id 15.0.1104.2; Sun, 7 Jun 2015 16:38:33 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1104.000; Sun, 7 Jun 2015 16:38:34 -0400 From: Igor Bryskin To: Andy Bierman , Susan Hares Thread-Topic: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) Thread-Index: AdCeXSaGCIO6ib4/SoSSV0U3LuPcfwAU3tIAABw2coAAIwozgAAAH3EAAAhY+oAABnuLAAAOIRwAAE9OacU= Date: Sun, 7 Jun 2015 20:38:33 +0000 Message-ID: <0c1b9fb2e34f4e2aa82faef4685cae5d@ATL-SRV-MBX1.advaoptical.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> <035401d09fc7$ee49b2e0$cadd18a0$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-07_16:2015-06-05,2015-06-07,1970-01-01 signatures=0 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , "Joel M. Halpern" , "i2rs-chairs@ietf.org" , Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Sun, 07 Jun 2015 20:38:41 -0000 Andy; You are making an excellent point. I totally agree. I also wonder if the sa= me logic applies ( and I'd say much more so) for the opposite direction - w= hen pushing routes real time from I2RS Client to Agent. If Yes, isn't this is what FORCES folks (Jamal especially) have been saying= all along? NETCONF/RESTCONF are great for a lot of stuff, but maybe not so much for I2= RS? What's the point of "raping" NETCONF if: a) it was never designed for architectures like I2RS; b) it's properties do not square (at least easily enough) with I2RS require= ments, c) no other NETCONF based applications are going to benefit from the propos= ed by I2RS modifications. Cheers, Igor ________________________________________ From: i2rs [i2rs-bounces@ietf.org] on behalf of Andy Bierman [andy@yumawork= s.com] Sent: Friday, June 5, 2015 10:28 PM To: Susan Hares Cc: Jeffrey Haas; i2rs@ietf.org; Joel M. Halpern; i2rs-chairs@ietf.org; Ali= a Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) Hi, IMO NETCONF notifications are probably not the best choice for the high-performance low-latency signalling that I2RS wants between agent and client. There is a lot of overhead in the filtering, replay, YANG schema processing, XML encoding, etc. Binary notifications that contain hard-wired standard messages specially written to implement the I2RS protocol would be much faster and less expensive to implement. If this is to be as fast as a signalling protocol then it would be wise to consider protocol performance issues. Andy On Fri, Jun 5, 2015 at 12:43 PM, Susan Hares wrote: > Andy and Joel: > > As my chair note stated, the chairs know they are providing extra details= with the requirements. However, in the past the feedback from various NET= MOD/NETCONF participants has been not enough detail. The use of NACM to co= ntrol input to a I2RS agent and assign priority to a client - is one of tho= se extra info. I believe the tight notification guarantees to support a I2= RS control loop is a requirement rather than extra suggestions. > > Hopefully, that the NETMOD/NETCONF chairs will review through the initial= ephemeral state document and describe what they feel is requirements versu= s added suggestions. The I2RS chairs will clean-up that requirements docu= ment next week. > > Sue > > -----Original Message----- > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Friday, June 05, 2015 12:38 PM > To: Joel M. Halpern > Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; Alia = Atlas > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern wro= te: >> I would describe it somewhat differently from any of the choices you lis= t. >> >> A) I2RS has some a set of architectural requirements. These were not >> as cleanly described as one might like but they were very clearly >> accepted by the working group and understood to be needed for the protoc= ol choice. >> B) The working group has decided that it will use NetConf/RestConf if >> that can meet the requirements. >> > > I would say the arch is a mixture of architecture and functional requirem= ents. > Almost as if the authors had a design in mind and reverse-engineered the = requirements from the design. > > As Juergen pointed out, the requirement to assign a priority to a client = does not require NACM. NACM is a design choice for that requirement. > > I have some concerns about the tight notification control loop that is pr= oposed. IMO, this is going to be too slow and too complicated. It seems t= o me that the only company that has implemented something close to I2RS is = using a design that does not rely on a near real-time reliable notification= loop. > > I don't have a strong preference for ephemeral datastore vs. tagging non-= config data. The current NETCONF datastores only apply to config=3Dtrue ob= jects. YANG design allows for the config=3Dfalse data to be further partit= ioned, but this is not required for I2RS to work. > > >> The corrolary is that if neither NetConf nor RestConf can meet the >> requirements, then the working group will, in my opinion, have to do >> something else. > > That would be OK too, if you want to completely > decouple I2RS from configuration. This simplifies some > things if was invisible to NETCONF/RESTCONF and YANG. > > >> >> Yours, >> Joel > > Andy > >> >> On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >>> >>> On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >>>> >>>> Juergen: >>>> >>>> I understand your technical point on being concerned about >>>> >>>> "solutions that require (i) separate data models for ephemeral state >>>> and >>>> (ii) data model specific merge logic. While this may work for I2RS, >>>> this approach does not scale or has a very high cost of scaling to >>>> other ephemeral state editing needs." >>>> >>>> If you have full overlay model proposal, we would be glad to receive i= t. >>>> However, no one else has proposed a full overlay model. >>> >>> >>> Frankly, there is no full alternate proposal either. The overlay >>> model has been discussed at quite some detail at a NETMOD interim. I >>> am happy to point at the meeting minutes. The question perhaps really >>> is whether (a) I2RS has requirements to be addresses and >>> NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a >>> solution into stone to be run through the NETCONF working group or >>> whether (c) creates a solution on its own independently of any other >>> NETMOD/NETCONF requirements. >>> >>>> Other answers are below. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, June 04, 2015 2:24 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; >>>> i2rs-chairs@ietf.org; 'Alia Atlas' >>>> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >>>> >>>> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>>>> >>>>> The minutes for the I2RS meeting are at: >>>>> >>>>> >>>>> >>>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in >>>>> ter >>>>> im-201 >>>>> 5-i2rs-8 >>>>> >>>>> >>>>> >>>>> These minute provide a lengthy of issues in the requirements. From >>>>> these minutes, there are the following 6 conclusions on the >>>>> protocol requirements that Jeff stated: >>>>> >>>>> >>>>> >>>>> 1) There will be no consideration of an overlay model unless a >>>>> fully >>>>> formed proposal is presented. >>>>> >>>>> Jeff and I appreciate Ken Watsen's comments on the list, but we >>>>> have had lots of suggestions regarding an overlay proposal - but no >>>>> full proposal. At this time, the WG will only consider full >>>>> proposals and not suggestions toward a proposal. >>>> >>>> >>>> For the record: I am highly concerned about solutions that require >>>> (i) separate data models for ephemeral state and (ii) data model >>>> specific merge logic. While this may work for I2RS, this approach >>>> does not scale or has a very high cost of scaling to other ephemeral >>>> state editing needs. >>>> >>>>> 2) Jeff's document provides details on ephemeral state requireme= nts >>>>> that have not changed. These requirements include: >>>>> >>>>> a. Highly reliable notifications (but not perfectly reliable >>>>> notifications) >>>>> >>>>> b. High bandwidth, asynchronous interface, with real-time >>>>> guarantees >>>> >>>> on >>>>> >>>>> getting data, >>>>> >>>>> c. Node identification of clients that write by client identity= , >>>>> secondary identity, and priority. Data models will determine what >>>>> is the "node" unit. For example, the I2RS RIB node unit is the route= . >>>> >>>> >>>> I am concerned about adding protocol mechanisms that are specific to >>>> a certain data model. It is unclear what a "node" unit it, terms >>>> like 'highly reliable notifications' and 'high bandwidth, >>>> asynchronous interface, with real-time guarantees' are somewhat >>>> unclear - how do we determine we have met any of these requirements? >>> >>> >>> Apparently no answer here... >>> >>>>> d. There is one priority per client. >>>>> >>>>> e. Priority is kept in the NACM at the client level [rather than >>>>> path >>>>> level (5/27 meeting) or group level (list discussion). >>>> >>>> >>>> Why does this mapping of username to priority have to be maintained >>>> in NACM? >>> >>> >>> Apparently no answer here... >>> >>>>> 3) Joel suggests that large data write may be best done in netco= nf >>>> >>>> with >>>>> >>>>> guarantees >>>>> >>>>> a. I2RS will be focused on highly asynchronous interfaces with >>>>> less >>>>> than full routing tables. >>>>> >>>>> b. A client whose large data is interrupted by a notification ha= s a >>>>> difficult time determine when the notification happened in the >>>>> stream >>>>> - so the I2RS client must ask the agent again. >>>>> >>>>> c. Logging for traceability is different than event notificatio= n. >>>> >>>> >>>> Except c), I do not understand this. What are these 'guarantees' 3) >>>> is about? >>>> >>>> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may >>>> receive a change notification for one of the routes while the rest >>>> of the stream is in progress. If the change notification does not >>>> include the data, the I2RS client must poll the I2RS agent to >>>> determine if the route change notification occurred before or after >>>> that route's data was sent. >>>> Change notifications are reliable, but not perfectly reliable. >>>> Logging is different than change notifications as logging for >>>> tracing includes all change data reliably. >>> >>> >>> I am still confused what the requirement here is. >>> >>>>> 5) Secondary identity data is read-only meta-data that is stored= in >>>> >>>> the >>>>> >>>>> agent associated with a data model node that is being created or >>>>> updated (write-access) in the data store. >>>> >>>> >>>> Ehem, what is read-only data that is created or written? Did you >>>> want to say that the identity meta-data is immutable once a data >>>> node has been created? >>>> And if so, has priority the same property: Is priority of a data >>>> node is determined at creation time and then immutable? >>>> >>>> [sue]: Secondary identity data is read-only meta-data that is only >>>> changed when created or written. It is immutable unless the whole >>>> node is changed. >>>> Priority is linked to I2RS client. Priority remains unchanged with >>>> the identity of the client. >>> >>> >>> You can't ever change the priority of a client? I doubt this is >>> practical. >>> >>>> Priority of an entry (route1 from client-1, priority2) remains >>>> immutable with the writing of this entry from this client. If a new >>>> client (route-1 from client-2, pririty3), then the node and the >>>> meta-data changes. >>> >>> >>> So I understand the priority is determined at write time but then >>> sticking until the next write. Or in other words, to change the >>> priority I have to write the data again using a client with a >>> different priority (or using the same client in case priority of a >>> client turns out to be configurable). >>> >>>>> 6) I2RS Client and Agent Identities are mutually authenticated b= y >>>>> Authentication server (AAA), >>>>> >>>>> The values of identities are originally set by operators. >>>>> >>>> I am not sure how agent identity authentication via AAA works. Can >>>> someone point me to the right direction if I assume a secure >>>> transport such as SSH or TLS? >>>> >>>> The identities used in SSH are passed via AAA (diameter or radius). >>>> The identities are not standardized but sent in AAA (diameter or >>>> radius) messages based on operator assignment. >>> >>> >>> I know how I can pass the client identity via AAA using SSH, I like >>> to see an explanation how that is supposed to work for server >>> identities (and which operational problem that solves). >>> >>> /js >>> >> >> _______________________________________________ >> 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 Sun Jun 7 15:46: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 39A291AD1BA for ; Sun, 7 Jun 2015 15:46:50 -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_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 Mqjh79xFhPE3 for ; Sun, 7 Jun 2015 15:46:47 -0700 (PDT) Received: from mail-la0-f52.google.com (mail-la0-f52.google.com [209.85.215.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43171AD1A6 for ; Sun, 7 Jun 2015 15:46:46 -0700 (PDT) Received: by laar3 with SMTP id r3so35974927laa.3 for ; Sun, 07 Jun 2015 15:46: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=hAVrHe7mkmYCxoEbSirIBZEdrnkSmXZVMjHM8mbQK0I=; b=fNnpOXhB7gYhqfV+90PCCM/JCPo6vVYzwv7QiD8f+T9D3zm2OxppLxkl0+/5rRPtxz LEbb2i7CRZce4TjjTxR5WIEHPy/Tv7ayQwAN6EF9MltvOvus8oG4EqCFZu9osw+2Q1Wv 953T6/J75rx7OQUKx+ecnRV/yMsWg6mFunz/u6CZ939wBtxHQ5rVYQiB/3G1AsCreRrD 4l/4FUzMRWckOJhEl3PdDJ/Ln8rrKejKNm2JaFXZ29NB943aMQuOTYPZ/LzVE573JhMb qo+UVuNM/eoE0najB2ZGWDaCTQH4LeKRLQZwTP6ImEnsUyYJZ2jXRfVrqUpTMQsPCAdc O8/Q== X-Gm-Message-State: ALoCoQkDNzSLD70hJ7lg1/bCaUvNt9yxzwwqPqgKLQnp50rFI63CvSHUxAWwH2xLrfwj12R7H4fN MIME-Version: 1.0 X-Received: by 10.112.140.197 with SMTP id ri5mr13396152lbb.37.1433717205141; Sun, 07 Jun 2015 15:46:45 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Sun, 7 Jun 2015 15:46:45 -0700 (PDT) In-Reply-To: <0c1b9fb2e34f4e2aa82faef4685cae5d@ATL-SRV-MBX1.advaoptical.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <55719868.2030306@joelhalpern.com> <035401d09fc7$ee49b2e0$cadd18a0$@ndzh.com> <0c1b9fb2e34f4e2aa82faef4685cae5d@ATL-SRV-MBX1.advaoptical.com> Date: Sun, 7 Jun 2015 15:46:45 -0700 Message-ID: From: Andy Bierman To: Igor Bryskin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , Alia Atlas , Jeffrey Haas , "Joel M. Halpern" , Susan Hares Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Sun, 07 Jun 2015 22:46:50 -0000 On Sun, Jun 7, 2015 at 1:38 PM, Igor Bryskin wro= te: > Andy; > You are making an excellent point. I totally agree. I also wonder if the = same logic applies ( and I'd say much more so) for the opposite direction -= when pushing routes real time from I2RS Client to Agent. > If Yes, isn't this is what FORCES folks (Jamal especially) have been sayi= ng all along? > NETCONF/RESTCONF are great for a lot of stuff, but maybe not so much for = I2RS? > What's the point of "raping" NETCONF if: > a) it was never designed for architectures like I2RS; > b) it's properties do not square (at least easily enough) with I2RS requi= rements, > c) no other NETCONF based applications are going to benefit from the prop= osed by I2RS modifications. > I don't think it applies in the other direction. The issue is that notification delivery is not instantaneous after an edit occurs. Edits initiated from the client are not affected by a loosely coupled notification delivery system. Also, edits from the client can contain data model fragments that need to be validated and need to pass access control. There is no extra processing done on the input. All this processing is needed. But if the agent needs to tell a client that path "/foo/bar" has been deleted by a higher priority edit, none of the extra processing required for RESTCONF notifications is useful. It is all overhead. > Cheers, > Igor > Andy > ________________________________________ > From: i2rs [i2rs-bounces@ietf.org] on behalf of Andy Bierman [andy@yumawo= rks.com] > Sent: Friday, June 5, 2015 10:28 PM > To: Susan Hares > Cc: Jeffrey Haas; i2rs@ietf.org; Joel M. Halpern; i2rs-chairs@ietf.org; A= lia Atlas > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > Hi, > > IMO NETCONF notifications are probably not the best choice for > the high-performance low-latency signalling that I2RS wants > between agent and client. There is a lot of overhead in > the filtering, replay, YANG schema processing, XML encoding, etc. > > Binary notifications that contain hard-wired standard messages > specially written to implement the I2RS protocol would be much faster > and less expensive to implement. If this is to be as fast as a signallin= g > protocol then it would be wise to consider protocol performance issues. > > > Andy > > > On Fri, Jun 5, 2015 at 12:43 PM, Susan Hares wrote: >> Andy and Joel: >> >> As my chair note stated, the chairs know they are providing extra detail= s with the requirements. However, in the past the feedback from various NE= TMOD/NETCONF participants has been not enough detail. The use of NACM to c= ontrol input to a I2RS agent and assign priority to a client - is one of th= ose extra info. I believe the tight notification guarantees to support a I= 2RS control loop is a requirement rather than extra suggestions. >> >> Hopefully, that the NETMOD/NETCONF chairs will review through the initia= l ephemeral state document and describe what they feel is requirements vers= us added suggestions. The I2RS chairs will clean-up that requirements doc= ument next week. >> >> Sue >> >> -----Original Message----- >> From: Andy Bierman [mailto:andy@yumaworks.com] >> Sent: Friday, June 05, 2015 12:38 PM >> To: Joel M. Halpern >> Cc: Susan Hares; i2rs@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; Alia= Atlas >> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >> >> On Fri, Jun 5, 2015 at 5:39 AM, Joel M. Halpern wr= ote: >>> I would describe it somewhat differently from any of the choices you li= st. >>> >>> A) I2RS has some a set of architectural requirements. These were not >>> as cleanly described as one might like but they were very clearly >>> accepted by the working group and understood to be needed for the proto= col choice. >>> B) The working group has decided that it will use NetConf/RestConf if >>> that can meet the requirements. >>> >> >> I would say the arch is a mixture of architecture and functional require= ments. >> Almost as if the authors had a design in mind and reverse-engineered the= requirements from the design. >> >> As Juergen pointed out, the requirement to assign a priority to a client= does not require NACM. NACM is a design choice for that requirement. >> >> I have some concerns about the tight notification control loop that is p= roposed. IMO, this is going to be too slow and too complicated. It seems = to me that the only company that has implemented something close to I2RS is= using a design that does not rely on a near real-time reliable notificatio= n loop. >> >> I don't have a strong preference for ephemeral datastore vs. tagging non= -config data. The current NETCONF datastores only apply to config=3Dtrue o= bjects. YANG design allows for the config=3Dfalse data to be further parti= tioned, but this is not required for I2RS to work. >> >> >>> The corrolary is that if neither NetConf nor RestConf can meet the >>> requirements, then the working group will, in my opinion, have to do >>> something else. >> >> That would be OK too, if you want to completely >> decouple I2RS from configuration. This simplifies some >> things if was invisible to NETCONF/RESTCONF and YANG. >> >> >>> >>> Yours, >>> Joel >> >> Andy >> >>> >>> On 6/5/15 8:35 AM, Juergen Schoenwaelder wrote: >>>> >>>> On Thu, Jun 04, 2015 at 03:52:15PM -0400, Susan Hares wrote: >>>>> >>>>> Juergen: >>>>> >>>>> I understand your technical point on being concerned about >>>>> >>>>> "solutions that require (i) separate data models for ephemeral state >>>>> and >>>>> (ii) data model specific merge logic. While this may work for I2RS, >>>>> this approach does not scale or has a very high cost of scaling to >>>>> other ephemeral state editing needs." >>>>> >>>>> If you have full overlay model proposal, we would be glad to receive = it. >>>>> However, no one else has proposed a full overlay model. >>>> >>>> >>>> Frankly, there is no full alternate proposal either. The overlay >>>> model has been discussed at quite some detail at a NETMOD interim. I >>>> am happy to point at the meeting minutes. The question perhaps really >>>> is whether (a) I2RS has requirements to be addresses and >>>> NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a >>>> solution into stone to be run through the NETCONF working group or >>>> whether (c) creates a solution on its own independently of any other >>>> NETMOD/NETCONF requirements. >>>> >>>>> Other answers are below. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, June 04, 2015 2:24 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; >>>>> i2rs-chairs@ietf.org; 'Alia Atlas' >>>>> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >>>>> >>>>> On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: >>>>>> >>>>>> The minutes for the I2RS meeting are at: >>>>>> >>>>>> >>>>>> >>>>>> www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-in >>>>>> ter >>>>>> im-201 >>>>>> 5-i2rs-8 >>>>>> >>>>>> >>>>>> >>>>>> These minute provide a lengthy of issues in the requirements. From >>>>>> these minutes, there are the following 6 conclusions on the >>>>>> protocol requirements that Jeff stated: >>>>>> >>>>>> >>>>>> >>>>>> 1) There will be no consideration of an overlay model unless a >>>>>> fully >>>>>> formed proposal is presented. >>>>>> >>>>>> Jeff and I appreciate Ken Watsen's comments on the list, but we >>>>>> have had lots of suggestions regarding an overlay proposal - but no >>>>>> full proposal. At this time, the WG will only consider full >>>>>> proposals and not suggestions toward a proposal. >>>>> >>>>> >>>>> For the record: I am highly concerned about solutions that require >>>>> (i) separate data models for ephemeral state and (ii) data model >>>>> specific merge logic. While this may work for I2RS, this approach >>>>> does not scale or has a very high cost of scaling to other ephemeral >>>>> state editing needs. >>>>> >>>>>> 2) Jeff's document provides details on ephemeral state requirem= ents >>>>>> that have not changed. These requirements include: >>>>>> >>>>>> a. Highly reliable notifications (but not perfectly reliable >>>>>> notifications) >>>>>> >>>>>> b. High bandwidth, asynchronous interface, with real-time >>>>>> guarantees >>>>> >>>>> on >>>>>> >>>>>> getting data, >>>>>> >>>>>> c. Node identification of clients that write by client identit= y, >>>>>> secondary identity, and priority. Data models will determine what >>>>>> is the "node" unit. For example, the I2RS RIB node unit is the rout= e. >>>>> >>>>> >>>>> I am concerned about adding protocol mechanisms that are specific to >>>>> a certain data model. It is unclear what a "node" unit it, terms >>>>> like 'highly reliable notifications' and 'high bandwidth, >>>>> asynchronous interface, with real-time guarantees' are somewhat >>>>> unclear - how do we determine we have met any of these requirements? >>>> >>>> >>>> Apparently no answer here... >>>> >>>>>> d. There is one priority per client. >>>>>> >>>>>> e. Priority is kept in the NACM at the client level [rather tha= n >>>>>> path >>>>>> level (5/27 meeting) or group level (list discussion). >>>>> >>>>> >>>>> Why does this mapping of username to priority have to be maintained >>>>> in NACM? >>>> >>>> >>>> Apparently no answer here... >>>> >>>>>> 3) Joel suggests that large data write may be best done in netc= onf >>>>> >>>>> with >>>>>> >>>>>> guarantees >>>>>> >>>>>> a. I2RS will be focused on highly asynchronous interfaces with >>>>>> less >>>>>> than full routing tables. >>>>>> >>>>>> b. A client whose large data is interrupted by a notification h= as a >>>>>> difficult time determine when the notification happened in the >>>>>> stream >>>>>> - so the I2RS client must ask the agent again. >>>>>> >>>>>> c. Logging for traceability is different than event notificati= on. >>>>> >>>>> >>>>> Except c), I do not understand this. What are these 'guarantees' 3) >>>>> is about? >>>>> >>>>> [Sue]: The large database pulls of a I2RS RIB (1 million routes) may >>>>> receive a change notification for one of the routes while the rest >>>>> of the stream is in progress. If the change notification does not >>>>> include the data, the I2RS client must poll the I2RS agent to >>>>> determine if the route change notification occurred before or after >>>>> that route's data was sent. >>>>> Change notifications are reliable, but not perfectly reliable. >>>>> Logging is different than change notifications as logging for >>>>> tracing includes all change data reliably. >>>> >>>> >>>> I am still confused what the requirement here is. >>>> >>>>>> 5) Secondary identity data is read-only meta-data that is store= d in >>>>> >>>>> the >>>>>> >>>>>> agent associated with a data model node that is being created or >>>>>> updated (write-access) in the data store. >>>>> >>>>> >>>>> Ehem, what is read-only data that is created or written? Did you >>>>> want to say that the identity meta-data is immutable once a data >>>>> node has been created? >>>>> And if so, has priority the same property: Is priority of a data >>>>> node is determined at creation time and then immutable? >>>>> >>>>> [sue]: Secondary identity data is read-only meta-data that is only >>>>> changed when created or written. It is immutable unless the whole >>>>> node is changed. >>>>> Priority is linked to I2RS client. Priority remains unchanged with >>>>> the identity of the client. >>>> >>>> >>>> You can't ever change the priority of a client? I doubt this is >>>> practical. >>>> >>>>> Priority of an entry (route1 from client-1, priority2) remains >>>>> immutable with the writing of this entry from this client. If a new >>>>> client (route-1 from client-2, pririty3), then the node and the >>>>> meta-data changes. >>>> >>>> >>>> So I understand the priority is determined at write time but then >>>> sticking until the next write. Or in other words, to change the >>>> priority I have to write the data again using a client with a >>>> different priority (or using the same client in case priority of a >>>> client turns out to be configurable). >>>> >>>>>> 6) I2RS Client and Agent Identities are mutually authenticated = by >>>>>> Authentication server (AAA), >>>>>> >>>>>> The values of identities are originally set by operators. >>>>>> >>>>> I am not sure how agent identity authentication via AAA works. Can >>>>> someone point me to the right direction if I assume a secure >>>>> transport such as SSH or TLS? >>>>> >>>>> The identities used in SSH are passed via AAA (diameter or radius). >>>>> The identities are not standardized but sent in AAA (diameter or >>>>> radius) messages based on operator assignment. >>>> >>>> >>>> I know how I can pass the client identity via AAA using SSH, I like >>>> to see an explanation how that is supposed to work for server >>>> identities (and which operational problem that solves). >>>> >>>> /js >>>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 8 14:54: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 CFF281A908D; Mon, 8 Jun 2015 14:54:42 -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 zs3fPdrRAhNb; Mon, 8 Jun 2015 14:54:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AC32F1A9090; Mon, 8 Jun 2015 14:54:34 -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.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608215434.3381.42990.idtracker@ietfa.amsl.com> Date: Mon, 08 Jun 2015 14:54:34 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 21:54:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System Working Group of the IETF. Title : A YANG Data Model for Layer 3 Topologies Authors : Alexander Clemm Jan Medved Robert Varga Tony Tkacik Xufeng Liu Igor Bryskin Aihua Guo Hariharan Ananthakrishnan Nitin Bahadur Vishnu Beeram Filename : draft-ietf-i2rs-yang-l3-topology-00.txt Pages : 28 Date : 2015-06-08 Abstract: This document defines a YANG data model for layer 3 network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-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/ From nobody Tue Jun 9 08:29:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3561B1A8894 for ; Tue, 9 Jun 2015 08:29:46 -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 LfFaxjEAijVE for ; Tue, 9 Jun 2015 08:29: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 A5C0F1A88BC for ; Tue, 9 Jun 2015 08:29:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: Date: Tue, 9 Jun 2015 11:29:24 -0400 Message-ID: <018b01d0a2c9$115da3a0$3418eae0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01D0A2A7.8A4F10E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCixhir7BgNyIUiQ3mzweI3egGMtg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] Text to Add to introduction of draft-haas-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, 09 Jun 2015 15:29:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018C_01D0A2A7.8A4F10E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit WG: After reviewing the discussion on the list and the minutes of the last interim, I suggest that this gets added in an introductory section for Jeff Document. Any thoughts? Are these accurate? Sue --------- This document provides details on ephemeral state requirements that are derived from the architecture document. However, a restatement of 10 basic principles from the I2RS architecture may be helpful in order to set the context for the I2RS requirements for ephemeral state. 1. The I2RS protocol SHOULD support highly reliable notifications (but not perfectly reliable notifications) from an I2RS agent to an I2RS client. 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. 3. The I2RS protocol will operate on data models which may be protocol independent or protocol dependent. 4. I2RS Agent needs to record the client identity when a node is created or modified. The I2RS Agent needs to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. 5. Client identity will have only one priority for the client identity. A collision on writes is considered an error, but priority is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use. 6. The Agent identity and the Client identity should be passed outside of the I2RS protocol in a authentication and authorization protocol (AAA). Client priority may be passed in the AAA protocol. The values of identities are originally set by operators, and not standardized. 7. An I2RS Client and I2RS Agent mutually authenticate each other based on pre-established authenticated identities. 8. Secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written, updated or deleted. Just like the primary identity, the secondary identity is only recorded when the data node is written or updated or deleted. 9. I2RS agent can have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. Note: Jeff's suggests that priority is kept at the NACM at the client level (rather than the path level or the group level) will allow these lower priority clients to be filtered out using an extended NACM approach. This is only a suggestion of a method to provide the requirement 9. 10. The I2RS protocol MUST support the use of a secure transport. However, certain functions such as notifications MAY use a non-secure transport. Each model or service (notification, logging) must define within the model or service the valid uses of a non-secure transport. ------=_NextPart_000_018C_01D0A2A7.8A4F10E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

WG: =

 

After reviewing the discussion on the list and the = minutes of the last interim, I suggest that this gets added in an = introductory section for Jeff Document.  

 

Any = thoughts?  Are these accurate?

 

Sue =

 

---------

This = document provides details on ephemeral state requirements that are = derived from the architecture document. However, a restatement of 10 = basic principles from the I2RS architecture may be helpful in order to = set the context for the I2RS requirements for ephemeral = state.


 1.   The = I2RS protocol SHOULD support highly reliable notifications (but not = perfectly reliable notifications) from an I2RS agent to an  I2RS = client.

 2.   The I2RS protocol SHOULD support a = high bandwidth, asynchronous interface, with real-time guarantees on = getting data from an I2RS  agent by
an I2RS client. =

3.  The I2RS protocol will operate on data models which may = be protocol independent or protocol dependent.

 

4. I2RS = Agent needs to record the client identity when a node is created or = modified. The I2RS Agent needs to be able to read the client identity of = a node and use the client identity's associated priority to resolve = conflicts.   The secondary identity is useful for traceability = and may also be recorded.

 5.   Client identity will have only = one priority for the client identity. A collision on writes is = considered an error, but priority is utilized to
compare requests = from two different clients in order to modify an existing node = entry.  Only an entry from a client which is higher priority can = modify
an existing entry (First entry wins). Priority only has = meaning at the time of use.  

6.   The Agent = identity and the Client identity should be passed outside of the I2RS = protocol in a authentication and authorization  protocol = (AAA).
Client priority may be passed in the AAA protocol.  The = values of identities are originally set by operators, and not  = standardized.  

 7.  An I2RS Client and I2RS Agent = mutually authenticate each other based on pre-established authenticated = identities.  

 8. Secondary identity data is read-only = meta-data that is recorded by the I2RS agent associated with a data = model's node is written, updated or
deleted. Just like the primary = identity, the secondary identity is only recorded when the data node is = written or updated or deleted. 

 9.   I2RS = agent can have a lower priority I2RS client attempting to modify a = higher priority client's entry in a data model.  The filtering out = of
lower priority clients attempting to write or modify a higher = priority client's entry in a data model SHOULD be effectively handled = and not put an
undue strain on the I2RS agent.  =

Note:  Jeff's suggests that priority is kept at the NACM at = the client level (rather than the path level or the group level) will = allow these lower
priority clients to be filtered out using an = extended NACM approach. This is only a suggestion of a method to provide = the requirement 9. 

10.  The I2RS protocol MUST support the use of a = secure transport. However, certain functions such as notifications MAY = use a non-secure transport.  Each model or service (notification, = logging) must define within the model or service the valid uses of a = non-secure transport.

 

------=_NextPart_000_018C_01D0A2A7.8A4F10E0-- From nobody Tue Jun 9 13:57: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 F17B61A1A68; Tue, 9 Jun 2015 13:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.154 X-Spam-Level: X-Spam-Status: No, score=-97.154 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnufbTCZrb4o; Tue, 9 Jun 2015 13:57:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04A1A1A73; Tue, 9 Jun 2015 13:57:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: Date: Tue, 9 Jun 2015 16:57:03 -0400 Message-ID: <023301d0a2f6$d6ad71d0$84085570$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0234_01D0A2D5.4F9EDF10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCi9dfrchnV+DzOQ52VhnCsPsYx9w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , netconf@ietf.org, netmod@ietf.org Subject: [i2rs] I2RS Interim on 6/10/2015 at 10:00 - Discussion of I2RS Requirements to be sent to NETCONF on 6/10/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, 09 Jun 2015 20:57:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0234_01D0A2D5.4F9EDF10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2SR Protocol Requirements will be passed to NETCONF later this week https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs (adopted by I2RS WG) http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements : withdrawn http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC completed, consensus) http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ WG LC complete, consensus Come and discuss these at the I2RS Interim before the documents are passed to NETCONF. Sue Hares ================== I2RS interim 6/10/2015 Agenda: 0) Agenda Bashing [10:00 - 10:05] 1) DiscussionI2RS Protocol requirements for ephemeral state [10:05 - 10:20] https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs presenter (Jeff Haas) 2) Review of WG Adoption and WG LC Discussion on All requirements including the following drafts [10:20-10:30] http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements - withdrawn http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC completed, consensus) http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ WG LC complete, consensus 3) draft-hares-i2rs-auth-transaction-00.txt (WG Adoption 6/10 to 6/24) [10:30-10:45] 4) Open Discussion [10:45 to 11:15] http://etherpad.tools.ietf.org:9000/p/i2rs-interim-Jun-10-2015-minutes [Jeff and Sue will be active in the discussions. We appreciate any extra note-takers] Meeting blue sheets: http://etherpad.tools.ietf.org:9000/p/i2rs-interim-jun-10-2015-vBlueSheets [Please sign up on the virtual Blue Sheets. ] I2RS Interim 6/7 Wednesday, June 10, 2015 9:30 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m82ee9ad7a04c2334cb77af58f195cf48 Meeting number: 648 859 109 Meeting password: choice.is.yours 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: 648 859 109 -------------------------------- ------=_NextPart_000_0234_01D0A2D5.4F9EDF10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2SR = Protocol Requirements will be passed to NETCONF later this week =

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-re= qs (adopted by I2RS WG)

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

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus  

 

Come and = discuss these at the I2RS Interim before the documents are passed to = NETCONF.

 

Sue Hares

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= o:p>

 

I2RS interim 6/10/2015

 

Agenda: =

 

0) Agenda Bashing [10:00 – 10:05] =

1) DiscussionI2RS Protocol = requirements for ephemeral state   [10:05 – 10:20] =

https://datatracker.ietf.org/doc/draft-haas-i2rs-epheme= ral-state-reqs

        presenter = (Jeff Haas)   

 

2) Review of = WG Adoption and WG LC

Discussion = on  All requirements including the following drafts = [10:20-10:30]  

 

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

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus

 

3) = draft-hares-i2rs-auth-transaction-00.txt  (WG Adoption 6/10 to = 6/24) [10:30-10:45]

 

4) Open = Discussion [10:45 to 11:15]

 

=

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

[Jeff = and Sue will be active in the discussions.  We appreciate any extra = note-takers]

 Meeting blue sheets:

   http://etherpad.tools.ietf.org:9000/p= /i2rs-interim-jun-10-2015-vBlueSheets

[Please sign up on the virtual Blue Sheets. = ]

 

         &= nbsp;      =             &= nbsp;     

 I2RS Interim 6/7

Wednesday, June 10, 2015

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

 

 

Join WebEx = meeting

= https://ietf.webex.com/ietf/j.php?MTID=3Dm82ee9ad7a04c2334cb77af58f195cf4= 8

 

Meeting number: =            648 859 109 =

Meeting = password:         = choice.is.yours

 

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: 648 859 = 109

 

 

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

 

------=_NextPart_000_0234_01D0A2D5.4F9EDF10-- From nobody Tue Jun 9 14:32: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 53FB81A1B21; Tue, 9 Jun 2015 14:32:07 -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_20=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYu0fEIRb4aH; Tue, 9 Jun 2015 14:32:05 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7BB1A1B05; Tue, 9 Jun 2015 14:32:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: Date: Tue, 9 Jun 2015 17:31:54 -0400 Message-ID: <026e01d0a2fb$b52d99e0$1f88cda0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026F_01D0A2DA.2E1DA790" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCi90273nYdXGB4SLeA1ZmD/g423g== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Alia Atlas' , netconf@ietf.org, netmod@ietf.org Subject: [i2rs] WG documents for I2RS Protocol - WG calls 5/27 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, 09 Jun 2015 21:32:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_026F_01D0A2DA.2E1DA790 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The following I2RS Protocol Requirements will be passed to NETCONF later this week https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-reqs (adopted by I2RS WG) (will be sent as draft-ietf-i2rs-ephemeral-state-reqs) http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC completed, consensus) http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/ WG LC complete, consensus Come and discuss these at the I2RS Interim before the documents are passed to NETCONF. Below are 10 requirements that NETCONF SHOULD meet. There has been debate on the I2RS list whether NETCONF can provide requirement 2. If you have an opinion on these requirements, the interim tomorrow is your chance to provide feedback before the requirements go to NETCONF. Sue Hares ============================================= 1. The I2RS protocol SHOULD support highly reliable notifications (but not perfectly reliable notifications) from an I2RS agent to an I2RS client. 2. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, with real-time guarantees on getting data from an I2RS agent by an I2RS client. 3. The I2RS protocol will operate on data models which may be protocol independent or protocol dependent. 4. I2RS Agent needs to record the client identity when a node is created or modified. The I2RS Agent needs to be able to read the client identity of a node and use the client identity's associated priority to resolve conflicts. The secondary identity is useful for traceability and may also be recorded. 5. Client identity will have only one priority for the client identity. A collision on writes is considered an error, but priority is utilized to compare requests from two different clients in order to modify an existing node entry. Only an entry from a client which is higher priority can modify an existing entry (First entry wins). Priority only has meaning at the time of use. 6. The Agent identity and the Client identity should be passed outside of the I2RS protocol in a authentication and authorization protocol (AAA). Client priority may be passed in the AAA protocol. The values of identities are originally set by operators, and not standardized. 7. An I2RS Client and I2RS Agent mutually authenticate each other based on pre-established authenticated identities. 8. Secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written, updated or deleted. Just like the primary identity, the secondary identity is only recorded when the data node is written or updated or deleted. 9. I2RS agent can have a lower priority I2RS client attempting to modify a higher priority client's entry in a data model. The filtering out of lower priority clients attempting to write or modify a higher priority client's entry in a data model SHOULD be effectively handled and not put an undue strain on the I2RS agent. Note: Jeff's suggests that priority is kept at the NACM at the client level (rather than the path level or the group level) will allow these lower priority clients to be filtered out using an extended NACM approach. This is only a suggestion of a method to provide the requirement 9. 10. The I2RS protocol MUST support the use of a secure transport. However, certain functions such as notifications MAY use a non-secure transport. Each model or service (notification, logging) must define within the model or service the valid uses of a non-secure transport. ------=_NextPart_000_026F_01D0A2DA.2E1DA790 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = following I2RS Protocol Requirements will be passed to NETCONF later = this week

 

https://datatracker.ietf.org/doc/draft-haas-i2rs-ephemeral-state-re= qs (adopted by I2RS WG)

   (will be sent as = draft-ietf-i2rs-ephemeral-state-reqs)

http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub= -requirements/ ( WG LC completed, consensus) 

http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceab= ility/  WG LC complete, consensus  

 

Come and = discuss these at the I2RS Interim before the documents are passed to = NETCONF.

 

Below are 10 requirements that NETCONF SHOULD = meet.  There has been debate on the I2RS list whether NETCONF can = provide requirement 2.  If you have an opinion on these = requirements,  the interim tomorrow is your chance to provide = feedback before the requirements go to NETCONF.  

 

Sue = Hares

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

 

 1.   The I2RS protocol SHOULD support = highly reliable notifications (but not perfectly reliable notifications) = from an I2RS agent to an  I2RS client.

 2.  =  The I2RS protocol SHOULD support a high bandwidth, asynchronous = interface, with real-time guarantees on getting data from an I2RS  = agent by an I2RS client.

3.  The I2RS protocol will operate = on data models which may be protocol independent or protocol = dependent.

 

4. I2RS Agent needs to = record the client identity when a node is created or modified. The I2RS = Agent needs to be able to read the client identity of a node and use the = client identity's associated priority to resolve conflicts.   = The secondary identity is useful for traceability and may also be = recorded.

 5.   Client identity will = have only one priority for the client identity. A collision on writes is = considered an error, but priority is utilized to compare requests from = two different clients in order to modify an existing node entry.  = Only an entry from a client which is higher priority can modify an = existing entry (First entry wins). Priority only has meaning at the time = of use.  

6.   The Agent identity and the Client = identity should be passed outside of the I2RS protocol in a = authentication and authorization  protocol (AAA).  Client = priority may be passed in the AAA protocol.  The values of = identities are originally set by operators, and not  standardized. =  

 7.  An I2RS Client and I2RS Agent mutually = authenticate each other based on pre-established authenticated = identities.  

 8. Secondary identity data is read-only = meta-data that is recorded by the I2RS agent associated with a data = model's node is written, updated or deleted. Just like the primary = identity, the secondary identity is only recorded when the data node is = written or updated or deleted. 

 9.   I2RS = agent can have a lower priority I2RS client attempting to modify a = higher priority client's entry in a data model.  The filtering out = of lower priority clients attempting to write or modify a higher = priority client's entry in a data model SHOULD be effectively handled = and not put an
undue strain on the I2RS agent.  =

Note:  Jeff's suggests that priority is kept at the NACM at = the client level (rather than the path level or the group level) will = allow these lower priority clients to be filtered out using an extended = NACM approach. This is only a suggestion of a method to provide the = requirement 9. 

10.  The = I2RS protocol MUST support the use of a secure transport. However, = certain functions such as notifications MAY use a non-secure = transport.  Each model or service (notification, logging) must = define within the model or service the valid uses of a non-secure = transport.

 

 

------=_NextPart_000_026F_01D0A2DA.2E1DA790-- From nobody Tue Jun 9 17:08: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 011C31A8F36 for ; Tue, 9 Jun 2015 17:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.321 X-Spam-Level: X-Spam-Status: No, score=0.321 tagged_above=-999 required=5 tests=[BAYES_20=-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 Vle7xh2-Ul5M for ; Tue, 9 Jun 2015 17:08:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 571691A8BC1 for ; Tue, 9 Jun 2015 17:08:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F377F1E397; Tue, 9 Jun 2015 20:09:47 -0400 (EDT) Date: Tue, 9 Jun 2015 20:09:47 -0400 From: Jeffrey Haas To: Susan Hares , 'Andy Bierman' , "'Joel M. Halpern'" , i2rs@ietf.org, chen.ran@zte.com.cn, 'Alia Atlas' Message-ID: <20150610000947.GB21226@pfrc.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150529061023.GB1694@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) 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, 10 Jun 2015 00:08:51 -0000 [I am massively behind in my mail again. My apologies.] On Fri, May 29, 2015 at 08:10:24AM +0200, Juergen Schoenwaelder wrote: > 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. As discussed at the most recent interim, the priority should be made a property of the group rather than a rule. I have no issue with this. To answer other comments regarding "why put this in NACM at all", this is an attempt to show binding of user to priority. In the case that NACM is in use, I believe this would be required by I2RS. In the absence of NACM, it would be a similar property of a local user database. -- Jeff From nobody Tue Jun 9 17:33: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 2B0471A901E; Tue, 9 Jun 2015 17:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 hCXa7wTpuLxH; Tue, 9 Jun 2015 17:33:46 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 485FD1A900B; Tue, 9 Jun 2015 17:33:46 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 76A5E1E397; Tue, 9 Jun 2015 20:34:44 -0400 (EDT) Date: Tue, 9 Jun 2015 20:34:44 -0400 From: Jeffrey Haas To: Susan Hares , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Message-ID: <20150610003444.GC21226@pfrc.org> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150605123533.GA55279@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Wed, 10 Jun 2015 00:33:47 -0000 Juergen, On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote: > Frankly, there is no full alternate proposal either. The overlay model > has been discussed at quite some detail at a NETMOD interim. I am > happy to point at the meeting minutes. The question perhaps really is > whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF > looks at solutions or whether (b) I2RS casts a solution into stone to > be run through the NETCONF working group or whether (c) creates a > solution on its own independently of any other NETMOD/NETCONF > requirements. During that interim, we did discuss a number of details regarding overlays. We also discussed a number of issues that overlays have when ephemeral state was not disjoint from static configuration state. As a result of that discussion and further presentation at a later I2RS meeting regarding the Venn diagram interactions of static and ephemeral configuration state, my latest draft attempts to codify behaviors that shouldn't be problematic in either proposed form or in overlay. The point of frustration for all parties seems to be that while the paragraph from you above seems to indicate that there is some understanding of the requirements, I am unable to provide text that illustrates either requirement or potential solution to the matter. All parties are spending their resources saying "I think I understand this point, but this is wrong." If the points are understood well enough to disagree with potential solutions, I would suggest that they may be clear enough for both protocol and data modeling experts to contribute text that either clarifies the requirements to the collective experts' needs or similarly a proposal documenting a solution. These fundamental failures suggest a few possibilities: 1. There is a complete failure to properly communicate. If so, we should find replacement parties to carry on the work. We had some declared interest in a design team. Sue has, I believe, contacted people about it. Those individuals should take over the work. 2. Netconf/restconf/yang are inappropriate tools and we have wasted the Working Group's time. I don't believe this as my employer has ephemeral datastores in an upcoming release. It does not, however, have full I2RS properties such as priority or secondary-id. 3. The relevant experts are trying to get I2RS ephemeral state work to die. If so, let's have the relevant discussion either publicly or privately so we can stop wasting people's IETF cycles. -- Jeff From nobody Wed Jun 10 05:44: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 4FCA21A00C0; Wed, 10 Jun 2015 05:44:46 -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 kTR55zDsSkV7; Wed, 10 Jun 2015 05:44:44 -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 5D1CE1A00A7; Wed, 10 Jun 2015 05:44:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8409161B; Wed, 10 Jun 2015 14:44:42 +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 RMC4ZP6couHx; Wed, 10 Jun 2015 14:44:39 +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, 10 Jun 2015 14:44:41 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E88222002B; Wed, 10 Jun 2015 14:44:41 +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 cIaJf8CLYeR5; Wed, 10 Jun 2015 14:44:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E6872002C; Wed, 10 Jun 2015 14:44:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 94A62344DE26; Wed, 10 Jun 2015 14:44:37 +0200 (CEST) Date: Wed, 10 Jun 2015 14:44:36 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20150610124435.GC37135@elstar.local> Mail-Followup-To: Jeffrey Haas , Susan Hares , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150610003444.GC21226@pfrc.org> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, Susan Hares , 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) 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, 10 Jun 2015 12:44:46 -0000 On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: > Juergen, > > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote: > > Frankly, there is no full alternate proposal either. The overlay model > > has been discussed at quite some detail at a NETMOD interim. I am > > happy to point at the meeting minutes. The question perhaps really is > > whether (a) I2RS has requirements to be addresses and NETMOD/NETCONF > > looks at solutions or whether (b) I2RS casts a solution into stone to > > be run through the NETCONF working group or whether (c) creates a > > solution on its own independently of any other NETMOD/NETCONF > > requirements. > > During that interim, we did discuss a number of details regarding overlays. > We also discussed a number of issues that overlays have when ephemeral state > was not disjoint from static configuration state. > > As a result of that discussion and further presentation at a later I2RS > meeting regarding the Venn diagram interactions of static and ephemeral > configuration state, my latest draft attempts to codify behaviors that > shouldn't be problematic in either proposed form or in overlay. > > The point of frustration for all parties seems to be that while the > paragraph from you above seems to indicate that there is some understanding > of the requirements, I am unable to provide text that illustrates either > requirement or potential solution to the matter. All parties are spending > their resources saying "I think I understand this point, but this is wrong." > If the points are understood well enough to disagree with potential > solutions, I would suggest that they may be clear enough for both protocol > and data modeling experts to contribute text that either clarifies the > requirements to the collective experts' needs or similarly a proposal > documenting a solution. > > These fundamental failures suggest a few possibilities: > 1. There is a complete failure to properly communicate. If so, we should > find replacement parties to carry on the work. We had some declared > interest in a design team. Sue has, I believe, contacted people about it. > Those individuals should take over the work. > 2. Netconf/restconf/yang are inappropriate tools and we have wasted the > Working Group's time. I don't believe this as my employer has > ephemeral datastores in an upcoming release. It does not, however, have > full I2RS properties such as priority or secondary-id. > 3. The relevant experts are trying to get I2RS ephemeral state work to die. > If so, let's have the relevant discussion either publicly or privately so > we can stop wasting people's IETF cycles. I can assure you that, at least from my side, 3. is not the case. My perspective is likely slightly different from yours since I (not surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps YANG), I believe we will have to envision more usages of that feature than just I2RS. Looking at things from a wider and longer term perspective, I am concerned about (i) duplicated data modeling work and I am concerned about (ii) use-case specific merge logic that needs to be supported. From this perspective, the overlay model has been prety attractive because it comes with a single merge logic and it minimizes (or even eliminates) duplicated data modeling work. /js PS: Out of curiosity: Can you disclose what your employer's ephemeral datastore solution coming out as a product soon looks like? Is it closer to an overlay approach or is it closer to what you described in your I-D? -- 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 Jun 10 06:09: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 0ED3D1A3BA2 for ; Wed, 10 Jun 2015 06:09: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 cXAMODKX4yIf for ; Wed, 10 Jun 2015 06:09: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 B8AC51A6F11 for ; Wed, 10 Jun 2015 06:09:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.194.25.239; From: "Susan Hares" To: References: <20150610130814.29749.20135.idtracker@ietfa.amsl.com> In-Reply-To: <20150610130814.29749.20135.idtracker@ietfa.amsl.com> Date: Wed, 10 Jun 2015 09:09:37 -0400 Message-ID: <005f01d0a37e$b4b4f7f0$1e1ee7d0$@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: AQHbt35+H7yHNeI19+ZUQnVuwNKeVZ2PjgOg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , 'Alia Atlas' Subject: [i2rs] FW: New Version Notification for draft-hares-i2rs-auth-trans-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, 10 Jun 2015 13:09:57 -0000 This draft contains requirements for security for the I2RS protocol not = covered in other I2RS drafts.=20 This draft will be discussed at today's I2RS interim.=20 Sue Hares -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Wednesday, June 10, 2015 9:08 AM To: Susan Hares; Susan Hares Subject: New Version Notification for draft-hares-i2rs-auth-trans-00.txt A new version of I-D, draft-hares-i2rs-auth-trans-00.txt has been successfully submitted by Susan Hares and posted to the IETF = repository. Name: draft-hares-i2rs-auth-trans Revision: 00 Title: I2RS Security Related Requirements Document date: 2015-06-10 Group: Individual Submission Pages: 11 URL: = https://www.ietf.org/internet-drafts/draft-hares-i2rs-auth-trans-00.txt Status: = https://datatracker.ietf.org/doc/draft-hares-i2rs-auth-trans/ Htmlized: = https://tools.ietf.org/html/draft-hares-i2rs-auth-trans-00 Abstract: This presents an security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. = =20 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 Jun 10 07:53: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 40F2F1A038B; Wed, 10 Jun 2015 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucObAQMCkdnH; Wed, 10 Jun 2015 07:53:15 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 488521A023E; Wed, 10 Jun 2015 07:53:15 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.25.239; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Jeffrey Haas'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> In-Reply-To: <20150610124435.GC37135@elstar.local> Date: Wed, 10 Jun 2015 10:52:51 -0400 Message-ID: <000201d0a38d$20d635d0$6282a170$@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: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fgH6v/10AuL3kOCecboQ0A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Wed, 10 Jun 2015 14:53:17 -0000 Juergen: The I2RS WG still needs a written draft proposing how this would work to have an effective discussion. If it has these benefits you mention, it would be good to write itup. Best wishes, Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Wednesday, June 10, 2015 8:45 AM To: Jeffrey Haas Cc: Susan Hares; i2rs@ietf.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: > Juergen, > > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote: > > Frankly, there is no full alternate proposal either. The overlay > > model has been discussed at quite some detail at a NETMOD interim. I > > am happy to point at the meeting minutes. The question perhaps > > really is whether (a) I2RS has requirements to be addresses and > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a > > solution into stone to be run through the NETCONF working group or > > whether (c) creates a solution on its own independently of any other > > NETMOD/NETCONF requirements. > > During that interim, we did discuss a number of details regarding overlays. > We also discussed a number of issues that overlays have when ephemeral > state was not disjoint from static configuration state. > > As a result of that discussion and further presentation at a later > I2RS meeting regarding the Venn diagram interactions of static and > ephemeral configuration state, my latest draft attempts to codify > behaviors that shouldn't be problematic in either proposed form or in overlay. > > The point of frustration for all parties seems to be that while the > paragraph from you above seems to indicate that there is some > understanding of the requirements, I am unable to provide text that > illustrates either requirement or potential solution to the matter. > All parties are spending their resources saying "I think I understand this point, but this is wrong." > If the points are understood well enough to disagree with potential > solutions, I would suggest that they may be clear enough for both > protocol and data modeling experts to contribute text that either > clarifies the requirements to the collective experts' needs or > similarly a proposal documenting a solution. > > These fundamental failures suggest a few possibilities: > 1. There is a complete failure to properly communicate. If so, we should > find replacement parties to carry on the work. We had some declared > interest in a design team. Sue has, I believe, contacted people about it. > Those individuals should take over the work. > 2. Netconf/restconf/yang are inappropriate tools and we have wasted the > Working Group's time. I don't believe this as my employer has > ephemeral datastores in an upcoming release. It does not, however, have > full I2RS properties such as priority or secondary-id. > 3. The relevant experts are trying to get I2RS ephemeral state work to die. > If so, let's have the relevant discussion either publicly or privately so > we can stop wasting people's IETF cycles. I can assure you that, at least from my side, 3. is not the case. My perspective is likely slightly different from yours since I (not surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps YANG), I believe we will have to envision more usages of that feature than just I2RS. Looking at things from a wider and longer term perspective, I am concerned about (i) duplicated data modeling work and I am concerned about (ii) use-case specific merge logic that needs to be supported. From this perspective, the overlay model has been prety attractive because it comes with a single merge logic and it minimizes (or even eliminates) duplicated data modeling work. /js PS: Out of curiosity: Can you disclose what your employer's ephemeral datastore solution coming out as a product soon looks like? Is it closer to an overlay approach or is it closer to what you described in your I-D? -- 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 Jun 10 09:15: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 D222D1B3351 for ; Wed, 10 Jun 2015 09:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.1 X-Spam-Level: X-Spam-Status: No, score=-100.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 T3Cu4BVdtCfZ for ; Wed, 10 Jun 2015 09:15:47 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2871B334D for ; Wed, 10 Jun 2015 09:15:47 -0700 (PDT) Received: by oihd6 with SMTP id d6so35550966oih.2 for ; Wed, 10 Jun 2015 09:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8JAY7bEWqmVNF8H9+HL2SR+cp/sHQVPdyZ+EARGU+00=; b=evI0S7/kls+/Ul9aTI8rS/fVMeAid/925AFyHtC9AxFzBqVjIa84iYQIdUg/ulbU9I PP7FhBBuyIMRUdUdLYw5lBvMUYtk8ZPRb+ELmL+bx8z4+PQx/aw3B/TuXmpc3zNU6vqq /iIL6MbpKnsazRu1pu+D+/ee4LN6hNv5IUfePmEbbtWBsgn7MDgm9Uet/1Sa7Rov9ewY hXTgZs7WeOXGpjYfhYFf8E/CcwTCLhmM43tLbc0Z9ARDqvNdIUy0eYDRI4zFN/mRYNt5 hTmwQYro92gVJTNxLW1izwgmh0ay0dNW9X2qVMlEskJIHJ9+WmnGRIbc/etXtoG0B2Lg UL3w== MIME-Version: 1.0 X-Received: by 10.182.236.5 with SMTP id uq5mr3534682obc.13.1433952946783; Wed, 10 Jun 2015 09:15:46 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Wed, 10 Jun 2015 09:15:46 -0700 (PDT) Date: Wed, 10 Jun 2015 12:15:46 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3393a048c0a05182c30e3 Archived-At: Subject: [i2rs] storage of priority and client ID with a node 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, 10 Jun 2015 16:15:50 -0000 --001a11c3393a048c0a05182c30e3 Content-Type: text/plain; charset=UTF-8 As I mentioned in the virtual interim, I'd like to explain a little further about what I see as semantics and desired behavior around the storing and managing of priority and client ID. First, the priority mechanism is intended to handle "error cases of colliding writes" in a predictable way that results in a consistent mechanism. It is true that the same mechanism could be used if they weren't considered "errors". I think this is a nice property - but it is also important to minimize the impact of the priority mechanism. Second, if there is a priority conflict where both clients (Client_A and Client_B) share the same priority, the client that wrote first wins. This is to avoid network oscillation if two clients are "fighting" over writing the same state. When there are multiple clients and the time arrival of the messages may not be predictable (network transit differences, which socket is read, software differences), basing state on last arrival time doesn't give consistent and predictable behavior. That gives behavior as in the following time-line: Time_1: Client_A writes X=N with priority 10 Time_2: Client_B attempts to write X=K with priority 10 and is rejected Time_3: Client_A writes X=P with priority 10 and succeeds For the I2RS Agent to properly handle these actions, it is necessary to know that X is owned by Client_A. Priority alone is not sufficient because the basis for rejecting Client_B's write but accepting Client_A's write is that Client_A is the owner. Thus, I believe that it is necessary to store the Client Identity with the nodes that it owns. This could be in an I2RS-specific overlay that is only used by the I2RS agent and only contains the nodes that have been written by I2RS. Third, a question has come up regarding what the behavior of priority is if a client's priority changes and whether priority needs to be stored with each node when that node is written. In my "keep-it-simple" perspective, priority is associated with a Client and is only used on a conflict. This would mean that priority isn't stored with a node when that node is written. Instead, the Client Identity is stored with the node and the Client's priority is looked up in a client table that the I2RS Agent can access. That client table could be populated via configuration, via a AAA protocol, via NACM, etc. The semantic implications are as follows: Time_1: Client_A writes X=N with priority 10 Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > 6) * Time_4: Client_A attempts to write X=N with priority 6 (fails b/c 8 > 6) Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 Time_6 Client_B writes X=P with priority 7 and succeeds (same owner, no priority check) The alternate approach would have store the priority with which a node was written. That is more like a priority lock that could only be changed by a client with higher priority or by the same client, regardless of priority. This approach would require storing a priority per node and the semantic implications would be as follows: Time_1: Client_A writes X=N with priority 10 Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 * Time_3: Client_B attempts to write X=K with priority 8 and fails (10 > 8) * Time_4: Client_A writes X=N with priority 6 & succeeds (same owner, no priority check) Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) The behavior for these two models is different at Time_3 and Time_4. I'd like to see if there's agreement that the first model (priority stored with client) is acceptable or if the second model (priority stored with node) is necessary. Thanks, Alia --001a11c3393a048c0a05182c30e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<no-hat>
As I mentioned in the virtua= l interim, I'd like to explain a little further about what I see as sem= antics and desired behavior around the storing and managing of priority and= client ID.

First, the priority mechanism is inten= ded to handle "error cases of colliding writes" in a predictable = way that results in a consistent mechanism.=C2=A0 It is true that the same = mechanism could be used if they weren't considered "errors".= =C2=A0 I think this is a nice property - but it is also important to minimi= ze the impact of the priority mechanism.

Second, i= f there is a priority conflict where both clients (Client_A and Client_B) s= hare the same priority, the client that wrote first wins.=C2=A0 This is to = avoid network oscillation if two clients are "fighting" over writ= ing the same state.=C2=A0 When there are multiple clients and the time arri= val of the messages may not be predictable (network transit differences, wh= ich socket is read, software differences), basing state on last arrival tim= e doesn't give consistent and predictable behavior.

That gives behavior as in the following time-line:
=C2=A0 = =C2=A0 Time_1: =C2=A0Client_A writes X=3DN with priority 10
=C2= =A0 =C2=A0 Time_2: =C2=A0Client_B attempts to write X=3DK with priority 10 = and is rejected
=C2=A0 =C2=A0 Time_3: =C2=A0Client_A writes X=3DP= with priority 10 and succeeds

For the I2RS Agent = to properly handle these actions, it is necessary to know that X is owned b= y Client_A.=C2=A0 Priority alone is not sufficient because the basis for re= jecting Client_B's write but accepting Client_A's write is that Cli= ent_A is the owner.

Thus, I believe that it is nec= essary to store the Client Identity with the nodes that it owns.
= This could be in an I2RS-specific overlay that is only used by the I2RS age= nt and only contains the nodes that have been written by I2RS.=C2=A0
<= div>
Third, a question has come up regarding what the behavio= r of priority is if a client's priority changes and whether priority ne= eds to be stored with each node when that node is written.

In my "keep-it-simple" perspective, priority is associat= ed with a Client and is only used on a conflict.=C2=A0 This would mean that= priority isn't stored with a node when that node is written.=C2=A0 Ins= tead, the Client Identity is stored with the node and the Client's prio= rity is looked up in a client table that the I2RS Agent can access.=C2=A0 T= hat client table could be populated via configuration, via a AAA protocol, = via NACM, etc.

The semantic implications are as fo= llows:
=C2=A0 =C2=A0 =C2=A0 Time_1: =C2=A0Client_A writes X=3DN w= ith priority 10
=C2=A0 =C2=A0 =C2=A0 Time_2: =C2=A0Client_A's= priority is changed (UNUSUAL) to priority 6
=C2=A0* =C2=A0 =C2= =A0Time_3: =C2=A0Client_B writes X=3DK with priority 8 =C2=A0(succeeds sinc= e 8 > 6)
=C2=A0* =C2=A0 =C2=A0Time_4: =C2=A0Client_A attempts = to write X=3DN with priority 6 =C2=A0(fails b/c 8 > 6)
=C2=A0 = =C2=A0 =C2=A0 Time_5: =C2=A0Client_B's priority is changed (UNUSUAL) to= priority 7
=C2=A0 =C2=A0 =C2=A0 Time_6 =C2=A0 Client_B writes X= =3DP with priority 7 and succeeds (same owner, no priority check)

The alternate approach would have store the priority with w= hich a node was written.=C2=A0 That is more like a priority lock that could= only be changed by a client with higher priority or by the same client, re= gardless of priority.=C2=A0 This approach would require storing a priority = per node and the semantic implications would be as follows:

<= /div>
=C2=A0 =C2=A0 =C2=A0 Time_1: =C2=A0Client_A writes X=3DN wit= h priority 10
=C2=A0 =C2=A0 =C2=A0 Time_2: =C2=A0Client_A's p= riority is changed (UNUSUAL) to priority 6
=C2=A0* =C2=A0 =C2=A0T= ime_3: =C2=A0Client_B attempts to write X=3DK with priority 8 =C2=A0and fai= ls (10 > 8)
=C2=A0* =C2=A0 =C2=A0Time_4: =C2=A0Client_A writes= X=3DN with priority 6 & succeeds (same owner, no priority check)
=
=C2=A0 =C2=A0 =C2=A0 Time_5: =C2=A0Client_B's priority is changed = (UNUSUAL) to priority 7
=C2=A0 =C2=A0 =C2=A0 Time_6 =C2=A0 Client= _B writes X=3DP with priority 7 and succeeds (7 > 6)
The behavior for these two models is different at Time_3 and Ti= me_4.

I'd like to see if there's agreement= that the first model (priority stored with client) is acceptable or if the= second model (priority stored with node) is necessary.

Thanks,
Alia
</no-hat>

=
--001a11c3393a048c0a05182c30e3-- From nobody Wed Jun 10 10:16:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398E41ACD80 for ; Wed, 10 Jun 2015 10:16:02 -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 nVzNnQ6sKjYr for ; Wed, 10 Jun 2015 10:15:59 -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 5DF431A90F0 for ; Wed, 10 Jun 2015 10:15:59 -0700 (PDT) Received: by labko7 with SMTP id ko7so37916971lab.2 for ; Wed, 10 Jun 2015 10:15:57 -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=Uns/TK2kBXatNyDqrl1h4JuRCHirwvl49G3u2S1sCfs=; b=fVYMkWOE1JRFYllz0/G8DGC3hfM3D1jJAS2BT6NUgdJJPFo/1eM4du2cAHAXxBCQS0 DtQ7WhkWmFK/+LkugdMpgr/hTD68H/WyGiauJtQnUDXRIT5gOOYqjICl5Ui/EsuZIJ5o 2DGrlpy4ItPXmqx6b4U4gUQRGEeOkrp2pT1QxE/XspDHqaguEjZaXdox4rUcx5HJM1By RShtSgDO9iUOna8A9E676oN/ivT23ylURl65XSeNIMLzAkSeeJhtRp38UVYNNRPFhz7D vKJXBrVBU6OqCPA8+tRZlT4jQyh1ELF7WStO28XDS6R7V+4EOjy5+bahmBCAt+uOOddB ZjOw== X-Gm-Message-State: ALoCoQlwv4Fm7IxRxOEDYPXnMOQbPVu+ye0OnEgTQTLqDWUpi01Xpwrq8xCj+xomGrdII4Y36pNS MIME-Version: 1.0 X-Received: by 10.152.204.7 with SMTP id ku7mr5251100lac.38.1433956557821; Wed, 10 Jun 2015 10:15:57 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 10:15:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 10:15:57 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] storage of priority and client ID with a node 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, 10 Jun 2015 17:16:02 -0000 On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas wrote: > > As I mentioned in the virtual interim, I'd like to explain a little further > about what I see as semantics and desired behavior around the storing and > managing of priority and client ID. > > First, the priority mechanism is intended to handle "error cases of > colliding writes" in a predictable way that results in a consistent > mechanism. It is true that the same mechanism could be used if they weren't > considered "errors". I think this is a nice property - but it is also > important to minimize the impact of the priority mechanism. > > Second, if there is a priority conflict where both clients (Client_A and > Client_B) share the same priority, the client that wrote first wins. This > is to avoid network oscillation if two clients are "fighting" over writing > the same state. When there are multiple clients and the time arrival of the > messages may not be predictable (network transit differences, which socket > is read, software differences), basing state on last arrival time doesn't > give consistent and predictable behavior. > Neither does "first wins". It is just as arbitrary and based on the same unpredictable network. I think the "higher priority wins" could be useful for I2RS where multiple applications are touching the same RIB data structures. This is a new twist -- competing configuration management apps don't usually occur so it has not been an issue for NETCONF. > That gives behavior as in the following time-line: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_B attempts to write X=K with priority 10 and is rejected > Time_3: Client_A writes X=P with priority 10 and succeeds > > For the I2RS Agent to properly handle these actions, it is necessary to know > that X is owned by Client_A. Priority alone is not sufficient because the > basis for rejecting Client_B's write but accepting Client_A's write is that > Client_A is the owner. > > Thus, I believe that it is necessary to store the Client Identity with the > nodes that it owns. > This could be in an I2RS-specific overlay that is only used by the I2RS > agent and only contains the nodes that have been written by I2RS. > IMO a tie is an error (as Joel put it). First one in a tie or last one in a tie is just as arbitrary and unpredictable. Last one does not require saving the client. First one does. But IMO it is useful to save the client so it can be returned in meta-data or filtered (e.g. GET(all-for-client-A)), so first-one wins is not a big deal to support. > Third, a question has come up regarding what the behavior of priority is if > a client's priority changes and whether priority needs to be stored with > each node when that node is written. > > In my "keep-it-simple" perspective, priority is associated with a Client and > is only used on a conflict. This would mean that priority isn't stored with > a node when that node is written. Instead, the Client Identity is stored > with the node and the Client's priority is looked up in a client table that > the I2RS Agent can access. That client table could be populated via > configuration, via a AAA protocol, via NACM, etc. > > The semantic implications are as follows: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > 6) > * Time_4: Client_A attempts to write X=N with priority 6 (fails b/c 8 >> 6) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (same owner, > no priority check) > > The alternate approach would have store the priority with which a node was > written. That is more like a priority lock that could only be changed by a > client with higher priority or by the same client, regardless of priority. > This approach would require storing a priority per node and the semantic > implications would be as follows: > > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B attempts to write X=K with priority 8 and fails (10 >> 8) > * Time_4: Client_A writes X=N with priority 6 & succeeds (same owner, > no priority check) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) > > The behavior for these two models is different at Time_3 and Time_4. > > I'd like to see if there's agreement that the first model (priority stored > with client) is acceptable or if the second model (priority stored with > node) is necessary. I think the first model is OK. > > Thanks, > Alia > > > Andy > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Jun 10 11:54: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 E6D6E1A6FBB for ; Wed, 10 Jun 2015 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 sbv8P7HYm8zh for ; Wed, 10 Jun 2015 11:54:12 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5361A6FCB for ; Wed, 10 Jun 2015 11:54:11 -0700 (PDT) Received: by obbqz1 with SMTP id qz1so41728151obb.3 for ; Wed, 10 Jun 2015 11:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MQLI2dSDN/frv1hXapOov1LB2bO9h3xarMDi3puzjhI=; b=C6NOqkhZRteAobtwHBjurndCT0ifldN89GsGD0WTODTMqmPMIPdTaebzhDk+fbhD/V WZXZ7bK8NbOgEKodVt7HhTYSqJ4UbhS8zVUN2stBPK3iYjPZx+Tt/Y13QITyNy3L5fTB 972vSyF6ECzVrpedg8Nwzx0kObbFbqc1x2Nv09cRp1okiNa+OI0L0zUMNeWcbFPHDOiy uYg8ZPMAjFtmQFFE4agjdwmrDOIXEcnKYfHg1Viv2K3c916bvO8DhKTPB4TGwMd1u3s6 T0a2Cr4zL+r75nrd2+cnFMSB6QYqNuJRxMiqt+WqtauaLYeLJduFSm7uOPFVvK9qifZ9 PSPQ== MIME-Version: 1.0 X-Received: by 10.60.74.34 with SMTP id q2mr4139846oev.68.1433962451271; Wed, 10 Jun 2015 11:54:11 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Wed, 10 Jun 2015 11:54:11 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 14:54:11 -0400 Message-ID: From: Alia Atlas To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1135fc5a87854805182e6656 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] storage of priority and client ID with a node 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, 10 Jun 2015 18:54:15 -0000 --001a1135fc5a87854805182e6656 Content-Type: text/plain; charset=UTF-8 Hi Andy, On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman wrote: > On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas wrote: > > > > As I mentioned in the virtual interim, I'd like to explain a little > further > > about what I see as semantics and desired behavior around the storing and > > managing of priority and client ID. > > > > First, the priority mechanism is intended to handle "error cases of > > colliding writes" in a predictable way that results in a consistent > > mechanism. It is true that the same mechanism could be used if they > weren't > > considered "errors". I think this is a nice property - but it is also > > important to minimize the impact of the priority mechanism. > > > > Second, if there is a priority conflict where both clients (Client_A and > > Client_B) share the same priority, the client that wrote first wins. > This > > is to avoid network oscillation if two clients are "fighting" over > writing > > the same state. When there are multiple clients and the time arrival of > the > > messages may not be predictable (network transit differences, which > socket > > is read, software differences), basing state on last arrival time doesn't > > give consistent and predictable behavior. > > > > Neither does "first wins". It is just as arbitrary and based on the same > unpredictable network. > [Alia] Sure - but doing "first wins" in the event of the same priority ensures that it won't oscillate. Doing "last arrival time" lets it oscillate. I think the "higher priority wins" could be useful for I2RS > where multiple applications are touching the same RIB data structures. > This is a new twist -- competing configuration management apps > don't usually occur so it has not been an issue for NETCONF. [Alia] Agreed - IMHO, a network operator would assign different priorities to each client so that the conflicts with the same priority don't happen. I can see different clients managing different services or such. > > That gives behavior as in the following time-line: > > Time_1: Client_A writes X=N with priority 10 > > Time_2: Client_B attempts to write X=K with priority 10 and is > rejected > > Time_3: Client_A writes X=P with priority 10 and succeeds > > > > For the I2RS Agent to properly handle these actions, it is necessary to > know > > that X is owned by Client_A. Priority alone is not sufficient because > the > > basis for rejecting Client_B's write but accepting Client_A's write is > that > > Client_A is the owner. > > > > Thus, I believe that it is necessary to store the Client Identity with > the > > nodes that it owns. > > This could be in an I2RS-specific overlay that is only used by the I2RS > > agent and only contains the nodes that have been written by I2RS. > > > > IMO a tie is an error (as Joel put it). > First one in a tie or last one in a tie is just as arbitrary > and unpredictable. Last one does not require saving the client. > First one does. > [Alia] I agree that last one wouldn't require saving the client - but it also wouldn't prevent oscillations if there were two clients fighting over writing their state. But IMO it is useful to save the client so it can be returned in meta-data > or filtered (e.g. GET(all-for-client-A)), so first-one wins is not > a big deal to support. > Agreed that saving the client can be useful for filtering or monitoring apps. > > Third, a question has come up regarding what the behavior of priority is > if > > a client's priority changes and whether priority needs to be stored with > > each node when that node is written. > > > > In my "keep-it-simple" perspective, priority is associated with a Client > and > > is only used on a conflict. This would mean that priority isn't stored > with > > a node when that node is written. Instead, the Client Identity is stored > > with the node and the Client's priority is looked up in a client table > that > > the I2RS Agent can access. That client table could be populated via > > configuration, via a AAA protocol, via NACM, etc. > > > > > The semantic implications are as follows: > > Time_1: Client_A writes X=N with priority 10 > > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > > 6) > > * Time_4: Client_A attempts to write X=N with priority 6 (fails > b/c 8 > >> 6) > > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > > Time_6 Client_B writes X=P with priority 7 and succeeds (same > owner, > > no priority check) > > > > The alternate approach would have store the priority with which a node > was > > written. That is more like a priority lock that could only be changed > by a > > client with higher priority or by the same client, regardless of > priority. > > This approach would require storing a priority per node and the semantic > > implications would be as follows: > > > > Time_1: Client_A writes X=N with priority 10 > > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > > * Time_3: Client_B attempts to write X=K with priority 8 and fails > (10 > >> 8) > > * Time_4: Client_A writes X=N with priority 6 & succeeds (same > owner, > > no priority check) > > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) > > > > The behavior for these two models is different at Time_3 and Time_4. > > > > I'd like to see if there's agreement that the first model (priority > stored > > with client) is acceptable or if the second model (priority stored with > > node) is necessary. > > I think the first model is OK. > Thanks, Alia > > > > > Thanks, > > Alia > > > > > > > > > Andy > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a1135fc5a87854805182e6656 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andy,

On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman <andy@yumaworks= .com> wrote:
On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas <akatlas@gmail.com> wrote:
> <no-hat>
> As I mentioned in the virtual interim, I'd like to explain a littl= e further
> about what I see as semantics and desired behavior around the storing = and
> managing of priority and client ID.
>
> First, the priority mechanism is intended to handle "error cases = of
> colliding writes" in a predictable way that results in a consiste= nt
> mechanism.=C2=A0 It is true that the same mechanism could be used if t= hey weren't
> considered "errors".=C2=A0 I think this is a nice property -= but it is also
> important to minimize the impact of the priority mechanism.
>
> Second, if there is a priority conflict where both clients (Client_A a= nd
> Client_B) share the same priority, the client that wrote first wins.= =C2=A0 This
> is to avoid network oscillation if two clients are "fighting"= ; over writing
> the same state.=C2=A0 When there are multiple clients and the time arr= ival of the
> messages may not be predictable (network transit differences, which so= cket
> is read, software differences), basing state on last arrival time does= n't
> give consistent and predictable behavior.
>

Neither does "first wins".=C2=A0 It is just as arbitrary a= nd based on the same
unpredictable network.

[Alia] Sure - bu= t doing "first wins" in the event of the same priority ensures th= at
it won't oscillate.=C2=A0 Doing =C2=A0"last arrival t= ime" lets it oscillate.=C2=A0

I think the "higher priority wins" could be useful for I2RS
where multiple applications are touching the same RIB data structures.
This is a new twist -- competing configuration management apps
don't usually occur so it has not been an issue for NETCONF.
=C2=A0
[Alia] Agreed - IMHO, a network operator would assi= gn different priorities to
each client so that the conflicts with= the same priority don't happen.=C2=A0 I can see
different cl= ients managing different services or such.
=C2=A0
> That gives behavior as in th= e following time-line:
>=C2=A0 =C2=A0 =C2=A0Time_1:=C2=A0 Client_A writes X=3DN with priority 1= 0
>=C2=A0 =C2=A0 =C2=A0Time_2:=C2=A0 Client_B attempts to write X=3DK with= priority 10 and is rejected
>=C2=A0 =C2=A0 =C2=A0Time_3:=C2=A0 Client_A writes X=3DP with priority 1= 0 and succeeds
>
> For the I2RS Agent to properly handle these actions, it is necessary t= o know
> that X is owned by Client_A.=C2=A0 Priority alone is not sufficient be= cause the
> basis for rejecting Client_B's write but accepting Client_A's = write is that
> Client_A is the owner.
>
> Thus, I believe that it is necessary to store the Client Identity with= the
> nodes that it owns.
> This could be in an I2RS-specific overlay that is only used by the I2R= S
> agent and only contains the nodes that have been written by I2RS.
>

IMO a tie is an error (as Joel put it).
First one in a tie or last one in a tie is just as arbitrary
and unpredictable.=C2=A0 Last one does not require saving the client.
First one does.

[Alia] I agree that las= t one wouldn't require saving the client - but it also
wouldn= 't prevent oscillations if there were two clients fighting over writing=
their state.=C2=A0

But IMO it is useful to save the client so it can be returned in meta-data<= br> or filtered (e.g. GET(all-for-client-A)), so first-one wins is not
a big deal to support.

Agreed that savi= ng the client can be useful for filtering or monitoring apps.
=C2= =A0
> Third, a question has come up regarding what th= e behavior of priority is if
> a client's priority changes and whether priority needs to be store= d with
> each node when that node is written.
>
> In my "keep-it-simple" perspective, priority is associated w= ith a Client and
> is only used on a conflict.=C2=A0 This would mean that priority isn= 9;t stored with
> a node when that node is written.=C2=A0 Instead, the Client Identity i= s stored
> with the node and the Client's priority is looked up in a client t= able that
> the I2RS Agent can access.=C2=A0 That client table could be populated = via
> configuration, via a AAA protocol, via NACM, etc.

>
> The semantic implications are as follows:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_1:=C2=A0 Client_A writes X=3DN with pri= ority 10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_2:=C2=A0 Client_A's priority is cha= nged (UNUSUAL) to priority 6
>=C2=A0 *=C2=A0 =C2=A0 Time_3:=C2=A0 Client_B writes X=3DK with priority= 8=C2=A0 (succeeds since 8 > 6)
>=C2=A0 *=C2=A0 =C2=A0 Time_4:=C2=A0 Client_A attempts to write X=3DN wi= th priority 6=C2=A0 (fails b/c 8
>> 6)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_5:=C2=A0 Client_B's priority is cha= nged (UNUSUAL) to priority 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_6=C2=A0 =C2=A0Client_B writes X=3DP wit= h priority 7 and succeeds (same owner,
> no priority check)
>
> The alternate approach would have store the priority with which a node= was
> written.=C2=A0 That is more like a priority lock that could only be ch= anged by a
> client with higher priority or by the same client, regardless of prior= ity.
> This approach would require storing a priority per node and the semant= ic
> implications would be as follows:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_1:=C2=A0 Client_A writes X=3DN with pri= ority 10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_2:=C2=A0 Client_A's priority is cha= nged (UNUSUAL) to priority 6
>=C2=A0 *=C2=A0 =C2=A0 Time_3:=C2=A0 Client_B attempts to write X=3DK wi= th priority 8=C2=A0 and fails (10
>> 8)
>=C2=A0 *=C2=A0 =C2=A0 Time_4:=C2=A0 Client_A writes X=3DN with priority= 6 & succeeds (same owner,
> no priority check)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_5:=C2=A0 Client_B's priority is cha= nged (UNUSUAL) to priority 7
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Time_6=C2=A0 =C2=A0Client_B writes X=3DP wit= h priority 7 and succeeds (7 > 6)
>
> The behavior for these two models is different at Time_3 and Time_4. >
> I'd like to see if there's agreement that the first model (pri= ority stored
> with client) is acceptable or if the second model (priority stored wit= h
> node) is necessary.

I think the first model is OK.

<= div>=C2=A0Thanks,
Alia

>
> Thanks,
> Alia
> </no-hat>
>
>


Andy

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

--001a1135fc5a87854805182e6656-- From nobody Wed Jun 10 13:19: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 BC90F1A88FC for ; Wed, 10 Jun 2015 13:19:42 -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 j0jMHZny3kuX for ; Wed, 10 Jun 2015 13:19:40 -0700 (PDT) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) (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 217CB1AC3A0 for ; Wed, 10 Jun 2015 13:19:38 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so35053996lbb.3 for ; Wed, 10 Jun 2015 13:19:36 -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=oh8hBjQWr5v+WHJ/5IlmXnGi4P2zRwh7OY7j99cOPgA=; b=i3hM7uFE0YP1ArmVlYwU3uEG4nCdtAICqCdExUuvkJhmLTwMvyvuHlJA7LC21QgYga EntpRTmkeQ+Wlwl64K6ZR7SDRf0uqrsTYnbL1mzSnKtMQ/FmOUBbI8ZERzW1JsD4jGau VxbQ+2/AZnJiaQIyeTFPKAZ6rcRgIT2a70p9P7LYqYOy4F1bLydduZE+32wXDM+Ptmgq 9ybRJ9HRR+08r/hP9qCYUe2pqLADfZb+7v3fLqfFbS9nW/sCfIPmsEUrXfVZ+wVwj0PP SQxi+F3k9ft6Fou6Mhod5LUAvYaPDxk32yeThQdwNtC1WVYBMhXC+mBhrn9P9MgNBNeQ OY3g== X-Gm-Message-State: ALoCoQmUTHffzGBvMw/JKA61+mvURW3sSwJ+gnHnfCrIw2mpb3Z06AO0j45PR07qRKRAQQim5zk3 MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr5923799laj.123.1433967576659; Wed, 10 Jun 2015 13:19:36 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 10 Jun 2015 13:19:36 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 13:19:36 -0700 Message-ID: From: Andy Bierman To: Alia Atlas Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] storage of priority and client ID with a node 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, 10 Jun 2015 20:19:42 -0000 On Wed, Jun 10, 2015 at 11:54 AM, Alia Atlas wrote: > Hi Andy, > > On Wed, Jun 10, 2015 at 1:15 PM, Andy Bierman wrote: >> >> On Wed, Jun 10, 2015 at 9:15 AM, Alia Atlas wrote: >> > >> > As I mentioned in the virtual interim, I'd like to explain a little >> > further >> > about what I see as semantics and desired behavior around the storing >> > and >> > managing of priority and client ID. >> > >> > First, the priority mechanism is intended to handle "error cases of >> > colliding writes" in a predictable way that results in a consistent >> > mechanism. It is true that the same mechanism could be used if they >> > weren't >> > considered "errors". I think this is a nice property - but it is also >> > important to minimize the impact of the priority mechanism. >> > >> > Second, if there is a priority conflict where both clients (Client_A and >> > Client_B) share the same priority, the client that wrote first wins. >> > This >> > is to avoid network oscillation if two clients are "fighting" over >> > writing >> > the same state. When there are multiple clients and the time arrival of >> > the >> > messages may not be predictable (network transit differences, which >> > socket >> > is read, software differences), basing state on last arrival time >> > doesn't >> > give consistent and predictable behavior. >> > >> >> Neither does "first wins". It is just as arbitrary and based on the same >> unpredictable network. > > > [Alia] Sure - but doing "first wins" in the event of the same priority > ensures that > it won't oscillate. Doing "last arrival time" lets it oscillate. > OK -- I forgot I2RS clients might be coded to send an edit if they get the notification for "your data was deleted". If 2 with the same priority do that, they will oscillate. NETCONF is more set-it-and-forget-it. Andy >> I think the "higher priority wins" could be useful for I2RS >> where multiple applications are touching the same RIB data structures. >> This is a new twist -- competing configuration management apps >> don't usually occur so it has not been an issue for NETCONF. > > > [Alia] Agreed - IMHO, a network operator would assign different priorities > to > each client so that the conflicts with the same priority don't happen. I > can see > different clients managing different services or such. > >> >> > That gives behavior as in the following time-line: >> > Time_1: Client_A writes X=N with priority 10 >> > Time_2: Client_B attempts to write X=K with priority 10 and is >> > rejected >> > Time_3: Client_A writes X=P with priority 10 and succeeds >> > >> > For the I2RS Agent to properly handle these actions, it is necessary to >> > know >> > that X is owned by Client_A. Priority alone is not sufficient because >> > the >> > basis for rejecting Client_B's write but accepting Client_A's write is >> > that >> > Client_A is the owner. >> > >> > Thus, I believe that it is necessary to store the Client Identity with >> > the >> > nodes that it owns. >> > This could be in an I2RS-specific overlay that is only used by the I2RS >> > agent and only contains the nodes that have been written by I2RS. >> > >> >> IMO a tie is an error (as Joel put it). >> First one in a tie or last one in a tie is just as arbitrary >> and unpredictable. Last one does not require saving the client. >> First one does. > > > [Alia] I agree that last one wouldn't require saving the client - but it > also > wouldn't prevent oscillations if there were two clients fighting over > writing > their state. > >> But IMO it is useful to save the client so it can be returned in meta-data >> or filtered (e.g. GET(all-for-client-A)), so first-one wins is not >> a big deal to support. > > > Agreed that saving the client can be useful for filtering or monitoring > apps. > >> >> > Third, a question has come up regarding what the behavior of priority is >> > if >> > a client's priority changes and whether priority needs to be stored with >> > each node when that node is written. >> > >> > In my "keep-it-simple" perspective, priority is associated with a Client >> > and >> > is only used on a conflict. This would mean that priority isn't stored >> > with >> > a node when that node is written. Instead, the Client Identity is >> > stored >> > with the node and the Client's priority is looked up in a client table >> > that >> > the I2RS Agent can access. That client table could be populated via >> > configuration, via a AAA protocol, via NACM, etc. >> >> > >> > The semantic implications are as follows: >> > Time_1: Client_A writes X=N with priority 10 >> > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 >> > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > >> > 6) >> > * Time_4: Client_A attempts to write X=N with priority 6 (fails >> > b/c 8 >> >> 6) >> > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 >> > Time_6 Client_B writes X=P with priority 7 and succeeds (same >> > owner, >> > no priority check) >> > >> > The alternate approach would have store the priority with which a node >> > was >> > written. That is more like a priority lock that could only be changed >> > by a >> > client with higher priority or by the same client, regardless of >> > priority. >> > This approach would require storing a priority per node and the semantic >> > implications would be as follows: >> > >> > Time_1: Client_A writes X=N with priority 10 >> > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 >> > * Time_3: Client_B attempts to write X=K with priority 8 and fails >> > (10 >> >> 8) >> > * Time_4: Client_A writes X=N with priority 6 & succeeds (same >> > owner, >> > no priority check) >> > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 >> > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) >> > >> > The behavior for these two models is different at Time_3 and Time_4. >> > >> > I'd like to see if there's agreement that the first model (priority >> > stored >> > with client) is acceptable or if the second model (priority stored with >> > node) is necessary. >> >> I think the first model is OK. > > > Thanks, > Alia >> >> >> > >> > Thanks, >> > Alia >> > >> > >> > >> >> >> Andy >> >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> > > > From nobody Thu Jun 11 13:11: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 516641B313E for ; Thu, 11 Jun 2015 13:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 8sPNKmeYZ3iH for ; Thu, 11 Jun 2015 13:11:38 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47161A1B4A for ; Thu, 11 Jun 2015 13:11:38 -0700 (PDT) Received: by obbqz1 with SMTP id qz1so10455084obb.3 for ; Thu, 11 Jun 2015 13:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gk43EUXIyHs5nxq+XjVtithW0k3CLG0QvQ/pH4cipoA=; b=S4qEE3SJ1iWdOguUO4xLrVPGlD9kKRjGZDC4hCfLZJYjgNL5DYJuxOIBL7IFs2b+pf BunGb+HdFQYFsmnRJXwM2kY0V5dsWTRXQiOLa0+UeOnI2r9fsUBeDijfaNi0dEBdQ/ED CFhth+3iOw7H0ERubaepKulkTBF55PUbJ9L2XtdVzitPvP261SkA0RmQVGUiSVEbuRXb cTH6Auc+qJMGx0cZxvGTOkT5IseeraTZY5S/4pcVFuCA7CnGL9s/kRKC10D0LJ9RN2nJ aw74ffm7wtMP4ytglZnWrvP6O1b3FHwrxcijGFrdPKHfKiKaIB4Jsp0Nix+ckpMMBr+P /5Fw== MIME-Version: 1.0 X-Received: by 10.182.29.68 with SMTP id i4mr9154742obh.57.1434053498151; Thu, 11 Jun 2015 13:11:38 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Thu, 11 Jun 2015 13:11:38 -0700 (PDT) Date: Thu, 11 Jun 2015 16:11:38 -0400 Message-ID: From: Alia Atlas To: "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2993a58a9ee05184399f1 Archived-At: Subject: [i2rs] quick comment on draft-hares-i2rs-auth-trans-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, 11 Jun 2015 20:11:40 -0000 --001a11c2993a58a9ee05184399f1 Content-Type: text/plain; charset=UTF-8 Sue, Thanks for writing this draft. I think it is useful to clearly articulate the outside-of-I2RS behavior and protocols that are needed for the mutual authentication. I do have a couple comments on the draft. In Sec 3.1, it says "Each Identity will be linked to one secondary identity for the period of a connection." I would have assumed that the client could arbitrarily change its' secondary identity. This is to support the broker case where a client may be passing along requests from multiple applications. Since the secondary identity is just passed along and stored for traceability, I don't think that allowing it to change would cause significant complications. What do others think? In the I2RS architecture, there are 3 different types of transaction behavior desired for processing a message. In Sec 4, there's an assumption that "fail-on-error" with the associated roll-back is the only mode. Thus, I think that Section 4 needs a bit of massaging. Thanks, Alia --001a11c2993a58a9ee05184399f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<no-hat>

Sue,

Thanks for writing this = draft.=C2=A0 I think it is useful to clearly articulate the outside-of-I2RS= behavior and protocols that are needed for the mutual authentication.=C2= =A0 I do have a couple comments on the draft.


In Sec 3.1, it say= s "Each Identity will be linked to one secondary identity for the peri= od of a connection." =C2=A0I would have assumed that the client could = arbitrarily change its' secondary identity.=C2=A0 This is to support th= e broker case where a client may be passing along requests from multiple ap= plications.=C2=A0 Since the secondary identity is just passed along and sto= red for traceability, I don't think that allowing it to change would ca= use significant complications. =C2=A0 What do others think?


In t= he I2RS architecture, there are 3 different types of transaction behavior d= esired for processing a message. In Sec 4, there's an assumption that &= quot;fail-on-error" with the associated roll-back is the only mode. = =C2=A0 Thus, I think that Section 4 needs a bit of massaging.


Th= anks,

Alia
--001a11c2993a58a9ee05184399f1-- From nobody Fri Jun 12 08:45: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 589571A0364; Fri, 12 Jun 2015 08:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 83968Op-yqCj; Fri, 12 Jun 2015 08:45:21 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 03F141A1B17; Fri, 12 Jun 2015 08:44:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> In-Reply-To: <20150604062424.GA40773@elstar.local> Date: Fri, 12 Jun 2015 11:43:38 -0400 Message-ID: <011d01d0a526$8d909ef0$a8b1dcd0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011E_01D0A505.0686C720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipnr9VKfA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 12 Jun 2015 15:45:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011E_01D0A505.0686C720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: Mahesh Jethanandari indicated that he wanted to make sure the comment after 2c below has been responded to the following comment: >"I am concerned about adding protocol mechanisms that are specific to a certain data model. > It is unclear what a "node" unit it, terms like 'highly reliable notifications' and 'high bandwidth, > asynchronous interface, with real-time guarantees' are somewhat unclear - how do we > determine we have met any of these requirements?" I want to thank you and Mahesh for making sure this question gets asked. You are correct that I2RS is data-model focused, and the unit of notification is data dependent. Below my best estimate of the units with times, notifications, normal groups of the units with times. See Definitions for the info, I2RS Model info, Notifications and read/write groupings. Would it be helpful to have this information on a wiki-page for now? I will query each model author to provide their input to the wiki page, and start a discussion on the mail list. I think it is useful to put these requirements in their drafts. What do you think? Sue Hares =================================== Definitions A few repetitions of the definitions may help from the architecture document and interims may help: Highly reliable notifications: are notifications which provide notifications which align with the current status. In the I2RS interim notes, we noted notifications are not logging which is covered by the traceability draft. Notifications are status changes and each model provides the status changes. If the changes come too quickly (E.g. route changes), then the change will give the latest status. Highly reliable notifications are guaranteed to arrive normally, but buffer overrun or system issue may cause a few to be lost. Perfectly reliable notifications are possible in high-available systems which duplicate streams of data. The I2RS WG is not asking for perfectly reliable data streams. High-bandwidth: It is assumed that the pull of a full RIB, full topology model (all topologies), and a full FB-FIB is possible. However, the normal mode is a query of a portion of these models. As discussed in the 5/27/2015 interim, a full pull may find that portions of the RIB change during the pull. Joel Halpern suggest NETCONF may be a better mechanism for the full dump. However, the portions of the models - must be reported quickly so that programmatic changes can be made. Asynchronous: means that multiple streams of data from different transport sessions can query/write different portions of any of the I2RS models in parallel - AND these read/write portions of the model can operates in parallel along with pub/sub, traceability. Writes operate in parallel operating on portions of the model. Exact definition of locking of the portion of a model for a write has been discussed, but this should be discussed per module. Real-time guarantees: Real time guarantees means that the processing and response must be listed under a certain time per module. The module can give general ranges, but the specific definition is left to the implementation. I will start a mail thread on these guarantees per module. My understanding is that we are looking for seconds or sub-second in routes, portions of topology, and in the filter rule. I2RS Module information =============================== This node will provide you the unit of focus for the protocol independent modules (I2RS RIB, I2RS topology, and I2RS Filter-Based RIB Model). The I2RS RIB and I2RS Topology have yang modules, and the I2RS Filter-Based RIB Model has an Information al model so we can provide the unit of focus. (Hopefully, the I2RS Filter-based RIB Model will have the yang model read by 6/24) Protocol independent models (info/yang) were developed for BGP, OSPF, ISIS, MPLS and SFC. These yang modules are being revised and could be reviewed at the 6/24/2015 interim. These drafts are in flux so I need to query the mail list on the use cases, and the authors on their changes. I can get more detail by the end of next week so we can talk about it at the 6/24/2015 interim. Some of the flux is the also base yang modules (as an example BGP) that impacts derivatives (EVPN, L2VPN, L3VPN). I have reference the explanation sections in the I2RS drafts. As a yang doctor, I hope it is evident which yang language parallel to these sections. (if not, please post suggestions for corrections so the authors can fix these drafts). Model Unit type reference Frequency of reference ======= ======== ============ ========= =============================== I2RS RIB Route main key unit section 2.3 high R/W Next-hop dependent subunit section 2.4 high to medium R/W RIB grouping of routes section 2.2 Initial start-up (mostly R/ some W) RIB list grouping of RIBS section 2.1 Initial start-up (mostly R/ some W) The topology nodes are out for the non-TE version. TE version will not arrive until IETF time-frame. I2RS Topology Unit Type Reference Frequency of Reference ============== ======== ======= =========== =========================== Generic Topology Node main unit section 3.1 R/W or W from agent data Link main unit section 3.2 R/W or W from agent data Network main unit section 3.1/3.2 R/W or W from Agent Full pull query Termination sub-unit section 3.1 - point L2 Topology same as generic section 2 - see note on TE additions L3 Topology same as generic section 3.2 for IGP - see note on TE Additions Section 3.3 for OSPF L1 Topology same as generic See note: draft being overhauled to align to TEAS link & TE models Service Topology same as generic See note: draft being overhauled to link to L3SM style of service topologies Module: Unit Type Section Frequency ======== ====== ====== ==================== ========== FB-RIB policy-rule main unit section 4.2 info module R/W main unit FB-RIB_ Ordered list of see section 4.1-4.3 R/W policy rule inserted ordered-list filters into ordered list interface-list ordered list see section 4.2-4.3 Initial start-up /config of interface + interface status references FB-RIB RIB group see section 4.1 to 4.2 Groups policy-rule + Interfaces Note on Topology modules . All topology will be augment by TE modules with structure in draft-ietf-teas-yang-te-topo-00 as updated by https://github.com/ietf-mpls-yang/te. . L1 topology draft - will be overhauled based on decision on ephemeral state (just completed), and the TE drafts which have topology. It may take portions of other TEAS drafts ( draft-saad-teas-yang-te-01) . Service module needs to provide link to work from service. Only one service model is being designed: o L3SM - protocol independent service module for L3 services (https://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ o L2SM - is not yet started. o Service forwarding topologies - initial draft done Notifications Status Timing ----------------- --------------------------------------------- -------- I2RS RIB nexthop-resolution-status-change second or less Route-change second or less L3 Topology igp-node-event second or less igp-link-event igp-prefix-event igp-termination-point-event L2 Topology TBD - but likely the same) second or less (l2-node-event, l2-link-event, l2-prefix-event, L2-termination-point-event) L1 Topology TBD- but likely the same second or less Service Topology Unknown - too much in flux FB-RIB FB-RIB interface loss second or less Policy-Rule interface loss second or less Policy-Rule second+ Query/Write Groupings Normal High Normal Time High BW time --------------------- ---------- ---------------------- ----------------- ------------------- I2RS RIB: Routes 1-10Ks 100K to 1Million < 1 second 1-5 second I2RS RIB: RIBs 1-20 RIBs 100-300 RIB TBD TBD (10K-100K RT) (10K-100k) Topology 1-5K node not really sure TBD TBD 300-10K links 1K - 50K topology FB RIB 1-10K rules not really sure <1 second TBD *tp = termination point -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, June 04, 2015 2:24 AM To: Susan Hares Cc: i2rs@ietf.org; jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-inter > im-201 > 5-i2rs-8 > > > > These minute provide a lengthy of issues in the requirements. From > these minutes, there are the following 6 conclusions on the protocol > requirements that Jeff stated: > > > > 1) There will be no consideration of an overlay model unless a fully > formed proposal is presented. > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > had lots of suggestions regarding an overlay proposal - but no full > proposal. At this time, the WG will only consider full proposals and > not suggestions toward a proposal. For the record: I am highly concerned about solutions that require (i) separate data models for ephemeral state and (ii) data model specific merge logic. While this may work for I2RS, this approach does not scale or has a very high cost of scaling to other ephemeral state editing needs. > 2) Jeff's document provides details on ephemeral state requirements > that have not changed. These requirements include: > > a. Highly reliable notifications (but not perfectly reliable > notifications) > > b. High bandwidth, asynchronous interface, with real-time guarantees on > getting data, > > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is > the "node" unit. For example, the I2RS RIB node unit is the route. I am concerned about adding protocol mechanisms that are specific to a certain data model. It is unclear what a "node" unit it, terms like 'highly reliable notifications' and 'high bandwidth, asynchronous interface, with real-time guarantees' are somewhat unclear - how do we determine we have met any of these requirements? > d. There is one priority per client. > > e. Priority is kept in the NACM at the client level [rather than path > level (5/27 meeting) or group level (list discussion). Why does this mapping of username to priority have to be maintained in NACM? > 3) Joel suggests that large data write may be best done in netconf with > guarantees > > a. I2RS will be focused on highly asynchronous interfaces with less > than full routing tables. > > b. A client whose large data is interrupted by a notification has a > difficult time determine when the notification happened in the stream > - so the I2RS client must ask the agent again. > > c. Logging for traceability is different than event notification. Except c), I do not understand this. What are these 'guarantees' 3) is about? > 5) Secondary identity data is read-only meta-data that is stored in the > agent associated with a data model node that is being created or > updated > (write-access) in the data store. Ehem, what is read-only data that is created or written? Did you want to say that the identity meta-data is immutable once a data node has been created? And if so, has priority the same property: Is priority of a data node is determined at creation time and then immutable? > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > I am not sure how agent identity authentication via AAA works. Can someone point me to the right direction if I assume a secure transport such as SSH or TLS? /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/> ------=_NextPart_000_011E_01D0A505.0686C720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Mahesh = Jethanandari indicated that he wanted to make sure the comment after 2c = below has been responded to the following comment:

 

>"I am concerned about adding protocol = mechanisms that are specific to a certain data model.

> It is unclear what a "node" unit it, = terms like 'highly reliable notifications' and 'high = bandwidth,

> asynchronous = interface, with real-time guarantees' are somewhat unclear - how do we =

> determine we have met any of = these requirements?"

 

I want = to thank you and Mahesh for making sure this question gets asked. =

 

You are correct that I2RS is data-model focused, = and the unit of notification is data dependent. Below my best estimate = of the units with times, notifications,  normal groups of the units = with times.  See Definitions for the info, I2RS Model info, = Notifications and read/write groupings.

Would it be helpful to have this information on a = wiki-page for now?  I will query each model author to provide their = input to the wiki page, and start a discussion on the mail list. =

 

I think it is useful to put these requirements in = their drafts.  What do you think?

 

 

Sue = Hares

 

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

Definitions

A few = repetitions of the definitions may help from the architecture document = and interims may help:

 

Highly reliable notifications: are = notifications which provide notifications which align with the current = status.  In the I2RS interim notes, we noted notifications are not = logging which is covered by the traceability draft.  Notifications = are status changes and each model provides the status changes.  If = the changes come too quickly (E.g. route changes), then the change will = give the latest status. Highly reliable notifications are guaranteed to = arrive normally, but buffer overrun or system issue may cause a few to = be lost.  Perfectly reliable notifications are possible in = high-available systems which duplicate streams of data.  The I2RS = WG is not asking for perfectly reliable data streams. =  

 

High-bandwidth:  It is assumed that the = pull of a full RIB, full topology model (all topologies), and a full = FB-FIB is possible.  However, the normal mode is a query of a = portion of these models.  As discussed in the 5/27/2015 interim, a = full pull may find that portions of the RIB change during the = pull.  Joel Halpern suggest NETCONF may be a better mechanism for = the full dump.  However, the portions of the models – must be = reported quickly so that programmatic changes can be = made.

 

Asynchronous: means that multiple streams of = data from different transport sessions can query/write different = portions of any of the I2RS models in parallel – AND these = read/write portions of the model can  operates in parallel along = with pub/sub, traceability.   Writes operate in parallel = operating on portions of the model.  Exact definition of locking of = the portion of a model for a write has been discussed, but this should = be discussed per module. 

 

Real-time guarantees:  Real time = guarantees means that the processing and response must be listed under a = certain time per module.  The module can give general ranges, but = the specific definition is left to the implementation.   I = will start a mail thread on these guarantees per module.  My = understanding is that we are looking for seconds or sub-second in = routes, portions of topology, and in the filter rule.  =

 

 

I2RS Module information

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

This node will provide you the unit of focus for = the protocol independent modules (I2RS RIB, I2RS topology, and I2RS = Filter-Based RIB Model).    The I2RS RIB and I2RS = Topology have yang modules, and the I2RS Filter-Based RIB Model has an = Information al model so we can provide the unit of focus.  =  (Hopefully, the I2RS Filter-based RIB Model will have the yang = model read by 6/24)

 

Protocol independent models (info/yang) were = developed for BGP, OSPF, ISIS, MPLS and SFC. These yang modules are = being revised and could be reviewed at the 6/24/2015 interim.  = These drafts are in flux so I need to query the mail list on the use = cases, and the authors on their changes.  I can get more detail by = the end of next week so we can talk about it at the 6/24/2015 = interim.  Some of the flux is the also base yang modules (as an = example BGP) that impacts derivatives (EVPN, L2VPN, L3VPN).  =  

 

I have reference the explanation sections in the = I2RS drafts.  As a yang doctor, I hope it is evident which yang = language parallel to these sections.  (if not, please post = suggestions for corrections so the authors can fix these drafts). =

 

 Model    =    Unit  =            =    type        &nb= sp; =             &= nbsp;       reference   = ; Frequency of reference =            

=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   &= nbsp;        = =3D=3D=3D=3D=3D=3D=3D=3D=3D   = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

I2RS RIB =    Route        &n= bsp;     main   key = unit           section = 2.3    high R/W   

        &nbs= p;           Next-= hop      dependent subunit    = section 2.4   high to medium R/W

        &nbs= p;       =       RIB =             &= nbsp;   grouping of routes     = section 2.2    Initial start-up (mostly R/ some W) =  

        &nbs= p;       =       RIB list =           grouping of = RIBS         section = 2.1    Initial start-up (mostly R/ some W) =  

 

The topology nodes are out for the non-TE = version.  TE version will not arrive until IETF time-frame. =

 

I2RS = Topology        = Unit       =       Type =           Reference&nbs= p;   =          Frequency of = Reference

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

Generic = Topology =  Node          main = unit    section 3.1 =           R/W or W = from agent data  

        &nbs= p;            = ;            =  Link      =           main unit =      section 3.2 =           R/W or W = from agent data

        &nbs= p;            = ;           =      Network    main = unit    section 3.1/3.2    R/W or W from = Agent

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =            Full pull = query  

        &nbs= p;            = ;            =  Termination sub-unit   section 3.1

        &nbs= p;            = ;            =    - point   

        &nbs= p;            = ;            =             &= nbsp; 

        &nbs= p;            = ;            =             &= nbsp; 

L2 = Topology            = same as = generic           =    section 2 – see note on TE additions =      

L3 = Topology =           same as = generic =             &= nbsp;section 3.2 for IGP – see note on TE Additions =

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;      Section 3.3 for = OSPF

L1 Topology =            same as = generic            =     See note: draft being overhauled to align =

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       to TEAS link & TE = models     

Service Topology  same as generic =           =     See note:  draft being overhauled to link = to

        &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;          =        L3SM style of service topologies =

 

Module:    =     Unit =             &= nbsp;Type =             &= nbsp;         Section =             &= nbsp;           &n= bsp;       Frequency =

=3D=3D=3D=3D=3D=3D=3D=3D  =     =3D=3D=3D=3D=3D=3D   =       =3D=3D=3D=3D=3D=3D =             &= nbsp;   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

FB-RIB   =        policy-rule    =    main = unit          =     section 4.2 info module    R/W main = unit  

        &nbs= p;      

        &nbs= p;            = ; FB-RIB_        =   Ordered list of     see section 4.1-4.3 =           R/W policy = rule inserted

       = ordered-list =          filters =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;        into ordered list =

   

       inte= rface-list    ordered = list       see section = 4.2-4.3       =        Initial start-up /config =  

       &nbs= p;            = ;            =  of interface =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     + interface status

       &nbs= p;            = ;            =      references

 

       FB-RIB =             &= nbsp; RIB group         =     see section 4.1 to = 4.2      Groups policy-rule + =  

        &nbs= p;            = ;           =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;       Interfaces =

 

Note on Topology modules

·         = All topology will be augment by TE = modules with structure in draft-ietf-teas-yang-te-topo-00  as = updated by https://github.com/ietf-mpl= s-yang/te.

·         = L1 topology draft – will be = overhauled based on decision on ephemeral state (just completed), and = the TE drafts which have topology.  It may take portions of other = TEAS drafts (draft-saad-te= as-yang-te-01) =

·         = Service module needs to provide link to = work from service.  Only one service model is being designed: =  

o   L3SM – = protocol independent service module for L3 services (https= ://datatracker.ietf.org/doc/draft-l3vpn-service-yang/

<= p class=3DMsoPlainText = style=3D'margin-left:1.0in;text-indent:-.25in;mso-list:l1 level2 = lfo1'>o   L2SM – is = not yet started.

o   Service = forwarding topologies – initial draft done  

 

=

Notifications =             &= nbsp;   Status =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      Timing =      

-----------------  =             &= nbsp;  ---------------------------------------------  = ;  --------

I2RS RIB  =             &= nbsp; =             &= nbsp;nexthop-resolution-status-change     second or = less

        &nbs= p;       =             &= nbsp; =             &= nbsp; Route-change =             &= nbsp;           &n= bsp;           &nb= sp;   second or less

 

L3 = Topology =             &= nbsp;          = igp-node-event =             &= nbsp;           &n= bsp;      =         second or = less

=             &= nbsp;           &n= bsp;           &nb= sp;     igp-link-event

        &nbs= p;            = ;      =             &= nbsp;   igp-prefix-event

        &nbs= p;            = ;            =             &= nbsp;  igp-termination-point-event

 

L2 = Topology           = ;            = TBD – but likely the = same)           &n= bsp;           &nb= sp;           &nbs= p;        second or = less

        &nbs= p;            = ;            =             &= nbsp;  (l2-node-event, l2-link-event, l2-prefix-event, =

        &nbs= p;            = ;            =             L= 2-termination-point-event)

 

L1 = Topology =             &= nbsp;          TBD- but = likely the same =             &= nbsp;           &n= bsp;           &nb= sp;         second or = less

Service = Topology           = ;   Unknown – too much in flux

 

FB-RIB =             &= nbsp;           &n= bsp;         FB-RIB interface = loss =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     second or less

        &nbs= p;       =             &= nbsp;           &n= bsp;       Policy-Rule interface loss =             &= nbsp;           &n= bsp;           &nb= sp;        second or = less

        &nbs= p;            = ;            =             &= nbsp;  = Policy-Rule          &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  second+

 

 

Query/Write

Groupings =             &= nbsp;    Normal =           High =             &= nbsp;        =             N= ormal Time      High BW time =    

---------------------      = ----------  =           -------------= ---------     -----------------    = -------------------

I2RS RIB: = Routes      1-10Ks =             &= nbsp;100K to 1Million        < 1 = second            = 1-5 second   

I2RS RIB: = RIBs          1-20 RIBs =          100-300 = RIB         =         TBD   &nbs= p;            = ;     TBD =             &= nbsp;          

        &nbs= p;            = ;            =  (10K-100K RT)   (10K-100k) =             &= nbsp;    

 

Topology =             &= nbsp;     1-5K node =        not really sure =             &= nbsp;   = TBD           &nbs= p;            TBD =   

        &nbs= p;            = ;            =    300-10K links

        &nbs= p;            = ;           =        1K – 50K = topology

 

FB RIB =             &= nbsp;     =         1-10K rules  =       not really sure =             <1 = second          TBD =   

*tp =3D termination = point  

 

 

 

-----Original Message-----
From: Juergen = Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: = Thursday, June 04, 2015 2:24 AM
To: Susan Hares
Cc: i2rs@ietf.org; = jhaas@pfrc.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia = Atlas'
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim = (5/27/2015)

 

On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan = Hares wrote:

> The minutes for = the I2RS meeting are at:

> =

> 

>

> www.ietf.org/proceedings/= interim/2015/05/27/i2rs/minutes/minutes-inter

> im-201

> 5-i2rs-8

>

> 

>

> = These minute provide a lengthy of issues in the requirements.  From =

> these minutes, there are the = following 6 conclusions on the protocol

> requirements that Jeff = stated:

>

> 

>

> = 1)      There will be no consideration of an = overlay model unless a fully

> = formed proposal is presented.

>

> = Jeff and I appreciate Ken Watsen's comments on the list, but we have =

> had lots of suggestions = regarding an overlay proposal - but no full

> proposal.  At this time, the WG will only = consider full proposals and

> = not suggestions toward a proposal.

 

For = the record: I am highly concerned about solutions that require (i) = separate data models for ephemeral state and (ii) data model specific = merge logic. While this may work for I2RS, this approach does not scale = or has a very high cost of scaling to other ephemeral state editing = needs.

> 2)      Jeff's = document provides details on ephemeral state = requirements

> that have not = changed.  These requirements include:

>

> = a.       Highly reliable notifications = (but not perfectly reliable

> = notifications)

> =

> = b.      High bandwidth, asynchronous interface, = with real-time guarantees on

> = getting data,

> =

> = c.       Node identification of clients = that write by client identity,

> secondary identity, and priority.  Data = models will determine what is

> the "node" unit.  For example, = the I2RS RIB node unit is the route.

 

I am = concerned about adding protocol mechanisms that are specific to a = certain data model. It is unclear what a "node" unit it, terms = like 'highly reliable notifications' and 'high bandwidth, asynchronous = interface, with real-time guarantees' are somewhat unclear - how do we = determine we have met any of these requirements?

 

> = d.      There is one priority per client. =

>

> e.      Priority is = kept in the NACM at the client level [rather than path

> level (5/27 meeting) or group level (list = discussion). 

 

Why = does this mapping of username to priority have to be maintained in = NACM?

 

> 3)      Joel suggests = that large data write may be best done in netconf with

> guarantees

>

> = a.       I2RS will be focused on highly = asynchronous interfaces with less

> than full routing tables.

>

> = b.      A client whose large data is = interrupted by a notification has a

> difficult time determine when the notification = happened in the stream

> - so = the I2RS client must ask the agent again.

>

> = c.       Logging for traceability is = different than event notification.

 

Except = c), I do not understand this. What are these 'guarantees' 3) is = about?

 

> 5)      Secondary = identity data is read-only meta-data that is stored in = the

> agent associated with a = data model node that is being created or

> updated

> (write-access) in the data store.  =

 

Ehem, what is read-only data that is created or = written? Did you want to say that the identity meta-data is immutable = once a data node has been created? And if so, has priority the same = property: Is priority of a data node is determined at creation time and = then immutable?

 

> = 6)      I2RS Client and Agent Identities are = mutually authenticated by

> = Authentication server (AAA),

> =

> The values of identities are = originally set by operators.  

> 

 

I am = not sure how agent identity authentication via AAA works. Can someone = point me to the right direction if I assume a secure transport such as = SSH or TLS?

/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/>

------=_NextPart_000_011E_01D0A505.0686C720-- From nobody Fri Jun 12 09:18:26 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C13E1A879A; Fri, 12 Jun 2015 09:18:18 -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 YrZGHRTCk9ni; Fri, 12 Jun 2015 09:18:16 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E02D41A87AA; Fri, 12 Jun 2015 09:17:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: Date: Fri, 12 Jun 2015 12:17:21 -0400 Message-ID: <018b01d0a52b$435e1380$ca1a3a80$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018C_01D0A509.BC4FA7D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdClKz73uXQsemG7RpyfIMyQzz7Y1Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs-chairs@ietf.org, 'Alia Atlas' Subject: [i2rs] IESG statement on Internet draft authorship 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, 12 Jun 2015 16:18:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_018C_01D0A509.BC4FA7D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I2RS WG members:=20 =20 You may want to know about the IESG statement on Internet draft = authorship. My thanks to Deborah Brungard (our Routing AD) who = forwarded this to me.=20 =20 Sue Hares =20 -----Original Message----- From: BRUNGARD, DEBORAH A [mailto:db3546@att.com]=20 Sent: Friday, June 12, 2015 10:36 AM To: rtg-chairs@ietf.org Subject: FW: IESG Statement on Internet Draft Authorship =20 Not everyone pays attention to the ietf-list, you may want to distribute = on your wg lists- =20 =20 -----Original Message----- From: IETF-Announce [ = mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Thursday, June 11, 2015 2:32 PM To: IETF Announcement List Subject: IESG Statement on Internet Draft Authorship =20 The IESG has received some reports of IETF participants having been = listed as document authors on drafts without their consent ("surprised = authorship"). In some cases, the surprised authors had never seen the = draft that surprised them. It appears that some draft authors think that = including other participants as authors is a way to show support for the = concepts in the document and gain acceptance for those concepts. This = may be thought of as especially useful if the additional authors are = established IETF participants. =20 Adding names of IETF participants who did not actually work on a = proposal might seem to be a low-risk way of demonstrating "support", but = this is very clearly not an acceptable practice: no one should ever be = added to the list of authors on a draft unless that person has consented = to it and has contributed significantly to the development of the draft. =20 The practice of adding surprised authors is =20 - not in line with the IETF culture, where it's the technical issues=20 that matter, not who the authors or supporters are; - unethical, as it is wrong to claim support from someone who has not=20 consented to it; - misleading in terms of support; and - problematic in terms of IPR disclosures (BCPs 78 and 79).=20 =20 To emphasize this last point, the person submitting an Internet-Draft is = asserting that "This Internet-Draft is submitted in full conformance = with the provisions of BCP 78 and BCP 79". A submitter who has not = discussed this with all the listed authors cannot make that claim, and = this can cause procedural and legal problems later. =20 All authors need to be aware of the =E2=80=8BRFC Editor's statement on = authorship [1], especially as it relates to responsibility for the = document's contents. The IESG strongly recommends that all drafts have = explicit permission from all authors to have their names listed before = the draft is submitted. =20 If you feel that you are impacted by the above issues, please talk to = your Area Director or contact the IESG by =E2=80=8Bsending email to < = iesg@ietf.org>. As the administrator of the I-D = repository (regardless of the source or intended stream for the draft), = the IESG will handle each case of disputed authorship on a case-by-base = basis. All reports will be investigated, and substantiated claims will = be met with corrective actions. =20 The default corrective action will be the replacement of the offending = draft with a "disputed authorship" tombstone. Such a tombstone would: =20 - Be published as a successor to the offending draft, - Have the offended IETF participant listed as the only author, - Will state "The author listed on this tombstone Internet-Draft has=20 stated that he/she should not have been listed as an author on the=20 previous version. The IETF considers being added as an author=20 without one's permission as unethical. The default behaviour of the=20 IESG in such cases is to approve replacement of the offending draft=20 with this tombstone. Please direct any queries to the author listed=20 here."=20 =20 [1] = = http://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html =20 =20 ------=_NextPart_000_018C_01D0A509.BC4FA7D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I2RS WG = members:

 

You may want to know about the IESG statement on = Internet draft authorship. =C2=A0My thanks to Deborah Brungard = =C2=A0(our Routing AD) who forwarded this to me.

 

Sue = Hares

 

-----Original Message-----
From: BRUNGARD, = DEBORAH A [mailto:db3546@att.com]
Sent: Friday, June 12, 2015 10:36 = AM
To: rtg-chairs@ietf.org
Subject: FW: IESG Statement on Internet = Draft Authorship

 

Not = everyone pays attention to the ietf-list, you may want to distribute on = your wg lists-

 

 

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

From: IETF-Announce [mailto:ietf-announce-boun= ces@ietf.org] On Behalf Of The IESG

Sent: Thursday, June 11, 2015 2:32 = PM

To: IETF Announcement = List

Subject: IESG Statement on = Internet Draft Authorship

 

The = IESG has received some reports of IETF participants having been listed = as document authors on drafts without their consent ("surprised = authorship"). In some cases, the surprised authors had never seen = the draft that surprised them. It appears that some draft authors think = that including other participants as authors is a way to show support = for the concepts in the document and gain acceptance for those concepts. = This may be thought of as especially useful if the additional authors = are established IETF participants.

 

Adding = names of IETF participants who did not actually work on a proposal might = seem to be a low-risk way of demonstrating "support", but this = is very clearly not an acceptable practice: no one should ever be added = to the list of authors on a draft unless that person has consented to it = and has contributed significantly to the development of the = draft.

 

The practice of adding surprised authors = is

 

=C2=A0 - not in line with the IETF culture, where = it's the technical issues

=C2=A0=C2=A0=C2=A0=C2=A0that matter, not who the = authors or supporters are;

=C2=A0 = - unethical, as it is wrong to claim support from someone who has not =

=C2=A0=C2=A0=C2=A0=C2=A0consented = to it;

=C2=A0 - misleading in = terms of support; and

=C2=A0 - = problematic in terms of IPR disclosures (BCPs 78 and 79). =

 

To emphasize this last point, the person submitting = an Internet-Draft is asserting that "This Internet-Draft is = submitted in full conformance with the provisions of BCP 78 and BCP = 79". A submitter who has not discussed this with all the listed = authors cannot make that claim, and this can cause procedural and legal = problems later.

 

All = authors need to be aware of the =E2=80=8BRFC Editor's statement on = authorship [1], especially as it relates to responsibility for the = document's contents. The IESG strongly recommends that all drafts have = explicit permission from all authors to have their names listed before = the draft is submitted.

 

If you = feel that you are impacted by the above issues, please talk to your Area = Director or contact the IESG by =E2=80=8Bsending email to <iesg@ietf.org&= gt;. As the administrator of the I-D repository (regardless of the = source or intended stream for the draft), the IESG will handle each case = of disputed authorship on a case-by-base basis. All reports will be = investigated, and substantiated claims will be met with corrective = actions.

 

The default corrective action will be the = replacement of the offending draft with a "disputed = authorship" tombstone. Such a tombstone would:

 

=C2=A0 = - Be published as a successor to the offending draft,

=C2=A0 - Have the offended IETF participant listed = as the only author,

=C2=A0 - Will = state "The author listed on this tombstone Internet-Draft has =

=C2=A0=C2=A0=C2=A0=C2=A0stated = that he/she should not have been listed as an author on the =

=C2=A0=C2=A0=C2=A0=C2=A0previous = version. The IETF considers being added as an author

=C2=A0=C2=A0=C2=A0=C2=A0without one's permission as = unethical. The default behaviour of the

=C2=A0=C2=A0=C2=A0=C2=A0IESG in such cases is to = approve replacement of the offending draft

=C2=A0=C2=A0=C2=A0=C2=A0with this tombstone. Please = direct any queries to the author listed

=C2=A0=C2=A0=C2=A0=C2=A0here." =

 

[1] http://www.rfc-editor.org= /pipermail/rfc-interest/2015-May/008869.html

 

 

------=_NextPart_000_018C_01D0A509.BC4FA7D0-- From nobody Sun Jun 14 05:51: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 689AF1B2D4B for ; Sun, 14 Jun 2015 05:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 epv2BiturpBX for ; Sun, 14 Jun 2015 05:51:11 -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 836821ACEBF for ; Sun, 14 Jun 2015 05:51:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 400E41351; Sun, 14 Jun 2015 14:51:09 +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 zixvIDc6PBA3; Sun, 14 Jun 2015 14:51: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; Sun, 14 Jun 2015 14:51:07 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8ECB420036; Sun, 14 Jun 2015 14:51:07 +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 pzTDGPA6q6P5; Sun, 14 Jun 2015 14:51:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 169F720035; Sun, 14 Jun 2015 14:51:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 415143469E46; Sun, 14 Jun 2015 14:51:04 +0200 (CEST) Date: Sun, 14 Jun 2015 14:51:03 +0200 From: Juergen Schoenwaelder To: Alia Atlas Message-ID: <20150614125103.GA3063@elstar.local> Mail-Followup-To: Alia Atlas , "i2rs@ietf.org" References: 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" Subject: Re: [i2rs] storage of priority and client ID with a node 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: Sun, 14 Jun 2015 12:51:14 -0000 Alia, thinks for a very useful message that answered several of my questions. I hope the reasoning can be captured somewhere. /js On Wed, Jun 10, 2015 at 12:15:46PM -0400, Alia Atlas wrote: > > As I mentioned in the virtual interim, I'd like to explain a little further > about what I see as semantics and desired behavior around the storing and > managing of priority and client ID. > > First, the priority mechanism is intended to handle "error cases of > colliding writes" in a predictable way that results in a consistent > mechanism. It is true that the same mechanism could be used if they > weren't considered "errors". I think this is a nice property - but it is > also important to minimize the impact of the priority mechanism. > > Second, if there is a priority conflict where both clients (Client_A and > Client_B) share the same priority, the client that wrote first wins. This > is to avoid network oscillation if two clients are "fighting" over writing > the same state. When there are multiple clients and the time arrival of > the messages may not be predictable (network transit differences, which > socket is read, software differences), basing state on last arrival time > doesn't give consistent and predictable behavior. > > That gives behavior as in the following time-line: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_B attempts to write X=K with priority 10 and is rejected > Time_3: Client_A writes X=P with priority 10 and succeeds > > For the I2RS Agent to properly handle these actions, it is necessary to > know that X is owned by Client_A. Priority alone is not sufficient because > the basis for rejecting Client_B's write but accepting Client_A's write is > that Client_A is the owner. > > Thus, I believe that it is necessary to store the Client Identity with the > nodes that it owns. > This could be in an I2RS-specific overlay that is only used by the I2RS > agent and only contains the nodes that have been written by I2RS. > > Third, a question has come up regarding what the behavior of priority is if > a client's priority changes and whether priority needs to be stored with > each node when that node is written. > > In my "keep-it-simple" perspective, priority is associated with a Client > and is only used on a conflict. This would mean that priority isn't stored > with a node when that node is written. Instead, the Client Identity is > stored with the node and the Client's priority is looked up in a client > table that the I2RS Agent can access. That client table could be populated > via configuration, via a AAA protocol, via NACM, etc. > > The semantic implications are as follows: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > 6) > * Time_4: Client_A attempts to write X=N with priority 6 (fails b/c 8 > > 6) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (same > owner, no priority check) > > The alternate approach would have store the priority with which a node was > written. That is more like a priority lock that could only be changed by a > client with higher priority or by the same client, regardless of priority. > This approach would require storing a priority per node and the semantic > implications would be as follows: > > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B attempts to write X=K with priority 8 and fails > (10 > 8) > * Time_4: Client_A writes X=N with priority 6 & succeeds (same owner, > no priority check) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) > > The behavior for these two models is different at Time_3 and Time_4. > > I'd like to see if there's agreement that the first model (priority stored > with client) is acceptable or if the second model (priority stored with > node) is necessary. > > Thanks, > Alia > > _______________________________________________ > 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 Sun Jun 14 11:59: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 A2A9D1ACD59 for ; Sun, 14 Jun 2015 11:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.055 X-Spam-Level: X-Spam-Status: No, score=-99.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX8y62nNFiRL for ; Sun, 14 Jun 2015 11:59: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 DE29C1ACD4B for ; Sun, 14 Jun 2015 11:59:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.82.115; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Alia Atlas'" References: <20150614125103.GA3063@elstar.local> In-Reply-To: <20150614125103.GA3063@elstar.local> Date: Sun, 14 Jun 2015 14:59:10 -0400 Message-ID: <003101d0a6d4$32b27c60$98177520$@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: AQHYY65ni4PerkKdgBReDdxBvn/vigFzCKmznZFIlGA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] storage of priority and client ID with a node X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:59:21 -0000 Juergen: Would Jeff's ephemeral state be a reasonable place to put it. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Sunday, June 14, 2015 8:51 AM To: Alia Atlas Cc: i2rs@ietf.org Subject: Re: [i2rs] storage of priority and client ID with a node Alia, thinks for a very useful message that answered several of my questions. I hope the reasoning can be captured somewhere. /js On Wed, Jun 10, 2015 at 12:15:46PM -0400, Alia Atlas wrote: > > As I mentioned in the virtual interim, I'd like to explain a little > further about what I see as semantics and desired behavior around the > storing and managing of priority and client ID. > > First, the priority mechanism is intended to handle "error cases of > colliding writes" in a predictable way that results in a consistent > mechanism. It is true that the same mechanism could be used if they > weren't considered "errors". I think this is a nice property - but it > is also important to minimize the impact of the priority mechanism. > > Second, if there is a priority conflict where both clients (Client_A > and > Client_B) share the same priority, the client that wrote first wins. > This is to avoid network oscillation if two clients are "fighting" > over writing the same state. When there are multiple clients and the > time arrival of the messages may not be predictable (network transit > differences, which socket is read, software differences), basing state > on last arrival time doesn't give consistent and predictable behavior. > > That gives behavior as in the following time-line: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_B attempts to write X=K with priority 10 and is rejected > Time_3: Client_A writes X=P with priority 10 and succeeds > > For the I2RS Agent to properly handle these actions, it is necessary > to know that X is owned by Client_A. Priority alone is not sufficient > because the basis for rejecting Client_B's write but accepting > Client_A's write is that Client_A is the owner. > > Thus, I believe that it is necessary to store the Client Identity with > the nodes that it owns. > This could be in an I2RS-specific overlay that is only used by the > I2RS agent and only contains the nodes that have been written by I2RS. > > Third, a question has come up regarding what the behavior of priority > is if a client's priority changes and whether priority needs to be > stored with each node when that node is written. > > In my "keep-it-simple" perspective, priority is associated with a > Client and is only used on a conflict. This would mean that priority > isn't stored with a node when that node is written. Instead, the > Client Identity is stored with the node and the Client's priority is > looked up in a client table that the I2RS Agent can access. That > client table could be populated via configuration, via a AAA protocol, via NACM, etc. > > The semantic implications are as follows: > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B writes X=K with priority 8 (succeeds since 8 > 6) > * Time_4: Client_A attempts to write X=N with priority 6 (fails b/c 8 > > 6) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (same > owner, no priority check) > > The alternate approach would have store the priority with which a node > was written. That is more like a priority lock that could only be > changed by a client with higher priority or by the same client, regardless of priority. > This approach would require storing a priority per node and the > semantic implications would be as follows: > > Time_1: Client_A writes X=N with priority 10 > Time_2: Client_A's priority is changed (UNUSUAL) to priority 6 > * Time_3: Client_B attempts to write X=K with priority 8 and fails > (10 > 8) > * Time_4: Client_A writes X=N with priority 6 & succeeds (same owner, > no priority check) > Time_5: Client_B's priority is changed (UNUSUAL) to priority 7 > Time_6 Client_B writes X=P with priority 7 and succeeds (7 > 6) > > The behavior for these two models is different at Time_3 and Time_4. > > I'd like to see if there's agreement that the first model (priority > stored with client) is acceptable or if the second model (priority > stored with > node) is necessary. > > Thanks, > Alia > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Jun 14 15:40: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 2EC2E1A1EF4; Sun, 14 Jun 2015 15:40:19 -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 8dT8a4p6U-vA; Sun, 14 Jun 2015 15:40:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F051A1EF5; Sun, 14 Jun 2015 15:40:17 -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.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150614224017.5087.22536.idtracker@ietfa.amsl.com> Date: Sun, 14 Jun 2015 15:40:17 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-shaikh-idr-bgp-model-02.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: Sun, 14 Jun 2015 22:40:19 -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 : BGP Model for Service Provider Networks Authors : Anees Shaikh Rob Shakir Keyur Patel Susan Hares Kevin D'Souza Deepak Bansal Alexander Clemm Aleksandr Zhdankin Mahesh Jethanandani Xyfeng Liu Filename : draft-shaikh-idr-bgp-model-02.txt Pages : 77 Date : 2015-06-14 Abstract: This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects based on data center, carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-shaikh-idr-bgp-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-shaikh-idr-bgp-model-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-shaikh-idr-bgp-model-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 15 16:04: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 62AFD1B2F6D; Mon, 15 Jun 2015 16:04:46 -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 VOYXc7tVM8o4; Mon, 15 Jun 2015 16:04:44 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 104421B2F69; Mon, 15 Jun 2015 16:04:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=8.25.222.10; From: "Susan Hares" To: , , Date: Mon, 15 Jun 2015 19:04:42 -0400 Message-ID: <00b001d0a7bf$aa734ea0$ff59ebe0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdCnv4CgVRt9jT5tTUacBsSoRjMmEw== X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] Third and FINAL call for volunteers, Nomcom 2015-2016 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, 15 Jun 2015 23:04:46 -0000 Hi all:=20 You can volunteering for nomcom for 1 more week. Consider volunteering = - you'll see how your Routing AD gets selected. =20 Sue=20 -----Original Message----- From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of = NomCom Chair 2015 Sent: Monday, June 15, 2015 5:59 AM To: IETF Announcement List Cc: ietf@ietf.org Subject: Third and FINAL call for volunteers, Nomcom 2015-2016 ***Reminder: Deadline for volunteering for Nomcom is in ONE WEEK.*** The IETF nomcom appoints folks to fill the open slots on the IAOC, the = IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random = way from a pool of volunteers. The more volunteers, the better chance we = have of choosing a random yet representative cross section of the IETF = population. The details of the operation of the nomcom can be found in RFC 7437, and = BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As = specified in RFC 7437, that means three out of the five past meetings up = to the time this email announcement goes out to start the solicitation = of volunteers. The five meetings out of which you must have attended *three* are: IETF 88 (Vancouver), \ 89 (London), \ 90 (Toronto), *** ANY THREE! 91 (Honolulu), / 92 (Dallas) / If you qualify, please volunteer. However, much as we want this, = before you decide to volunteer, please be sure you are willing to forgo = appointment to any of the positions for which this nomcom is = responsible. As of today, we have 151 confirmed volunteers. 72 of those who ticked = the box on the registration form for Hawaii, Dallas and Prague have = still not responded. If you believe you have volunteered, and your name is NOT below, please = contact me as soon as possible. Thank you for volunteering! The list of people and posts whose terms end with the March 2016 IETF = meeting, and thus the positions for which this nomcom is responsible, = are IAOC: No terms expire at this time. IAB: Mary Barnes Joe Hildebrand Ted Hardie Erik Nordmark Brian Trammell Marc Blanchet IESG: Alissa Cooper (ART) Barry Leiba (ART) Brian Haberman (Internet) Benoit Claise (Operations and Management) Alia Atlas (Routing) Kathleen = Moriarty (Security) Martin Stiemerling (Transport) The Applications and Real-Time (ART) area is the expected new area = resulting from the merge of the APP and RAI areas. All appointments are for 2 years. The ART and Routing areas have 3 ADs and the General area has 1; all = other areas have 2 ADs. Thus, all areas have at least one continuing AD. The primary activity for this nomcom will begin in July 2015 and should = be completed in January 2016. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There = will be activities to collect requirements from the community, review = candidate questionnaires, review feedback from community members about = candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is = also a very rewarding experience. It is very important that you be able to attend IETF94 (Yokohama) to = conduct interviews. Being at IETF93 (Prague) is useful for orientation. Being at IETF95 is = not essential. Please volunteer by sending me an email before 11:59 pm CET (UTC +2 = hours) June 22, 2015, as follows: To: nomcom-chair-2015@ietf.org Subject: Nomcom 2015-16 Volunteer Please include the following information in the email body: Your Full Name: __________ // as you write it on the IETF registration form Current Primary = Affiliation: // Typically what goes in the Company field // in the IETF Registration Form Emails: _______________ // All email addresses used to register for the past 5 IETF meetings // Preferred email address first Telephone: _______________________ // For confirmation if selected You should expect an email response from me within 3 business days = stating whether or not you are qualified. If you don't receive this = response, please re-send your email with the tag "RESEND"" added to the = subject line. If you are not yet sure if you would like to volunteer, please consider = that nomcom members play a very important role in shaping the leadership = of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You will find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2015/ Thank you! Harald Alvestrand hta+nomcom@alvestrand.no nomcom-chair-2015@ietf.org =3D=3D=3D=3D=3D qualified volunteers so far, in alphabetical order by = first name Adam Montville Adrian Farrel ANDREW Dolganow Andrew Newton = Andy Bierman ANM Zaheduzzaman Sarker Anoop Ghanwani Anthony Nadalin Ari = Keranen Benno Overeinder Bernard Aboba Bhumip KHASNABISH Bing Liu Borje = Ohlman Carl Moberg Carlos Martinez Cengiz Alaettinoglu Charles Eckel = Charles Perkins Chris Bowers Christer Holmberg Christian Huitema = Christian O'Flaherty Cong Liu Corinna Schmitt Cullen Jennings Damien = Saucez Daniele Ceccarelli Dapeng Liu David Conrad David Lamparter David = Mandelberg David Sinicrope Dean Bogdanovic Derek Atkins Dhruv Dhody = Dimitri Papadimitriou Donald Eastlake 3rd Edward Lemon Eliot Lear Emil = Ivov Eric Gray Eric Vyncke Fangwei Hu Fernando Gont Fred Baker George = Michaelson George Swallow Georgios Karagiannis Gonzalo Salgueiro Gregory = Mirsky Hannes Gredler Hongyu Li Huaimo Chen Ignas Bagdonas Jason Weil = Jean-Marc Valin Jean-Michel Combes Jesus Maria Martin Garcia Joel = Halpern John Bradley John Brzozowski John Drake John Mattsson John = Scudder Jon Hudson Jon Mitchell jouni korhonen Karen O'Donoghue Keith = Moore Kenneth Gray Kent Watsen Kepeng Li Keyur Patel Laurent Ciavaglia = Lee Howard Liang Xia Linda Dunbar Lingli Deng Lixia Zhang Lucy Lynch = Luigi Iannone Mach CHEN Magnus Westerlund Mahalingam Mani Mark Townsley = Matthew Bocci Matthew Lepinski Mehmet Ersue Michael Jones Michael = StJohns Min Ye nalini elkins Nancy Cam-Winget Nathan Egge Niel Harper = Ning Kong Ning Zong Ole Jacobsen Ole Tr=C3=B8an Pascal Thubert Patrick = McManus Paul Wouters Peng Fan Peter Koch Peter Yee P=C3=A5l-Erik = Martinsen QIN WU Rich Salz Richard Barnes Robby Simpson Ron Bonica Ross = Callon Salvatore Loreto Sam K. Aldrin Sanjay Mishra Scott Mansfield = Sheng Jiang SHUCHENG LIU Simon Perreault Sri Gundavelli Stephan Wenger = Stephen Kent Steve Donovan Steve Olshansky Steven Wright Suhas = Nandakumar Suresh Krishnan Susan Hares Thomas Nadeau Thomas Walsh Tim = Wicinski Timothy Terriberry Tina (Ting) Tsou (Zou) TIRUMALESWAR REDDY = KONDA Tobias Gondrom Toerless Eckert Tomohiro Fujisaki Tony Hansen Uma = Chunduri Vic Liu Vijay Gurbani Warren Kumari Wassim Haddad Wijnands = IJsbrand Xufeng Liu Yi Zhao Yihong Huang Yizhou Li Yuanlong Jiang = Zhaohui Zhang From nobody Tue Jun 16 16:31: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 B78451B29CD for ; Tue, 16 Jun 2015 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjvVvnGbNNHp for ; Tue, 16 Jun 2015 16:31:03 -0700 (PDT) Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) (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 7B5D61B29AA for ; Tue, 16 Jun 2015 16:31:02 -0700 (PDT) Received: by labbc20 with SMTP id bc20so21602678lab.1 for ; Tue, 16 Jun 2015 16:31:01 -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=6+EBAMQjIdmP30XqIHM8LGhWMMGWr9Rlm7mL9M21iSU=; b=eXtG2t1iPAMezewbycA1mMQPOTlYsER1C+MBcR9XRXTM+gL+Ng1c5wNUmVLsX6gXFZ 84v5myldhUsDsF//hRs3r6DrgzPav25Acp2RoGKxyuXUpGpAgDr5L5W1g/a6b9OXqLTF Xq2Vzm9pT8BBIk98uu/gmssqcrIyjdVpZjfKe3A3fGAsC0arW9x5iOSad5YKCsq4yOCV gPwDq/Yt1wBY8TOm4ReHtZQSU0FkjmA05P0ECiymkPI43SUJaRUbGOdAjcdMRHZCpj/c y9VJF36iskIlK7Y1ZTOGRelPlnUYa+7rLLrruwWP25fFiT+bqNp2G92Pt7zhXVRrhY1k F1wA== X-Gm-Message-State: ALoCoQmJ97uO9nbimfJg05P8OhC6rH8rHa+MQdlKN82ZVFYzGnzhCJt2LanJ3X/BEAvf+W7eUlX3 MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr4808097laa.33.1434497460853; Tue, 16 Jun 2015 16:31:00 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 16 Jun 2015 16:31:00 -0700 (PDT) In-Reply-To: <000201d0a38d$20d635d0$6282a170$@ndzh.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> Date: Tue, 16 Jun 2015 16:31:00 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c27cf095f29e0518aaf781 Archived-At: Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Alia Atlas , Jeffrey Haas , "Joel M. Halpern" Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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, 16 Jun 2015 23:31:05 -0000 --001a11c27cf095f29e0518aaf781 Content-Type: text/plain; charset=UTF-8 Hi, I think I understand Juergen's concerns about I2RS requirements. Some of them are not specified as functionality, but rather as solutions. Most notably, the NETCONF WG needs to decide the best way to integrate ephemeral configuration into the existing framework. That may end up being a query-tag or a datastore or something new, but that is a standards implementation detail, not a requirement. Andy On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares wrote: > Juergen: > > > The I2RS WG still needs a written draft proposing how this would work to > have an effective discussion. > > > If it has these benefits you mention, it would be good to write itup. > > Best wishes, > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Wednesday, June 10, 2015 8:45 AM > To: Jeffrey Haas > Cc: Susan Hares; i2rs@ietf.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; > 'Alia Atlas' > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: > > Juergen, > > > > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote: > > > Frankly, there is no full alternate proposal either. The overlay > > > model has been discussed at quite some detail at a NETMOD interim. I > > > am happy to point at the meeting minutes. The question perhaps > > > really is whether (a) I2RS has requirements to be addresses and > > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a > > > solution into stone to be run through the NETCONF working group or > > > whether (c) creates a solution on its own independently of any other > > > NETMOD/NETCONF requirements. > > > > During that interim, we did discuss a number of details regarding > overlays. > > We also discussed a number of issues that overlays have when ephemeral > > state was not disjoint from static configuration state. > > > > As a result of that discussion and further presentation at a later > > I2RS meeting regarding the Venn diagram interactions of static and > > ephemeral configuration state, my latest draft attempts to codify > > behaviors that shouldn't be problematic in either proposed form or in > overlay. > > > > The point of frustration for all parties seems to be that while the > > paragraph from you above seems to indicate that there is some > > understanding of the requirements, I am unable to provide text that > > illustrates either requirement or potential solution to the matter. > > All parties are spending their resources saying "I think I understand > this > point, but this is wrong." > > If the points are understood well enough to disagree with potential > > solutions, I would suggest that they may be clear enough for both > > protocol and data modeling experts to contribute text that either > > clarifies the requirements to the collective experts' needs or > > similarly a proposal documenting a solution. > > > > These fundamental failures suggest a few possibilities: > > 1. There is a complete failure to properly communicate. If so, we should > > find replacement parties to carry on the work. We had some declared > > interest in a design team. Sue has, I believe, contacted people about > it. > > Those individuals should take over the work. > > 2. Netconf/restconf/yang are inappropriate tools and we have wasted the > > Working Group's time. I don't believe this as my employer has > > ephemeral datastores in an upcoming release. It does not, however, > have > > full I2RS properties such as priority or secondary-id. > > 3. The relevant experts are trying to get I2RS ephemeral state work to > die. > > If so, let's have the relevant discussion either publicly or privately > so > > we can stop wasting people's IETF cycles. > > I can assure you that, at least from my side, 3. is not the case. > > My perspective is likely slightly different from yours since I (not > surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS > itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps > YANG), I believe we will have to envision more usages of that feature than > just I2RS. Looking at things from a wider and longer term perspective, I am > concerned about (i) duplicated data modeling work and I am concerned about > (ii) use-case specific merge logic that needs to be supported. From this > perspective, the overlay model has been prety attractive because it comes > with a single merge logic and it minimizes (or even eliminates) duplicated > data modeling work. > > /js > > PS: Out of curiosity: Can you disclose what your employer's ephemeral > datastore solution coming out as a product soon looks like? Is it > closer to an overlay approach or is it closer to what you > described in your I-D? > > -- > 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 > --001a11c27cf095f29e0518aaf781 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I think I understand Juergen's = concerns about I2RS requirements.
Some of them are not specified = as functionality, but rather as solutions.

Most no= tably, the NETCONF WG needs to decide the best way to
integrate e= phemeral configuration into the existing framework.
That may end = up being a query-tag or a datastore or something new, but that is
a standards implementation detail, not a requirement.

=

Andy

On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares <= span dir=3D"ltr"><s= hares@ndzh.com> wrote:
Juer= gen:

<chair hat on>
The I2RS WG still needs a written draft proposing how this would work to have an effective discussion.
<chair hat off>

If it has these benefits you mention, it would be good to write itup.

Best wishes,

Sue

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Wednesday, June 10, 2015 8:45 AM
To: Jeffrey Haas
Cc: Susan Hares; i2rs@ietf.org; 'J= oel M. Halpern'; i2rs-chairs@ie= tf.org;
'Alia Atlas'
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015)

On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote:
> Juergen,
>
> On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder wrote:=
> > Frankly, there is no full alternate proposal either. The overlay<= br> > > model has been discussed at quite some detail at a NETMOD interim= . I
> > am happy to point at the meeting minutes. The question perhaps > > really is whether (a) I2RS has requirements to be addresses and > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a
> > solution into stone to be run through the NETCONF working group o= r
> > whether (c) creates a solution on its own independently of any ot= her
> > NETMOD/NETCONF requirements.
>
> During that interim, we did discuss a number of details regarding
overlays.
> We also discussed a number of issues that overlays have when ephemeral=
> state was not disjoint from static configuration state.
>
> As a result of that discussion and further presentation at a later
> I2RS meeting regarding the Venn diagram interactions of static and
> ephemeral configuration state, my latest draft attempts to codify
> behaviors that shouldn't be problematic in either proposed form or= in
overlay.
>
> The point of frustration for all parties seems to be that while the > paragraph from you above seems to indicate that there is some
> understanding of the requirements, I am unable to provide text that > illustrates either requirement or potential solution to the matter. > All parties are spending their resources saying "I think I unders= tand this
point, but this is wrong."
> If the points are understood well enough to disagree with potential > solutions, I would suggest that they may be clear enough for both
> protocol and data modeling experts to contribute text that either
> clarifies the requirements to the collective experts' needs or
> similarly a proposal documenting a solution.
>
> These fundamental failures suggest a few possibilities:
> 1. There is a complete failure to properly communicate.=C2=A0 If so, w= e should
>=C2=A0 =C2=A0 find replacement parties to carry on the work.=C2=A0 We h= ad some declared
>=C2=A0 =C2=A0 interest in a design team.=C2=A0 Sue has, I believe, cont= acted people about
it.
>=C2=A0 =C2=A0 Those individuals should take over the work.
> 2. Netconf/restconf/yang are inappropriate tools and we have wasted th= e
>=C2=A0 =C2=A0 Working Group's time.=C2=A0 I don't believe this = as my employer has
>=C2=A0 =C2=A0 ephemeral datastores in an upcoming release.=C2=A0 It doe= s not, however,
have
>=C2=A0 =C2=A0 full I2RS properties such as priority or secondary-id. > 3. The relevant experts are trying to get I2RS ephemeral state work to=
die.
>=C2=A0 =C2=A0 If so, let's have the relevant discussion either publ= icly or privately
so
>=C2=A0 =C2=A0 we can stop wasting people's IETF cycles.

I can assure you that, at least from my side, 3. is not the case.

My perspective is likely slightly different from yours since I (not
surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS
itself: If we add writable ephemeral state to NETCONF/RESTCONF (and perhaps=
YANG), I believe we will have to envision more usages of that feature than<= br> just I2RS. Looking at things from a wider and longer term perspective, I am=
concerned about (i) duplicated data modeling work and I am concerned about<= br> (ii) use-case specific merge logic that needs to be supported. From this perspective, the overlay model has been prety attractive because it comes with a single merge logic and it minimizes (or even eliminates) duplicated<= br> data modeling work.

/js

PS: Out of curiosity: Can you disclose what your employer's ephemeral =C2=A0 =C2=A0 datastore solution coming out as a product soon looks like? I= s it
=C2=A0 =C2=A0 closer to an overlay approach or is it closer to what you
=C2=A0 =C2=A0 described in your I-D?

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a11c27cf095f29e0518aaf781-- From nobody Tue Jun 16 17:04: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 0E6E21B2C70; Tue, 16 Jun 2015 17:04:24 -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 JxG6bHLMRoE5; Tue, 16 Jun 2015 17:04:21 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DFD1B2C9B; Tue, 16 Jun 2015 17:04:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A284B1C0499; Tue, 16 Jun 2015 17:04:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B9A8F1C0487; Tue, 16 Jun 2015 17:04:14 -0700 (PDT) Message-ID: <5580B96F.7080001@joelhalpern.com> Date: Tue, 16 Jun 2015 20:03:59 -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 , Susan Hares References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Wed, 17 Jun 2015 00:04:24 -0000 There are at least two dimensions to your comment. One aspect is that I2RS should not, and has tried not to, prescribe the implementation mechanism to meet the requirements. The requirement is ephemeral config, with a descriptive definition and identity and priority aspects. The mechanism to meet that is up to whatever protocol is to be used. The other aspect that strikes me is that the NetConf WG is perfectly free to conclude that they think that what is needed is a mechanism that does not fully meet the I2RS requirements. If so, the I2RS group will have to decide between changing its requirements and picking another protocol. As long as those points are understood by each side, we are fine. Yours, Joel On 6/16/15 7:31 PM, Andy Bierman wrote: > Hi, > > I think I understand Juergen's concerns about I2RS requirements. > Some of them are not specified as functionality, but rather as solutions. > > Most notably, the NETCONF WG needs to decide the best way to > integrate ephemeral configuration into the existing framework. > That may end up being a query-tag or a datastore or something new, but > that is > a standards implementation detail, not a requirement. > > > Andy > > On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares > wrote: > > Juergen: > > > The I2RS WG still needs a written draft proposing how this would work to > have an effective discussion. > > > If it has these benefits you mention, it would be good to write itup. > > Best wishes, > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de > ] > Sent: Wednesday, June 10, 2015 8:45 AM > To: Jeffrey Haas > Cc: Susan Hares; i2rs@ietf.org ; 'Joel M. > Halpern'; i2rs-chairs@ietf.org ; > 'Alia Atlas' > Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) > > On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: > > Juergen, > > > > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder > wrote: > > > Frankly, there is no full alternate proposal either. The overlay > > > model has been discussed at quite some detail at a NETMOD > interim. I > > > am happy to point at the meeting minutes. The question perhaps > > > really is whether (a) I2RS has requirements to be addresses and > > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a > > > solution into stone to be run through the NETCONF working group or > > > whether (c) creates a solution on its own independently of any > other > > > NETMOD/NETCONF requirements. > > > > During that interim, we did discuss a number of details regarding > overlays. > > We also discussed a number of issues that overlays have when > ephemeral > > state was not disjoint from static configuration state. > > > > As a result of that discussion and further presentation at a later > > I2RS meeting regarding the Venn diagram interactions of static and > > ephemeral configuration state, my latest draft attempts to codify > > behaviors that shouldn't be problematic in either proposed form or in > overlay. > > > > The point of frustration for all parties seems to be that while the > > paragraph from you above seems to indicate that there is some > > understanding of the requirements, I am unable to provide text that > > illustrates either requirement or potential solution to the matter. > > All parties are spending their resources saying "I think I > understand this > point, but this is wrong." > > If the points are understood well enough to disagree with potential > > solutions, I would suggest that they may be clear enough for both > > protocol and data modeling experts to contribute text that either > > clarifies the requirements to the collective experts' needs or > > similarly a proposal documenting a solution. > > > > These fundamental failures suggest a few possibilities: > > 1. There is a complete failure to properly communicate. If so, > we should > > find replacement parties to carry on the work. We had some > declared > > interest in a design team. Sue has, I believe, contacted > people about > it. > > Those individuals should take over the work. > > 2. Netconf/restconf/yang are inappropriate tools and we have > wasted the > > Working Group's time. I don't believe this as my employer has > > ephemeral datastores in an upcoming release. It does not, > however, > have > > full I2RS properties such as priority or secondary-id. > > 3. The relevant experts are trying to get I2RS ephemeral state > work to > die. > > If so, let's have the relevant discussion either publicly or > privately > so > > we can stop wasting people's IETF cycles. > > I can assure you that, at least from my side, 3. is not the case. > > My perspective is likely slightly different from yours since I (not > surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS > itself: If we add writable ephemeral state to NETCONF/RESTCONF (and > perhaps > YANG), I believe we will have to envision more usages of that > feature than > just I2RS. Looking at things from a wider and longer term > perspective, I am > concerned about (i) duplicated data modeling work and I am concerned > about > (ii) use-case specific merge logic that needs to be supported. From this > perspective, the overlay model has been prety attractive because it > comes > with a single merge logic and it minimizes (or even eliminates) > duplicated > data modeling work. > > /js > > PS: Out of curiosity: Can you disclose what your employer's ephemeral > datastore solution coming out as a product soon looks like? Is it > closer to an overlay approach or is it closer to what you > described in your I-D? > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Tue Jun 16 17:32: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 C11F91B30FE for ; Tue, 16 Jun 2015 17:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ls7nxjvwS4OP for ; Tue, 16 Jun 2015 17:32:43 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 797F21B3005 for ; Tue, 16 Jun 2015 17:29:59 -0700 (PDT) Received: by lbbti3 with SMTP id ti3so21225649lbb.1 for ; Tue, 16 Jun 2015 17:29: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=SBpf7wKwpkg8DDODwHavyJNav8nAbday0HhU8RBMR18=; b=lV0bRV8I0+FdzfVj3FUGZH2x8HisQ5rODED3gHYCFuJcfLU++AJ7/DEZLb5yOS9uwL pWObK3vXK8zhs2duo8QcPQWEsKTHH7jdKINwX/5SxUA4SZZPw+klXwmpjvMXHpY1oa2u IlHmUh5LYfFFzz9U6GuHNq3S9dRQEGNkEfqNowuA4OFATtg0RqL3eGUB3t/GKaIcUTxT In70XZtRME0LInD/slCqPdCjZhTEGJ6YBxmBkqky+SKvbn4qgdCDK5wqyRNtqIohTcGc 3P8hXGDausDa4lVbzGAyD4+6AITGtmJUNOOcWuRqgl0ZZpZlZf9CTDZrKt/FNevaoIvK feCQ== X-Gm-Message-State: ALoCoQn981rhdnaDxBeW08z++cCiffBoc9cHlQ2e0KMxAD+Gf2n0nrNavhScMTLDzCeyDLpRfhgW MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr5024720lab.82.1434500997945; Tue, 16 Jun 2015 17:29:57 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 16 Jun 2015 17:29:57 -0700 (PDT) In-Reply-To: <5580B96F.7080001@joelhalpern.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> <5580B96F.7080001@joelhalpern.com> Date: Tue, 16 Jun 2015 17:29:57 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c3677e69b58a0518abca9c Archived-At: Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Alia Atlas , Jeffrey Haas , Susan Hares Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Wed, 17 Jun 2015 00:32:46 -0000 --001a11c3677e69b58a0518abca9c Content-Type: text/plain; charset=UTF-8 On Tue, Jun 16, 2015 at 5:03 PM, Joel M. Halpern wrote: > There are at least two dimensions to your comment. > > One aspect is that I2RS should not, and has tried not to, prescribe the > implementation mechanism to meet the requirements. The requirement is > ephemeral config, with a descriptive definition and identity and priority > aspects. The mechanism to meet that is up to whatever protocol is to be > used. > > The impact on the existing documents needs to be examined by the WG. This is where datastore vs. tag details could be quite different. The other aspect that strikes me is that the NetConf WG is perfectly free > to conclude that they think that what is needed is a mechanism that does > not fully meet the I2RS requirements. If so, the I2RS group will have to > decide between changing its requirements and picking another protocol. > > As long as those points are understood by each side, we are fine. > I don't know what the WG consensus will be, but IMO I2RS needs to distinguish the parts that need signalling events from the parts that need access to the YANG notifications. These are not the same. I know the implementation requirements for RFC 5277 fairly well and I am recommending against its use for signalling events. Other than that I see no issues supporting I2RS requirements. > Yours, > Joel > > Andy > On 6/16/15 7:31 PM, Andy Bierman wrote: > >> Hi, >> >> I think I understand Juergen's concerns about I2RS requirements. >> Some of them are not specified as functionality, but rather as solutions. >> >> Most notably, the NETCONF WG needs to decide the best way to >> integrate ephemeral configuration into the existing framework. >> That may end up being a query-tag or a datastore or something new, but >> that is >> a standards implementation detail, not a requirement. >> >> >> Andy >> >> On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares > > wrote: >> >> Juergen: >> >> >> The I2RS WG still needs a written draft proposing how this would work >> to >> have an effective discussion. >> >> >> If it has these benefits you mention, it would be good to write itup. >> >> Best wishes, >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de >> ] >> Sent: Wednesday, June 10, 2015 8:45 AM >> To: Jeffrey Haas >> Cc: Susan Hares; i2rs@ietf.org ; 'Joel M. >> Halpern'; i2rs-chairs@ietf.org ; >> 'Alia Atlas' >> Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) >> >> On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote: >> > Juergen, >> > >> > On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen Schoenwaelder >> wrote: >> > > Frankly, there is no full alternate proposal either. The overlay >> > > model has been discussed at quite some detail at a NETMOD >> interim. I >> > > am happy to point at the meeting minutes. The question perhaps >> > > really is whether (a) I2RS has requirements to be addresses and >> > > NETMOD/NETCONF looks at solutions or whether (b) I2RS casts a >> > > solution into stone to be run through the NETCONF working group >> or >> > > whether (c) creates a solution on its own independently of any >> other >> > > NETMOD/NETCONF requirements. >> > >> > During that interim, we did discuss a number of details regarding >> overlays. >> > We also discussed a number of issues that overlays have when >> ephemeral >> > state was not disjoint from static configuration state. >> > >> > As a result of that discussion and further presentation at a later >> > I2RS meeting regarding the Venn diagram interactions of static and >> > ephemeral configuration state, my latest draft attempts to codify >> > behaviors that shouldn't be problematic in either proposed form or >> in >> overlay. >> > >> > The point of frustration for all parties seems to be that while the >> > paragraph from you above seems to indicate that there is some >> > understanding of the requirements, I am unable to provide text that >> > illustrates either requirement or potential solution to the matter. >> > All parties are spending their resources saying "I think I >> understand this >> point, but this is wrong." >> > If the points are understood well enough to disagree with potential >> > solutions, I would suggest that they may be clear enough for both >> > protocol and data modeling experts to contribute text that either >> > clarifies the requirements to the collective experts' needs or >> > similarly a proposal documenting a solution. >> > >> > These fundamental failures suggest a few possibilities: >> > 1. There is a complete failure to properly communicate. If so, >> we should >> > find replacement parties to carry on the work. We had some >> declared >> > interest in a design team. Sue has, I believe, contacted >> people about >> it. >> > Those individuals should take over the work. >> > 2. Netconf/restconf/yang are inappropriate tools and we have >> wasted the >> > Working Group's time. I don't believe this as my employer has >> > ephemeral datastores in an upcoming release. It does not, >> however, >> have >> > full I2RS properties such as priority or secondary-id. >> > 3. The relevant experts are trying to get I2RS ephemeral state >> work to >> die. >> > If so, let's have the relevant discussion either publicly or >> privately >> so >> > we can stop wasting people's IETF cycles. >> >> I can assure you that, at least from my side, 3. is not the case. >> >> My perspective is likely slightly different from yours since I (not >> surprisingly) care more about NETCONF/RESTCONF and YANG than I2RS >> itself: If we add writable ephemeral state to NETCONF/RESTCONF (and >> perhaps >> YANG), I believe we will have to envision more usages of that >> feature than >> just I2RS. Looking at things from a wider and longer term >> perspective, I am >> concerned about (i) duplicated data modeling work and I am concerned >> about >> (ii) use-case specific merge logic that needs to be supported. From >> this >> perspective, the overlay model has been prety attractive because it >> comes >> with a single merge logic and it minimizes (or even eliminates) >> duplicated >> data modeling work. >> >> /js >> >> PS: Out of curiosity: Can you disclose what your employer's ephemeral >> datastore solution coming out as a product soon looks like? Is it >> closer to an overlay approach or is it closer to what you >> described in your I-D? >> >> -- >> 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 >> >> >> --001a11c3677e69b58a0518abca9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 16, 2015 at 5:03 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
There are at leas= t two dimensions to your comment.

One aspect is that I2RS should not, and has tried not to, prescribe the imp= lementation mechanism to meet the requirements.=C2=A0 The requirement is ep= hemeral config, with a descriptive definition and identity and priority asp= ects.=C2=A0 The mechanism to meet that is up to whatever protocol is to be = used.


The impact on the existing documents n= eeds to be examined by the WG.
This is where datastore vs. tag de= tails could be quite different.


The other aspect that strikes me is that the NetConf WG is perfectly free t= o conclude that they think that what is needed is a mechanism that does not= fully meet the I2RS requirements.=C2=A0 If so, the I2RS group will have to= decide between changing its requirements and picking another protocol.

As long as those points are understood by each side, we are fine.


I don't know what the WG cons= ensus will be, but IMO I2RS needs to
distinguish the parts that n= eed signalling events from the
parts that need access to the YANG= notifications.=C2=A0 These are not the same.
I know the implemen= tation requirements for RFC 5277 fairly well and I
am recommendin= g against its use for signalling events.
Other than that I see no= issues supporting I2RS requirements.



Yours,
Joel



Andy
=C2=A0
On 6/16/15 7:31 PM, Andy Bierman wrote:
Hi,

I think I understand Juergen's concerns about I2RS requirements.
Some of them are not specified as functionality, but rather as solutions.
Most notably, the NETCONF WG needs to decide the best way to
integrate ephemeral configuration into the existing framework.
That may end up being a query-tag or a datastore or something new, but
that is
a standards implementation detail, not a requirement.


Andy

On Wed, Jun 10, 2015 at 7:52 AM, Susan Hares <shares@ndzh.com
<mailto:shares@ndzh= .com>> wrote:

=C2=A0 =C2=A0 Juergen:

=C2=A0 =C2=A0 <chair hat on>
=C2=A0 =C2=A0 The I2RS WG still needs a written draft proposing how this wo= uld work to
=C2=A0 =C2=A0 have an effective discussion.
=C2=A0 =C2=A0 <chair hat off>

=C2=A0 =C2=A0 If it has these benefits you mention, it would be good to wri= te itup.

=C2=A0 =C2=A0 Best wishes,

=C2=A0 =C2=A0 Sue

=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: Juergen Schoenwaelder
=C2=A0 =C2=A0 [mailto:j.schoenwaelder@jacobs-university.de
=C2=A0 =C2=A0 <mailto:j.schoenwaelder@jacobs-university.de>]
=C2=A0 =C2=A0 Sent: Wednesday, June 10, 2015 8:45 AM
=C2=A0 =C2=A0 To: Jeffrey Haas
=C2=A0 =C2=A0 Cc: Susan Hares; i2rs@ietf.org <mailto:i2rs@ietf.org>; 'Joel M.
=C2=A0 =C2=A0 Halpern'; i2rs-chairs@ietf.org <mailto:i2rs-chairs@ietf.org>;
=C2=A0 =C2=A0 'Alia Atlas'
=C2=A0 =C2=A0 Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2= 015)

=C2=A0 =C2=A0 On Tue, Jun 09, 2015 at 08:34:44PM -0400, Jeffrey Haas wrote:=
=C2=A0 =C2=A0 =C2=A0> Juergen,
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> On Fri, Jun 05, 2015 at 02:35:33PM +0200, Juergen = Schoenwaelder
=C2=A0 =C2=A0 wrote:
=C2=A0 =C2=A0 =C2=A0> > Frankly, there is no full alternate proposal = either. The overlay
=C2=A0 =C2=A0 =C2=A0> > model has been discussed at quite some detail= at a NETMOD
=C2=A0 =C2=A0 interim. I
=C2=A0 =C2=A0 =C2=A0> > am happy to point at the meeting minutes. The= question perhaps
=C2=A0 =C2=A0 =C2=A0> > really is whether (a) I2RS has requirements t= o be addresses and
=C2=A0 =C2=A0 =C2=A0> > NETMOD/NETCONF looks at solutions or whether = (b) I2RS casts a
=C2=A0 =C2=A0 =C2=A0> > solution into stone to be run through the NET= CONF working group or
=C2=A0 =C2=A0 =C2=A0> > whether (c) creates a solution on its own ind= ependently of any
=C2=A0 =C2=A0 other
=C2=A0 =C2=A0 =C2=A0> > NETMOD/NETCONF requirements.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> During that interim, we did discuss a number of de= tails regarding
=C2=A0 =C2=A0 overlays.
=C2=A0 =C2=A0 =C2=A0> We also discussed a number of issues that overlays= have when
=C2=A0 =C2=A0 ephemeral
=C2=A0 =C2=A0 =C2=A0> state was not disjoint from static configuration s= tate.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> As a result of that discussion and further present= ation at a later
=C2=A0 =C2=A0 =C2=A0> I2RS meeting regarding the Venn diagram interactio= ns of static and
=C2=A0 =C2=A0 =C2=A0> ephemeral configuration state, my latest draft att= empts to codify
=C2=A0 =C2=A0 =C2=A0> behaviors that shouldn't be problematic in eit= her proposed form or in
=C2=A0 =C2=A0 overlay.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> The point of frustration for all parties seems to = be that while the
=C2=A0 =C2=A0 =C2=A0> paragraph from you above seems to indicate that th= ere is some
=C2=A0 =C2=A0 =C2=A0> understanding of the requirements, I am unable to = provide text that
=C2=A0 =C2=A0 =C2=A0> illustrates either requirement or potential soluti= on to the matter.
=C2=A0 =C2=A0 =C2=A0> All parties are spending their resources saying &q= uot;I think I
=C2=A0 =C2=A0 understand this
=C2=A0 =C2=A0 point, but this is wrong."
=C2=A0 =C2=A0 =C2=A0> If the points are understood well enough to disagr= ee with potential
=C2=A0 =C2=A0 =C2=A0> solutions, I would suggest that they may be clear = enough for both
=C2=A0 =C2=A0 =C2=A0> protocol and data modeling experts to contribute t= ext that either
=C2=A0 =C2=A0 =C2=A0> clarifies the requirements to the collective exper= ts' needs or
=C2=A0 =C2=A0 =C2=A0> similarly a proposal documenting a solution.
=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 =C2=A0> These fundamental failures suggest a few possibili= ties:
=C2=A0 =C2=A0 =C2=A0> 1. There is a complete failure to properly communi= cate.=C2=A0 If so,
=C2=A0 =C2=A0 we should
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 find replacement parties to carry on = the work.=C2=A0 We had some
=C2=A0 =C2=A0 declared
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 interest in a design team.=C2=A0 Sue = has, I believe, contacted
=C2=A0 =C2=A0 people about
=C2=A0 =C2=A0 it.
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Those individuals should take over th= e work.
=C2=A0 =C2=A0 =C2=A0> 2. Netconf/restconf/yang are inappropriate tools a= nd we have
=C2=A0 =C2=A0 wasted the
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 Working Group's time.=C2=A0 I don= 't believe this as my employer has
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 ephemeral datastores in an upcoming r= elease.=C2=A0 It does not,
=C2=A0 =C2=A0 however,
=C2=A0 =C2=A0 have
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 full I2RS properties such as priority= or secondary-id.
=C2=A0 =C2=A0 =C2=A0> 3. The relevant experts are trying to get I2RS eph= emeral state
=C2=A0 =C2=A0 work to
=C2=A0 =C2=A0 die.
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 If so, let's have the relevant di= scussion either publicly or
=C2=A0 =C2=A0 privately
=C2=A0 =C2=A0 so
=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 we can stop wasting people's IETF= cycles.

=C2=A0 =C2=A0 I can assure you that, at least from my side, 3. is not the c= ase.

=C2=A0 =C2=A0 My perspective is likely slightly different from yours since = I (not
=C2=A0 =C2=A0 surprisingly) care more about NETCONF/RESTCONF and YANG than = I2RS
=C2=A0 =C2=A0 itself: If we add writable ephemeral state to NETCONF/RESTCON= F (and
=C2=A0 =C2=A0 perhaps
=C2=A0 =C2=A0 YANG), I believe we will have to envision more usages of that=
=C2=A0 =C2=A0 feature than
=C2=A0 =C2=A0 just I2RS. Looking at things from a wider and longer term
=C2=A0 =C2=A0 perspective, I am
=C2=A0 =C2=A0 concerned about (i) duplicated data modeling work and I am co= ncerned
=C2=A0 =C2=A0 about
=C2=A0 =C2=A0 (ii) use-case specific merge logic that needs to be supported= . From this
=C2=A0 =C2=A0 perspective, the overlay model has been prety attractive beca= use it
=C2=A0 =C2=A0 comes
=C2=A0 =C2=A0 with a single merge logic and it minimizes (or even eliminate= s)
=C2=A0 =C2=A0 duplicated
=C2=A0 =C2=A0 data modeling work.

=C2=A0 =C2=A0 /js

=C2=A0 =C2=A0 PS: Out of curiosity: Can you disclose what your employer'= ;s ephemeral
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0datastore solution coming out as a produc= t soon looks like? Is it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0closer to an overlay approach or is it cl= oser to what you
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0described in your I-D?

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Jacobs University Bremen gGmbH
=C2=A0 =C2=A0 Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Camp= us Ring 1 | 28759 Bremen | Germany
=C2=A0 =C2=A0 Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>

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



--001a11c3677e69b58a0518abca9c-- From nobody Thu Jun 18 14:59:45 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 45A1B1A8830; Thu, 18 Jun 2015 14:59:43 -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 W3MJoUXHaqmj; Thu, 18 Jun 2015 14:59:41 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D2791A1B2E; Thu, 18 Jun 2015 14:59:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.166.245; From: "Susan Hares" To: , Date: Thu, 18 Jun 2015 17:59:36 -0400 Message-ID: <007101d0aa12$12650d10$372f2730$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01D0A9F0.8B5800F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCqEBLOHQPWu27uSS6sM6nTmeEgVQ== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'Acee Lindem \(acee\)'" Subject: [i2rs] I2RS Requirements for OSPF ephemeral state X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2015 21:59:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0072_01D0A9F0.8B5800F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG is passing its requirements for I2RS protocol's to NETCONF. These requirements include ephemeral state, pub/sub, traceability, authentication of I2rs client/agent, security and transport requirements. As part of that work, we would like to confirm that the following things are useful for the I2RS protocol to support. . IGP-REQ01: Track Router-ID used in OSPF instances and by OSPF neighbors . IGP-REQ02: Allow ephemeral (temporary) configuration changes to OSPF . IGP-REQ03: Allow ephemeral Loop-Free Alternative configuration changes to OSPF . IGP-REQ04: Allow ephemeral load balancing configuration changes to OSPF . IGP-REQ05/REQ07: I2RS subscription (pub/sub) to OSPF notification via I2RS for interface, neighbor, topology, and prefix . IGP-REQ06: Subscription (pub/sub) or query of OSPF configuration and dynamic statistics via I2RS (interface, neighbor, lsdb) . IGP-REQ08: Subscription (pub/sub) or query of OSPF protocol statistics The number IGP-REQxx refers to the numbering used in draft-ietf-i2rs-usecase-reqs-summary-01 . Please let me know if these OSPF changes that can help manage temporary changes in OSPF? IMHO IGP-REQ03 is not a basic OSPF requirement and should only be supported on OSPF supporting LFA. How much yang model additions will these I2RS additions cost? All I2RS requirements except IGP-REQ03 can be implemented an ephemeral copy of the OSPF yang module augmented by OSPF protocol statistics, OSPF topology information (kept by I2RS L3 topology model), and 5+ I2RS specific notifications. Thank you for your help. Sue Hares ------=_NextPart_000_0072_01D0A9F0.8B5800F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = WG is passing its requirements for I2RS protocol’s to NETCONF. = These requirements include  ephemeral state, pub/sub, traceability, = authentication of I2rs client/agent, security and transport = requirements.   As part of that work, we would like to confirm = that the following things are useful for the I2RS protocol to = support.

 

·         = IGP-REQ01: Track Router-ID used in OSPF = instances and by OSPF neighbors

·         = IGP-REQ02: Allow ephemeral (temporary) = configuration changes to OSPF

·         = IGP-REQ03:  Allow ephemeral = Loop-Free Alternative configuration changes to OSPF

·         = IGP-REQ04: Allow ephemeral load balancing = configuration changes to OSPF

·         = IGP-REQ05/REQ07: I2RS subscription = (pub/sub) to OSPF notification via I2RS  for interface, neighbor, = topology, and prefix

·         = IGP-REQ06: Subscription (pub/sub) or = query of OSPF configuration and dynamic statistics via I2RS (interface, = neighbor, lsdb)

·         = IGP-REQ08: Subscription (pub/sub) or = query of  OSPF protocol statistics

 

The number = IGP-REQxx refers to the numbering used in draft-ietf-i2rs-usecase-reqs-summary-01. =  

 

Please let me know if these OSPF changes that can help = manage temporary changes in OSPF? IMHO IGP-REQ03 is not a basic OSPF = requirement and should only be supported on OSPF supporting LFA.  =  

 

How much yang model additions will these I2RS = additions cost?

All I2RS = requirements except IGP-REQ03 can be implemented an ephemeral copy of = the OSPF yang module augmented by OSPF protocol statistics, OSPF = topology information (kept by I2RS L3 topology model), and 5+ I2RS = specific notifications.   

 

Thank you = for your help.

 

Sue Hares =  

------=_NextPart_000_0072_01D0A9F0.8B5800F0-- From nobody Thu Jun 18 15:34:24 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008BF1A9071 for ; Thu, 18 Jun 2015 15:34:19 -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 clzRv371-9IM for ; Thu, 18 Jun 2015 15:34:17 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3C951A6EF0 for ; Thu, 18 Jun 2015 15:34:16 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.166.245; From: "Susan Hares" To: , Date: Thu, 18 Jun 2015 18:34:14 -0400 Message-ID: <009901d0aa16$e8465430$b8d2fc90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009A_01D0A9F5.6137C170" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCqFuDEJ8aXBxplTEGJdGIzhJKowA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , hannes@juniper.net, chopps@chopps.org, 'Alia Atlas' Subject: [i2rs] I2RS requirements for IGP protocols 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, 18 Jun 2015 22:34:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_009A_01D0A9F5.6137C170 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG is passing its requirements for I2RS protocol's to NETCONF. These requirements include ephemeral state, pub/sub, traceability, authentication of I2rs client/agent, security and transport requirements. As part of that work, we would like to confirm that the following things are useful for the I2RS protocol to support. . IGP-REQ01: Track system-id used in ISIS instances and IS neighbors on ISIS adjacencies . IGP-REQ02: Allow ephemeral (temporary) configuration changes to ISIS . IGP-REQ03: Allow ephemeral configuration to fast-reroute in ISIS . IGP-REQ04: Allow ephemeral load balancing configuration changes to ISIS flows . IGP-REQ05/REQ07: I2RS subscription (pub/sub) to ISIS notification via I2RS for interface, neighbor, database, and prefix . IGP-REQ06: Subscription (pub/sub) or query of ISIS configuration and dynamic statistics via I2RS (interface, neighbor, database) . IGP-REQ08: Subscription (pub/sub) or query of ISIS protocol statistics The number IGP-REQxx refers to the numbering used in draft-ietf-i2rs-usecase-reqs-summary-01 . Please let me know if these I2RS features ISIS changes that can help manage short-term changes to ISIS topology for DDoS, changes to exits, or on-demand bandwidth paths. How much yang model additions will these I2RS additions cost? All I2RS requirements can be implemented an ephemeral copy of the ISIS yang module augmented by: a) 5+ notifications and b) I2RS L3 Topology model which reads in the IGP data from ISIS. Thank you for your help. Sue Hares ------=_NextPart_000_009A_01D0A9F5.6137C170 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS = WG is passing its requirements for I2RS protocol’s to NETCONF. = These requirements include  ephemeral state, pub/sub, traceability, = authentication of I2rs client/agent, security and transport = requirements.   As part of that work, we would like to confirm = that the following things are useful for the I2RS protocol to = support.

 

·         = IGP-REQ01: Track system-id used in ISIS = instances and IS neighbors on ISIS adjacencies  

·         = IGP-REQ02: Allow ephemeral (temporary) = configuration changes to ISIS

·         = IGP-REQ03: Allow ephemeral configuration = to fast-reroute in ISIS

·         = IGP-REQ04: Allow ephemeral load balancing = configuration changes to ISIS flows

·         = IGP-REQ05/REQ07: I2RS subscription = (pub/sub) to ISIS notification via I2RS  for interface, neighbor, = database, and prefix

·         = IGP-REQ06: Subscription (pub/sub) or = query of ISIS configuration and dynamic statistics via I2RS (interface, = neighbor, database)

·         = IGP-REQ08: Subscription (pub/sub) or = query of  ISIS protocol statistics

 

The number = IGP-REQxx refers to the numbering used in draft-ietf-i2rs-usecase-reqs-summary-01.   Please let me = know if these I2RS features ISIS changes that can help manage short-term = changes to ISIS topology for DDoS, changes to exits, or on-demand = bandwidth paths.

 

 

How much = yang model additions will these I2RS additions cost? =

All I2RS requirements can be = implemented an ephemeral copy of the ISIS yang module augmented by: a) = 5+ notifications and b) I2RS L3 Topology model which reads in the IGP = data from ISIS.

 

Thank you = for your help.

 

Sue Hares =  

 

------=_NextPart_000_009A_01D0A9F5.6137C170-- From nobody Thu Jun 18 23:46: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 7E49B1A1EF9; Thu, 18 Jun 2015 23:46:37 -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 QSmMtEO3zt3i; Thu, 18 Jun 2015 23:46:36 -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 D566F1A1EF4; Thu, 18 Jun 2015 23:46:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F356C8EA; Fri, 19 Jun 2015 08:46:31 +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 0-AUdEIjEBGz; Fri, 19 Jun 2015 08:46:21 +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, 19 Jun 2015 08:46:31 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00D062002B; Fri, 19 Jun 2015 08:46:34 +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 BdRB-PTISwmg; Fri, 19 Jun 2015 08:46:44 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98EC62002C; Fri, 19 Jun 2015 08:46:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6F8263476AC4; Fri, 19 Jun 2015 08:46:31 +0200 (CEST) Date: Fri, 19 Jun 2015 08:46:30 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150619064629.GA25770@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201d0a38d$20d635d0$6282a170$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) 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, 19 Jun 2015 06:46:37 -0000 On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote: > Juergen: > > > The I2RS WG still needs a written draft proposing how this would work to > have an effective discussion. > > My understanding is that I2RS formulates requirements and the solution is done in NETCONF. If this is correct, then there is in principle no point in sending solution drafts to I2RS. Yes, I understand that requirements are often written with certain solutions in mind and this is why requirement processes usually are frustrating. /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 Jun 19 08:09:34 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74D9F1A8A75; Fri, 19 Jun 2015 08:09:33 -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 P7kwNJFeoEca; Fri, 19 Jun 2015 08:09:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A871A8ABD; Fri, 19 Jun 2015 08:09:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id BDD3A840F74; Fri, 19 Jun 2015 08:09:30 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 12812840F46; Fri, 19 Jun 2015 08:09:29 -0700 (PDT) To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> <20150619064629.GA25770@elstar.local> From: "Joel M. Halpern" Message-ID: <55843089.5020604@joelhalpern.com> Date: Fri, 19 Jun 2015 11:08:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150619064629.GA25770@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 19 Jun 2015 15:09:33 -0000 While I would expect most of the detail work on a solution to be done in NetConf, it would be very unusual to treat the requirements as something thrown over the wall, with the ensuing work done only in NetConf. If NetConf wants its work to be suitable to meet the I2RS requirements, then experience with many cross-WG activities tells us the proposal will need to also be reviewed and discussed with I2RS. If NetConf wants to do what it judges is best, and merely hope that I2RS adopts it when it is done, then the NetConf WG is certainly free to do that. But the odds of meeting the requirements are low, and the odds of I2RS waiting around on the assumption that the right magic will be thrown back over the wall is also low. Yours, Joel On 6/19/15 2:46 AM, Juergen Schoenwaelder wrote: > On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote: >> Juergen: >> >> >> The I2RS WG still needs a written draft proposing how this would work to >> have an effective discussion. >> >> > > My understanding is that I2RS formulates requirements and the solution > is done in NETCONF. If this is correct, then there is in principle no > point in sending solution drafts to I2RS. > > Yes, I understand that requirements are often written with certain > solutions in mind and this is why requirement processes usually are > frustrating. > > /js > From nobody Fri Jun 19 09:27: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 B0D7B1AC3F0 for ; Fri, 19 Jun 2015 09:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4zfHiSjZ0Sp for ; Fri, 19 Jun 2015 09:27:36 -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 62C831A1A1E for ; Fri, 19 Jun 2015 09:27:30 -0700 (PDT) Received: by laka10 with SMTP id a10so77410698lak.0 for ; Fri, 19 Jun 2015 09:27: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; bh=2kLHfcQKyUgIc+3sw1B5Lw6C+JREDAqzfFuMu1lb9/c=; b=M1nO5KDq2NM5LfYfrUkIYjosfBCMY8by4AJq8/x85zVsp81HEq4D7ocIOb+pYEmCrB gY1S/wLgHuo6MOiQWhAjuxWaNRct+Ba9wM3WjeEb84+Pnvil1MBI3TGDsahpmpiPvk54 qcJ+lA3nped8JdCGOcNg8V6fElErbZ+BYBuMDMdmShoyVDnY/zLx9jT37i5gy2L1ZKMx YJPok5o/uiyomROfYsnApnXLn0TL6ZvBFgqBcN/tb3IlUCyE8IiPVLLwfSM9HrRFe5Z6 A3GXmbNs7rfqTkY8Adzn3b/0nEJxKY0RtcIg8bnxkpTn9S5fb7diQMRVnfy8dtgkvzkT 2gfg== X-Gm-Message-State: ALoCoQkWG7G5qpQ2y80DdvAuC5i3UiXChlLRYlWWlhBpG9GBKbl1+1DkKL6ux8ULKel88dReVOzQ MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr18544662lab.82.1434731248836; Fri, 19 Jun 2015 09:27:28 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Fri, 19 Jun 2015 09:27:28 -0700 (PDT) In-Reply-To: <55843089.5020604@joelhalpern.com> References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> <20150619064629.GA25770@elstar.local> <55843089.5020604@joelhalpern.com> Date: Fri, 19 Jun 2015 09:27:28 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a11c3677e6f79980518e166e6 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , i2rs-chairs@ietf.org, Susan Hares , Alia Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 19 Jun 2015 16:27:39 -0000 --001a11c3677e6f79980518e166e6 Content-Type: text/plain; charset=UTF-8 Hi, It is all too easy for IETF work to fall apart because of charter overlap. It's way too easy to confuse process with progress. Since the IETF is comprised of volunteers, it usually takes the involvement of stake-holders all the way through to RFC publication to get work done. My guess that unless I2RS people are involved and doing most of the work, the NETCONF WG is not likely to make much progress or even get started. Andy On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern wrote: > While I would expect most of the detail work on a solution to be done in > NetConf, it would be very unusual to treat the requirements as something > thrown over the wall, with the ensuing work done only in NetConf. If > NetConf wants its work to be suitable to meet the I2RS requirements, then > experience with many cross-WG activities tells us the proposal will need to > also be reviewed and discussed with I2RS. > > If NetConf wants to do what it judges is best, and merely hope that I2RS > adopts it when it is done, then the NetConf WG is certainly free to do > that. But the odds of meeting the requirements are low, and the odds of > I2RS waiting around on the assumption that the right magic will be thrown > back over the wall is also low. > > Yours, > Joel > > On 6/19/15 2:46 AM, Juergen Schoenwaelder wrote: > >> On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote: >> >>> Juergen: >>> >>> >>> The I2RS WG still needs a written draft proposing how this would work to >>> have an effective discussion. >>> >>> >>> >> My understanding is that I2RS formulates requirements and the solution >> is done in NETCONF. If this is correct, then there is in principle no >> point in sending solution drafts to I2RS. >> >> Yes, I understand that requirements are often written with certain >> solutions in mind and this is why requirement processes usually are >> frustrating. >> >> /js >> >> > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a11c3677e6f79980518e166e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

It is all too easy for IETF work to= fall apart because of charter overlap.
It's way too easy to = confuse process with progress.

Since the IETF is c= omprised of volunteers, it usually takes the involvement
of stake= -holders all the way through to RFC publication to get work done.
My guess that unless I2RS people are involved and doing most of the work,<= /div>
the NETCONF WG is not likely to make much progress or even get st= arted.


Andy




On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
While I would exp= ect most of the detail work on a solution to be done in NetConf, it would b= e very unusual to treat the requirements as something thrown over the wall,= with the ensuing work done only in NetConf.=C2=A0 If NetConf wants its wor= k to be suitable to meet the I2RS requirements, then experience with many c= ross-WG activities tells us the proposal will need to also be reviewed and = discussed with I2RS.

If NetConf wants to do what it judges is best, and merely hope that I2RS ad= opts it when it is done, then the NetConf WG is certainly free to do that.= =C2=A0 But the odds of meeting the requirements are low, and the odds of I2= RS waiting around on the assumption that the right magic will be thrown bac= k over the wall is also low.

Yours,
Joel

On 6/19/15 2:46 AM, Juergen Schoenwaelder wrote:
On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote:
Juergen:

<chair hat on>
The I2RS WG still needs a written draft proposing how this would work to have an effective discussion.
<chair hat off>


My understanding is that I2RS formulates requirements and the solution
is done in NETCONF. If this is correct, then there is in principle no
point in sending solution drafts to I2RS.

Yes, I understand that requirements are often written with certain
solutions in mind and this is why requirement processes usually are
frustrating.

/js


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

--001a11c3677e6f79980518e166e6-- From nobody Fri Jun 19 11:12: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 85FA01ACE80; Fri, 19 Jun 2015 11:12:24 -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 MZmoURKZe7Bp; Fri, 19 Jun 2015 11:12:22 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C541ACE83; Fri, 19 Jun 2015 11:12:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.166.245; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> <20150619064629.GA25770@elstar.local> In-Reply-To: <20150619064629.GA25770@elstar.local> Date: Fri, 19 Jun 2015 14:12:10 -0400 Message-ID: <022901d0aabb$7647fd20$62d7f760$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_022A_01D0AA99.EF37E3C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fgH6v/10AuL3kOAArrRk9gJFnFdAnmh/NvA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, "'Joel M. Halpern'" , i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 19 Jun 2015 18:12:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_022A_01D0AA99.EF37E3C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juergen: Is your email a request for information regarding the I2RS process or a concern regarding the process? If you wished additional information about the process, as a chair - I am glad to repeat the process to make it clear. Please see the restatement of the process below. The I2RS chairs chose to provide additional input on solutions to guide NETCONF in understanding the I2RS requirements. Based on earlier feedback on too little details on our requirements, the I2RS chairs choose to provide extra details. If you are concerned about our providing extra detail, I have noted your concern. The chairs choose this direction knowing the pros/cons. We hope it will help NETCONF. If you wished to influence the I2RS requirements, you were invited to provide a proposal that would influence the I2RS WG requirements. Since you did not, you are welcome to influence the NETCONF process in providing a solution. In the IETF, you have the freedom choose where you volunteer your efforts. Best wishes for a wonderful day, Sue Hares ===================================================================== Process restated: At the end of IETF 92, the NETCONF chairs agreed with the I2RS chairs on the following cycle of work to resolve the I2RS/NETCONF work on the I2RS re-use of an NETCONF protocol a) I2RS would create a set of requirements for the I2RS protocol, b) I2RS would send these requirements to the NETCONF, and within a month of sending the requirements NETCONF would provide a review of those requirements and an initial suggestion to those solutions c) After NETCONF suggests a solution, I2RS will review it to see if it accept it. There is no requirement for NETCONF solution to be selected as an I2RS protocol. There is no requirement for the NETCONF solution to be the only protocol I2RS selection to support the I2RS interface. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, June 19, 2015 2:47 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote: > Juergen: > > > The I2RS WG still needs a written draft proposing how this would work > to have an effective discussion. > > My understanding is that I2RS formulates requirements and the solution is done in NETCONF. If this is correct, then there is in principle no point in sending solution drafts to I2RS. Yes, I understand that requirements are often written with certain solutions in mind and this is why requirement processes usually are frustrating. /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/> ------=_NextPart_000_022A_01D0AA99.EF37E3C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juergen:

 

Is your = email  a request for information regarding the I2RS process or a = concern regarding the process? If you wished additional information = about the process, as a chair - I am glad to repeat the process to make = it clear. Please see the restatement of the process below. =   

 

The I2RS chairs chose to provide additional input on = solutions to guide NETCONF in understanding the I2RS requirements. =   Based on earlier feedback on too little details on our = requirements, the I2RS chairs choose to provide extra details.  If = you are concerned about our providing extra detail, I have noted your = concern.  The chairs choose this direction knowing the = pros/cons.  We hope it will help NETCONF.

 

If you = wished to influence the I2RS requirements, you were invited to provide a = proposal that would influence the I2RS WG requirements.   = Since you did not, you are welcome to influence the NETCONF process in = providing a solution.  In the IETF, you have the freedom choose = where you volunteer your efforts.

 

Best wishes = for a wonderful day,

Sue Hares =

 

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

Process restated: =

 

At the end of IETF 92, the NETCONF chairs agreed = with the I2RS chairs on the following cycle of work to resolve the = I2RS/NETCONF work on the I2RS re-use of an NETCONF protocol =

 

a) I2RS would create a set of requirements for the = I2RS protocol,

 

b) = I2RS would send these requirements to the NETCONF, and

within a month of sending the requirements NETCONF = would provide

a review of those = requirements and an initial suggestion to those solutions =

 

c) After NETCONF  suggests a solution, I2RS = will review it to see if it accept it.

 

There = is no requirement for NETCONF solution to be selected as an I2RS = protocol. There is no requirement for the NETCONF solution to be the = only protocol I2RS selection to support the I2RS interface. =

 

 

 

-----Original Message-----
From: Juergen = Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: = Friday, June 19, 2015 2:47 AM
To: Susan Hares
Cc: 'Jeffrey Haas'; = i2rs@ietf.org; 'Joel M. Halpern'; i2rs-chairs@ietf.org; 'Alia = Atlas'
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim = (5/27/2015)

 

On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan = Hares wrote:

> = Juergen:

>

> <chair hat on>

> The I2RS WG still needs a written draft = proposing how this would work

> to have an effective = discussion.

> <chair hat = off>

> 

 

My = understanding is that I2RS formulates requirements and the solution is = done in NETCONF. If this is correct, then there is in principle no point = in sending solution drafts to I2RS.

 

Yes, I = understand that requirements are often written with certain solutions in = mind and this is why requirement processes usually are = frustrating.

 

/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/>

------=_NextPart_000_022A_01D0AA99.EF37E3C0-- From nobody Fri Jun 19 11:23: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 D5C801ACED1; Fri, 19 Jun 2015 11:23:43 -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 vHgp4777e-Un; Fri, 19 Jun 2015 11:23:42 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2577D1ACEBB; Fri, 19 Jun 2015 11:23:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.166.245; From: "Susan Hares" To: "'Andy Bierman'" , "'Joel M. Halpern'" References: <000e01d09e60$57db6730$07923590$@ndzh.com> <20150604062424.GA40773@elstar.local> <01fe01d09eff$f51d4690$df57d3b0$@ndzh.com> <20150605123533.GA55279@elstar.local> <20150610003444.GC21226@pfrc.org> <20150610124435.GC37135@elstar.local> <000201d0a38d$20d635d0$6282a170$@ndzh.com> <20150619064629.GA25770@elstar.local> <55843089.5020604@joelhalpern.com> In-Reply-To: Date: Fri, 19 Jun 2015 14:23:39 -0400 Message-ID: <024301d0aabd$110d9cb0$3328d610$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0244_01D0AA9B.89FF09F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE7Ym4ASWic4wJc0k7xiPsd0EWwAQKAc9ipAmLgPkkCD3L4fgH6v/10AuL3kOAArrRk9gJFnFdAAvOKUTUCVXnEip4+RkqA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs-chairs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/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: Fri, 19 Jun 2015 18:23:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0244_01D0AA9B.89FF09F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 The NETCONF chairs promised an initial response within a month. I hope = NETCONF can at least provide a scope during that time period.=20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, June 19, 2015 12:27 PM To: Joel M. Halpern Cc: Susan Hares; Jeffrey Haas; i2rs@ietf.org; i2rs-chairs@ietf.org; Alia = Atlas Subject: Re: [i2rs] I2RS minutes for the I2RS Interim (5/27/2015) =20 Hi, =20 It is all too easy for IETF work to fall apart because of charter = overlap. It's way too easy to confuse process with progress. =20 Since the IETF is comprised of volunteers, it usually takes the = involvement of stake-holders all the way through to RFC publication to get work = done. My guess that unless I2RS people are involved and doing most of the = work, the NETCONF WG is not likely to make much progress or even get started. =20 =20 Andy =20 =20 =20 =20 On Fri, Jun 19, 2015 at 8:08 AM, Joel M. Halpern = wrote: While I would expect most of the detail work on a solution to be done in = NetConf, it would be very unusual to treat the requirements as something = thrown over the wall, with the ensuing work done only in NetConf. If = NetConf wants its work to be suitable to meet the I2RS requirements, = then experience with many cross-WG activities tells us the proposal will = need to also be reviewed and discussed with I2RS. If NetConf wants to do what it judges is best, and merely hope that I2RS = adopts it when it is done, then the NetConf WG is certainly free to do = that. But the odds of meeting the requirements are low, and the odds of = I2RS waiting around on the assumption that the right magic will be = thrown back over the wall is also low. Yours, Joel On 6/19/15 2:46 AM, Juergen Schoenwaelder wrote: On Wed, Jun 10, 2015 at 10:52:51AM -0400, Susan Hares wrote: Juergen: The I2RS WG still needs a written draft proposing how this would work to have an effective discussion. My understanding is that I2RS formulates requirements and the solution is done in NETCONF. If this is correct, then there is in principle no point in sending solution drafts to I2RS. Yes, I understand that requirements are often written with certain solutions in mind and this is why requirement processes usually are frustrating. /js _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0244_01D0AA9B.89FF09F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

The NETCONF chairs promised an initial response within a month.=C2=A0 = I hope NETCONF can at least provide a scope during that time period. =

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, June = 19, 2015 12:27 PM
To: Joel M. Halpern
Cc: Susan = Hares; Jeffrey Haas; i2rs@ietf.org; i2rs-chairs@ietf.org; Alia = Atlas
Subject: Re: [i2rs] I2RS minutes for the I2RS Interim = (5/27/2015)

 

Hi,

 

It is all too easy for IETF work to fall apart because = of charter overlap.

It's = way too easy to confuse process with = progress.

 

Since the IETF is comprised of volunteers, it usually = takes the involvement

of = stake-holders all the way through to RFC publication to get work = done.

My guess that unless = I2RS people are involved and doing most of the = work,

the NETCONF WG is = not likely to make much progress or even get = started.

 

 

Andy

 

 

 

 

On Fri, = Jun 19, 2015 at 8:08 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

While I would expect most of the detail work on a = solution to be done in NetConf, it would be very unusual to treat the = requirements as something thrown over the wall, with the ensuing work = done only in NetConf.  If NetConf wants its work to be suitable to = meet the I2RS requirements, then experience with many cross-WG = activities tells us the proposal will need to also be reviewed and = discussed with I2RS.

If NetConf wants to do what it judges is = best, and merely hope that I2RS adopts it when it is done, then the = NetConf WG is certainly free to do that.  But the odds of meeting = the requirements are low, and the odds of I2RS waiting around on the = assumption that the right magic will be thrown back over the wall is = also low.

Yours,
Joel

On 6/19/15 2:46 AM, Juergen = Schoenwaelder wrote:

On Wed, Jun 10, = 2015 at 10:52:51AM -0400, Susan Hares wrote:

Juergen:

<chair hat = on>
The I2RS WG still needs a written draft proposing how this = would work to
have an effective discussion.
<chair hat = off>


My understanding is that I2RS = formulates requirements and the solution
is done in NETCONF. If this = is correct, then there is in principle no
point in sending solution = drafts to I2RS.

Yes, I understand that requirements are often = written with certain
solutions in mind and this is why requirement = processes usually are
frustrating.

/js


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

 

------=_NextPart_000_0244_01D0AA9B.89FF09F0-- From nobody Mon Jun 22 05:09: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 47EAE1A049A for ; Mon, 22 Jun 2015 05:09:48 -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 hLpluOsOAUj7 for ; Mon, 22 Jun 2015 05:09:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF871A03A0 for ; Mon, 22 Jun 2015 05:09:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.195.139; From: "Susan Hares" To: Date: Mon, 22 Jun 2015 08:09:41 -0400 Message-ID: <012901d0ace4$51f7f530$f5e7df90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012A_01D0ACC2.CAE73F90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCs5CH+3iNy1oApRgGLXdP/1Yq5AA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] I2RS meeting at 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, 22 Jun 2015 12:09:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012A_01D0ACC2.CAE73F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS will be meeting at 17:40 - 18:40 on Tuesday 7/21/2015 and 17:40 - 19:10 on Thursday 7/23/2015. Sue Hares and Jeff Haas ------=_NextPart_000_012A_01D0ACC2.CAE73F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I2RS will = be meeting at 17:40 – 18:40 on Tuesday 7/21/2015 and 17:40 – = 19:10 on Thursday 7/23/2015.

 

Sue Hares = and Jeff Haas

 

------=_NextPart_000_012A_01D0ACC2.CAE73F90-- From nobody Mon Jun 22 11:36: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 72A911A1A02 for ; Mon, 22 Jun 2015 11:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.122 X-Spam-Level: * X-Spam-Status: No, score=1.122 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 cvSvRxdmELs7 for ; Mon, 22 Jun 2015 11:36:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE41A1A00 for ; Mon, 22 Jun 2015 11:36:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 493AA1E3A6; Mon, 22 Jun 2015 14:38:10 -0400 (EDT) Date: Mon, 22 Jun 2015 14:38:10 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20150622183810.GC30137@pfrc.org> References: <20150614125103.GA3063@elstar.local> <003101d0a6d4$32b27c60$98177520$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003101d0a6d4$32b27c60$98177520$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , 'Alia Atlas' Subject: Re: [i2rs] storage of priority and client ID with a node 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, 22 Jun 2015 18:36:55 -0000 On Sun, Jun 14, 2015 at 02:59:10PM -0400, Susan Hares wrote: > Juergen: > > Would Jeff's ephemeral state be a reasonable place to put it. The ephemeral state draft is one possibility. A second one would be a standalone draft meant to serve as an appendix on this point for the architecture. -- Jeff From nobody Tue Jun 23 06:02:45 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 2F8F71A026C for ; Tue, 23 Jun 2015 06:02:44 -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_50=0.8, GB_I_LETTER=-2, 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 PwUD3LdlHIvP for ; Tue, 23 Jun 2015 06:02:40 -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 9DC601A0358 for ; Tue, 23 Jun 2015 06:02:38 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7B43D3A0221; Tue, 23 Jun 2015 15:02:36 +0200 (CEST) Received-SPF: PermError (tgtim3c03.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP102.EUROPE.telefonica.corp) Received: from ESTGVMSP102.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 5EEFE3A0214; Tue, 23 Jun 2015 15:02:36 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.49) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Jun 2015 15:02:35 +0200 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:02:34 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 13:02:34 +0000 From: DIEGO LOPEZ GARCIA To: Alia Atlas Thread-Topic: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 Thread-Index: AQHQpILdCszgEnUD0kWN0jCiLF3lGZ26IKOA Date: Tue, 23 Jun 2015 13:02:34 +0000 Message-ID: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [91.235.173.15] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0624; 5:8M42PlgpPLb7kLa+dNKaqAOicInkZHjPeHtN0+VBjU0BqpnZt7M/LVEba8TEdnyyqovTxAUSaH19k9fn5+rVr4FGWdjumyt3lIaQcIIgApxmGiV1u0LmvZi3+75E3QrGVIxr40GDXDydKKMoGxZLYw==; 24:OorwdmEb+074nNvt2Dim0+n54q/eRfcN06UEGYq9LO9dBPZbqaHOzH8gqHX0byAdsUNa9mEjnYP8FULVGo5LadZoP3pIeLAgiZF3w2TEEeM=; 20:gxKTjS1nbbuyivaTNeiY9CMlVKwBPJrQuiLO1TGU60sGndz5zfSvqtbiklUVd/+ISxBrqwbnZpDVMaXFXG5EAw== 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: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(252514010)(52604005)(164054003)(51704005)(51444003)(82746002)(40100003)(551934003)(102836002)(15975445007)(1411001)(66066001)(122556002)(33656002)(50986999)(54356999)(77096005)(19580405001)(19580395003)(87936001)(2656002)(86362001)(106116001)(5001920100001)(5002640100001)(92566002)(110136002)(189998001)(5001960100002)(77156002)(62966003)(230783001)(36756003)(46102003)(2950100001)(19617315012)(83716003)(76176999)(2900100001)(104396002)(299355004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0624; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 13:02:34.1303 (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" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:02:44 -0000 --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=3Dus-ascii Hi Alia, Just a remark on your comment about section 3.1: I think the current =3D requirement of associating a single secondary identity per connection =3D does make sense if we want to keep traceability over I2RS secure =3D transports.=3D20 You need to associate secondary identities with primary ones in a secure = =3D way to guarantee such traceability, and the mechanisms for this I can =3D imagine using current transports (such as a certificate extension or =3D alternate identity, or additional information in secure tokens) are =3D associated with connection handshake, and therefore re-association is =3D complicated to implement without restarting the connection. Note I say =3D complicated, not impossible, but I cannot see the advantage in the =3D additional complexity, especially when experience shows that additional =3D complexity becoming source of security flaws... Be goode, On 11 Jun 2015, at 22:11 , Alia Atlas wrote: > >=3D20 > Sue, >=3D20 > Thanks for writing this draft. I think it is useful to clearly =3D articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication. I do have a couple comments on the =3D draft. >=3D20 >=3D20 > In Sec 3.1, it says "Each Identity will be linked to one secondary =3D identity for the period of a connection." I would have assumed that the = =3D client could arbitrarily change its' secondary identity. This is to =3D support the broker case where a client may be passing along requests =3D from multiple applications. Since the secondary identity is just passed = =3D along and stored for traceability, I don't think that allowing it to =3D change would cause significant complications. What do others think? >=3D20 >=3D20 > In the I2RS architecture, there are 3 different types of transaction =3D behavior desired for processing a message. In Sec 4, there's an =3D assumption that "fail-on-error" with the associated roll-back is the =3D only mode. Thus, I think that Section 4 needs a bit of massaging. >=3D20 >=3D20 > Thanks, >=3D20 > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- "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 ---------------------------------- --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=3Dus-ascii Hi =3D Alia,

Just a remark on your comment about section =3D 3.1: I think the current requirement of associating a single secondary =3D identity per connection does make sense if we want to keep traceability =3D over I2RS secure transports. 

You need to =3D associate secondary identities with primary ones in a secure way to =3D guarantee such traceability, and the mechanisms for this I can imagine =3D using current transports (such as a certificate extension or alternate =3D identity, or additional information in secure tokens) are associated =3D with connection handshake, and therefore re-association is complicated =3D to implement without restarting the connection. Note I say complicated, =3D not impossible, but I cannot see the advantage in the additional =3D complexity, especially when experience shows that additional complexity =3D becoming source of security flaws...

Be =3D goode,

On 11 Jun 2015, at 22:11 , Alia Atlas =3D <akatlas@gmail.com> =3D wrote:

<no-hat>

Sue,

Tha= nks=3D for writing this draft.  I think it is useful to clearly =3D articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.  I do have a couple comments on the =3D draft.


In Sec 3.1, it says "Each Identity will be linked to =3D one secondary identity for the period of a connection."  I would =3D have assumed that the client could arbitrarily change its' secondary =3D identity.  This is to support the broker case where a client may be = =3D passing along requests from multiple applications.  Since the =3D secondary identity is just passed along and stored for traceability, I =3D don't think that allowing it to change would cause significant =3D complications.   What do others think?


In the I2RS =3D architecture, there are 3 different types of transaction behavior =3D desired for processing a message. In Sec 4, there's an assumption that =3D "fail-on-error" with the associated roll-back is the only mode.   =3D Thus, I think that Section 4 needs a bit of =3D massaging.


Thanks,

Alia
_______________________________________________
i2rs mailing =3D list
i2rs@ietf.org
https://www.ietf.org/m= a=3D ilman/listinfo/i2rs

--
"Esta vez no fallaremos, Doctor =3D Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lop= e=3D z/

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

=3D --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1-- ________________________________ 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 From nobody Tue Jun 23 06:11: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 A36781A1A7D for ; Tue, 23 Jun 2015 06:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OglJoeLs6EFX for ; Tue, 23 Jun 2015 06:10:57 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F207B1A1A9D for ; Tue, 23 Jun 2015 06:10:56 -0700 (PDT) Received: by obpn3 with SMTP id n3so5778887obp.0 for ; Tue, 23 Jun 2015 06:10:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QrxbmKDMkmH/vC9rOlQj6wF3SesqgFN2eFYiOCcYtow=; b=ak70jKskepXP5CkebEAe/Tq+/OpbrKeGWrAWsbZ/O0P1JMXahdlk7xNhrVty+pWZ2q hkhrYos8oKGUxQ/MfKNb2aNQ2W/IRPoM2QtbiuThf9XzdVXU2lnL/rJsNJWczL0vP3xL TzmN7PvFdoowArV7s8/5Uq0R45pVQ50HW7frqry7C86mspxDxcXvePhdPTY8QVMGzfVM twwrQc8wghl5fuPMSb853sYvl0vdr0Rq86NXRNoatvYufCwKKdzogihzlgHd5zUVlvh4 PXqCPg0Oodgy5uV7sf4r/yTsLOWG/dWKH2atWFVskcyOWuKse6mls5/fm9USaoIuqmp9 ar3Q== MIME-Version: 1.0 X-Received: by 10.202.89.213 with SMTP id n204mr3377285oib.91.1435065056385; Tue, 23 Jun 2015 06:10:56 -0700 (PDT) Received: by 10.60.165.145 with HTTP; Tue, 23 Jun 2015 06:10:56 -0700 (PDT) In-Reply-To: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> References: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> Date: Tue, 23 Jun 2015 09:10:56 -0400 Message-ID: From: Alia Atlas To: DIEGO LOPEZ GARCIA Content-Type: multipart/alternative; boundary=001a113d2b16ea60b305192f1e82 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:11:01 -0000 --001a113d2b16ea60b305192f1e82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Diego, The secondary identity is just an opaque value to allow traceability. It's to support a client easily being a broker for multiple applications. I don't agree that there is value in trying to secure the secondary identity the way you are describing. This path leads to there being basically no value for having secondary identities. Regards, Alia On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA < diego.r.lopez@telefonica.com> wrote: > > --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=3Dus-ascii > > Hi Alia, > > Just a remark on your comment about section 3.1: I think the current =3D > requirement of associating a single secondary identity per connection =3D > does make sense if we want to keep traceability over I2RS secure =3D > transports.=3D20 > > You need to associate secondary identities with primary ones in a secure = =3D > way to guarantee such traceability, and the mechanisms for this I can =3D > imagine using current transports (such as a certificate extension or =3D > alternate identity, or additional information in secure tokens) are =3D > associated with connection handshake, and therefore re-association is =3D > complicated to implement without restarting the connection. Note I say = =3D > complicated, not impossible, but I cannot see the advantage in the =3D > additional complexity, especially when experience shows that additional = =3D > complexity becoming source of security flaws... > > Be goode, > > On 11 Jun 2015, at 22:11 , Alia Atlas wrote: > > > > >=3D20 > > Sue, > >=3D20 > > Thanks for writing this draft. I think it is useful to clearly =3D > articulate the outside-of-I2RS behavior and protocols that are needed =3D > for the mutual authentication. I do have a couple comments on the =3D > draft. > >=3D20 > >=3D20 > > In Sec 3.1, it says "Each Identity will be linked to one secondary =3D > identity for the period of a connection." I would have assumed that the = =3D > client could arbitrarily change its' secondary identity. This is to =3D > support the broker case where a client may be passing along requests =3D > from multiple applications. Since the secondary identity is just passed = =3D > along and stored for traceability, I don't think that allowing it to =3D > change would cause significant complications. What do others think? > >=3D20 > >=3D20 > > In the I2RS architecture, there are 3 different types of transaction = =3D > behavior desired for processing a message. In Sec 4, there's an =3D > assumption that "fail-on-error" with the associated roll-back is the =3D > only mode. Thus, I think that Section 4 needs a bit of massaging. > >=3D20 > >=3D20 > > Thanks, > >=3D20 > > Alia > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > "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 > ---------------------------------- > > > --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; > charset=3Dus-ascii > > charset=3D3Dus-ascii"> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =3D > Alia,

Just a remark on your comment about section =3D > 3.1: I think the current requirement of associating a single secondary = =3D > identity per connection does make sense if we want to keep traceability = =3D > over I2RS secure transports. 

You need to = =3D > associate secondary identities with primary ones in a secure way to =3D > guarantee such traceability, and the mechanisms for this I can imagine = =3D > using current transports (such as a certificate extension or alternate = =3D > identity, or additional information in secure tokens) are associated =3D > with connection handshake, and therefore re-association is complicated = =3D > to implement without restarting the connection. Note I say complicated, = =3D > not impossible, but I cannot see the advantage in the additional =3D > complexity, especially when experience shows that additional complexity = =3D > becoming source of security flaws...

Be =3D > goode,

On 11 Jun 2015, at 22:11 , Alia Atlas =3D > <akatlas@gmail.com> =3D > wrote:

type=3D3D"cite"> charset=3D3Dutf-8">
<no-hat>

Sue,

T= hanks=3D > for writing this draft.  I think it is useful to clearly =3D > articulate the outside-of-I2RS behavior and protocols that are needed =3D > for the mutual authentication.  I do have a couple comments on the = =3D > draft.


In Sec 3.1, it says "Each Identity will be linked to = =3D > one secondary identity for the period of a connection."  I would =3D > have assumed that the client could arbitrarily change its' secondary =3D > identity.  This is to support the broker case where a client may be = =3D > passing along requests from multiple applications.  Since the =3D > secondary identity is just passed along and stored for traceability, I = =3D > don't think that allowing it to change would cause significant =3D > complications.   What do others think?


In the I2RS =3D > architecture, there are 3 different types of transaction behavior =3D > desired for processing a message. In Sec 4, there's an assumption that = =3D > "fail-on-error" with the associated roll-back is the only mode.   = =3D > Thus, I think that Section 4 needs a bit of =3D > massaging.


Thanks,

Alia
> _______________________________________________
i2rs mailing =3D > list
href=3D3D"mailto:i2rs@ietf.org">i2rs@ietf.org
> https://www.ietf.org/ma=3D > ilman/listinfo/i2rs

apple-content-edited=3D3D"true"> >
auto; text-align: start; text-indent: 0px; text-transform: none; =3D > white-space: normal; widows: auto; word-spacing: 0px; =3D > -webkit-text-stroke-width: 0px; word-wrap: break-word; =3D > -webkit-nbsp-mode: space; -webkit-line-break: =3D > after-white-space;">--
"Esta vez no fallaremos, Doctor =3D > Infierno"

Dr Diego R. Lopez
Telefonica I+D
href=3D3D"http://people.tid.es/diego.lopez/"> > http://people.tid.es/diego.lope=3D > z/

e-mail: diego.r.lopez@telefonica.com
Tel:   =3D >  +34 913 129 041
Mobile: +34 682 051 =3D > 091
----------------------------------
> >
>
=3D > > --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1-- > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential 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 o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > --001a113d2b16ea60b305192f1e82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Diego,

The secondary identity is jus= t an opaque value to allow traceability.=C2=A0 It's to support a
<= div>client easily being a broker for multiple applications.=C2=A0 I don'= ;t agree that there is value
in trying to secure the secondary id= entity the way you are describing.=C2=A0 This path leads
to there= being basically no value for having secondary identities.

Regards,
Alia

=
On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GAR= CIA <diego.r.lopez@telefonica.com> wrote:

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 charset=3Dus-ascii

Hi Alia,

Just a remark on your comment about section 3.1: I think the current =3D requirement of associating a single secondary identity per connection =3D does make sense if we want to keep traceability over I2RS secure =3D
transports.=3D20

You need to associate secondary identities with primary ones in a secure = =3D
way to guarantee such traceability, and the mechanisms for this I can =3D imagine using current transports (such as a certificate extension or =3D alternate identity, or additional information in secure tokens) are =3D
associated with connection handshake, and therefore re-association is =3D complicated to implement without restarting the connection. Note I say =3D<= br> complicated, not impossible, but I cannot see the advantage in the =3D
additional complexity, especially when experience shows that additional =3D=
complexity becoming source of security flaws...

Be goode,

On 11 Jun 2015, at 22:11 , Alia Atlas <akatlas@gmail.com> wrote:

> <no-hat>
>=3D20
> Sue,
>=3D20
> Thanks for writing this draft.=C2=A0 I think it is useful to clearly = =3D
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.=C2=A0 I do have a couple comments on the =3D=
draft.
>=3D20
>=3D20
> In Sec 3.1, it says "Each Identity will be linked to one secondar= y =3D
identity for the period of a connection."=C2=A0 I would have assumed t= hat the =3D
client could arbitrarily change its' secondary identity.=C2=A0 This is = to =3D
support the broker case where a client may be passing along requests =3D from multiple applications.=C2=A0 Since the secondary identity is just pass= ed =3D
along and stored for traceability, I don't think that allowing it to = =3D
change would cause significant complications.=C2=A0 =C2=A0= What do others think?
>=3D20
>=3D20
> In the I2RS architecture, there are 3 different types of transaction = =3D
behavior desired for processing a message. In Sec 4, there's an =3D
assumption that "fail-on-error" with the associated roll-back is = the =3D
only mode.=C2=A0 =C2=A0Thus, I think that Section 4 needs = a bit of massaging.
>=3D20
>=3D20
> Thanks,
>=3D20
> Alia
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: diego.r.lopez@telef= onica.com
Tel:=C2=A0 =C2=A0 +34 913 129 041
Mobile: +34 = 682 051 091
----------------------------------


--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 charset=3Dus-ascii

<html><head><meta http-equiv=3D3D"Content-Type" co= ntent=3D3D"text/html =3D
charset=3D3Dus-ascii"></head><body style=3D3D"word-wr= ap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">H= i =3D
Alia,<div><br></div><div>Just a remark on your comm= ent about section =3D
3.1: I think the current requirement of associating a single secondary =3D<= br> identity per connection does make sense if we want to keep traceability =3D=
over I2RS secure transports.&nbsp;</div><div><br><= /div><div>You need to =3D
associate secondary identities with primary ones in a secure way to =3D
guarantee such traceability, and the mechanisms for this I can imagine =3D<= br> using current transports (such as a certificate extension or alternate =3D<= br> identity, or additional information in secure tokens) are associated =3D with connection handshake, and therefore re-association is complicated =3D<= br> to implement without restarting the connection. Note I say complicated, =3D=
not impossible, but I cannot see the advantage in the additional =3D
complexity, especially when experience shows that additional complexity =3D=
becoming source of security flaws...</div><div><br></d= iv><div>Be =3D
goode,</div><div><br><div><div>On 11 Jun 2015= , at 22:11 , Alia Atlas =3D
&lt;<a href=3D3D"mailto:ak= atlas@gmail.com">akatlas@g= mail.com</a>&gt; =3D
wrote:</div><br class=3D3D"Apple-interchange-newline">= ;<blockquote =3D
type=3D3D"cite"><meta http-equiv=3D3D"Content-Type&quo= t; content=3D3D"text/html; =3D
charset=3D3Dutf-8"><div dir=3D3D"ltr">&lt;no-ha= t&gt;<br><br>Sue,<br><br>Thanks=3D
=C2=A0for writing this draft.&nbsp; I think it is useful to clearly =3D=
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.&nbsp; I do have a couple comments on the= =3D
draft.<br><br><br>In Sec 3.1, it says "Each Identity= will be linked to =3D
one secondary identity for the period of a connection." &nbsp;I wo= uld =3D
have assumed that the client could arbitrarily change its' secondary = =3D
identity.&nbsp; This is to support the broker case where a client may b= e =3D
passing along requests from multiple applications.&nbsp; Since the =3D<= br> secondary identity is just passed along and stored for traceability, I =3D<= br> don't think that allowing it to change would cause significant =3D
complications. &nbsp; What do others think?<br><br><br&g= t;In the I2RS =3D
architecture, there are 3 different types of transaction behavior =3D
desired for processing a message. In Sec 4, there's an assumption that = =3D
"fail-on-error" with the associated roll-back is the only mode. &= amp;nbsp; =3D
Thus, I think that Section 4 needs a bit of =3D
massaging.<br><br><br>Thanks,<br><br>Alia<= /div>
_______________________________________________<br>i2rs mailing =3D list<br><a =3D
href=3D3D"mailto:i2rs@ietf.org&qu= ot;>i2rs@ietf.org</a><br&g= t;https://www.ietf.= org/ma=3D
ilman/listinfo/i2rs<br></blockquote></div><br>&= lt;div =3D
apple-content-edited=3D3D"true">
<div style=3D3D"color: rgb(0, 0, 0); letter-spacing: normal; orphan= s: =3D
auto; text-align: start; text-indent: 0px; text-transform: none; =3D
white-space: normal; widows: auto; word-spacing: 0px; =3D
-webkit-text-stroke-width: 0px; word-wrap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: =3D
after-white-space;">--<br>"Esta vez no fallaremos, Docto= r =3D
Infierno"<br><br>Dr Diego R. Lopez<br>Telefonica I+D= <br><a =3D
href=3D3D"http://people.tid.es/diego.lopez/">http://people.tid.es/diego.lope=3D=
z/</a><br><br>e-mail: diego.r.lopez@telefonica.com<br>Tel: &nbsp; = =3D
&nbsp;+3= 4 913 129 041<br>Mobile: +34 682 051 =3D
091<br>----------------------------------</div>

</div>
<br></div></body></html>=3D

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1--

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n.

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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

--001a113d2b16ea60b305192f1e82-- From nobody Tue Jun 23 06:11: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 61ECA1A1A8D for ; Tue, 23 Jun 2015 06:11:41 -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 3N43XaqDKLTd for ; Tue, 23 Jun 2015 06:11:32 -0700 (PDT) Received: from smtpjc.telefonica.com (smtpjc.telefonica.com [81.47.204.76]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830781A1A9D for ; Tue, 23 Jun 2015 06:11:30 -0700 (PDT) Received: from smtpjc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D350E1B8339; Tue, 23 Jun 2015 15:11:26 +0200 (CEST) Received-SPF: PermError (tgtimjc801.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP110.EUROPE.telefonica.corp) Received: from ESTGVMSP110.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtpjc.telefonica.com (Postfix) with ESMTPS id BAA001B8336; Tue, 23 Jun 2015 15:11:26 +0200 (CEST) Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.53) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Jun 2015 15:11:25 +0200 Received: from DB4PR06MB0621.eurprd06.prod.outlook.com (10.161.13.139) by DB4PR06MB473.eurprd06.prod.outlook.com (10.141.238.139) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:11:24 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (10.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:11:23 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 13:11:23 +0000 From: DIEGO LOPEZ GARCIA To: Alia Atlas Thread-Topic: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 Thread-Index: AQHQpILdCszgEnUD0kWN0jCiLF3lGZ26Iy6A Date: Tue, 23 Jun 2015 13:11:23 +0000 Message-ID: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [91.235.173.15] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0621; 5:EP2qcjsKDfeKEaYTWrYJN0fCpnFnnbIzvDi9IHIu20zdIJ9zVrDzPepXUva7JqROYyRCZIp3BZsp9FF4Us3o168gWDMmhgGzOk7yjecwGFSjvDjGvBd7bSJJfAQsH5/1OLwUTGKdYa/AH5Rpz8X7nA==; 24:H5L2dSD2d4pYjH5XC68bD8lY8IQTOiv0tUI4cqKLGjTKFQPSB2Mfs3FoRAMPLJjMsaU5q0vRMz1R4zwI66Ry1AoJ+vw6CWLoyFJ3ZaLOtLA=; 20:/i4SziHk7m/UeuRD5qaz1sCRb/J0QHfcB1jkxSRIGAgwI7QsXMT2mgQ5Z2j++/IjrD1FEuR4HQq4hylZh6X5uw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB473; 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:DB4PR06MB0621; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0621; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(52604005)(164054003)(24454002)(51444003)(2656002)(87936001)(36756003)(551934003)(230783001)(1411001)(16236675004)(19617315012)(15975445007)(86362001)(82746002)(2950100001)(102836002)(2900100001)(77096005)(92566002)(46102003)(40100003)(62966003)(77156002)(189998001)(54356999)(106116001)(5001960100002)(50986999)(76176999)(19580395003)(83716003)(33656002)(19580405001)(66066001)(122556002)(110136002)(5002640100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_296D132F5E2E495AAEB917B161BC7286telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 13:11:23.6197 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB473; 2:exAdDncB5aAGf8QRN7c0pqTQyjsOAZ50rYA9npd6Irr7LU2lB8q37gerB897p+Lu; 3:jyE/0cPOjF3n0mvvKUdJTF/ZQY3808RUdIFIcroCapFP560fAZXl722x7EkHcGfRa8YgAgHF/8p9j3JVq3JSmhAdidVy2xZZ3tYdH+0ju1VTZwZ2WVmM3ShPVGgWXN5e/ualf9jfH8rYmiGPIKb/jg==; 23:bT+awuSCpAqBlpDLClDmIv9vV/+cCwp2oYUSAqSJv223WpI0VgSOd3eZjQS1TAVj+zw4ZCqkjFXjEWgRof4o0tngFxj5l3PaDS2nhov98t4R9Wo2JoGVKKOWh1eXucShTwn+38oQdkC3L6IyV9guSItK4/yqMURqHK2GjoWouJVUfL17tpIWiPKLcOdHCB35mXNoJuH178hAOHJQUdV9VmUHI3HiF8IIEUNsDnTiO1Hk3EX0rx+LSaZ3dB79Ju1h X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:11:41 -0000 --_000_296D132F5E2E495AAEB917B161BC7286telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alia, Just a remark on your comment about section 3.1: I think the current requir= ement of associating a single secondary identity per connection does make s= ense if we want to keep traceability over I2RS secure transports. You need to associate secondary identities with primary ones in a secure wa= y to guarantee such traceability, and the mechanisms for this I can imagine= using current transports (such as a certificate extension or alternate ide= ntity, or additional information in secure tokens) are associated with conn= ection handshake, and therefore re-association is complicated to implement = without restarting the connection. Note I say complicated, not impossible, = but I cannot see the advantage in the additional complexity, especially whe= n experience shows that additional complexity becoming source of security f= laws... Be goode, On 11 Jun 2015, at 22:11 , Alia Atlas > wrote: Sue, Thanks for writing this draft. I think it is useful to clearly articulate = the outside-of-I2RS behavior and protocols that are needed for the mutual a= uthentication. I do have a couple comments on the draft. In Sec 3.1, it says "Each Identity will be linked to one secondary identity= for the period of a connection." I would have assumed that the client cou= ld arbitrarily change its' secondary identity. This is to support the brok= er case where a client may be passing along requests from multiple applicat= ions. Since the secondary identity is just passed along and stored for tra= ceability, I don't think that allowing it to change would cause significant= complications. What do others think? In the I2RS architecture, there are 3 different types of transaction behavi= or desired for processing a message. In Sec 4, there's an assumption that "= fail-on-error" with the associated roll-back is the only mode. Thus, I th= ink that Section 4 needs a bit of massaging. Thanks, Alia _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs -- "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=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. 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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_296D132F5E2E495AAEB917B161BC7286telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <9A2F87B5ADDE784EBE5762501A44494A@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Alia,

Just a remark on your comment about section 3.1: I think the current r= equirement of associating a single secondary identity per connection does m= ake sense if we want to keep traceability over I2RS secure transports. = ;

You need to associate secondary identities with primary ones in a secu= re way to guarantee such traceability, and the mechanisms for this I can im= agine using current transports (such as a certificate extension or alternat= e identity, or additional information in secure tokens) are associated with connection handshake, and therefore = re-association is complicated to implement without restarting the connectio= n. Note I say complicated, not impossible, but I cannot see the advantage i= n the additional complexity, especially when experience shows that additional complexity becoming source of securi= ty flaws...

Be goode,

On 11 Jun 2015, at 22:11 , Alia Atlas <akatlas@gmail.com> wrote:

<no-hat>

Sue,

Thanks for writing this draft.  I think it is useful to clearly articu= late the outside-of-I2RS behavior and protocols that are needed for the mut= ual authentication.  I do have a couple comments on the draft.


In Sec 3.1, it says "Each Identity will be linked to one secondary ide= ntity for the period of a connection."  I would have assumed that= the client could arbitrarily change its' secondary identity.  This is= to support the broker case where a client may be passing along requests from multiple applications.  Since the secondary ident= ity is just passed along and stored for traceability, I don't think that al= lowing it to change would cause significant complications.   What do o= thers think?


In the I2RS architecture, there are 3 different types of transaction behavi= or desired for processing a message. In Sec 4, there's an assumption that &= quot;fail-on-error" with the associated roll-back is the only mode. &n= bsp; Thus, I think that Section 4 needs a bit of massaging.


Thanks,

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

--
"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=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
 --_000_296D132F5E2E495AAEB917B161BC7286telefonicacom_-- From nobody Tue Jun 23 06:41: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 B729A1A8A0C for ; Tue, 23 Jun 2015 06:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HkFKA2h20Nf for ; Tue, 23 Jun 2015 06:41:06 -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 E18201A86EB for ; Tue, 23 Jun 2015 06:41:05 -0700 (PDT) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2F3246029B; Tue, 23 Jun 2015 15:41:03 +0200 (CEST) Received-SPF: PermError (tgtim3c02.telefonica.com: domain of diego.r.lopez@telefonica.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=10.92.4.9; envelope-from=diego.r.lopez@telefonica.com; helo=ESTGVMSP110.EUROPE.telefonica.corp) Received: from ESTGVMSP110.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 14E7460296; Tue, 23 Jun 2015 15:41:03 +0200 (CEST) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.53) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 23 Jun 2015 15:41:02 +0200 Received: from DB4PR06MB0623.eurprd06.prod.outlook.com (10.161.13.141) by DB4PR06MB538.eurprd06.prod.outlook.com (10.141.239.27) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:41:01 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0623.eurprd06.prod.outlook.com (10.161.13.141) with Microsoft SMTP Server (TLS) id 15.1.195.15; Tue, 23 Jun 2015 13:41:01 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0195.005; Tue, 23 Jun 2015 13:41:00 +0000 From: DIEGO LOPEZ GARCIA To: Alia Atlas Thread-Topic: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 Thread-Index: AQHQpILdCszgEnUD0kWN0jCiLF3lGZ26IKOAgAACawCAAAhlgA== Date: Tue, 23 Jun 2015 13:41:00 +0000 Message-ID: <1E0ED488-9114-4909-BD6F-EC9F6296FB4F@telefonica.com> References: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [91.235.173.15] x-microsoft-exchange-diagnostics: 1; DB4PR06MB0623; 5:by+2gk4P6DAu6GiSfF89JY28AVrXrsQwyXGUHE8UFm88C1mTjryOGqEpDz403KV5HEdafOMUybBfb0VbZlZ1KHFgP27zxSmCRvzElmwAfn9qnt3/2hkFi+AHaWxPTFOkZzeq4S+5m1T7TKesfUWWfA==; 24:ypqujWbg6U1Rcbu/ASWiln36PWiXDwLHi5n+q+cSgEaFTKNFZK519gBxCVFPB0sy8rxjcaUlfrWH0ub7/7O18SnQ8vH8KPkE5ClTIA512Vo=; 20:iGRMrNQDoPYchP5IrfVQC47pA11P1uzBZAbNtljmme24BYhK2uAqzrAELpVjFj+bIt9m9fZn3rYxZNo+LW7F3g== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB538; 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:DB4PR06MB0623; BCL:0; PCL:0; RULEID:; SRVR:DB4PR06MB0623; x-forefront-prvs: 06167FAD59 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51704005)(52604005)(377454003)(252514010)(24454002)(51444003)(164054003)(33656002)(19580395003)(1411001)(122556002)(62966003)(54356999)(19580405001)(86362001)(230783001)(551934003)(36756003)(87936001)(2656002)(40100003)(46102003)(66066001)(50986999)(19617315012)(16236675004)(5002640100001)(77096005)(106116001)(77156002)(2950100001)(76176999)(92566002)(2900100001)(5001960100002)(83716003)(82746002)(189998001)(102836002)(110136002)(15975445007)(408884003)(104396002)(299355004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0623; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_1E0ED48891144909BD6FEC9F6296FB4Ftelefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2015 13:41:00.6601 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0623 X-Microsoft-Exchange-Diagnostics: 1; DB4PR06MB538; 2:ecOVCMltoG1mxvADpjlhJ2Fx1vcJmFZCgram5oam9y9qb1nNRS/SZaV2dKWr1o8D; 3:gk79FaoKguVqSVzmxLwnhhTiaAksrzJBW7xKNsrVLb3dPORXUuNPPJKAZ/z25GpC6W+VbwLzMmNJULXFqgGRWmsMOU5JDTmkX2nxhORLIIhFbAQFrfIxQKJcr7Ze6066cMR3rwov/y9ZuJ+UpyjgHA==; 23:RI3Js7M0MsJxnByeVesXjBfG8VRX0hOUapHaBvy8XMhzZM4lw+drK2KpgqcxXxxNrsecCcpdaBxzyi6zguz5+ztpz0ha8pwAyDXUao8qCkSn1/u0fY5FaTFbDSO8DnK38wGv31lkVKI+rjJ3XK9Wi/uewRXYyT1ktQKQ5lGlm+rR0sbn2R8upcWr70Eh8XZrnpIW2rjAyNtKMXzChEVJni2kQlp9ZzGl6WMi1wX9GzwIRhkrhu5WMBSvl1MTILeF X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 13:41:12 -0000 --_000_1E0ED48891144909BD6FEC9F6296FB4Ftelefonicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alia, My understanding was that secondary identity was not intended to be only a = general declaration made by the client, in which case what you say definite= ly holds. If the trust model at the agent does not completely rely on clien= t assertions, the only way in which I see you can ensure traceability is by= associating data with a minimum level of assurance, in despite of those da= ta being opaque or not to the entities providing or recording them. If the first assumption holds, I'll stay corrected and support your comment= to section 3.1. If not, I'd say I have a point here... Be goode, On 23 Jun 2015, at 14:10 , Alia Atlas > wrote: Hi Diego, The secondary identity is just an opaque value to allow traceability. It's= to support a client easily being a broker for multiple applications. I don't agree that= there is value in trying to secure the secondary identity the way you are describing. Thi= s path leads to there being basically no value for having secondary identities. Regards, Alia On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA > wrote: --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=3Dus-ascii Hi Alia, Just a remark on your comment about section 3.1: I think the current =3D requirement of associating a single secondary identity per connection =3D does make sense if we want to keep traceability over I2RS secure =3D transports.=3D20 You need to associate secondary identities with primary ones in a secure = =3D way to guarantee such traceability, and the mechanisms for this I can =3D imagine using current transports (such as a certificate extension or =3D alternate identity, or additional information in secure tokens) are =3D associated with connection handshake, and therefore re-association is =3D complicated to implement without restarting the connection. Note I say =3D complicated, not impossible, but I cannot see the advantage in the =3D additional complexity, especially when experience shows that additional =3D complexity becoming source of security flaws... Be goode, On 11 Jun 2015, at 22:11 , Alia Atlas > wrote: > >=3D20 > Sue, >=3D20 > Thanks for writing this draft. I think it is useful to clearly =3D articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication. I do have a couple comments on the =3D draft. >=3D20 >=3D20 > In Sec 3.1, it says "Each Identity will be linked to one secondary =3D identity for the period of a connection." I would have assumed that the = =3D client could arbitrarily change its' secondary identity. This is to =3D support the broker case where a client may be passing along requests =3D from multiple applications. Since the secondary identity is just passed = =3D along and stored for traceability, I don't think that allowing it to =3D change would cause significant complications. What do others think? >=3D20 >=3D20 > In the I2RS architecture, there are 3 different types of transaction =3D behavior desired for processing a message. In Sec 4, there's an =3D assumption that "fail-on-error" with the associated roll-back is the =3D only mode. Thus, I think that Section 4 needs a bit of massaging. >=3D20 >=3D20 > Thanks, >=3D20 > Alia > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- "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 ---------------------------------- --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=3Dus-ascii Hi =3D Alia,

Just a remark on your comment about section =3D 3.1: I think the current requirement of associating a single secondary =3D identity per connection does make sense if we want to keep traceability =3D over I2RS secure transports. 

You need to =3D associate secondary identities with primary ones in a secure way to =3D guarantee such traceability, and the mechanisms for this I can imagine =3D using current transports (such as a certificate extension or alternate =3D identity, or additional information in secure tokens) are associated =3D with connection handshake, and therefore re-association is complicated =3D to implement without restarting the connection. Note I say complicated, =3D not impossible, but I cannot see the advantage in the additional =3D complexity, especially when experience shows that additional complexity =3D becoming source of security flaws...

Be =3D goode,

On 11 Jun 2015, at 22:11 , Alia Atlas =3D <">akatla= s@gmail.com> =3D wrote:

<no-hat>

Sue,

Tha= nks=3D for writing this draft.  I think it is useful to clearly =3D articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.  I do have a couple comments on the =3D draft.


In Sec 3.1, it says "Each Identity will be linked to =3D one secondary identity for the period of a connection."  I would =3D have assumed that the client could arbitrarily change its' secondary =3D identity.  This is to support the broker case where a client may be = =3D passing along requests from multiple applications.  Since the =3D secondary identity is just passed along and stored for traceability, I =3D don't think that allowing it to change would cause significant =3D complications.   What do others think?


In the I2RS =3D architecture, there are 3 different types of transaction behavior =3D desired for processing a message. In Sec 4, there's an assumption that =3D "fail-on-error" with the associated roll-back is the only mode.   =3D Thus, I think that Section 4 needs a bit of =3D massaging.


Thanks,

Alia
_______________________________________________
i2rs mailing =3D list
">i2rs@ietf.org
https://www.ietf.org/ma=3D ilman/listinfo/i2rs

--
"Esta vez no fallaremos, Doctor =3D Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lop= e=3D z/

e-mail: diego.r.lopez@t= elefonica.com
Tel:   =3D  +34 913 129 041
Mobile: +34 682 051 = =3D 091
----------------------------------

=3D --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1-- ________________________________ 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 -- "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_1E0ED48891144909BD6FEC9F6296FB4Ftelefonicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <62720BEE706F9840877C4BB65E5BA3FF@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Alia,

My understanding was that secondary identity was not intended to be on= ly a general declaration made by the client, in which case what you say def= initely holds. If the trust model at the agent does not completely rely on = client assertions, the only way in which I see you can ensure traceability is by associating data with a m= inimum level of assurance, in despite of those data being opaque or not to = the entities providing or recording them.

If the first assumption holds, I'll stay corrected and support your co= mment to section 3.1. If not, I'd say I have a point here...

Be goode,

On 23 Jun 2015, at 14:10 , Alia Atlas <akatlas@gmail.com> wrote:

Hi Diego,

The secondary identity is just an opaque value to allow traceability.&= nbsp; It's to support a
client easily being a broker for multiple applications.  I don't = agree that there is value
in trying to secure the secondary identity the way you are describing.=   This path leads
to there being basically no value for having secondary identities.

Regards,
Alia

On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GAR= CIA <diego= .r.lopez@telefonica.com> wrote:

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
        charset=3Dus-ascii

Hi Alia,

Just a remark on your comment about section 3.1: I think the current =3D requirement of associating a single secondary identity per connection =3D does make sense if we want to keep traceability over I2RS secure =3D
transports.=3D20

You need to associate secondary identities with primary ones in a secure = =3D
way to guarantee such traceability, and the mechanisms for this I can =3D imagine using current transports (such as a certificate extension or =3D alternate identity, or additional information in secure tokens) are =3D
associated with connection handshake, and therefore re-association is =3D complicated to implement without restarting the connection. Note I say =3D<= br> complicated, not impossible, but I cannot see the advantage in the =3D
additional complexity, especially when experience shows that additional =3D=
complexity becoming source of security flaws...

Be goode,

On 11 Jun 2015, at 22:11 , Alia Atlas <akatlas@gmail.com> wrote:

> <no-hat>
>=3D20
> Sue,
>=3D20
> Thanks for writing this draft.  I think it is useful to clearly = =3D
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.  I do have a couple comments on the =3D=
draft.
>=3D20
>=3D20
> In Sec 3.1, it says "Each Identity will be linked to one secondar= y =3D
identity for the period of a connection."  I would have assumed t= hat the =3D
client could arbitrarily change its' secondary identity.  This is to = =3D
support the broker case where a client may be passing along requests =3D from multiple applications.  Since the secondary identity is just pass= ed =3D
along and stored for traceability, I don't think that allowing it to =3D change would cause significant complications.   = What do others think?
>=3D20
>=3D20
> In the I2RS architecture, there are 3 different types of transaction = =3D
behavior desired for processing a message. In Sec 4, there's an =3D
assumption that "fail-on-error" with the associated roll-back is = the =3D
only mode.   Thus, I think that Section 4 needs = a bit of massaging.
>=3D20
>=3D20
> Thanks,
>=3D20
> Alia
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs

--
"Esta vez no fallaremos, Doctor Infierno"

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

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


--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
        charset=3Dus-ascii

<html><head><meta http-equiv=3D3D"Content-Type" co= ntent=3D3D"text/html =3D
charset=3D3Dus-ascii"></head><body style=3D3D"word-wr= ap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">H= i =3D
Alia,<div><br></div><div>Just a remark on your comm= ent about section =3D
3.1: I think the current requirement of associating a single secondary =3D<= br> identity per connection does make sense if we want to keep traceability =3D=
over I2RS secure transports.&nbsp;</div><div><br><= /div><div>You need to =3D
associate secondary identities with primary ones in a secure way to =3D
guarantee such traceability, and the mechanisms for this I can imagine =3D<= br> using current transports (such as a certificate extension or alternate =3D<= br> identity, or additional information in secure tokens) are associated =3D with connection handshake, and therefore re-association is complicated =3D<= br> to implement without restarting the connection. Note I say complicated, =3D=
not impossible, but I cannot see the advantage in the additional =3D
complexity, especially when experience shows that additional complexity =3D=
becoming source of security flaws...</div><div><br></d= iv><div>Be =3D
goode,</div><div><br><div><div>On 11 Jun 2015= , at 22:11 , Alia Atlas =3D
&lt;<a href=3D3D"mailto:ak= atlas@gmail.com">akatlas@g= mail.com</a>&gt; =3D
wrote:</div><br class=3D3D"Apple-interchange-newline">= ;<blockquote =3D
type=3D3D"cite"><meta http-equiv=3D3D"Content-Type&quo= t; content=3D3D"text/html; =3D
charset=3D3Dutf-8"><div dir=3D3D"ltr">&lt;no-ha= t&gt;<br><br>Sue,<br><br>Thanks=3D
 for writing this draft.&nbsp; I think it is useful to clearly =3D=
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.&nbsp; I do have a couple comments on the= =3D
draft.<br><br><br>In Sec 3.1, it says "Each Identity= will be linked to =3D
one secondary identity for the period of a connection." &nbsp;I wo= uld =3D
have assumed that the client could arbitrarily change its' secondary =3D identity.&nbsp; This is to support the broker case where a client may b= e =3D
passing along requests from multiple applications.&nbsp; Since the =3D<= br> secondary identity is just passed along and stored for traceability, I =3D<= br> don't think that allowing it to change would cause significant =3D
complications. &nbsp; What do others think?<br><br><br&g= t;In the I2RS =3D
architecture, there are 3 different types of transaction behavior =3D
desired for processing a message. In Sec 4, there's an assumption that =3D<= br> "fail-on-error" with the associated roll-back is the only mode. &= amp;nbsp; =3D
Thus, I think that Section 4 needs a bit of =3D
massaging.<br><br><br>Thanks,<br><br>Alia<= /div>
_______________________________________________<br>i2rs mailing =3D list<br><a =3D
href=3D3D"mailto:i2rs@ietf.org&qu= ot;>i2rs@ietf.org</a><br&g= t;https://www.ietf.org/ma=3D
ilman/listinfo/i2rs<br></blockquote></div><br>&= lt;div =3D
apple-content-edited=3D3D"true">
<div style=3D3D"color: rgb(0, 0, 0); letter-spacing: normal; orphan= s: =3D
auto; text-align: start; text-indent: 0px; text-transform: none; =3D
white-space: normal; widows: auto; word-spacing: 0px; =3D
-webkit-text-stroke-width: 0px; word-wrap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: =3D
after-white-space;">--<br>"Esta vez no fallaremos, Docto= r =3D
Infierno"<br><br>Dr Diego R. Lopez<br>Telefonica I&#= 43;D<br><a =3D
href=3D3D"http://people.tid.es/diego.lopez/">http://people.tid.es/diego.lope=3D
z/</a><br><br>e-mail: diego.r.lopez@telefonica.com<br>Tel: &nbsp; = =3D
&nbsp;+34 913 129 041<br>Mobile: +34 682 051 =3D
091<br>----------------------------------</div>

</div>
<br></div></body></html>=3D

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1--

________________________________

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


--
"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_1E0ED48891144909BD6FEC9F6296FB4Ftelefonicacom_-- From nobody Tue Jun 23 07:20: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 CD4C21A8F4A for ; Tue, 23 Jun 2015 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsrCSv9-1S6a for ; Tue, 23 Jun 2015 07:20:35 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 D37E21A8F42 for ; Tue, 23 Jun 2015 07:20:34 -0700 (PDT) Received: by obbop1 with SMTP id op1so7081295obb.2 for ; Tue, 23 Jun 2015 07:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dL1oVyxUa9rDrfASN7ApwmhrDnXuvK+uZWJXKLWa2mQ=; b=kZ2IpUQdSllTHaUT9/KsIIPjJotWRZeucQrAzZjH+G9M1hAwpNBI6TK8hMB7A7seae fvTTAJtgWTd5agDYZUF/jIA/xdlTPp6GcwfExBr6D32R7YPtG9GYL9YhuOLLFBOecZav fL0WkG4yCw3BYeX4zKXRFevqqQ37p01BkyPQuz4tW7+D6Zid2MRQTeBTVNMO4siKYRSk aHzrdRbweB6/cIRK1ANtaqhriH/9Ti3M97KN4mKBzGP+xNp6UptfalX1p3Qrz1sL3W+6 VpmtMP5IYgxJjAAOwMGrb1fr5qdEsVSoX6q+Oz3UxP/Qq/VwB9h+CCoJbC1j3EBGQXx8 iGug== MIME-Version: 1.0 X-Received: by 10.60.156.130 with SMTP id we2mr30206525oeb.24.1435069234341; Tue, 23 Jun 2015 07:20:34 -0700 (PDT) Received: by 10.60.165.145 with HTTP; Tue, 23 Jun 2015 07:20:34 -0700 (PDT) In-Reply-To: <1E0ED488-9114-4909-BD6F-EC9F6296FB4F@telefonica.com> References: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> <1E0ED488-9114-4909-BD6F-EC9F6296FB4F@telefonica.com> Date: Tue, 23 Jun 2015 10:20:34 -0400 Message-ID: From: Alia Atlas To: DIEGO LOPEZ GARCIA Content-Type: multipart/alternative; boundary=089e01182852f0ef2305193017c5 Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 14:20:40 -0000 --089e01182852f0ef2305193017c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Diego, On Jun 23, 2015 9:41 AM, "DIEGO LOPEZ GARCIA" wrote: > Hi Alia, > > My understanding was that secondary identity was not intended to be only > a general declaration made by the client, in which case what you say > definitely holds. If the trust model at the agent does not completely rel= y > on client assertions, the only way in which I see you can ensure > traceability is by associating data with a minimum level of assurance, in > despite of those data being opaque or not to the entities providing or > recording them. > > I believe that the secondary identity is intended to be only a general declaration made by the client. It's the minimum to provide some traceability without complicated support for the broker client model. That is why it is merely an opaque value to the agent; it has no meaning and isn't verified but merely stored. With the primary identity verified and an integrity-protected channel for writing state, I think that secondary identity will be whatever the associated client sent. By having that opaque value recorded, an operator can compare it to what the client thinks was happening. Certainly, that's the discussion and conclusion that I recall and I haven't seen any further discussion to make me think that the conclusion has changed. Regards, Alia > If the first assumption holds, I'll stay corrected and support your > comment to section 3.1. If not, I'd say I have a point here... > > Be goode, > > On 23 Jun 2015, at 14:10 , Alia Atlas wrote: > > Hi Diego, > > The secondary identity is just an opaque value to allow traceability. > It's to support a > client easily being a broker for multiple applications. I don't agree > that there is value > in trying to secure the secondary identity the way you are describing. > This path leads > to there being basically no value for having secondary identities. > > Regards, > Alia > > On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA < > diego.r.lopez@telefonica.com> wrote: > >> >> --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=3Dus-ascii >> >> Hi Alia, >> >> Just a remark on your comment about section 3.1: I think the current =3D >> requirement of associating a single secondary identity per connection = =3D >> does make sense if we want to keep traceability over I2RS secure =3D >> transports.=3D20 >> >> You need to associate secondary identities with primary ones in a secure= =3D >> way to guarantee such traceability, and the mechanisms for this I can = =3D >> imagine using current transports (such as a certificate extension or =3D >> alternate identity, or additional information in secure tokens) are =3D >> associated with connection handshake, and therefore re-association is = =3D >> complicated to implement without restarting the connection. Note I say = =3D >> complicated, not impossible, but I cannot see the advantage in the =3D >> additional complexity, especially when experience shows that additional = =3D >> complexity becoming source of security flaws... >> >> Be goode, >> >> On 11 Jun 2015, at 22:11 , Alia Atlas wrote: >> >> > >> >=3D20 >> > Sue, >> >=3D20 >> > Thanks for writing this draft. I think it is useful to clearly =3D >> articulate the outside-of-I2RS behavior and protocols that are needed = =3D >> for the mutual authentication. I do have a couple comments on the =3D >> draft. >> >=3D20 >> >=3D20 >> > In Sec 3.1, it says "Each Identity will be linked to one secondary =3D >> identity for the period of a connection." I would have assumed that the= =3D >> client could arbitrarily change its' secondary identity. This is to =3D >> support the broker case where a client may be passing along requests =3D >> from multiple applications. Since the secondary identity is just passed= =3D >> along and stored for traceability, I don't think that allowing it to =3D >> change would cause significant complications. What do others think? >> >=3D20 >> >=3D20 >> > In the I2RS architecture, there are 3 different types of transaction = =3D >> behavior desired for processing a message. In Sec 4, there's an =3D >> assumption that "fail-on-error" with the associated roll-back is the =3D >> only mode. Thus, I think that Section 4 needs a bit of massaging. >> >=3D20 >> >=3D20 >> > Thanks, >> >=3D20 >> > Alia >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> -- >> "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 >> ---------------------------------- >> >> >> --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/html; >> charset=3Dus-ascii >> >> > charset=3D3Dus-ascii">> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi =3D >> Alia,

Just a remark on your comment about section =3D >> 3.1: I think the current requirement of associating a single secondary = =3D >> identity per connection does make sense if we want to keep traceability = =3D >> over I2RS secure transports. 

You need to = =3D >> associate secondary identities with primary ones in a secure way to =3D >> guarantee such traceability, and the mechanisms for this I can imagine = =3D >> using current transports (such as a certificate extension or alternate = =3D >> identity, or additional information in secure tokens) are associated =3D >> with connection handshake, and therefore re-association is complicated = =3D >> to implement without restarting the connection. Note I say complicated, = =3D >> not impossible, but I cannot see the advantage in the additional =3D >> complexity, especially when experience shows that additional complexity = =3D >> becoming source of security flaws...

Be =3D >> goode,

On 11 Jun 2015, at 22:11 , Alia Atlas =3D >> <akatlas@gmail.com> =3D >> wrote:

> type=3D3D"cite">> charset=3D3Dutf-8">
> dir=3D3D"ltr"><no-hat>

Sue,

Thanks=3D >> for writing this draft.  I think it is useful to clearly =3D >> articulate the outside-of-I2RS behavior and protocols that are needed = =3D >> for the mutual authentication.  I do have a couple comments on the = =3D >> draft.


In Sec 3.1, it says "Each Identity will be linked to = =3D >> one secondary identity for the period of a connection."  I would = =3D >> have assumed that the client could arbitrarily change its' secondary =3D >> identity.  This is to support the broker case where a client may be= =3D >> passing along requests from multiple applications.  Since the =3D >> secondary identity is just passed along and stored for traceability, I = =3D >> don't think that allowing it to change would cause significant =3D >> complications.   What do others think?


In the I2RS =3D >> architecture, there are 3 different types of transaction behavior =3D >> desired for processing a message. In Sec 4, there's an assumption that = =3D >> "fail-on-error" with the associated roll-back is the only mode.   = =3D >> Thus, I think that Section 4 needs a bit of =3D >> massaging.


Thanks,

Alia
>> _______________________________________________
i2rs mailing =3D >> list
> href=3D3D"mailto:i2rs@ietf.org">i2rs@ietf.org
>> https://www.ietf.org/ma=3D >> ilman/listinfo/i2rs
<= /blockquote>

> =3D >> apple-content-edited=3D3D"true"> >>
> auto; text-align: start; text-indent: 0px; text-transform: none; =3D >> white-space: normal; widows: auto; word-spacing: 0px; =3D >> -webkit-text-stroke-width: 0px; word-wrap: break-word; =3D >> -webkit-nbsp-mode: space; -webkit-line-break: =3D >> after-white-space;">--
"Esta vez no fallaremos, Doctor =3D >> Infierno"

Dr Diego R. Lopez
Telefonica I+D
> href=3D3D"http://people.tid.es/diego.lopez/"> >> http://people.tid.es/diego.lope=3D >> z/

e-mail: >> diego.r.lopez@telefonica.com
Tel:   =3D >>  +34 913 129 041
Mobile: +34 682 051 =3D >> 091
----------------------------------
>> >>
>>
=3D >> >> --Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1-- >> >> ________________________________ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, >> puede contener informaci=C3=B3n privilegiada o confidencial y es para us= o >> exclusivo de la persona o entidad de destino. Si no es usted. el >> destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, >> divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida e= n virtud de >> la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le r= ogamos >> que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a = su >> destrucci=C3=B3n. >> >> The information contained in this transmission is privileged and >> confidential 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 you have receiv= ed >> this transmission in error, do not read it. Please immediately reply to = the >> sender that you have received this communication in error and then delet= e >> it. >> >> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >> destinat=C3=A1rio, pode conter informa=C3=A7=C3=A3o privilegiada ou conf= idencial e =C3=A9 para >> uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa= senhoria o >> destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3= =A7=C3=A3o, >> divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode esta= r proibida em virtude da >> legisla=C3=A7=C3=A3o vigente. Se recebeu esta mensagem por erro, rogamos= -lhe que nos >> o comunique imediatamente por esta mesma via e proceda a sua destrui=C3= =A7=C3=A3o >> > > > -- > "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, > puede contener informaci=C3=B3n privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilizaci=C3= =B3n, > divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en= virtud de > la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le ro= gamos > que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a s= u > destrucci=C3=B3n. > > The information contained in this transmission is privileged and > confidential 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 o= r > copying of this communication is strictly prohibited. If you have receive= d > this transmission in error, do not read it. Please immediately reply to t= he > sender that you have received this communication in error and then delete > it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3= =A1rio, > pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9 pa= ra uso exclusivo > da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vossa senhoria o des= tinat=C3=A1rio > indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga= =C3=A7=C3=A3o e/ou > c=C3=B3pia sem autoriza=C3=A7=C3=A3o pode estar proibida em virtude da le= gisla=C3=A7=C3=A3o vigente. > Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique > imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o > --089e01182852f0ef2305193017c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Diego,

On Jun 23, 2015 9:41 AM, "DIEGO LOPEZ GARCI= A" <diego.r.lopez@telefonica.com> wrote:
Hi Alia,

My understanding was that secondary identity was not intended to be on= ly a general declaration made by the client, in which case what you say def= initely holds. If the trust model at the agent does not completely rely on = client assertions, the only way in which I see you can ensure traceability is by associating data with a m= inimum level of assurance, in despite of those data being opaque or not to = the entities providing or recording them.


I believe that the se= condary identity is intended to be only a general declaration made by the c= lient.=C2=A0 It's the minimum to provide some traceability without comp= licated support for the broker client model.=C2=A0 That is why it is merely= an opaque value to the agent; it has no meaning and isn't verified but= merely stored.

With the primary identity verified= and an integrity-protected channel for writing state, I think that seconda= ry identity will be whatever the associated client sent.=C2=A0 By having th= at opaque value recorded, an operator can compare it to what the client thi= nks was happening.

Certainly, that's the discu= ssion and conclusion that I recall and I haven't seen any further discu= ssion to make me think that the conclusion has changed. =C2=A0
Regards,
Alia=C2=A0

=C2=A0<= /div>
If the first assumption holds, I'll stay corrected and support you= r comment to section 3.1. If not, I'd say I have a point here...

Be goode,

On 23 Jun 2015, at 14:10 , Alia Atlas <akatlas@gmail.com> wrote:

Hi Diego,

The secondary identity is just an opaque value to allow traceability.= =C2=A0 It's to support a
client easily being a broker for multiple applications.=C2=A0 I don= 9;t agree that there is value
in trying to secure the secondary identity the way you are describing.= =C2=A0 This path leads
to there being basically no value for having secondary identities.

Regards,
Alia

On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GAR= CIA <diego= .r.lopez@telefonica.com> wrote:

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 charset=3Dus-ascii

Hi Alia,

Just a remark on your comment about section 3.1: I think the current =3D requirement of associating a single secondary identity per connection =3D does make sense if we want to keep traceability over I2RS secure =3D
transports.=3D20

You need to associate secondary identities with primary ones in a secure = =3D
way to guarantee such traceability, and the mechanisms for this I can =3D imagine using current transports (such as a certificate extension or =3D alternate identity, or additional information in secure tokens) are =3D
associated with connection handshake, and therefore re-association is =3D complicated to implement without restarting the connection. Note I say =3D<= br> complicated, not impossible, but I cannot see the advantage in the =3D
additional complexity, especially when experience shows that additional =3D=
complexity becoming source of security flaws...

Be goode,

On 11 Jun 2015, at 22:11 , Alia Atlas <akatlas@gmail.com> wrote:

> <no-hat>
>=3D20
> Sue,
>=3D20
> Thanks for writing this draft.=C2=A0 I think it is useful to clearly = =3D
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.=C2=A0 I do have a couple comments on the =3D=
draft.
>=3D20
>=3D20
> In Sec 3.1, it says "Each Identity will be linked to one secondar= y =3D
identity for the period of a connection."=C2=A0 I would have assumed t= hat the =3D
client could arbitrarily change its' secondary identity.=C2=A0 This is = to =3D
support the broker case where a client may be passing along requests =3D from multiple applications.=C2=A0 Since the secondary identity is just pass= ed =3D
along and stored for traceability, I don't think that allowing it to = =3D
change would cause significant complications.=C2=A0 =C2=A0What do oth= ers think?
>=3D20
>=3D20
> In the I2RS architecture, there are 3 different types of transaction = =3D
behavior desired for processing a message. In Sec 4, there's an =3D
assumption that "fail-on-error" with the associated roll-back is = the =3D
only mode.=C2=A0 =C2=A0Thus, I think that Section 4 needs a bit of ma= ssaging.
>=3D20
>=3D20
> Thanks,
>=3D20
> Alia
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: d= iego.r.lopez@telefonica.com
Tel:=C2=A0 =C2=A0 +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 charset=3Dus-ascii

<html><head><meta http-equiv=3D3D"Content-Type" co= ntent=3D3D"text/html =3D
charset=3D3Dus-ascii"></head><body style=3D3D"word-wr= ap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">H= i =3D
Alia,<div><br></div><div>Just a remark on your comm= ent about section =3D
3.1: I think the current requirement of associating a single secondary =3D<= br> identity per connection does make sense if we want to keep traceability =3D=
over I2RS secure transports.&nbsp;</div><div><br><= /div><div>You need to =3D
associate secondary identities with primary ones in a secure way to =3D
guarantee such traceability, and the mechanisms for this I can imagine =3D<= br> using current transports (such as a certificate extension or alternate =3D<= br> identity, or additional information in secure tokens) are associated =3D with connection handshake, and therefore re-association is complicated =3D<= br> to implement without restarting the connection. Note I say complicated, =3D=
not impossible, but I cannot see the advantage in the additional =3D
complexity, especially when experience shows that additional complexity =3D=
becoming source of security flaws...</div><div><br></d= iv><div>Be =3D
goode,</div><div><br><div><div>On 11 Jun 2015= , at 22:11 , Alia Atlas =3D
&lt;<a href=3D3D"mailto:akatlas@gmail.com">akatlas@gmail.com</a>&gt; =3D
wrote:</div><br class=3D3D"Apple-interchange-newline">= ;<blockquote =3D
type=3D3D"cite"><meta http-equiv=3D3D"Content-Type&quo= t; content=3D3D"text/html; =3D
charset=3D3Dutf-8"><div dir=3D3D"ltr">&lt;no-ha= t&gt;<br><br>Sue,<br><br>Thanks=3D
=C2=A0for writing this draft.&nbsp; I think it is useful to clearly =3D=
articulate the outside-of-I2RS behavior and protocols that are needed =3D for the mutual authentication.&nbsp; I do have a couple comments on the= =3D
draft.<br><br><br>In Sec 3.1, it says "Each Identity= will be linked to =3D
one secondary identity for the period of a connection." &nbsp;I wo= uld =3D
have assumed that the client could arbitrarily change its' secondary = =3D
identity.&nbsp; This is to support the broker case where a client may b= e =3D
passing along requests from multiple applications.&nbsp; Since the =3D<= br> secondary identity is just passed along and stored for traceability, I =3D<= br> don't think that allowing it to change would cause significant =3D
complications. &nbsp; What do others think?<br><br><br&g= t;In the I2RS =3D
architecture, there are 3 different types of transaction behavior =3D
desired for processing a message. In Sec 4, there's an assumption that = =3D
"fail-on-error" with the associated roll-back is the only mode. &= amp;nbsp; =3D
Thus, I think that Section 4 needs a bit of =3D
massaging.<br><br><br>Thanks,<br><br>Alia<= /div>
_______________________________________________<br>i2rs mailing =3D list<br><a =3D
href=3D3D"mailto:i2= rs@ietf.org">i2rs@ietf.org</a><br>https://www.ietf.= org/ma=3D
ilman/listinfo/i2rs<br></blockquote></div><br>&= lt;div =3D
apple-content-edited=3D3D"true">
<div style=3D3D"color: rgb(0, 0, 0); letter-spacing: normal; orphan= s: =3D
auto; text-align: start; text-indent: 0px; text-transform: none; =3D
white-space: normal; widows: auto; word-spacing: 0px; =3D
-webkit-text-stroke-width: 0px; word-wrap: break-word; =3D
-webkit-nbsp-mode: space; -webkit-line-break: =3D
after-white-space;">--<br>"Esta vez no fallaremos, Docto= r =3D
Infierno"<br><br>Dr Diego R. Lopez<br>Telefonica I+D= <br><a =3D
href=3D3D"http://people.tid.es/diego.lopez/">http://people.tid.es/diego.lope=3D
z/</a><br><br>e-mail: diego.r.lopez@telefonica.com<br&g= t;Tel: &nbsp; =3D
&nbsp;+34 913 129 041<br>Mobile: +34 682 051 =3D
091<br>----------------------------------</div>

</div>
<br></div></body></html>=3D

--Apple-Mail=3D_B6401857-FE32-45EF-A393-65E1C90F6FC1--

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://peop= le.tid.es/diego.lopez/

e-mail: d= iego.r.lopez@telefonica.com
Tel: =C2=A0 =C2=A0+34 913 129 041
Mobile: +34 682 051 091
----------------------------------



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3= n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec= ibido este mensaje por error, le rogamos que nos lo comunique inmediatament= e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.

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=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
--089e01182852f0ef2305193017c5-- From nobody Tue Jun 23 09:52: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 928461B2E07; Tue, 23 Jun 2015 09:52:38 -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 Y9ggpbGkI_0X; Tue, 23 Jun 2015 09:52:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 655821B2E03; Tue, 23 Jun 2015 09:52:37 -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.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 09:52:37 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.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, 23 Jun 2015 16:52:38 -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 : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-00.txt Pages : 13 Date : 2015-06-23 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-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ From nobody Tue Jun 23 11:09:10 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B171A0067 for ; Tue, 23 Jun 2015 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg2Lx8dN6VYl for ; Tue, 23 Jun 2015 11:09:08 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FFB1A005F for ; Tue, 23 Jun 2015 11:09:06 -0700 (PDT) Received: by lbbvz5 with SMTP id vz5so11871918lbb.0 for ; Tue, 23 Jun 2015 11:09:05 -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=hHJkNesqwLkKu5T0ZOJBCE8+vA8SvHsV4fgTcUPUZdA=; b=lOCSe3J9N1xuSkaDKdoRH8vzaCKQY2jqR88Cg9bYFOLy3F3eBEoUFtuSaZNGR/RijV hslB/RXA3sskwD83K9gqSX8kfgmdT/W4K0I74L2JCDIeSnQAEqVDiMXX+UTmBUZ2P41i BlhyghIAE4FpCf/cZAg0PD2s3CdR4Utl+ha4biSTn2TRO67v8Gr8q+Sj0m5b69fpOIgC M5ZJ9p0891lZ9Pq92IjKr3VSBMeLmPqGwTLX3sx6aoR24gDgZAajMqqamP5WXDIaZNgY 5Pd/Kx9/FZC1BSdONFKdC6lS0hrcWik8UiN7LojnmyeKVHOr/mEpQLRAI+TmnxV4zhDg I2Gw== X-Gm-Message-State: ALoCoQl98w/t49ntEV9UZ1pXDsPZeD0PXV3fHZtzqix16zAd7VDWwL1Y8PWuKAGePrIlnM0Y66KR MIME-Version: 1.0 X-Received: by 10.152.37.67 with SMTP id w3mr36386589laj.123.1435082944953; Tue, 23 Jun 2015 11:09:04 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 23 Jun 2015 11:09:04 -0700 (PDT) In-Reply-To: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> Date: Tue, 23 Jun 2015 11:09:04 -0700 Message-ID: From: Andy Bierman To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=089e0158ba0a28571b05193349a8 Archived-At: Cc: "i2rs@ietf.org" , i-d-announce@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 18:09:09 -0000 --089e0158ba0a28571b05193349a8 Content-Type: text/plain; charset=UTF-8 Hi, This draft seems to propose very specific solutions, not requirements. This text is in the section explaining why an ephemeral datastore won't work: The most obvious disadvantage of such a fully separate datastore is that interaction with the network element's operational or configuration state becomes significantly more difficult. I don't see any evidence or examples in the draft to support this claim. The requirements do not make it clear how a YANG module is implemented by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all how YANG data-def-stmts are handled correctly by each protocol. Perhaps you can provide some data model examples. Andy On Tue, Jun 23, 2015 at 9:52 AM, wrote: > > 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 : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-00.txt > Pages : 13 > Date : 2015-06-23 > > 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-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --089e0158ba0a28571b05193349a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

This draft seems to propose very sp= ecific solutions, not requirements.


This text is in the section explaining why an ephemeral datastore won'= t work:

   The most obvious disadvantage of such a =
fully separate datastore is
   that interaction with the network element's operational or
   configuration state becomes significantly more difficult.

= I don't see any evidence or examples in the draft to support this claim= .

The requirements do not make it clear how a YANG= module is implemented
by I2RS vs. implemented by NETCONF or REST= CONF.=C2=A0 It is not clear at all
how YANG data-def-stmts are ha= ndled correctly by each protocol.
Perhaps you can provide some da= ta model examples.


Andy
<= br>


On Tue, Jun 23, 2015 at 9:52 AM, <internet-drafts@iet= f.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=C2=A0This draft is a work item of the Interface to the Routing System Work= ing Group of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= I2RS Ephemeral State Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jeff= Haas
=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 Susan Hares
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-i2rs-ephemeral-state-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-06-23

Abstract:
=C2=A0 =C2=A0This document covers requests to the netmod and netconf Workin= g
=C2=A0 =C2=A0Groups for functionality to support the ephemeral state requir= ements
=C2=A0 =C2=A0to implement the I2RS architecture.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf= -i2rs-ephemeral-state-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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

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

--089e0158ba0a28571b05193349a8-- From nobody Tue Jun 23 11:19:18 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E6F1A7D82; Tue, 23 Jun 2015 11:19:15 -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 MXZsj8M9eeam; Tue, 23 Jun 2015 11:19:12 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA261A876C; Tue, 23 Jun 2015 11:19:11 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: , Date: Tue, 23 Jun 2015 14:19:08 -0400 Message-ID: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DA_01D0ADBF.9235C2E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCt3DMPLBEZlsLhQ3mxKrWQI0Jk+w== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, netmod@ietf.org, "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' , 'Benoit Claise' , 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" Subject: [i2rs] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 18:19:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DA_01D0ADBF.9235C2E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Netconf Working Group: The I2RS WG would like to pass you a set of requirements for the I2RS protocol, and asks that you provide an analysis by IETF 93 on whether NETCONF or RESTCONF can meet these requirements. We expect that these requirements may require changes to the either NETCONF or RESTCONF. The I2RS architecture document ( draft-ietf-i2rs-architecture-09) provides a high-level overview of the I2RS protocol. The I2RS has compiled the following documents to provide the additional details on the requirements for the protocols. 1) draft-ietf-i2rs-ephemeral-state-00 2) draft-ietf-i2rs-pub-sub-requirements-02 3) draft-ietf-i2rs-traceability-03 The draft-ietf-i2rs-ephemeral-state-00 contains the results of the discussion from the 6/10 interim and the top 10 requirements for I2RS. In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of detailed requirements on how the I2RS WG sees the I2RS protocol operating. These detailed requirements are to be seen as suggestions on what type of solution the I2RS WG would like to see, but I2RS WG is asking the NETCONF WG to provide its best designed protocol. Please note as part of these detailed requirement the draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata to record secondary identity. The I2RS protocol is driven by data-models. The approved data models for protocol independent services are: - draft-ietf-i2rs-rib-data-model-00 - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 (released later this week) - Topology model which is a composite of: o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 released later this week). o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) At this time, none of the Topology models utilize Traffic engineering. It is anticipated that these models will support traffic engineering. Estimated rates of transfer and timing requirements for these modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol requirements table. We hope that NETCONF WG can provide some initial feedback on these requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the 6/24 interim at 10:00-11:30am ET to provide a time for any participate in the I2RS, netconf, or netmod group to ask additional questions on these requirements. Sue Hares Interim time: 10:00-11:30am ET Date 6/24/2015 Webex: https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d0f agenda: 10:00 - 10:05 - Bash Agenda 10:05 - 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements 10:20 - 10:30 Review of requirements for mutual authentication, and transaction in draft-hares-auth-trans-01 requirements 10:30- 11:30 Open discussion for I2RS Requirements Proceedings and slides can be found at: http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html Sue Hares ------=_NextPart_000_00DA_01D0ADBF.9235C2E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Netconf = Working Group:

 

The I2RS WG = would like to pass you a set of requirements for the I2RS protocol, and = asks that you provide an analysis by IETF 93 on whether NETCONF or = RESTCONF can meet these requirements.   We expect that these = requirements may require changes to the either NETCONF or = RESTCONF. 

 

The I2RS = architecture document (<= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-architecture-09) = provides a high-level overview of the I2RS =  protocol.  The I2RS has compiled the following documents to = provide the additional details on the requirements for the protocols. =

 

1)      draft-ietf-i2rs-ephemeral-state-00 =

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

3)      <= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-traceability-03  =

 

The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for = I2RS.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains = an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as = suggestions on what type of solution the I2RS WG would like to see, but = I2RS WG is asking the NETCONF WG to provide its best designed = protocol.  Please note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity.   

 

The I2RS = protocol is driven by data-models.  The approved data models for = protocol independent services are:

-          = draft-ietf-i2rs-rib-data-model-00

-          = Filter-Based RIBS:  draft-kini-i2rs= -fb-rib-data-model.00 (released later this = week)

-          = Topology model = which is a composite of:

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

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

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

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

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

 

At this time, none of the Topology models utilize = Traffic engineering.  It is anticipated that these models will = support traffic engineering.  Estimated rates of transfer and = timing requirements for these modules are at: http://trac.tools.i= etf.org/wg/i2rs/trac/wiki - under the protocol requirements table. =

 

We hope that NETCONF WG can provide some initial = feedback on these requirements by IETF 93 at the Tuesday I2RS = session.   I2RS will use the 6/24 interim at 10:00-11:30am ET =  to provide a time for any participate in the I2RS, netconf, or = netmod group to ask additional questions on these requirements. =

 

Sue Hares

 

Interim = time: 10:00-11:30am ET

Date = 6/24/2015

Webex:

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b000= 8a3c52069d0f

 

agenda: =

 

10:00 – 10:05 – Bash = Agenda

10:05 – 10:20- -  = review of requirements from

= draft-ietf-i2rs-ephemeral-state-00

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

= draft-ietf-i2rs-traceability-03

Timing requirements =

 

10:20 – 10:30    Review of = requirements for mutual authentication,

and = transaction in  draft-hares-auth-trans-01 requirements =

 

10:30- 11:30     Open discussion = for I2RS Requirements

 

Proceedings = and slides can be found at:

http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedi= ngs.html

 

Sue Hares

 

 

------=_NextPart_000_00DA_01D0ADBF.9235C2E0-- From nobody Tue Jun 23 11:31:06 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3D1B2F34 for ; Tue, 23 Jun 2015 11:31: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 FIE0A3OBmRzC for ; Tue, 23 Jun 2015 11:31:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375B41B2F2F for ; Tue, 23 Jun 2015 11:31:01 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: Date: Tue, 23 Jun 2015 14:30:57 -0400 Message-ID: <010401d0ade2$c018cf90$404a6eb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01D0ADC1.39088F20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCt4pUdKfExknApTp6C1+74YxEKlA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "'Alvaro Retana \(aretana\)'" , 'Benoit Claise' , "'BRUNGARD, DEBORAH A'" , 'Alia Atlas' Subject: [i2rs] 6/24/2015 I2RS interim 10:00 - 11:30am 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, 23 Jun 2015 18:31:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0105_01D0ADC1.39088F20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Interim time: 10:00-11:30am ET Date 6/24/2015 Webex: https://ietf.webex.com/ietf/j.php?MTID=m4260bee7be61cb17b0008a3c52069d0f agenda: 10:00 - 10:05 - Bash Agenda 10:05 - 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements 10:20 - 10:30 Review of requirements for mutual authentication, and transaction in draft-hares-auth-trans-01 requirements 10:30- 11:30 Open discussion for I2RS Requirement Proceedings at: http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html ------=_NextPart_000_0105_01D0ADC1.39088F20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Interim = time: 10:00-11:30am ET

Date = 6/24/2015

Webex:

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61c= b17b0008a3c52069d0f

 

agenda: =

 

10:00 – 10:05 – Bash = Agenda

10:05 – 10:20- -  = review of requirements from

= draft-ietf-i2rs-ephemeral-state-00

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

draft-ietf-i2rs-traceability-03

Timing requirements

 

10:20 = – 10:30    Review of requirements for mutual = authentication,

and transaction = in  draft-hares-auth-trans-01 requirements

 

10:30- = 11:30     Open discussion for I2RS = Requirement

 

Proceedings at:

http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedi= ngs.html

 

------=_NextPart_000_0105_01D0ADC1.39088F20-- From nobody Tue Jun 23 11:37: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 6DC7E1A90D7 for ; Tue, 23 Jun 2015 11:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id py9iEK9lnRFE for ; Tue, 23 Jun 2015 11:37:22 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FF51A8782 for ; Tue, 23 Jun 2015 11:37:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: "'Andy Bierman'" References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 23 Jun 2015 14:37:09 -0400 Message-ID: <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01D0ADC2.16B58580" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCQIeJoLHKQ7oAYGCGjY2QIv20pQwG7T9z7oC2kBEA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 18:37:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0112_01D0ADC2.16B58580 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt. = This document is now a WG document =E2=80=93 so suggestions on changing = the text are welcome. It is a work-in-progress so I appreciate your = help in refining this draft. Please suggest alternate text for the = draft. My comments on individual points are below.=20 =20 At the front of this document are the top 10 requirements for the I2RS = protocol. All other details within this draft are to provide more = detail to these requirements, and do not dictate a solution to the = NETCONF/NETMOD working group. I hope my message to netconf/netmod/I2rs = further clarifies this point. =20 The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement = on web-ex. Please join us at the interim and continue to discuss the = requirements on this mail list.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, June 23, 2015 2:09 PM To: internet-drafts@ietf.org Cc: i2rs@ietf.org; i-d-announce@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt =20 Hi, =20 This draft seems to propose very specific solutions, not requirements. =20 =20 This text is in the section explaining why an ephemeral datastore won't = work: =20 The most obvious disadvantage of such a fully separate datastore is that interaction with the network element's operational or configuration state becomes significantly more difficult. =20 I don't see any evidence or examples in the draft to support this claim. =20 =20 [Sue: This is correct. The authors recorded what they heard at the I2RS = interims. If you would like to clarify this =E2=80=93 please do. I = have heard this is implementation dependent. Is this true?=20 =20 The requirements do not make it clear how a YANG module is implemented by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all how YANG data-def-stmts are handled correctly by each protocol. Perhaps you can provide some data model examples. =20 [Sue: I have given the I2RS yang module list in the netconf announcement = for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB. These data = modules provide you with some examples, and I welcome a specific = discussion of these modules on the list or at the I2RS interim. =20 =20 Andy =20 =20 =20 On Tue, Jun 23, 2015 at 9:52 AM, wrote: 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 : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-00.txt Pages : 13 Date : 2015-06-23 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-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0112_01D0ADC2.16B58580 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

Thank you for the feedback on = draft-ietf-i2rs-pehemeral-state-00.txt.=C2=A0 =C2=A0This document is now = a WG document =E2=80=93 so suggestions on changing the text are welcome. = =C2=A0=C2=A0It is a work-in-progress so I appreciate your help in = refining this draft. =C2=A0Please suggest alternate text for the = draft.=C2=A0 My comments on individual points are below. =

 

At the front of this document are the top 10 requirements for the = I2RS protocol.=C2=A0 All other details within this draft are to provide = more detail to these requirements, and do not dictate a solution to the = NETCONF/NETMOD working group. =C2=A0I hope my message to = netconf/netmod/I2rs further clarifies this = point.

 

The I2RS 6/24/2015 interim will continue to discuss the I2RS = requirement on web-ex.=C2=A0 Please join us at the interim and continue = to discuss the requirements on this mail list.

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, June 23, 2015 2:09 PM
To: = internet-drafts@ietf.org
Cc: i2rs@ietf.org; = i-d-announce@ietf.org
Subject: Re: [i2rs] I-D Action: = draft-ietf-i2rs-ephemeral-state-00.txt

 

Hi,

 

This draft seems to propose very specific solutions, = not requirements.

 

 

This text is in the section explaining why an = ephemeral datastore won't work:

 

=C2=A0=C2=A0 The most obvious disadvantage of such =
a fully separate datastore is
=C2=A0=C2=A0 that interaction with the network =
element's operational or
=C2=A0=C2=A0 configuration state becomes =
significantly more difficult.
 

I don't see any evidence or examples in the draft to = support this claim.

 

 

[Sue: This is correct.=C2=A0 The authors recorded what they heard at = the I2RS interims.=C2=A0 If you would like to clarify this =E2=80=93 = please do.=C2=A0 I have heard this is implementation dependent.=C2=A0 Is = this true?

 

The requirements do not make it clear how a YANG = module is implemented

by = I2RS vs. implemented by NETCONF or RESTCONF.  It is not clear at = all

how YANG = data-def-stmts are handled correctly by each = protocol.

Perhaps you can = provide some data model examples.

 

[Sue: I have given the I2RS yang module list in the netconf = announcement for the I2RS RIB, I2RS Topology drafts, and I2RS FB = RIB.=C2=A0 =C2=A0These data modules provide you with some examples, and = I welcome a specific discussion of these modules on the list or at the = I2RS interim. =C2=A0

=C2=A0

Andy

 

 

 

On Tue, = Jun 23, 2015 at 9:52 AM, <internet-drafts@ietf.org> = wrote:


A New Internet-Draft is = available from the on-line Internet-Drafts directories.
 This = draft is a work item of the Interface to the Routing System Working = Group of the IETF.

        Title    =        : I2RS Ephemeral State Requirements
  =       Authors         : Jeff = Haas
                  =         Susan Hares
        = Filename        : = draft-ietf-i2rs-ephemeral-state-00.txt
        = Pages           : 13
    =     Date            : = 2015-06-23

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-ietf-i2rs-epheme= ral-state/

There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-s= tate-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/

________= _______________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_0112_01D0ADC2.16B58580-- From nobody Tue Jun 23 12:05:16 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3E21B2F9A for ; Tue, 23 Jun 2015 12:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9Aiil4V4QqdL for ; Tue, 23 Jun 2015 12:05:12 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) (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 B89F11B2F97 for ; Tue, 23 Jun 2015 12:05:11 -0700 (PDT) Received: by lbbpo10 with SMTP id po10so12737887lbb.3 for ; Tue, 23 Jun 2015 12:05:10 -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=16CG4b5U9R0btrqbQiVx4vNfcRn4z7pKHbAPdpJ4hjo=; b=QVCfB7r3rplVoYGon3ghMkp16xGwcD5TVlGX5Q/jCH+Je0wmL1BPjRHNiPZAA6S6Xe stGRszAsttMbP+ClpzHc9rePpB3LkPhbzGTVlfLC77JkF/O7aXoqWTPlZNlVLTmPw0dt NxO71LaFfabsNi7VwKmV4immUrNSrAWcXbi8AhZWxj3Ki/DGGZanTcXGRLfBCISJ+sIr zQjBL+B6ttVKQpsiwTYucTDKF0XTZO6F4UUcS4pboeMgdzZfMZS1LBkYoSldIaQ6LlhR zwIKfh+pABhjm8LjR5y0u04cH8J+pCJ4k2Ah+WmodTLdxSrefPjZqpjeC8Kjlml7WKb5 icMQ== X-Gm-Message-State: ALoCoQmsp7vgC729VJ9miN7kb3iktPVJDVq9D+oEHzJjuDz2KynLkyaUqFt6pymTKYV8WlDbAX6k MIME-Version: 1.0 X-Received: by 10.112.55.207 with SMTP id u15mr36549542lbp.88.1435086310086; Tue, 23 Jun 2015 12:05:10 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 23 Jun 2015 12:05:09 -0700 (PDT) In-Reply-To: <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> Date: Tue, 23 Jun 2015 12:05:09 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a113403d8bc325c051934119a Archived-At: Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 19:05:14 -0000 --001a113403d8bc325c051934119a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I am still fairly confused how the running configuration interacts with ephemeral data, but I will wait to see some concrete solution proposals. The proposal does not mention what changes would be required to YANG to add "config=3Dephermal". There are 1000s of lines of text that would be impacted by this change. This change might break a YANG 1.0 tool, which would violate the NETMOD charter for YANG 1.1. This solution does seem to suggest that I2RS can never alter any value that is config=3Dtrue. These nodes can only be changed by NETCONF. This of course means that no client priority or secondary identity could be supported for config=3Dtrue nodes. Ephemeral data cannot really rely on any local config, since any client can alter it at any time. This might be fine, but I2RS clients need to be careful not to assume any particular running configuration in order to work. You cannot safely add an ephemeral leaf to a configuration container or list. It also means that I2RS can never be used to override a config=3Dtrue value (since the data models do not overlap). A special add-on I2RS module would be needed to define the specific I2RS override knobs. sec 6.2 adds client priority to the NACM group list. Users can be in multiple groups, so you need to specify how the client priority is determined as the group membership configuration is changed. +--rw groups | +--rw group [name] | +--rw name group-name-type | +--rw user-name* user-name-type | +--rw i2rs:i2rs-priority i2rs-priority-type Sec 6.3. shows the client setting its own priority. This does not seem correct if the administrator is supposed to set the client priorities. ... Andy On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares wrote: > Andy: > > > > Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt. > This document is now a WG document =E2=80=93 so suggestions on changing = the text > are welcome. It is a work-in-progress so I appreciate your help in > refining this draft. Please suggest alternate text for the draft. My > comments on individual points are below. > > > > At the front of this document are the top 10 requirements for the I2RS > protocol. All other details within this draft are to provide more detail > to these requirements, and do not dictate a solution to the NETCONF/NETMO= D > working group. I hope my message to netconf/netmod/I2rs further clarifie= s > this point. > > > > The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement > on web-ex. Please join us at the interim and continue to discuss the > requirements on this mail list. > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 2:09 PM > *To:* internet-drafts@ietf.org > *Cc:* i2rs@ietf.org; i-d-announce@ietf.org > *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt > > > > Hi, > > > > This draft seems to propose very specific solutions, not requirements. > > > > > > This text is in the section explaining why an ephemeral datastore won't > work: > > > > The most obvious disadvantage of such a fully separate datastore is > > that interaction with the network element's operational or > > configuration state becomes significantly more difficult. > > > > I don't see any evidence or examples in the draft to support this claim. > > > > > > [Sue: This is correct. The authors recorded what they heard at the I2RS > interims. If you would like to clarify this =E2=80=93 please do. I have= heard > this is implementation dependent. Is this true? > > > > The requirements do not make it clear how a YANG module is implemented > > by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all > > how YANG data-def-stmts are handled correctly by each protocol. > > Perhaps you can provide some data model examples. > > > > [Sue: I have given the I2RS yang module list in the netconf announcement > for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB. These data > modules provide you with some examples, and I welcome a specific discussi= on > of these modules on the list or at the I2RS interim. > > > > Andy > > > > > > > > On Tue, Jun 23, 2015 at 9:52 AM, wrote: > > > 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 : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-00.txt > Pages : 13 > Date : 2015-06-23 > > 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-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a113403d8bc325c051934119a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am still fairly confused how the = running configuration interacts
with ephemeral data, but I will w= ait to see some concrete solution
proposals.

=
The proposal does not mention what changes would be required to
<= div>YANG to add "config=3Dephermal".=C2=A0 There are 1000s of lin= es
of text that would be impacted by this change.=C2=A0 This chan= ge
might break a YANG 1.0 tool, which would violate the NETMOD ch= arter
for YANG 1.1.

This solution does s= eem to suggest that I2RS can never alter any
value that is config= =3Dtrue.=C2=A0 These nodes can only be changed by NETCONF.
This o= f course means that no client priority or secondary identity
coul= d be supported for config=3Dtrue nodes.=C2=A0 Ephemeral data cannot
really rely on any local config, since any client can alter it at any ti= me.
This might be fine, but I2RS clients need to be careful not t= o
assume any particular running configuration in order to work.
You cannot safely add an ephemeral leaf to a configuration contain= er
or list.

It also means that I2RS can = never be used to override a config=3Dtrue
value (since the data m= odels do not overlap).=C2=A0 A special add-on I2RS
module would b= e needed to define the specific I2RS override knobs.

sec 6.2 adds client priority to the NACM group list.
Users can= be in multiple groups, so you need to specify how
the client pri= ority is determined as the group membership
configuration is chan= ged.

   +--rw groups
      |  +--rw group [name]
      |     +--rw name         group-name-type
      |     +--rw user-name*   user-name-type
      |     +--rw i2rs:i2rs-priority i2rs-priority-type


Sec 6.3. shows the client setting its own pr= iority.
This does not seem correct if the administrator is supposed toset the client priorities.

       <foo xmlns:i2rs=3D"=
https://ietf.example.com/i2rs=
"
           i2rs:i2rs-secondary-identity=3D"user1" i2rs:i2rs-prior=
ity=3D"47">
          ...
      </foo>


Andy




On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares <shares@= ndzh.com> wrote:

Andy:

=C2=A0

Thank you for the feedback on draft-ietf= -i2rs-pehemeral-state-00.txt.=C2=A0 =C2=A0This document is now a WG documen= t =E2=80=93 so suggestions on changing the text are welcome. =C2=A0=C2=A0It= is a work-in-progress so I appreciate your help in refining this draft.=C2= =A0 Please suggest alternate text for the draft.=C2=A0 My comments on indiv= idual points are below.

=C2=A0

At the front of this document are the top 10 = requirements for the I2RS protocol.=C2=A0 All other details within this dra= ft are to provide more detail to these requirements, and do not dictate a s= olution to the NETCONF/NETMOD working group.=C2=A0 I hope my message to net= conf/netmod/I2rs further clarifies this point.

=C2=A0

The I2RS 6/24/2015 inte= rim will continue to discuss the I2RS requirement on web-ex.=C2=A0 Please j= oin us at the interim and continue to discuss the requirements on this mail= list.

=C2=A0

Sue Hares

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On= Behalf Of Andy Bierman
Sent: Tuesday, June 23, 2015 2:09 PM<= br>To: internet-drafts@ietf.org
Cc: i2rs@ietf.org; i-d-announce@ietf.org
Subject: Re: [i2= rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt=

=C2=A0

Hi,

=C2=A0

This draft seems to propose very specif= ic solutions, not requirements.

=C2=A0

= =C2=A0

This text is in the sect= ion explaining why an ephemeral datastore won't work:

=

=C2=A0

=C2=A0=C2=A0 The most obvious disadvantage of such a fully separate dat=
astore is
=C2=A0=
=C2=A0 that interaction with the network element's operational or
=C2=A0=C2=A0 configur=
ation state becomes significantly more difficult.
=C2=A0
I don=
9;t see any evidence or examples in the draft to support this claim.=

=C2=A0<=
u>
=
=C2=A0
[=
Sue: This is correct.=C2=A0 The authors recorded what they heard at the I2R=
S interims.=C2=A0 If you would like to clarify this =E2=80=93 please do.=C2=
=A0 I have heard this is implementation dependent.=C2=A0 Is this true? <=
/u>

=C2=A0=

The requirements do not make it clear= how a YANG module is implemented

by I2RS vs. implemented by NETCONF or RESTCONF.=C2=A0 It is not c= lear at all

how YANG dat= a-def-stmts are handled correctly by each protocol.

=

Perhaps you can provide some data model example= s.

=C2=A0

[Sue: I have given the I2RS yang module list in the netconf announcement f= or the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB.=C2=A0 =C2=A0These d= ata modules provide you with some examples, and I welcome a specific discus= sion of these modules on the list or at the I2RS interim. =C2=A0<= /u>

= =C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

On Tu= e, Jun 23, 2015 at 9:52 AM, <internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-l= ine Internet-Drafts directories.
=C2=A0This draft is a work item of the = Interface to the Routing System Working Group of the IETF.

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: I2RS E= phemeral State Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jeff Haas
=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 Susan Hares
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-i2rs-ephemeral-state-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-06-23

Abstract:
= =C2=A0 =C2=A0This document covers requests to the netmod and netconf Workin= g
=C2=A0 =C2=A0Groups for functionality to support the ephemeral state r= equirements
=C2=A0 =C2=A0to implement the I2RS architecture.


= The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/
<= br>There's also a htmlized version available at:
h= ttps://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-00

Please note that it may take a couple of minutes from the time of submiss= ion
until the htmlized version and diff are available at tools.ietf.org.

Internet-Dr= afts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<= /a>

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

=C2=A0


--001a113403d8bc325c051934119a-- From nobody Tue Jun 23 13:30: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 C4B0A1B3099 for ; Tue, 23 Jun 2015 13:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.454 X-Spam-Level: X-Spam-Status: No, score=-98.454 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, 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 PN9wNkHEG4yc for ; Tue, 23 Jun 2015 13:30:02 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B3A1B309F for ; Tue, 23 Jun 2015 13:30:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: "'Andy Bierman'" References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> In-Reply-To: Date: Tue, 23 Jun 2015 16:29:56 -0400 Message-ID: <016701d0adf3$5f014000$1d03c000$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0168_01D0ADD1.D7F45AF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCQIeJoLHKQ7oAYGCGjY2QIv20pQwG7T9z7An0NiTkBas9sGaAOiATA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alia Atlas' Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 20:30:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0168_01D0ADD1.D7F45AF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy: =20 We will look for concrete proposal in the NETCONF/NETMOD group.=20 =20 The proposal for =E2=80=9Cconfig =3D ephemeral=E2=80=9D came out of = discussion with the netconf group. Again, I hope there will be a = concrete proposal from that group. =20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, June 23, 2015 3:05 PM To: Susan Hares Cc: i2rs@ietf.org; Alia Atlas Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt =20 Hi, =20 I am still fairly confused how the running configuration interacts with ephemeral data, but I will wait to see some concrete solution proposals. =20 [sue]: Hopefully this will come out of netconf. =20 The proposal does not mention what changes would be required to YANG to add "config=3Dephermal". There are 1000s of lines of text that would be impacted by this change. This change might break a YANG 1.0 tool, which would violate the NETMOD charter for YANG 1.1. =20 [Sue]: Do you have an alternate proposal.=20 =20 This solution does seem to suggest that I2RS can never alter any value that is config=3Dtrue. These nodes can only be changed by = NETCONF. This of course means that no client priority or secondary identity could be supported for config=3Dtrue nodes. Ephemeral data cannot really rely on any local config, since any client can alter it at any = time. This might be fine, but I2RS clients need to be careful not to assume any particular running configuration in order to work. You cannot safely add an ephemeral leaf to a configuration container or list. [Sue]: You understand the meaning of ephemeral. The I2RS client will=20 Have to set the configuration via a normal netconf configuration.=20 =20 =20 It also means that I2RS can never be used to override a config=3Dtrue value (since the data models do not overlap). A special add-on I2RS module would be needed to define the specific I2RS override knobs. =20 [yes =E2=80=93 this is correct].=20 =20 sec 6.2 adds client priority to the NACM group list. Users can be in multiple groups, so you need to specify how the client priority is determined as the group membership configuration is changed. =20 +--rw groups | +--rw group [name] | +--rw name group-name-type | +--rw user-name* user-name-type | +--rw i2rs:i2rs-priority i2rs-priority-type =20 [Sue: Could you provide more details on this fact. I was concerned = because Martin indicated the group membership could be changed to the = highest group. Would it be better on the client?=20 Sec 6.3. shows the client setting its own priority. This does not seem correct if the administrator is supposed to set the client priorities. =20 ... =20 [Sue: It is the assumed the client is resetting its priority because the = administrator changed something.] =20 Great questions =E2=80=93 keep asking more!=20 =20 Andy =20 =20 =20 =20 On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares wrote: Andy:=20 =20 Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt. = This document is now a WG document =E2=80=93 so suggestions on changing = the text are welcome. It is a work-in-progress so I appreciate your = help in refining this draft. Please suggest alternate text for the = draft. My comments on individual points are below.=20 =20 At the front of this document are the top 10 requirements for the I2RS = protocol. All other details within this draft are to provide more = detail to these requirements, and do not dictate a solution to the = NETCONF/NETMOD working group. I hope my message to netconf/netmod/I2rs = further clarifies this point. =20 The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement = on web-ex. Please join us at the interim and continue to discuss the = requirements on this mail list.=20 =20 Sue Hares=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, June 23, 2015 2:09 PM To: internet-drafts@ietf.org Cc: i2rs@ietf.org; i-d-announce@ietf.org Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt =20 Hi, =20 This draft seems to propose very specific solutions, not requirements. =20 =20 This text is in the section explaining why an ephemeral datastore won't = work: =20 The most obvious disadvantage of such a fully separate datastore is that interaction with the network element's operational or configuration state becomes significantly more difficult. =20 I don't see any evidence or examples in the draft to support this claim. =20 =20 [Sue: This is correct. The authors recorded what they heard at the I2RS = interims. If you would like to clarify this =E2=80=93 please do. I = have heard this is implementation dependent. Is this true?=20 =20 The requirements do not make it clear how a YANG module is implemented by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all how YANG data-def-stmts are handled correctly by each protocol. Perhaps you can provide some data model examples. =20 [Sue: I have given the I2RS yang module list in the netconf announcement = for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB. These data = modules provide you with some examples, and I welcome a specific = discussion of these modules on the list or at the I2RS interim. =20 =20 Andy =20 =20 =20 On Tue, Jun 23, 2015 at 9:52 AM, wrote: 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 : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-00.txt Pages : 13 Date : 2015-06-23 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-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_0168_01D0ADD1.D7F45AF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

We will look for concrete proposal in the NETCONF/NETMOD group. =

 

The proposal for =E2=80=9Cconfig =3D ephemeral=E2=80=9D came out of = discussion with the netconf group.=C2=A0 Again, I hope there will be a = concrete proposal from that group. =C2=A0

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, June 23, 2015 3:05 PM
To: = Susan Hares
Cc: i2rs@ietf.org; Alia Atlas
Subject: = Re: [i2rs] I-D Action: = draft-ietf-i2rs-ephemeral-state-00.txt

 

Hi,

 

I = am still fairly confused how the running configuration = interacts

with ephemeral = data, but I will wait to see some concrete = solution

proposals.

 

[sue]: Hopefully this will come out of = netconf.

 

The = proposal does not mention what changes would be required = to

YANG to add = "config=3Dephermal".  There are 1000s of = lines

of text that would = be impacted by this change.  This = change

might break a YANG = 1.0 tool, which would violate the NETMOD = charter

for YANG = 1.1.

 

[Sue]: Do you have an alternate proposal. =

 

This solution does seem to suggest that I2RS can never = alter any

value that is = config=3Dtrue.  These nodes can only be changed by = NETCONF.

This of course = means that no client priority or secondary = identity

could be = supported for config=3Dtrue nodes.  Ephemeral data = cannot

really rely on any = local config, since any client can alter it at any = time.

This might be fine, = but I2RS clients need to be careful not to

assume any particular running configuration in order = to work.

You cannot safely = add an ephemeral leaf to a configuration = container

or = list.

[Sue]: You understand the meaning of ephemeral.=C2=A0 The I2RS client = will

Have to set the configuration via a normal netconf configuration. =

 

 

It also means that I2RS can never be used to override = a config=3Dtrue

value = (since the data models do not overlap).  A special add-on = I2RS

module would be = needed to define the specific I2RS override knobs.

 

[yes =E2=80=93 this is correct].

 

sec 6.2 adds client priority to the NACM group = list.

Users can be in = multiple groups, so you need to specify how

the client priority is determined as the group = membership

configuration = is changed.

 

=C2=A0=C2=A0 +--rw =
groups
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw group =
[name]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0 +--rw =
name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
group-name-type
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
|=C2=A0=C2=A0=C2=A0=C2=A0 +--rw user-name*=C2=A0=C2=A0 =
user-name-type
=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

 

[Sue: Could you provide more details on this fact. =C2=A0I was = concerned because Martin indicated the group membership could be changed = to the highest group. =C2=A0Would it be better on the client? =


Sec 6.3. shows the = client setting its own priority.
This does not seem correct if the = administrator is supposed to
set the client = priorities.

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <foo =
xmlns:i2rs=3D"https://ietf.example.com/i2rs&=
quot;
=C2=A0=C2=A0=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=C2=A0=C2=A0=C2=A0=C2=A0 =
</foo>

 

[Sue: It is the assumed the client is resetting its priority because = the administrator changed something.]

 

Great questions =E2=80=93 keep asking more! =

 

Andy

 

 

 

 

On Tue, = Jun 23, 2015 at 11:37 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Thank you for the feedback on = draft-ietf-i2rs-pehemeral-state-00.txt.   This document is now = a WG document =E2=80=93 so suggestions on changing the text are welcome. =   It is a work-in-progress so I appreciate your help in = refining this draft.  Please suggest alternate text for the = draft.  My comments on individual points are below. =

 

At the front of this document are the top 10 requirements for the = I2RS protocol.  All other details within this draft are to provide = more detail to these requirements, and do not dictate a solution to the = NETCONF/NETMOD working group.  I hope my message to = netconf/netmod/I2rs further clarifies this = point.

 

The I2RS 6/24/2015 interim will continue to discuss the I2RS = requirement on web-ex.  Please join us at the interim and continue = to discuss the requirements on this mail list.

 

Sue Hares

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, June 23, 2015 2:09 PM
To: internet-drafts@ietf.org
Cc: i2rs@ietf.org; i-d-announce@ietf.org
Subject: Re: = [i2rs] I-D Action: = draft-ietf-i2rs-ephemeral-state-00.txt

 <= /o:p>

Hi,

 <= /o:p>

This draft = seems to propose very specific solutions, not = requirements.

 <= /o:p>

 <= /o:p>

This text = is in the section explaining why an ephemeral datastore won't = work:

 <= /o:p>

   The most obvious disadvantage of such =
a fully separate datastore is
   that interaction with the network =
element's operational or
   configuration state becomes =
significantly more difficult.
 

I don't see = any evidence or examples in the draft to support this = claim.

 

 

[Sue: This is correct.  The authors recorded what they heard at = the I2RS interims.  If you would like to clarify this =E2=80=93 = please do.  I have heard this is implementation dependent.  Is = this true?

 <= /o:p>

The = requirements do not make it clear how a YANG module is = implemented

by I2RS vs. = implemented by NETCONF or RESTCONF.  It is not clear at = all

how YANG = data-def-stmts are handled correctly by each = protocol.

Perhaps you = can provide some data model examples.

 

[Sue: I have given the I2RS yang module list in the netconf = announcement for the I2RS RIB, I2RS Topology drafts, and I2RS FB = RIB.   These data modules provide you with some examples, and = I welcome a specific discussion of these modules on the list or at the = I2RS interim.  

 

Andy

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Jun = 23, 2015 at 9:52 AM, <internet-drafts@ietf.org> = wrote:


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Interface to the = Routing System Working Group of the IETF.

      =   Title           : I2RS Ephemeral = State Requirements
        Authors    =      : Jeff Haas
          =                 Susan = Hares
        Filename        = : draft-ietf-i2rs-ephemeral-state-00.txt
        = Pages           : 13
    =     Date            : = 2015-06-23

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-ietf-i2rs-epheme= ral-state/

There's also a htmlized version available = at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-s= tate-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/

________= _______________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 <= /o:p>

 

------=_NextPart_000_0168_01D0ADD1.D7F45AF0-- From nobody Tue Jun 23 14:48: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 2F3DA1A21C3 for ; Tue, 23 Jun 2015 14:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 08bdC5zdEag6 for ; Tue, 23 Jun 2015 14:48:07 -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 5AC021A8886 for ; Tue, 23 Jun 2015 14:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45927251335; Tue, 23 Jun 2015 14:48:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [209.5.235.18]) (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 A0CD724097E; Tue, 23 Jun 2015 14:48:06 -0700 (PDT) To: DIEGO LOPEZ GARCIA , Alia Atlas References: <296D132F-5E2E-495A-AEB9-17B161BC7286@telefonica.com> <1E0ED488-9114-4909-BD6F-EC9F6296FB4F@telefonica.com> From: "Joel M. Halpern" Message-ID: <5589D410.7080204@joelhalpern.com> Date: Tue, 23 Jun 2015 17:48:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <1E0ED488-9114-4909-BD6F-EC9F6296FB4F@telefonica.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" Subject: Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 21:48:10 -0000 My understanding matches Alia's. It is an opaque string recorded for traceability. In particular, to allow the broker model the attribution has to be per-request. Yours, Joel On 6/23/15 9:41 AM, DIEGO LOPEZ GARCIA wrote: > Hi Alia, > > My understanding was that secondary identity was not intended to be only > a general declaration made by the client, in which case what you say > definitely holds. If the trust model at the agent does not completely > rely on client assertions, the only way in which I see you can ensure > traceability is by associating data with a minimum level of assurance, > in despite of those data being opaque or not to the entities providing > or recording them. > > If the first assumption holds, I'll stay corrected and support your > comment to section 3.1. If not, I'd say I have a point here... > > Be goode, > > On 23 Jun 2015, at 14:10 , Alia Atlas > wrote: > >> Hi Diego, >> >> The secondary identity is just an opaque value to allow traceability. >> It's to support a >> client easily being a broker for multiple applications. I don't agree >> that there is value >> in trying to secure the secondary identity the way you are >> describing. This path leads >> to there being basically no value for having secondary identities. >> >> Regards, >> Alia >> >> On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA >> > >> wrote: >> >> >> --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >> charset=us-ascii >> >> Hi Alia, >> >> Just a remark on your comment about section 3.1: I think the current = >> requirement of associating a single secondary identity per >> connection = >> does make sense if we want to keep traceability over I2RS secure = >> transports.=20 >> >> You need to associate secondary identities with primary ones in a >> secure = >> way to guarantee such traceability, and the mechanisms for this I >> can = >> imagine using current transports (such as a certificate extension or = >> alternate identity, or additional information in secure tokens) are = >> associated with connection handshake, and therefore re-association >> is = >> complicated to implement without restarting the connection. Note I >> say = >> complicated, not impossible, but I cannot see the advantage in the = >> additional complexity, especially when experience shows that >> additional = >> complexity becoming source of security flaws... >> >> Be goode, >> >> On 11 Jun 2015, at 22:11 , Alia Atlas > > wrote: >> >> > >> >=20 >> > Sue, >> >=20 >> > Thanks for writing this draft. I think it is useful to clearly = >> articulate the outside-of-I2RS behavior and protocols that are >> needed = >> for the mutual authentication. I do have a couple comments on the = >> draft. >> >=20 >> >=20 >> > In Sec 3.1, it says "Each Identity will be linked to one secondary = >> identity for the period of a connection." I would have assumed >> that the = >> client could arbitrarily change its' secondary identity. This is to = >> support the broker case where a client may be passing along requests = >> from multiple applications. Since the secondary identity is just >> passed = >> along and stored for traceability, I don't think that allowing it to = >> change would cause significant complications. What do others think? >> >=20 >> >=20 >> > In the I2RS architecture, there are 3 different types of >> transaction = >> behavior desired for processing a message. In Sec 4, there's an = >> assumption that "fail-on-error" with the associated roll-back is the = >> only mode. Thus, I think that Section 4 needs a bit of massaging. >> >=20 >> >=20 >> > Thanks, >> >=20 >> > Alia >> > _______________________________________________ >> > i2rs mailing list >> > i2rs@ietf.org >> > https://www.ietf.org/mailman/listinfo/i2rs >> >> -- >> "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 >> ---------------------------------- >> >> >> --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/html; >> charset=us-ascii >> >> > charset=3Dus-ascii">> -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi = >> Alia,

Just a remark on your comment about section = >> 3.1: I think the current requirement of associating a single >> secondary = >> identity per connection does make sense if we want to keep >> traceability = >> over I2RS secure transports. 

You >> need to = >> associate secondary identities with primary ones in a secure way to = >> guarantee such traceability, and the mechanisms for this I can >> imagine = >> using current transports (such as a certificate extension or >> alternate = >> identity, or additional information in secure tokens) are associated = >> with connection handshake, and therefore re-association is >> complicated = >> to implement without restarting the connection. Note I say >> complicated, = >> not impossible, but I cannot see the advantage in the additional = >> complexity, especially when experience shows that additional >> complexity = >> becoming source of security flaws...

Be = >> goode,

On 11 Jun 2015, at 22:11 , Alia Atlas = >> <> ">akatlas@gmail.com >> > = >> wrote:

> type=3D"cite">> content=3D"text/html; = >> charset=3Dutf-8">
> dir=3D"ltr"><no-hat>

Sue,

Thanks= >> for writing this draft.  I think it is useful to clearly = >> articulate the outside-of-I2RS behavior and protocols that are >> needed = >> for the mutual authentication.  I do have a couple comments >> on the = >> draft.


In Sec 3.1, it says "Each Identity will be >> linked to = >> one secondary identity for the period of a connection."  I >> would = >> have assumed that the client could arbitrarily change its' secondary = >> identity.  This is to support the broker case where a client >> may be = >> passing along requests from multiple applications.  Since the = >> secondary identity is just passed along and stored for >> traceability, I = >> don't think that allowing it to change would cause significant = >> complications.   What do others think?


In the I2RS = >> architecture, there are 3 different types of transaction behavior = >> desired for processing a message. In Sec 4, there's an assumption >> that = >> "fail-on-error" with the associated roll-back is the only mode. >>   = >> Thus, I think that Section 4 needs a bit of = >> massaging.


Thanks,

Alia
>> _______________________________________________
i2rs mailing = >> list
> href=3D"mailto:i2rs@ietf.org ">i2rs@ietf.org >>
https://www.ietf.org/ma= >> ilman/listinfo/i2rs >>

> = >> apple-content-edited=3D"true"> >>
> auto; text-align: start; text-indent: 0px; text-transform: none; = >> white-space: normal; widows: auto; word-spacing: 0px; = >> -webkit-text-stroke-width: 0px; word-wrap: break-word; = >> -webkit-nbsp-mode: space; -webkit-line-break: = >> after-white-space;">--
"Esta vez no fallaremos, Doctor = >> Infierno"

Dr Diego R. Lopez
Telefonica I+D
> href=3D"http://people.tid.es/diego.lopez/">http://people.tid.es/diego.lope= >> z/

e-mail: >> diego.r.lopez@telefonica.com >>
Tel:   = >>  +34 913 129 041
Mobile: +34 >> 682 051 = >> 091
----------------------------------
>> >>
>>
= >> >> --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1-- >> >> ________________________________ >> >> Este mensaje y sus adjuntos se dirigen exclusivamente a su >> destinatario, puede contener información privilegiada o >> confidencial y es para uso exclusivo de la persona o entidad de >> destino. Si no es usted. el destinatario indicado, queda >> notificado de que la lectura, utilización, divulgación y/o copia >> sin autorización puede estar prohibida en virtud de la legislación >> vigente. Si ha recibido este mensaje por error, le rogamos que nos >> lo comunique inmediatamente por esta misma vía y proceda a su >> destrucción. >> >> The information contained in this transmission is privileged and >> confidential 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 you have received this transmission in >> error, do not read it. Please immediately 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ário, pode conter informação privilegiada ou confidencial >> e é para uso exclusivo da pessoa ou entidade de destino. Se não é >> vossa senhoria o destinatário indicado, fica notificado de que a >> leitura, utilização, divulgação e/ou cópia sem autorização pode >> estar proibida em virtude da legislação vigente. Se recebeu esta >> mensagem por erro, rogamos-lhe que nos o comunique imediatamente >> por esta mesma via e proceda a sua destruição >> >> > > -- > "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, > puede contener información privilegiada o confidencial y es para uso > exclusivo de la persona o entidad de destino. Si no es usted. el > destinatario indicado, queda notificado de que la lectura, utilización, > divulgación y/o copia sin autorización puede estar prohibida en virtud > de la legislación vigente. Si ha recibido este mensaje por error, le > rogamos que nos lo comunique inmediatamente por esta misma vía y proceda > a su destrucción. > > The information contained in this transmission is privileged and > confidential 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 you have > received this transmission in error, do not read it. Please immediately > 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ário, pode conter informação privilegiada ou confidencial e é > para uso exclusivo da pessoa ou entidade de destino. Se não é vossa > senhoria o destinatário indicado, fica notificado de que a leitura, > utilização, divulgação e/ou cópia sem autorização pode estar proibida em > virtude da legislação vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destruição > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 23 14:59: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 09E021A8946 for ; Tue, 23 Jun 2015 14:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, J_CHICKENPOX_64=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 9Lcy4CJUbq5B for ; Tue, 23 Jun 2015 14:59:46 -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 81AF51A88D0 for ; Tue, 23 Jun 2015 14:59:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 70C5724097E; Tue, 23 Jun 2015 14:59:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [209.5.235.18]) (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 CA1BA24094E; Tue, 23 Jun 2015 14:59:45 -0700 (PDT) To: Andy Bierman , Susan Hares References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> From: "Joel M. Halpern" Message-ID: <5589D6CB.7030505@joelhalpern.com> Date: Tue, 23 Jun 2015 17:59:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 21:59:48 -0000 If no ephemeral model can include any information which is config=true in a YANG model, I believe that would be a show-stopper for I2RS> There are many pieces of information I2RS needs to manipulate in an ephemeral fashion which are,as I understand it, config=true. Yours, Joel On 6/23/15 3:05 PM, Andy Bierman wrote: > Hi, > > I am still fairly confused how the running configuration interacts > with ephemeral data, but I will wait to see some concrete solution > proposals. > > The proposal does not mention what changes would be required to > YANG to add "config=ephermal". There are 1000s of lines > of text that would be impacted by this change. This change > might break a YANG 1.0 tool, which would violate the NETMOD charter > for YANG 1.1. > > This solution does seem to suggest that I2RS can never alter any > value that is config=true. These nodes can only be changed by NETCONF. > This of course means that no client priority or secondary identity > could be supported for config=true nodes. Ephemeral data cannot > really rely on any local config, since any client can alter it at any time. > This might be fine, but I2RS clients need to be careful not to > assume any particular running configuration in order to work. > You cannot safely add an ephemeral leaf to a configuration container > or list. > > It also means that I2RS can never be used to override a config=true > value (since the data models do not overlap). A special add-on I2RS > module would be needed to define the specific I2RS override knobs. > > sec 6.2 adds client priority to the NACM group list. > Users can be in multiple groups, so you need to specify how > the client priority is determined as the group membership > configuration is changed. > > +--rw groups > | +--rw group [name] > | +--rw name group-name-type > | +--rw user-name* user-name-type > | +--rw i2rs:i2rs-priority i2rs-priority-type > > > > Sec 6.3. shows the client setting its own priority. > This does not seem correct if the administrator is supposed to > set the client priorities. > > i2rs:i2rs-secondary-identity="user1" i2rs:i2rs-priority="47"> > ... > > > > > Andy > > > > > On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares > wrote: > > Andy: ____ > > __ __ > > Thank you for the feedback on > draft-ietf-i2rs-pehemeral-state-00.txt. This document is now a WG > document – so suggestions on changing the text are welcome. It is > a work-in-progress so I appreciate your help in refining this > draft. Please suggest alternate text for the draft. My comments on > individual points are below. ____ > > __ __ > > At the front of this document are the top 10 requirements for the > I2RS protocol. All other details within this draft are to provide > more detail to these requirements, and do not dictate a solution to > the NETCONF/NETMOD working group. I hope my message to > netconf/netmod/I2rs further clarifies this point.____ > > __ __ > > The I2RS 6/24/2015 interim will continue to discuss the I2RS > requirement on web-ex. Please join us at the interim and continue > to discuss the requirements on this mail list. ____ > > __ __ > > Sue Hares ____ > > __ __ > > *From:*i2rs [mailto:i2rs-bounces@ietf.org > ] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 2:09 PM > *To:* internet-drafts@ietf.org > *Cc:* i2rs@ietf.org ; i-d-announce@ietf.org > > *Subject:* Re: [i2rs] I-D Action: > draft-ietf-i2rs-ephemeral-state-00.txt____ > > __ __ > > Hi,____ > > __ __ > > This draft seems to propose very specific solutions, not > requirements.____ > > __ __ > > __ __ > > This text is in the section explaining why an ephemeral datastore > won't work:____ > > __ __ > > The most obvious disadvantage of such a fully separate datastore > is____ > > that interaction with the network element's operational or____ > > configuration state becomes significantly more difficult.____ > > __ __ > > I don't see any evidence or examples in the draft to support this > claim.____ > > __ __ > > __ __ > > [Sue: This is correct. The authors recorded what they heard at the > I2RS interims. If you would like to clarify this – please do. I > have heard this is implementation dependent. Is this true? ____ > > __ __ > > The requirements do not make it clear how a YANG module is > implemented____ > > by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at > all____ > > how YANG data-def-stmts are handled correctly by each protocol.____ > > Perhaps you can provide some data model examples.____ > > __ __ > > [Sue: I have given the I2RS yang module list in the netconf > announcement for the I2RS RIB, I2RS Topology drafts, and I2RS FB > RIB. These data modules provide you with some examples, and I > welcome a specific discussion of these modules on the list or at the > I2RS interim. ____ > > ____ > > Andy____ > > __ __ > > __ __ > > __ __ > > On Tue, Jun 23, 2015 at 9:52 AM, > wrote:____ > > > 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 : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-00.txt > Pages : 13 > Date : 2015-06-23 > > 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-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ > > _______________________________________________ > 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 Jun 23 19:21: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 0F1281B33A8 for ; Tue, 23 Jun 2015 19:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 acNkyxMpJ6VF for ; Tue, 23 Jun 2015 19:21:11 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 6128A1B339F for ; Tue, 23 Jun 2015 19:21:10 -0700 (PDT) Received: by lbnk3 with SMTP id k3so17774061lbn.1 for ; Tue, 23 Jun 2015 19:21:08 -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=y93AY0+/suaQ6ax3+xSO9KPgibejGfDL23Yb2Kl75cw=; b=lbss7Bv7pPHMwlJZ+CM1VtfYabGk2+GK7pi0+VGy58UXfu6Zt3MHjYMbz82brS07R6 oqUu5z77s9WNOSnvcCuSSKLa46xturkMW+jIAfIKBbIZmHBYz8h5b4QPiqnoek2risBT 9/Y7m1Qv/Ol1Nx9iVbx6o8v74S9/kTnUbhxf5FMd0hW+zTbb/kNopVvDw3puBC4TUpVj fqfxWQgH/DlHrlSxFtXd/nl7rhLh5gw7j8EYO0qJBUIxZRvkoxm3y607WIIfK0DWRQAa +Ud+3pOPrthXpvc3NOFpePRlLh7DmteeTUOftGbitI9zx3UOtJYfaM7Z8KCyxQ5C1Sow hJBQ== X-Gm-Message-State: ALoCoQn+mlkNlXAuJJDE0X4iavihFvFA909DwH2LqAdGruC8Am6BjYlHOue3CTPLtXB1su0idxSn MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr4366268laa.33.1435112468821; Tue, 23 Jun 2015 19:21:08 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Tue, 23 Jun 2015 19:21:08 -0700 (PDT) In-Reply-To: <016701d0adf3$5f014000$1d03c000$@ndzh.com> References: <20150623165237.12779.22569.idtracker@ietfa.amsl.com> <011101d0ade3$9dc4db90$d94e92b0$@ndzh.com> <016701d0adf3$5f014000$1d03c000$@ndzh.com> Date: Tue, 23 Jun 2015 19:21:08 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c27cf0ead0de05193a28a1 Archived-At: Cc: "i2rs@ietf.org" , Alia Atlas Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 02:21:14 -0000 --001a11c27cf0ead0de05193a28a1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 23, 2015 at 1:29 PM, Susan Hares wrote: > Andy: > > > > We will look for concrete proposal in the NETCONF/NETMOD group. > I doubt this will work without direct involvement from an I2RS proponent who really plans to implement the protocol in their products. I think about 5 or 6 of us have 7 or 8 different solutions in mind ;-) Otherwise you would have probably already seen a draft posted. > > The proposal for =E2=80=9Cconfig =3D ephemeral=E2=80=9D came out of discu= ssion with the > netconf group. Again, I hope there will be a concrete proposal from that > group. > > > OK, then I will assume the text that looks like specific YANG or XML is really just a shorthand for the concept. The YANG syntax is the easiest part. The text related to YANG validation, error handling, XPath evaluation, etc. is the hard part. Without a clear consensus on the properties, the YANG text will be difficult to write. I am hopeful that the protocol details will be more clear once persistent data vs. ephemeral data vs. operational data is sorted out. > Sue > > > Andy > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 3:05 PM > *To:* Susan Hares > *Cc:* i2rs@ietf.org; Alia Atlas > *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt > > > > Hi, > > > > I am still fairly confused how the running configuration interacts > > with ephemeral data, but I will wait to see some concrete solution > > proposals. > > > > [sue]: Hopefully this will come out of netconf. > > > > The proposal does not mention what changes would be required to > > YANG to add "config=3Dephermal". There are 1000s of lines > > of text that would be impacted by this change. This change > > might break a YANG 1.0 tool, which would violate the NETMOD charter > > for YANG 1.1. > > > > [Sue]: Do you have an alternate proposal. > > > > This solution does seem to suggest that I2RS can never alter any > > value that is config=3Dtrue. These nodes can only be changed by NETCONF. > > This of course means that no client priority or secondary identity > > could be supported for config=3Dtrue nodes. Ephemeral data cannot > > really rely on any local config, since any client can alter it at any tim= e. > > This might be fine, but I2RS clients need to be careful not to > > assume any particular running configuration in order to work. > > You cannot safely add an ephemeral leaf to a configuration container > > or list. > > [Sue]: You understand the meaning of ephemeral. The I2RS client will > > Have to set the configuration via a normal netconf configuration. > > > > > > It also means that I2RS can never be used to override a config=3Dtrue > > value (since the data models do not overlap). A special add-on I2RS > > module would be needed to define the specific I2RS override knobs. > > > > [yes =E2=80=93 this is correct]. > > > > sec 6.2 adds client priority to the NACM group list. > > Users can be in multiple groups, so you need to specify how > > the client priority is determined as the group membership > > configuration is changed. > > > > +--rw groups > > | +--rw group [name] > > | +--rw name group-name-type > > | +--rw user-name* user-name-type > > | +--rw i2rs:i2rs-priority i2rs-priority-type > > > > [Sue: Could you provide more details on this fact. I was concerned > because Martin indicated the group membership could be changed to the > highest group. Would it be better on the client? > > > Sec 6.3. shows the client setting its own priority. > This does not seem correct if the administrator is supposed to > set the client priorities. > > > > > i2rs:i2rs-secondary-identity=3D"user1" i2rs:i2rs-priority=3D"4= 7"> > > ... > > > > > > [Sue: It is the assumed the client is resetting its priority because the > administrator changed something.] > > > > Great questions =E2=80=93 keep asking more! > > > > Andy > > > > > > > > > > On Tue, Jun 23, 2015 at 11:37 AM, Susan Hares wrote: > > Andy: > > > > Thank you for the feedback on draft-ietf-i2rs-pehemeral-state-00.txt. > This document is now a WG document =E2=80=93 so suggestions on changing = the text > are welcome. It is a work-in-progress so I appreciate your help in > refining this draft. Please suggest alternate text for the draft. My > comments on individual points are below. > > > > At the front of this document are the top 10 requirements for the I2RS > protocol. All other details within this draft are to provide more detail > to these requirements, and do not dictate a solution to the NETCONF/NETMO= D > working group. I hope my message to netconf/netmod/I2rs further clarifie= s > this point. > > > > The I2RS 6/24/2015 interim will continue to discuss the I2RS requirement > on web-ex. Please join us at the interim and continue to discuss the > requirements on this mail list. > > > > Sue Hares > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Tuesday, June 23, 2015 2:09 PM > *To:* internet-drafts@ietf.org > *Cc:* i2rs@ietf.org; i-d-announce@ietf.org > *Subject:* Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt > > > > Hi, > > > > This draft seems to propose very specific solutions, not requirements. > > > > > > This text is in the section explaining why an ephemeral datastore won't > work: > > > > The most obvious disadvantage of such a fully separate datastore is > > that interaction with the network element's operational or > > configuration state becomes significantly more difficult. > > > > I don't see any evidence or examples in the draft to support this claim. > > > > > > [Sue: This is correct. The authors recorded what they heard at the I2RS > interims. If you would like to clarify this =E2=80=93 please do. I have= heard > this is implementation dependent. Is this true? > > > > The requirements do not make it clear how a YANG module is implemented > > by I2RS vs. implemented by NETCONF or RESTCONF. It is not clear at all > > how YANG data-def-stmts are handled correctly by each protocol. > > Perhaps you can provide some data model examples. > > > > [Sue: I have given the I2RS yang module list in the netconf announcement > for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB. These data > modules provide you with some examples, and I welcome a specific discussi= on > of these modules on the list or at the I2RS interim. > > > > Andy > > > > > > > > On Tue, Jun 23, 2015 at 9:52 AM, wrote: > > > 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 : I2RS Ephemeral State Requirements > Authors : Jeff Haas > Susan Hares > Filename : draft-ietf-i2rs-ephemeral-state-00.txt > Pages : 13 > Date : 2015-06-23 > > 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-ietf-i2rs-ephemeral-state/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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/ > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > --001a11c27cf0ead0de05193a28a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jun 23, 2015 at 1:29 PM, Susan Hares <shares@ndzh.com> wrote:

=C2=A0

We will look for concrete proposal in the NETCONF/NETMOD group= .


I doubt this will = work without direct involvement from an I2RS proponent
who really= plans to implement the protocol in their products.
I think about= 5 or 6 of us have 7 or 8 different solutions in mind ;-)
Otherwi= se you would have probably already seen a draft posted.


=C2=A0

The proposal for =E2=80=9Cconfig =3D ephemeral=E2=80=9D came out = of discussion with the netconf group.=C2=A0 Again, I hope there will be a c= oncrete proposal from that group. =C2=A0

=C2=A0



OK, then I will assume t= he text that looks like specific YANG or XML
is really just a sho= rthand for the concept.

The YANG syntax is the eas= iest part.
The text related to YANG validation, error handling, X= Path evaluation, etc.
is the hard part.=C2=A0 Without a clear con= sensus on the properties, the YANG text
will be difficult to writ= e.

I am hopeful that the protocol details will be = more clear once persistent data
vs. ephemeral data vs. operationa= l data is sorted out.


=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=

Sue

=C2=A0



Andy
=C2=A0

From:= i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy BiermanSent: Tuesday, June 23, 2015 3:05 PM
To: Susan Hares
= Cc: i2rs@ietf.org= ; Alia Atlas
Subject: Re: [i2rs] I-D Action: draft-ietf-i2rs-= ephemeral-state-00.txt

=C2=A0

Hi,

=C2=A0

I am still fairly confused how the running configuration interacts

with ephemeral data, but I w= ill wait to see some concrete solution

proposals.

=C2=A0

[sue]: Hopefully this will come out o= f netconf.

=C2=A0

= The proposal does not mention what changes would be required to

YANG to add "config=3Dephermal= ".=C2=A0 There are 1000s of lines

of text that would be impacted by this change.=C2=A0 This ch= ange

might break a YANG = 1.0 tool, which would violate the NETMOD charter

for YANG 1.1.

=C2=A0

[Sue]: Do you have an alternate propos= al.

=C2= =A0

This solution does seem to = suggest that I2RS can never alter any

value that is config=3Dtrue.=C2=A0 These nodes can only be c= hanged by NETCONF.

This = of course means that no client priority or secondary identity=

could be supported for config=3Dtrue = nodes.=C2=A0 Ephemeral data cannot

really rely on any local config, since any client can alter it a= t any time.

This might b= e fine, but I2RS clients need to be careful not to

<= div>

assume any particular running configuration in o= rder to work.

You cannot= safely add an ephemeral leaf to a configuration container

or list.

[Sue]: You understand the meaning of ep= hemeral.=C2=A0 The I2RS client will

Have to set the configuration via a nor= mal netconf configuration.

= =C2=A0

=C2=A0

= It also means that I2RS can never be used to override a config=3Dtrue

value (since the data models = do not overlap).=C2=A0 A special add-on I2RS

module would be needed to define the specific I2RS ove= rride knobs.

=C2=A0

[yes =E2=80=93 this is correct].

=

=C2=A0

sec 6.2 adds client priority to the NACM group list.

Users can be in multiple groups, so= you need to specify how

the client priority is determined as the group membership

configuration is changed.<= /p>

=C2=A0

=C2=A0=C2=A0 +--rw groups
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--rw group [name]<=
u>
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--rw name=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 group-name-type
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=
=A0=C2=A0 +--rw user-name*=C2=A0=C2=A0 user-name-type<=
/pre>
=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=

=C2=A0

[Sue: Could you provide more details on this fact.=C2=A0 I was = concerned because Martin indicated the group membership could be changed to= the highest group.=C2=A0 Would it be better on the client? <= /span>


Sec 6.3. shows the client settin= g its own priority.
This does not seem correct if the administrator is s= upposed to
set the client priorities.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 <foo xmlns:i2rs=3D"https://ietf.example.com/i2rs"<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 i2rs:i2rs-secondary-identity=3D"u=
ser1" 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=C2=A0=C2=A0=C2=A0=C2=A0 </foo>
<=
/div>
=C2=
=A0
[Sue=
: It is the assumed the client is resetting its priority because the admini=
strator changed something.]
=
=C2=A0
Great questions =E2=80=93 keep asking more=
! 
=C2=A0<=
u>
Andy
=C2=A0

=C2=A0

= =C2=A0

=C2= =A0

On Tue, Jun 23, 2015 at 11:37 AM,= Susan Hares <share= s@ndzh.com> wrote:

Andy:

=C2=A0

Thank you for the feedback on dra= ft-ietf-i2rs-pehemeral-state-00.txt.=C2=A0 =C2=A0This document is now a WG = document =E2=80=93 so suggestions on changing the text are welcome. =C2=A0= =C2=A0It is a work-in-progress so I appreciate your help in refining this d= raft.=C2=A0 Please suggest alternate text for the draft.=C2=A0 My comments = on individual points are below.

=C2=A0

At the front of this document are the= top 10 requirements for the I2RS protocol.=C2=A0 All other details within = this draft are to provide more detail to these requirements, and do not dic= tate a solution to the NETCONF/NETMOD working group.=C2=A0 I hope my messag= e to netconf/netmod/I2rs further clarifies this point.=

=C2=A0<= u>

The I2RS 6/24/2= 015 interim will continue to discuss the I2RS requirement on web-ex.=C2=A0 = Please join us at the interim and continue to discuss the requirements on t= his mail list.

=C2=A0

Sue Hares

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Tuesday, June 23, 2015= 2:09 PM
To: internet-drafts@ietf.org
Cc: i2rs@ietf.org; i-d-announce@ietf.org
Subject:<= /b> Re: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-00.txt=

=C2=A0

Hi,

=C2=A0

This draft seems to propose = very specific solutions, not requirements.

=C2=A0

=C2=A0

This text is in= the section explaining why an ephemeral datastore won't work:

=C2=A0

=C2=A0=C2=A0 The most obvious disadvantage of such a fully sep=
arate datastore is
=C2=A0=C2=A0 that interaction with the network element's operational=
 or
=C2=A0=C2=A0=
 configuration state becomes significantly more difficult.=

=C2=A0

I don't see any evidence or examples in the draft to support this clai= m.

=C2= =A0

=C2=A0

[Sue: This is correct.=C2=A0 The authors recorded what they heard = at the I2RS interims.=C2=A0 If you would like to clarify this =E2=80=93 ple= ase do.=C2=A0 I have heard this is implementation dependent.=C2=A0 Is this = true?

=C2=A0<= /u>

The requirements do not mak= e it clear how a YANG module is implemented

by I2RS vs. implemented by NETCONF or RESTCONF.=C2=A0 I= t is not clear at all

ho= w YANG data-def-stmts are handled correctly by each protocol.=

Perhaps you can provide some data mod= el examples.

=C2=A0

[Sue: I have given the I2RS yang module list in the netconf anno= uncement for the I2RS RIB, I2RS Topology drafts, and I2RS FB RIB.=C2=A0 =C2= =A0These data modules provide you with some examples, and I welcome a speci= fic discussion of these modules on the list or at the I2RS interim. =C2=A0<= /span>

=C2=A0

= Andy

=C2=A0

=C2=A0

=

=C2=A0

On Tue, Jun 23, 2015 at 9:52 AM, <internet-drafts@ietf.org> wrote:=


A New Internet-Draft is available fro= m the on-line Internet-Drafts directories.
=C2=A0This draft is a work it= em of the Interface to the Routing System Working Group of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : I2RS Ephemeral State Requirements
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jeff Haas
=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 Susan Ha= res
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : dr= aft-ietf-i2rs-ephemeral-state-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 13
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-06-23

Abstr= act:
=C2=A0 =C2=A0This document covers requests to the netmod and netcon= f Working
=C2=A0 =C2=A0Groups for functionality to support the ephemeral= state requirements
=C2=A0 =C2=A0to implement the I2RS architecture.
=

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/<= /a>

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-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.

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

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

=C2=A0

=C2=A0


--001a11c27cf0ead0de05193a28a1-- From nobody Wed Jun 24 06:24: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 5E87A1A9081 for ; Wed, 24 Jun 2015 06:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaAh3k06fqwq for ; Wed, 24 Jun 2015 06:24:28 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) (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 792341A907B for ; Wed, 24 Jun 2015 06:24:27 -0700 (PDT) Received: by lbbvz5 with SMTP id vz5so26285155lbb.0 for ; Wed, 24 Jun 2015 06:24:26 -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:date:message-id:subject:from:to :content-type; bh=te/FZr1CbwgQFvW6Q6bD1OVj0diKMH9RugGcReOVQnU=; b=NPvi5OgZY1GvvP13YTqGBSVRC6BED7fInRfYEr5BWK6AjHNyuE8nR/Uj9IavETXTOe +fhVB5iwK0vT7EWyHmGmlk64s6g/LDVQloCTBN6Bxmr2rjEV5gF0eXipHjHjb0AQD/vc TTvVS4EfbUw9ZGvdfNw5FzYCNUeQhRexJf5qncnXPmKyGigpXrOfKnfys5auCE9sZ8gR BFK/X7PFqDKxTRoVPOWKvPRVlvyUf8nIPam/Sem19PGc9QSwZWWOBQ9RZQKSk5EkMqnX fhakgcD2GlOvqcM+ss2E5KCJY4l4cqM+E+Ky4jBk2lXMPZak0RpYSQmiWFeSOiL0wfv+ W76w== X-Gm-Message-State: ALoCoQnE2YhcLbshnVWY3mqRqk8SIUE1vlQlc0vPr6k40u81semBXeL88hUoYoEucezRuPZjHJ3o MIME-Version: 1.0 X-Received: by 10.152.7.65 with SMTP id h1mr6656233laa.33.1435152265962; Wed, 24 Jun 2015 06:24:25 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 06:24:25 -0700 (PDT) Date: Wed, 24 Jun 2015 06:24:25 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" , "i2rs@ietf.org" Content-Type: multipart/mixed; boundary=001a11c27cf0031b750519436d7a Archived-At: Subject: [i2rs] extended datastores slide 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, 24 Jun 2015 13:24:30 -0000 --001a11c27cf0031b750519436d7a Content-Type: multipart/alternative; boundary=001a11c27cf0031b6f0519436d78 --001a11c27cf0031b6f0519436d78 Content-Type: text/plain; charset=UTF-8 Hi, I prepared 1 slide (based on Kent's slide). I am trying to understand the types of data and how they are identified in YANG and conceptually separated for protocol access. Andy --001a11c27cf0031b6f0519436d78 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I prepared 1 slide (based on Kent&#= 39;s slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated = for protocol access.



Andy

--001a11c27cf0031b6f0519436d78-- --001a11c27cf0031b750519436d7a Content-Type: application/pdf; name="extended_datastores.pdf" Content-Disposition: attachment; filename="extended_datastores.pdf" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ibasjxlw0 JVBERi0xLjQKJcOkw7zDtsOfCjIgMCBvYmoKPDwvTGVuZ3RoIDMgMCBSL0ZpbHRlci9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nL1YSW9cNwy+v1+hcwA/i6JWwBjAyyRAbq4H6CHoyW0SBDMt6h7y98tF 741m3uKlRmHYQ46oTyRFUqRtD+Zn97ex5sL2zqSCfTShBKKf/uh+/WD+7MDwz9O3zvKCOXQslITe G6Vl734AYUJXv3dfPwg4/xDCza7DQvLe0rG7383lR4L2Zvf1ysJm96Pb7rr7iXzow2s2QAHSIdjY o+5wxvOOL7zlAq6ss7i5cFfW27AhNhIRbbLZlrpQ+OtrkUV7Y29J4Hrz2+6znmZ775MNxvbRYXD0 mQFS5NMxht6TrrREbgrBj9zeeFLLGwyJ/u4NWtdyzb59973T1QGn5diliqt7DydcdTjdgcXCmmEh y1hTj4Dml0/iqp/0+5lu9Me76ftQL6FBXrVgKr9u08NL3I4ej1uJHkxwpfR5NGHkxj18QDVPEI70 0dm663DCvc3Z/0XLJTfP6b3k4iVLHqaJlzxlEDqgS6t5BFnzyG/ilb2zWyU+Un7cUtLEK7A2HRPl DC7nvhhMSNl8BncLwDiB8pEwnA2AzKcX5ZwHR+nucpDIqVzIEjneYss5LgzOF+WoEI1rnUfbSion mMQ1J7CrKupwYsPJquLKKYcT7rUB8/9bNg2adVtn5Fetfy6PAxj6jqPTW6FIxZQMJC0ELueRHmQZ lr/XfQMlmUsYKn1o6Fdn7Rt1mrpmXsuZPF3UeyZHM1A6OSqs6TypbjRHh9Tkpy1Qcm0CLUmi2bKW rj4gZb+LYZKu4CFYBAexAdZKkPQMhU/8hA4rtxBFlcTPLWd5JIBA5FK1iEgPvov+5PArSEDPNJSl XiFxCYTcPP26jzRrdzSXQhHoaRe/Uo5Kp9IO6bWKiV0rFKM+Ki3lcK80RJZw1J2AlHCIlXrsmm9Z UpoRpThTFQuj1RBiOgSWIA0waL66Sj3OhRKfNGg90gthNyIdGnop9FKTvYEkc+Xqc+E5HAaaPfE4 cKC2VM5GkaPdljULkWWVfuya70UaSuZ2stKezhxQIaLYVblQRI61AvJXNqqv0nN+OrOn4RbsFz0V 73DCzadfkNfM2UQv21mSXFO4S3pEuNFcDGAp+eB2KeQVDHKi485yOXJrSr/Xx3yjtnQjydW8kUgR J6UMQsz0CbZkBg+FL8fTE8BBkJyt9N7EFOk079Ql6qCRa3Zxk1dXK0rLsXME1amjj/Rrq+37aLoU CEu6T+WXrZkGARnEAwrmSdG5lku7pWIJ9m4sQLqXTA8BqMZ5wJptHEVcUzjaHrrxCH4DvE21a0MZ hjgR2AsySwGfz9wgV71OQSAuc2p0kDnK0R1IRhX65PdfgBrJuplHPk40UsBlJgbneWicTTWsvQiH iTJm5Jp9fC11teK0nPRNilud3nKvDaL30nemlq5aMNMNrdo0DSVXJAYmoUT1JFAkBa0n8oZrSWjT fwgrlDjwPXcaiLHXRwlPgwqpkkeDRWOPhgYZyiOdTj7CwFpYfoGJayTrTSCCOFEDC5EFvc262VuJ SQ2sVrJuJjOLBLGrAz2OZQ7YMLe54CIn0/mFGJrkmywtC+VUkAG+2j2iWTstm0kbEv4EBauF+I6a Dx4xYCvfIk8gR1++vDesE5c+F66wzcq5jDyJcQsjlNUGgmnIkqFKR5ZI3GmhlAEnD57S1ES0KyLP vhXK5ornqNnxFY9+eV304GAuwzQp9GwjoecNFjTc2rypeIcTbj6gC0cUujC8j8e75n+r3MnFbnWG lA9u7ixNg2Oryhdell5MRbdh5eYpb7TbhbsRFBC29RU9ufdZeB52JvPv8/Cex2O2yPN4LB2w7NAp +fTE2REhZekYqbug2swdqZN2XGiqINx5Vc5KOFVausjAqagdFnc7buy8TlZkB5TC31Q6aW+qXAra 6VbOsZxoBUlnyFyp2cDSc9WWkV4ejBTp0NBLjy2rAaE/Lx6A7OEhnLL2XjqAaMHgtep9vimgMUVl nokvKJMB6HjpXEfaYJIbX4dLfhKuU0AKH4baNuHDmbGOTE3y+RQ4QdY4Hf5Zc72srDga0A/j39HR XlwmnpOiCqFxNURGDuuKAnfzb1f03qxW6Mvtp4dgvv1jLndP3tz9Ze67fwG9sasrCmVuZHN0cmVh bQplbmRvYmoKCjMgMCBvYmoKMTU3MwplbmRvYmoKCjQgMCBvYmoKPDwvVHlwZS9YT2JqZWN0Ci9T dWJ0eXBlL0Zvcm0KL0JCb3hbIDM5NyA4IDM5NyA1ODcuMSBdCi9Hcm91cDw8L1MvVHJhbnNwYXJl bmN5L0NTL0RldmljZVJHQi9LIHRydWU+PgovTGVuZ3RoIDgKL0ZpbHRlci9GbGF0ZURlY29kZQo+ PgpzdHJlYW0KeJwDAAAAAAEKZW5kc3RyZWFtCmVuZG9iagoKNSAwIG9iago8PC9DQSAwLjUKICAg L2NhIDAuNQo+PgplbmRvYmoKCjcgMCBvYmoKPDwvTGVuZ3RoIDggMCBSL0ZpbHRlci9GbGF0ZURl Y29kZS9MZW5ndGgxIDU4Mjg+PgpzdHJlYW0KeJzlV21sW9UZfs+9/mrTxk4pUZBLfbzblGRO7LQB mnahcRLbSZqUOB9mdspa39g3sUtiW/ZNSjuqZkhA5dLRwVZgVGKbtA1tSL1u2ZROHQ0a0zRpDPZj PxgEIo1/NGvXrWgC2uw9x9dpElqQxqT92E187/M+7+d5zzn2uWp2QoE1MAUieGPjcmY9IYDXHwDI utikShfavBTxHIBQOZIZHa9pfOdvAOK/AMzG0bGDI7/5809rAcqYTzihyPGWJqcH5TDK9yaQ6Lx+ 0IzyCZQ3JcbVh31w0YDyKyhbxtIxuQ7qEJadx5tpXH44o5oOM/3rKNOUPK7sVn74XZQ/QPOeTDqn xmHTAsD6BqbPZJXM1aFnLSgHsT4VOQK8fBwREBOX/88v43G4HTqN94EVMvy+7BJfhjvYc+Hi8vv1 noWP/5tVWIqP5+An8Aoch7fhG7oiAEFIwgQyS6/X4E/IsisIQ/AzyN8i7MswjfqiXRSegudvYReE Z+Es/G5ZliCMwzexll/A22QL/B6XShquEAt8C36LUa8gt/tmoYRyvI1wOLKEfQdeEI7BLgHXKVaB GsEj2OB1OEX2YmQVx3l8ccTNnwn6BBzG+wAkYBIxv4z3ffoXWLXwDxzVYdgFj0IrjC3xOE9eFFfj /A3Ci9jT1zjnKSnNneJ+4ZeCcO0ZFL4Do/iRCY5dOC62gs9YQXD3ef2RcGhwoL8v2Hv/7p7uXV2d HQG/r72t1duy877mr+3Y3rTt3nu2NHjc9XU1d22u3iR9xemoWl9hs5avLVu9ymI2GQ2iQKDOLwWi VNsc1Qybpc7OeiZLMhLyEiKqUaQCy200GuVmdLmlFy1HVlh6i5beRUtio83QXF9H/RLV3vBJdJoM 9YURH/dJEarNc7ybY8NmLqxFwelED+qvSvioRqLUrwUmE3l/1IfxCmWr26V2ZXV9HRRWlyEsQ6TV SJkCqdlJOBBq/DsKAljWsrSaWO2X41qwL+z32Z3OSH1dl1Yu+bgK2nlIzdSumXlImmSlwzFaqJvJ Pzltg+Goa01cissPhjVRRt+86M/nn9AqXFqt5NNqD31QhSNXtDrJ59dcLGp3/2Ke7hspiWastkk0 fxVwONL8xeWMrDOmattVYDCA7c3nAxIN5KN5eXphaliiNilfWLMmn/FjhyEYRq/phV8ds2uBJyOa LZogO/TBBvq7tdv69oQ1oTpAEzIy+N8iOZvszopIySZ4KzVgI7Ad2FOnkw382LQXhlHQpvrCRZnC sP0MeD2uiCZEmWampLk9xDRTJc2ie1TC2eweCOc1Q3VXXPJjj4/J2tQwrqf9bCokm1b+kd0p5ddV 0O2eCLelWFVXPEk142ZsC3otdcCVwlzyNi6Uf1R8zNsxweaKdXS7hGFYHL/kj+r/k4kqDEDr67RO V3HqB8Oa14fAK+tz5C80eNBDjuIUJX18+jSPlNHWS22L88nK8icHwtxFd9PWt2sQjelemsfvY5mp Px/1FUtgsaS+8DloXJgr3E3tZxvhboj4mHFlO66rzf58OD6iOaL2OO60ERq2OzVvBCc4IoWVCFto 2KHaOUzn5Bk1oX0w3D0gdfcNhZv0QooKFs5Q7V8RRgrbi2FwyWmWagsNC3YxgoY2JGgAgdTWjHfN XG3Bjw0bzlm2VNuaaZjYoWSNZWi11K/4dDsmLwtqZMupvbMUzcREjNPeaXdGnMWrvk5ANdUTo4eF NbWzpBKr8ZsAOQHDcIr1soqteRqWFCkiJajmDYbZ2Fh7eJf1ZvCe63M1uExa0ixsEzhRXRJYM7WA y760uVoHlxfFzhXqrpKa5i1S90CeBZf0gICVd2nAlrC3qcLOdz/bz1JAxk2MO5rv53zB62V7OcG2 bV7qiuelgXAzt8ZvkMP2QyzXOugm3YNt9XX4ZdZWkMjRvoKXHB0YCp+z4ZHq6GD4jECE9mhbpLAJ deFzFH8rOCswlpFMoExgkfpRsHB7+zkvwBTXGjjB5dg0Ac5ZShyB2LRQ5GwlTkDOUOS8nGMXzlJV AnuM399+Gmfz80gkkY9G2BqHSuwI/hONSDuxO9LOAhFMa7TVktKmlUltjG9hfEuRNzHejCuDVJL6 ukN5m1+6WlXPf7rBh7e4MYQnYDO4CwQ8zWfMBsv81oLJ+G7zGVFACAWR0UZGnzGbVn3afIYwvrHC WVHtrHD6BHp9E3nuesIY+vjnPsMbUDx5kooPn7n26D37rM1XwVE8A/0xP7vsTMozswOSoBOoNTuv ++HriyYrz7CCcBF8unnx+Ez4OEoxBLDhWQDPRYYy03YcFWM3kAcW40QXYxK0jOpYwNFndCyCHQ7o 2IA2T+vYCOXwIx2b8Cyp6dgMh+CCji2wnmzX8SooJ7t1XIY17Fk8nbtJKf5aSJMf67gcdgrrMTsx rEJpRujXMQEqrtOxAOXiVh2LcK/o1bEBbSZ1bIQN4kkdm2CjeEbHZvin+JaOLVBjeF3Hq2CD4aKO y6DJaNHxGnjQWIq/Ft4zntJxOTxiOtSezhzMJkcTKq2J1dKtDQ3baL8Sp52yWke7UjE3bR0bo9wg R7NKTslOKnE37elq8/e3Dnb13k+TOTwWqVk5rozL2YdoemS5f09yWMnKajKdogNKNjnSr4xOjMnZ 1lxMScWVLK2nKy1Wyg8o2RwTtrgbtrkbb2hXGn9BIVj9aDKnKlkkkykacg+4aVBWlZRK5VScDi46 9o6MJGMKJ2NKVpXROK0msNT9E9lkLp6MsWw59+II2tPZTFovSVUmFbpbVlUll04lVDWzw+M5cOCA W9aNY2jrjqXHPZ+nUw9mlLiSS46mcOTuhDo+1oMFpXJY+ATPiNUs7VogncLJGSva1NGcolAWPofx R5Q4lpbJpvcrMdWdzo56DiQfSnqK8ZKpUc+NMCyKnufLeUM7pHEPHoQsvv2M4tuAChRqIAa1+NwK Dfi3DVE/KBDHZyfIaFGHqAtSaOVGxN4SxvB5I0KOSwo+FXxOcl9m2YNebeDHaK0wiLgX7kc2ye1l /KhoLaOtgu9JMuKHkEvjm83n5e9B/2Geh2mSaJ9C7QBnkujLPEfxbW+MR2zFXDFkUjxLFi3reV2f H+OL9A9wlFvUbMG6WN/c0HhT3y+K/OU6Uuz9KI+i8thFyySPHUKLAW4V5J6sFyrPluJWgzfJ2IsZ R9Cfde6GZYzHVlEuRk4jTuhd3Y8dz/IK4tyvNLYcZv7sHLA1mMVVmF7RJVbdJM+5m/MqX1NMl+BS Bnbgr44HfzfYnxttlkeO6XHdHI2j5X/qp+IOyfA+KnyeR9G2OOduHnMc11eP3qEUX/esQxNLxljs za3WWoA/iztnbFkcNrPsyXxL1ef0+kd4nmLXMnhPY98V3m03Z0f5GJM4h0lES+tjMzaqcyurKdWy fDz/y9xi8RCx4MSMN7kKq6KvEjP+Yrfw+wVi8EbI3DXy5jVCr5Ejn5DgJ2Tqyokrwt8v1zpOX75w Wei9tO/S6UtiwyVivUQsMG+bD85H5zPzP5g3rbZeJGvgQ1Lx17kmx/uNs6H3Gt8NwSxpDs5OzWqz 4vTCjHdo1lIWmCVi6F2x0mGboTMNM5mZqZm3ZuZmLs9Ypl498arw6/Meh/W847zgONt79shZMfoS sb7keEkIvhB9QThxilhPOU55Tonff97teL5jo+PZk3c55k5ePimw8PecXFsR2Pc9cuTpp54WMo9P PX7icXHqsROPCacnL0wKuWCtI51yOVIdX3Xc0VgVMjeKIZO44GCevuHqmkB0n9exD432DDU4hjpq Hbc1rgsZsVgDGlpFh9gi9opp8Snxgmi29Ac3OvrwMxe8HBSsvY5eTy+OcM4rdzsx0K7MrqldYleg 1tHZ0eSwdjg6PB1vdrzfcanDtK+DvIj/gdOBCwHRG6j1BLyBjc7Ahk57qLLx9pCt0RoSCIRII4Q8 1gWrYLXusx6xilZoAWGqkhjJNDlRGBxwubqnzQv4pm8J7tHIUa16gN29fUOa6agGoaE94QIh3448 dvw4tN3ZrW0dCGvROyPdWhyBl4EpBLY7C5XQFsnlVBe7iMuFcALv4JpAam+uSIKrpAZXjuRykMsR F9NxiAzkXIxmDPMh6Lk3B+zGtC5uxVAuV7X338ZwJH8KZW5kc3RyZWFtCmVuZG9iagoKOCAwIG9i agozMDgzCmVuZG9iagoKOSAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0JB QUFBQStMaWJlcmF0aW9uU2VyaWYKL0ZsYWdzIDQKL0ZvbnRCQm94Wy0xNzYgLTMwMyAxMDA1IDk4 MV0vSXRhbGljQW5nbGUgMAovQXNjZW50IDg5MQovRGVzY2VudCAtMjE2Ci9DYXBIZWlnaHQgOTgx Ci9TdGVtViA4MAovRm9udEZpbGUyIDcgMCBSCj4+CmVuZG9iagoKMTAgMCBvYmoKPDwvTGVuZ3Ro IDIyMS9GaWx0ZXIvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJxdkEFPxCAQhe/8ijnuHjbQnpsmZs0m Pegaqz+AwrSS2IFM6aH/3ilWTTxA8njvgzfoa/fYUcj6haPrMcMYyDMucWWHMOAUSFU1+ODyocru ZpuUFrbfloxzR2NsGqVfxVsyb3B68HHAs9J39siBJji9X3vR/ZrSJ85IGYxqW/A4yj1PNj3bGXWh Lp0XO+TtIshf4G1LCHXR1XcVFz0uyTpkSxOqxpgWmtutVUj+n3cQw+g+LEuykqQxtSnZ43Sn9rF+ 2oBbmaVJmb1U2B8PhL/fk2LaqbK+AH1ZbXUKZW5kc3RyZWFtCmVuZG9iagoKMTEgMCBvYmoKPDwv VHlwZS9Gb250L1N1YnR5cGUvVHJ1ZVR5cGUvQmFzZUZvbnQvQkFBQUFBK0xpYmVyYXRpb25TZXJp ZgovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDEKL1dpZHRoc1szNjUgMjUwIF0KL0ZvbnREZXNjcmlw dG9yIDkgMCBSCi9Ub1VuaWNvZGUgMTAgMCBSCj4+CmVuZG9iagoKMTIgMCBvYmoKPDwvTGVuZ3Ro IDEzIDAgUi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxNTEyMD4+CnN0cmVhbQp4nN16C1RU V7Lorn3O6e5D0/TpBpqfTZ+m+UkjjbQov4ajQNMEP42CAgYBoUH8AAIa0SRiYoyiCSTjNXFMRnMn k4n52RoTzc1kwp2Xm0xmkokvk5l38zIzcu9ksl4mcfTmZvJuxgCv9ukGP/m8td59a721XkOfU7t2 7aratWvvqtow2L8tQCLJMOGI0r6lre/g1o3DhJC3CAFz+/ZB+XLV91MQniCEWjr7urZkuj/4CyHc fxCiFbo2D3UeezZtNyF6HOI4sSHQ1hGVP+EmJOcEIhZuQETP1F1abP8ztlM3bBnccTSqZjO2v8L2 7Zt729s6739iiBDXDmwrW9p29BVq5nHYPo9tuadtSyD/M/ohtnG8TunrHRg8QrKmCSmIZ/19/YG+ het+XortAtTvN4gD/GGfSAQ1rE05XtBodWKEPtIQZZRM5uiYWEtcfEJi0hxrMvn//yO8JbxF7hD2 kFgypD5v+PBFJIbcRsj0p6x17Tm15v+uFrrQ6yx5hZwiJ27o2k/uxOczN+BeJf+FPK1Cx8h938H2 JfJUGDpMjpJ7v5VuI7kb+TyO8q99WhE7RB5GyefJj9FRUsCNUjeFez8gb34zK/gXeJM8SJ5EygfJ OXweQ8/bRT8jD9KVpIf+N24PuYscwDkeh24yivSt5HFYS9YhNvRZRwKk9yamI2SM/IjsxF04+xH2 TP87MXz1Y9T8API5QrrJ1utGPAlfshdnQ92fIy+ouD0znVoft5G+SOnk97DxAOnCbxu8j3rexy0m FYIJTuJmq2xsqK9btbLWv2L5sqU1t1T7qryVFeVLFitlpZ6S4qLCgkUL8+fnunLmZWdmpKelOlLs tvgYk2SMMugjRJ1WI/AcBZJd6fC2ysH01iCf7vD55rG2ow0RbdchWoMyorw30gTlVpVMvpFSQcrO myiVEKUySwmSXEJK5mXLlQ45+HaFQz4PTbUNCN9X4WiUg5dUeJkK8+lqw4ANux1HyJXxGyrkILTK lUHv9g0jla0VyO+0PqLcUR6ImJdNTkfoEdQjFMx09J2GzFJQAZpZWXSaEp2BiQ1yaZVtHUF/bUNl RZLd3jgvuzoY5ahQu0i5yjKoKQ9qVZZyN1OdHJRPZ4+PHDovkfWtzsgOR0fbrQ1Brg3HjnCVIyP3 Bk3O4FxHRXDuzg/jceaBYLajojLoZFxrVs7KqbkmEoJCmuSQR/5KcDqOS5/eiGkLYzRp0l8JA71o 3pERr0P2jrSOtJ2fHl7vkCXHyOnIyJG+SrQw8TfgqPPT/3AwKeg91BiUWjdAUXiy3pU1wejatQ1B muaVN7QhBn/LHPaCJLupcYbG/23dBA2B5kCb2u1s4gfPK2Q9NoLDtQ2htkzWJ50hisvZGKStrGd8 pie2nvUMz/TMDm914GrWrGoYCfJp1R2OSrTxwbbg8Hr0p41sKRxSMOqLJLtjxGySC12NKq2MWlV3 dMtBIR3NgqOuH4CewoaMSGoj6ovQ61ISCkg3meVCB7JhfCodla3h3+0b4pGBPC876HOGlr6uIahU IKC0hdeo8nSuC0e0teISdVeoyxd0OfqCMY4ls+vJ1KrsXtWgDgkPC8aUB0lre3hU0FVZwSTLlSOt FSEVGC9HbcNLxD09cXqBnPS8mywgjRWM2FKOfpVeOdLQ0Rm0tSZ14E7rlBuS7EGlERe40dEQaGSO hhaaO4Hi7KrEIC2va6hZ5aipbWooCCsS6mDs+LTKm9g4GpJCbNDlgro0ndxAk7hGJJQQIXsRcCwp wWdQm6bDr4QGV7HMVZeUyA2QRGaoUY3gXLkyUBGmY+0bmArMncp9M9w0rIl8yn1J9kZ76DMvm2K3 HBaMI3TMqL6ZLi4NTwLEUWSjopgt45nPyw2OgKPRsUEOKv4GNjdmHtXKYWOoNg+vVd0NreuMhWYi duyeaTBjBr3OpOuNG6xS27NN303d1TPd8ojOUbNqhDF3hBkS1Lw6SJgLKwWmJHX3s/3s8LbhJsYd re7nkdOKwvbyBrZtRxzVHSOOVQ0lKjWeIHck7WSyzKQGauqWzMvGw2zJaQfsrz2twP5VTQ0vSZhS 7a9rOEOBlrcuaTydin0NL8kYK1QsZViGZA2ZNRinldjQqfRJLymEDKu9vIpQ2+3ngag43QwOSPt5 GsJJMziKOD6EU1Qc++AqxW9AG+P5XSl3sPW5vXHDSGsj83FiQYvgLwTBUYrWcZSeBqqJDEY4AkuC escShi9j+LIQXsPwWvQMsMC87J0jUqXjr/HzWLCkpAIfHUI9ZsBaknMaiKvkjJbXXco7rRF+V3KG owiS0xxDCwx9RqsRvyo5AwzvNtlNaXaTvYLKU6nw8NQGof5vT1fwb7NEAXMEwk9hzqUny17QclqO RJyfHlfStHpfRIRBEJsIkYhCOC2RDaBr2S2AIIh8C3BiCzGTsktll8yFrq2XoNm1rvlSnsntcpoL 8Qian4tCY+3h75P8vK8e5PK++hX3kLDnkamS70/FPsJkx2Fu8GfM7vT0t4rvMIV9FO7TPaqjQzq4 S/Oghm7XwH3kUUKHCCyKuC2CzomAnTxE88DFww7YDw8DH6e9V/uQltPoIkDL86IoCeenryjFgiiI HNFLc/WFesrrY1CC/iP9F3ruNT0c0T+hf1HP7dWDRp+u9+o79fv0DPc6Uog6PU7/hXibT085xkkv ciByhRyN4AzovcrgxY992w3QYYDVBqgwwEIDpBrAYgDeAB8ZvjDQdw0wboAzBthrOGx43MB9G/Eb XxjgQwP81gCvGeBFAzxuAI3Ba1ht2Gc4YnjC8Lrht4aPDOIRBKiBrcjL58Z9exmjTsN2A4fM0g0L DRQZPcQAhnzC8CJSMyXEj5h42M6E1hk6DNz1gr8ud7sqk+tgGlgM6aoWQtc1bUK66I4a3jfQb5zL b1Wp3GuMAdPGa+AXdar6MLyg6r/Qs8RXaIAUAwAxSAb6ObPTBcOEgTtrgGHDmOGEgRs0QKsB6gyg GGCBAdDj1KEp5njfCQNQNs5v6DMwao02gue1gH6vMRIaS8rcZW5zXKEJ3OuaW5qdW2c//S39/c7+ dc3NzbMY1gh9bkI5m7f2q59rFNdTOdHH+wvQxdepqH6EVWcvKEDJee75uaS5GVquH2kXwSGCW/3l 7FO/n/rgZ7Bn6oE3IAoi35x6APbBT6YqaDaNmloLP5r8fPJdNXkntukrNEvIJhayS1mTGQXdUUNR B6K4TAN0G4YMBwzcQR54WTT4NvO384/wz/A8tiJ9vZbdFmqJNFg4ySvqRgUggiTIgiLwWmE4Howa f2RZBESIxmg/Z2F79+1m96U8detudbsvxeW5mnEOzmZw4pybt6ZFgSMl3+TIdy9yx7pjHaYYiztv 4SKaNbe+4J/v2Ju/4+c/d5clzrfq9Ia/0nfv/uyzuyfrl5fpNKHzas30p3w8v5zMIWlkk5LT5Njo oE3JG5NpPRfAVasWxaQqxWaFMStYM4bTSJXNBKbcjPGMCxlcBlv16GSHT6cTiD8tTZD9FknwR1lm DpxLpkIXOLe68MhJlH7XvDXxUp7r0vzcZrYAMcmUqRkXxTlSqGlBKbaSqRUycnA2UVQLMY7qfv+2 +xJ+YPJ0Ht185erSvcGO/ed6Xf9gHLt3XntdEQ//s360q3Cdb968tdUuSIbEh3+9t7jh2Ls740ee ftR6y+716hrtx7PrLzi/NLLlJZIyPaGk4pGZ5lX8BI6TaTRAxjBRZzORwY9ngDEDhjNAnZgcHedL iPTiKcEcOhe3wBWDoDMkaPw2KdpowOq3LK+sDBeGrculPHTKrf3hWc7PddpNC3Iom0msycHADHcy F+su5dgsY01cYdyC+jKlqzrzLFAKTwHlKJdYunKjt+muugz63IqNi5Pm1d9RO3kftyqlpjxXK2QX Fse4luZbs299oGPSFVq71dOfcpexIrcRN/PA+pRACm3K25hHC6Ea6MIIbwQV+QR+iD/A8xqtRbtd u0/LR3uVLDJqvmym5vxhucqmAU1f/lg+teXDdD6M50/k04RYM9G7/DqJpIU8MI/9lgHbYriWbJJ5 eWyWJLR9VA+kJsmeZ4lzL8iBBfkmtwnXN86Rw+WHFrqU5oftweXn/Wjn2/8I9+96PI8CqPN/hnIc nfzvc0pbK6u2VKen37LJu6RVsT23oQliIJ4ubFof4XRlifDDq9EZvhKnGJGWm58IfX0nunJzup7Y MXB8vTOn84eqTTBOCgGMk5EkgXQo3pPxsCsenomDpDhnXHHcrjj+pARJklMqlnZJ/C4jHOVgCEvP JsWFp1jSsJIEMU1EI2kUDafVRLdouZgWTSiAsnW+1IyTVxd49uyAGIrTx/CZx1vMWjZJBpdSIbDx /NUHJv8N3v0hRL/eO77y8K92Tf0bFPW+MrKcvhOc+vcXmoU9tSenvjo7+su7PFdP++5/b2Y/DqC/ 5pHF5DElb8hzwEOHIg9EUpqJB0mEkChQZ7xo8glzYufQtLRkr5Ij9hbsLhgt4ArKh2OqYpnrxsTO 8cXGllXZOOByy8fL6YlyKFd9GjervTbTUlgrionulhhwxYzG0JgYoz9RynH7SXix3a7mrSa2f3HW 6Ne45niazq57HqYNeAY7cfWFlPR83LplMLO62gzm4pbY8CEUyzwDnd8RxWWgTTygjeJiYyzwgx8+ Xnv3k2v+fU7RmuIFdaXpmp9EFHQd63nrV1nFxuSolPJ0d3VOPKexVt66zbF6T33WPy25rSm/JeaZ I5sOLE+mfHH5uqIkY0a526RsWu58+fRUjr+W5/p0uqRFtQsX1BXL95atH8xv5MGU11Td0MrOgULc Ky/yNWQReUWpH8zZm0N7Y3fHjsZymyyQthCykiB2AQg0llJ9clIyTa12OIgPz4DcaDoWfSI6GM1F Fw7rqyOUhGTMuLJ9K6wtVirjodhaOF5IhwuhkNk3KyPLV1YIUiFEZwtz/TJJhbHUK6k0NVWWovxC q75PT4f1oNcLaGlmZelS+IURCtTIhq1Za88emHhiAnswd4uiqkkXJcPMtsrAbbZgIZo9TpuDp6km lu29ZIF7sbjvh93rHupfZj4eNzZc1ObNyFm5zbt4uEv59S+e//WcvxdzK+pzdg46l21e7Gyqrymw g3PpbbVOq9K91LamVspYnDu/LMsWbcqq7Fx2+NidB2OyCh3GW2qyCzOskj7B4VrSMHsO8Vb02SiS QgaV4iH5gEwH5+ydQ7db9lnokPmAmR6JfCKS8pExkVQvJolULyQJmNjHUKolVcqYEYypw7mpkKo6 L/roxVRIqLLpQBfjj5CSw2EQdyBuQOdWZhm2Ba9Ff5BUm+TjCZRMtTMHb/jg4a1/+8vWM7sWw5/u PLet4JWMms0Vlb3L52Yv6y6t7FueRZOnPpz6c8WhX4/SXO+hdw/d+fj6jLntj++680frMzPWPxGO IXQ/zs9GSpVMKTY3lsbG2iNt3nF2PyyRXDJBrhBBRxIyoy0YMsyS1siiQ1mZ+21nODpgxt3Mku0b IoElLjYU7WJN94fCAMcBH+0s8hdaMvXm3OTSNYsSudKUqiVFcXHFpYUxpWuLrVruR4JQ0H6gdvIt Zvu9U2vQ9stIOikihxWpu2CogHZnDWXRfalH0O/OY8SL1kb4qm2NNlqtbdTSfdwRjuXME0oZ4tH6 JzDelQzPn2P0EkmScqUrEq+TgiVQVgJ9JWMl1FYC0yUwXjJRQudk+1Mki9GYpFvoF0JnhRoBWWDo 71dLi7yZ1XGqidqMw6ZnOHDWXw+FX1+szOajfYPP5QgA4eDwHFqF4xOUlYGyvqPNma/EF6+/pWTj ipz06s3emvbieJqy68KR+oYOKucWW6caBU2GrzhL5FLdRYkLql2x/gfe3tPxyOaClNaT97JAUdRz nK3p/SwvwNhpZ3mBDt2O5QV6zAsi4XjkdCSNdAwTx7jjgmPCwY87wOiAYQc4ZvKCOfHe8QQgCVJC bsJEwpUEQZeQSBL0scTsFyTVLu6yb84LYCYFcFyfIGC4ZDmPJ9lb11G64Z5l1hdMuQ1eNT84i6kB cHsWLcuLKwgcqpt00ecqN1Q6cup21EzeJbw1dad9SUGGdibX0TjQT4vpz14iWdMTz+v0Ppmt9DQC KcVeQgw53vddX7roiy6Y62p0HXBxGhc84XrR9VvXRy7+gAu2u6DRBRqXxeV1cVoX5j+vh8qNhaEa QWe46oE3Pe97PvZwL3vgqAcOeqDbM+Shaz1Q7QGnp9hDv/TAJx543wO/9MAr14gASeZ6Cj00yQOi B37xieeqh3ZjgDvqecnzpkfA7mXXKEJMmCg6K+gOD6CEGs9azyYPb/MAz0R84qGnPK96KPbv9tzQ rffA96cZG2UaLnoA2ZxibI556G6mzCYPXeGBYg+kqqQobZboGOM16qEdHqjxQBljC0aPzUNDRLs8 Bz1Pe1728L3q+JCojS97mDKcKgNUCYD8cSpX2aDLbB6/ZLpCh+cwmyJTlcMpfM4GPO35wMPhoE0e WKAOMnqg8GVEXvVwJzwwyIaE5saFxDFZ2Pc4I2boXR4eGV3wAG31jHlOeMY9PErP9YDLA0SJ9oAu Jd+fKYXTV1cof1UTWLaDQ2dpi1pE3VhbzZRe34i9rufm7pYbum+o1GaHhnaIa90sVi0aCll18x0J NCaZ37CJOIL58aLCWxc7nr+WUscX1LQpu0bncPEl/g5l5W1LU8/MUH1Xkr1+07VUO0TnrLtz1eR9 uMdGcKOV4rnBkV5lAcdCwIWZKHCF8DoyIVwR6EUBgsK4QI8L0CcMC9Qo2AR6RQDEC+wISUpJ860Q YDrUPS5cECYEJMGSW40bwKzhnDEdM1L/JRY83KaRs8Jbf1vA9vo9mM98whdhXTOkVB7hINGeZS+y cwlRXsWlH9XTV/Uwqj+un9Zz+oxh8F5MvZxKSaqUmovpCK9LDYYquGDGlQw6nQF94ZrHwGoe9BBL dGwkMc4UOKzOVNUIJSX9iZfCRbRpJre/Lt93sIIOY7EJir6rxuGLJlfOLAAd+OrZm6ucsQD9ryy+ HcDJelR7a8mAYuC0eIrxEp/Lczpezbhi4308rxOnRZgQ4aIIQXFcpMdF6BOHRWoTgYhwRe0QGbmJ WV4ExAtGPpasQotjZoEWv2bv/n6W+jrXsaJ7fm50vjuWw+kdOHv2rCA/88zfJviiq6+H856pNdxl zCnnk0ryvuLbOX9kPmU1Fg2UQn1kIJI2FW0souncQo6mm2GuHcS4hLihuANxvMZqsW637rPyosur 5KXkRsHuqItRNKpqWONVPaQ2bo5PEEqqjIkQkShXKVX0nSogVXLVWFWwivdfrILxKlhRBcNVJ6qo scpVRS9UXWEQ6OYaUxbhHjcu9sdaRH++BtKxxCNJuJjNzZfCtRzb7+p82ZvF7dmMM1zYXbdf4bps 0wMzy6sW7KzcK6WL3JjUm2I00TfFcpraPNapRL1g3tXh6fCm05ji+j5f1/eanc62Y70DJ3Ow6OPp 08w3LmbP93ctrGxfbLMp6ysWdq3Mm1qTXrW+JLGmNqVmx+rn5tYUOSpH3r73rgsPLOtuSyhdlMmJ zpLqjK/+6Y9/4l7f+lhnbm7XY33bjq/Pyun4QWhteKwDV2IdqCUxYFZ+1Um3032U64zeHr0vmuuG ITgAXHfMUMyBGG5Ac7eGBjRwu3BIoBsF2ImbnBaSRtJNuG3cPRxdyK3mOjmuiQcfD/VaqNJCNOUg hsRq0jT5Gk6jgY80X2hoopAlFAmcKMDHwpcC1QgGA59IsjAz40QCH5MvUS9JK2tztZysBa3WEsul cfkcp+HgI+4L3B2n+Fd5yvstQQvNtbRaxizjlisWwWUBoC0x0dHbsUQVOJ5d6GKC0VzocodyL1ez G1eTpZhbGWAu9LjcDFDhQvy9rlydufHi7JyDXXflcBlRnJaz86OPTd7596/TsvfpwsnnJKvFCDQq zmo8S43wyFSHsOdvu3maubJ8niDkVKzMnJqPZxDWqtwvMN/IINuU2iEJhuKgPQ3aOZC9NpvOewL3 nDiXVNmiIdrhT7TJu+VR+aLMy3KiJOv6dMO6C7oJnUB0kq5VbY4jQqvTsRsk21xoJqFClBVIkpr7 m9x3uLbGIzJcf99wh6T6JM/CAlZBalYN0UlK97LWPcYXxZKuw227z/TmpS5u6OovWnt/l2J4Kaq/ e1mXkkRTmh/ZWrphc2T57esKVz/09o4tP76j3h2Xt2Z7RVTTRnfXI6G7PsywuC/xvJXoWmWRer9y FGAh8RK6jxwhtMh4i5F+3wjdxiHjASMuaiVH/w6r7y7uNu5ejouSDCYfzy6qSxHAM0mkRklySrsk yksxoUeFVCftlQ5Lr0nvSboPJLjWFpIk4CXQSRxlLKb1dC2lWVRvTjKrjxrzWvNB8zHzL80fmHXT ZnjN/J6ZnjDDXvNhM201Q4W5zkxlM/DmGDN9Y+IaAUOwTkaomQFYpyaJdcIHjBSOMU6wlvGBEP6h r0kNvTiku1nexNf1mRHLd12vAKPSfZvEED4kVmkPCdYsul4FTZkZvkPmDTrd3En9ZnCZgZglM9Ua qVGE0E21mha13HADHc5lbr6kvvnK+jrSUJvFzwJ3KNUJX0mzXYoVgRMlbFVvcpu32nFPRidzcaXc omg3Dfxm6rbxv2ijY0waTXRMrO6LVzFqKpayirLY2LIlZRb6s5Bv5mBIPMvOOnhPmRZFeFN8X/xS 5F4WoVpsFIfEAyJfzPZigki/EOGo+KZID4ba1WK3yL/xvvixSH8pwosizMUB3TjgqCgkiaARIUGc q/I4Kp5ErtqPkTH9QISTIhwRoRBp6TwRQC/CQ5vEXeJB8WnxZfET8aqorRMR6xSLmR5XRfq4CMVi DZJwqSIcFI8h2S8RL+wWga4QW0SaKwLavesd8aJIgwxm2FGRx+B9XDwlMjzfJ0KLCIoav21iGRL0 isex47KoxTC/6LIIw0qzOCZeELleEfwiuNT4f0GEUyKMidAr7hapJMqiIvpFPpQyvMoYtuKgEyJf JoKsqqHlBD4KmqhCtVF92hPaIDuxh7VUy2KzEWOzVqaAQaZF4ABPY/UWuPktLPWckBgvLZv8MK/l hkx5Ngme9aJ1s+l2qNUy4yfX0uUQ6fxcwDTXnm+PpRd+OjWH38f/6WoS/6dHwufS7qkG+gPMjyxk iTLvXgPcK0JDDDRQMMVHmXwCe0gaSdIMa6hG/xlLVGXMpaQkgbBEEw/Vt5oL8lQvxE/0TDSfSeZ2 ZzUdantu3YEGp7PhwLrn2g41ZdGYg1N//l139+8/mTp4cOpThH7358lDqi6RqItT1cWnGPYbYL8I a2JgDepyfvp/PM/UwfdZVSN2jkk2zShqRT4b1YNeIkJSSKPJ6zVitwdaRymXP1MBUOc3qCQdmmQq /e5TptInv2cqTR0ks/fBG3BvmEgyeVcpPWmAkZjvxzwVwx22wjbrPVb6HIFHCdxODhF6C2kiGwnH nQDoh7vgQeBoO4AC4AZIA+Ck89N9yhpTdZ80LI1JXJ3UIdElElCH5JYoSFKCuUmvJ8SUa1JMraYx 0wmTxqTIY/IJmUvgmljaqvCclpdoiyuhJaE3YTSBT0gg8S2zMZ2VP82hvyhcymvGsI7VkLnQhKeE 6h/OlnCRpr7Vy3c72Jl3sGJIvUHgrl1A84emHpyqfpU+tOOlO5dk1N21Fsb+I7tux9KpYnh75Y5l abR68pywZ9GGI+vK79q8XJp8jPtUWVdmm/yPub71Id9aCxfoCtqH/mJXYghuhj5M4Ql5+Ti8A9QF WK6wy0pwsautaHTQtfA5XDhxQh0rYG78FcZLG31HKf4eB9+jcFSCIwTukx6VqPrn4p3WEev3rVy3 FR5NhmTJIPkejIZ90dAfDaujO6Ppg2bgzMxRUrFLIvE6/DEl26SjNthng0YbeG2QYAONDXQ2s0kl NGnsoLGn2xfavfZO+3b7PvsT9hftr9s/sn9hj3yDPamdbeHp9z/2vWYH1kn33jhE863jNXYLdnnt q7GLdYTQ+oc+t8OEHX5mf9dOz9rhhB3usj9op4N2aLXDEvtKO11gB9kO1G620w/tn9upSvq4/ayd qpQd9kE7VQlT7Qvs9LvpVjOeoBJaGE/oUkl/yxQAlfYIUwC+mXiGVnkCqVHVIJv+YTtttffZaYW9 zk5le66d8vYYO52wX7HT1+zv2el30y3CyYfJIEwEYRIIM/paPyV2xsBv5/32YfuYfdzOu+xA7JKd anGliZxsMkb62YlwqQzrXvxVQ3H4UuHm24bwqdryLZcRN4Xva91qk/3ReatrJjQ3N6t/LPa44l0m NTqHzmVnaL+BuuVYtpmekc8qooVlcH3AvjV9xfody1OK5Ohc04r9btPUqvEPI2y2eMrFWZMj3vvp +kd7i3kt5oPb9zj5/MmnkpqafKJ+sX9lMt2Ie8aKB1aJ8Aus1R5T9FxEdIQ7ojyCN0SwK7yNukhf olGCKClBAq9AKJipzeqysr9D7LaOWo9btUZrGYKnrK9aL1ovW7XFLQjRUB9nVVZ3+KxKRrZPtuZa W63cKZWIU6xgRC402h+JCa4/QWNkqU+Zm5WJoWsI51bVQGo5zK5qWOmPxTELSo5890wdGL7ItoI7 FrrPPvywpbizVq5MNM0zZ7qt+l9z576q5s7dvbM4UOPUaA5wgmVuSUbb3Xg+d0ADX8V9qtb3XmW+ VqGtlBIq41lzgWIxdJGAjKbhn7UJLqFF6BUuCoJAnvXDBcDKRD2Cmi/9oZnVB81qARQ6igC/Hdwf v7Jyf+QaDh+eIocPh840/Jo++U3iRanFWPJXYgv9L/GvRn4P1/4ddmqNxoFRjP2jMZ35R11CtKVT y0n5tX/dvem/bm30U1IhrCZPYuEZh9WjjR8ga/C7H7+rsU2EN7CP4QgpVHFPqX178Xu/BmF4g4wg fA++D7B+5MUjLaPX8n8kOUi/G7+RjA++17ICF/la+WdIB8rPJhvhC9pAf84t5Ma5cV7m3xJ2Cn/W FGje05bqrogLxCfFLyJe02/Xf2ooiiqIujPq58ZO415Tsulhk3qDRWysmCGhqCkRF8ZCwv1AGMeV Ydg5sHp2zq2z8wdixBaER2lJbxjmSCLZHoZ5pBkLwwKJIsfDsAbhZ8OwluwkL4dhHVbs+WFYJFFQ HYb1qMOa2f/Iz4GBMGwgvfBYGI4ipVRC6cCL2Bqny8MwkGQuKgxTEsVlh2GOLOCKwjCPND1hWCBz uENhWIPwk2FYSz7nXgvDOpLJnw/DIpnDT4RhPSngvwrDkeRWYUEYNpA/CGNhOIrcrukp7+0b6u/u 2jAoZ7bPlfNycxfJKwMdsq9tMFuu7mnPkRdv3iyrBANyf2Ag0L890JEjL61eUrlycV31iuVy94Dc Jg/2t3UEtrT1b5J7O28cv7R7faC/bbC7t0de1dYzsDLQtW1zW//igfZAT0egX54n30RwU3N1oH+A wfNzchfluK913kT6v1ECNe/qHhgM9COyu0euz1mVI/vbBgM9g3JbT4dcNztwRWdnd3tARbYH+gfb kLh3cAPquXFbf/dAR3c7kzaQM6t+eW9/X29Yo8HA9oC8rG1wMDDQ27NhcLCvyOW67bbbctrCxO1I m9Peu8X1XX2DQ32BjsBAd1cPTjxnw+CWzUtRoZ4BVHybKhG1ud5k3t4eXJjNIZpseSAQkBn7AeTf GehA1fr6ezcG2gdzevu7XLd1b+p2hfh193S5rrFhXMJy/nOj8WzqJX1kiPSTbtJFNpBBzPQzSTuZ i+88kos/ixBaSQJ4XsjER9qQIhuhatKDVDkILSab8Ue+jsOA2grgO4Dv7epYRrkURy0hlchtMalD eAVZjthulb4Nv4NI3Ya0AbIF3/1kE+J6Sed3yl+K49erclhPN9L3YO8qbPUgXzaui2xD/Ri/xYhp R0yPKqMf6eapWn0Xh+/uXa32DMzi56NGzGI5xP2NI7+b63/OEiGbd6lcBlXeIcpulXc9UqxSqfzq SGaFQVVaj0pV9w0SV6DEThzPbHaNsl3lPYjtEOdehDeE7bkRbd2vatChjpuZ2wBK/rr1me/1o/f1 3mQjpt12VeYyFT+o+hLr26C2+kgRRhoXuU39yUGaGzm3h/nmqNAWpPw/HTeIO6NPtWNAXeUupA2t eI7Kcwt61tKwhXpUf2cW2nbdHEO2+TYv86rv0I7ZfAMftrLszcbOaD8Q1r9TlROyWh8+e9HuAdXa OSq2S51jN65hN0LX68dWrCuMu1mbGV1unM//S9lcKHGYziBHyDd8TovKT0HL/qNSfR4HXrkfxifh 1CSQSYhYcRXkq/BXf6btM2+m7d+8WbYrXqet5fLuy9R4ecXllsujl09dFvR/+jDZ9sd/9dqM/wrK v3ottn+Z8Nrembg4cXmCUybcC70T3njb7z0X6//g4eovAlf/O27aZvyN7TdUfSi/iE/yvvMzeGW8 xPaP/nTbT36aaZt+Cfzn+84Pn+fUovG8Oc9rO1d2bsW53nO7zx0/d+qctu/MiTPBM5zxDIy9AMEX wPgC6IzPlz1/+XluODgWpMHgePBCkHOdKjtFTzwbfJaOP3vhWep6puwZevxpGH/qwlN0xcnRk9R1 svfkqyenT/KPHEu1+Y9B7xF49Qgc8Vptf3c4zrb78Ojh6cNc7gPKA3T4AegbHR6lY6MwPnphlK44 1HKo9xC3zzttO34P7L17vm1woMw2gDPo7Smx9XjzbYkQX5/gjq/Xurl6Dc65Ffta8Hurd75tbZPP 1oTv6DxzvYA24fO4+l4OjFwZRy/XTtdSpTa/wKvUpmV631Hq/FDtlW0+5FmF31NeuOi97KXDXrDk xdabwFgv5RnrKZB6IGCzGcuMLcbdRt5odBlXGHuNo8aLxmmjtgxxl40cporDFhDgPIydrlvldNac 106vrAlq/WuDsD+Ytoo9ldqmoGZ/kNQ3rW04DXB/4z333UeWWGuCeasagq3WxppgBwIKA4YRkKyn LWRJ4+DA4DYn+0AIIINO58AAg4C1nKE+FQLnAHYj2cDgADYGt5EB58AgDAzgRh5E/ACsQ3hggKEH AEfgd8AZYo8ckPE6ZICPwRDrgQGkH8DxA/Hr0K//Fw69QUUKZW5kc3RyZWFtCmVuZG9iagoKMTMg MCBvYmoKOTc4OQplbmRvYmoKCjE0IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5h bWUvQ0FBQUFBK0xpYmVyYXRpb25TYW5zCi9GbGFncyA0Ci9Gb250QkJveFstMjAzIC0zMDMgMTA0 OSA5MTBdL0l0YWxpY0FuZ2xlIDAKL0FzY2VudCA5MDUKL0Rlc2NlbnQgLTIxMQovQ2FwSGVpZ2h0 IDkxMAovU3RlbVYgODAKL0ZvbnRGaWxlMiAxMiAwIFIKPj4KZW5kb2JqCgoxNSAwIG9iago8PC9M ZW5ndGggMzU1L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2Sy26DMBBF93yFl+kiwuaZ SAgphSBl0YdK+wHEDClSMciQBX9fzwxtpS5Ax/ad4YixX1zKi+kX/9WOuoZFdL1pLczj3WoQV7j1 xlOBaHu9bCt666GZPN/V1uu8wHAx3Zhlnv/mzubFrmJ3ascrPHj+i23B9uYmdh9F7db1fZq+YACz COnluWihc32emum5GcCnqv2ldcf9su5dyV/gfZ1ABLRWrKLHFuap0WAbcwMvkzIXWVXlHpj231ko ueTa6c/GuqhyUSmjOHccEKcH5JA5Qo6IE8rEzGfkhJkyKXEgkQ/ck/aPnFHIJ+4ZIj/yfoVc8H6A XDJTnzNnyKdiLh0ryVwgs3+Kbor9kyMy+ycpMvtH6KA2f3RQ7J8myOwfo7Ni/wC/q9g/oJ7sH6On Yv+AfDZ/yrB/Qj3ZPyxpENsfx5HgnfkZtdB3a92Y6WLRfHGyvYHfuzeNE1bR8w0elrFzCmVuZHN0 cmVhbQplbmRvYmoKCjE2IDAgb2JqCjw8L1R5cGUvRm9udC9TdWJ0eXBlL1RydWVUeXBlL0Jhc2VG b250L0NBQUFBQStMaWJlcmF0aW9uU2FucwovRmlyc3RDaGFyIDAKL0xhc3RDaGFyIDMwCi9XaWR0 aHNbMzY1IDY2NiA1MDAgMjc3IDU1NiA1NTYgNTU2IDI3NyA3MjIgNTU2IDUwMCA1NTYgMzMzIDU1 NiA1NTYgODMzCjIyMiA1NTYgMjIyIDU1NiA2NjYgNTAwIDUwMCA2MTAgMzMzIDMzMyA3MjIgMzMz IDUwMCAyNzcgNTgzIF0KL0ZvbnREZXNjcmlwdG9yIDE0IDAgUgovVG9Vbmljb2RlIDE1IDAgUgo+ PgplbmRvYmoKCjE3IDAgb2JqCjw8L0xlbmd0aCAxOCAwIFIvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aDEgMTA4MjA+PgpzdHJlYW0KeJzleWtYW9eV6N7n6EhIPCQB4iXgHHEQIAQIJPMGc3jogA22 eDoCPyQZZMAPJJD8jBOTxBnb1NTOo45n0tjuTPpKk1g4doyb3Nid+dreO40du0mnnUlre1q3k96G 2ne+pOltYnHXPhIYu0nnfnfu990fV+Kcvfbaa6+99trrtVFwYrsXxaFJRCNhcJvH31df1YYQehsh nDi4I8gd2HCjCuCbCFErN/mHtxXY3v89QrIihBTM8Nbdm3719fOHEYpdhpD2+IjXM8RUrLMhlAnz UcUIILzhxxUIZcmgnzuyLbirPO6ZXugXQH9gq2/Qc932rBn6+6Ffus2zy5+hwECbdRb63Jhnm/fQ lkeuQf89hGKG/L5A8KeocB6hvCoy7p/w+s9oPpmDvhMh+reAw/AlnzgA5aRP0TJGrohRqmLj4hPU Gm1iUrIuBf3/82HeZt5GjzCPIR3aLb3v+8hqUDLaidD8h6R37x1+6P+uFDHSG6djI/oY/W7JwPfQ u+i7KITeWUqN87GJnB5ORLfQR+gHX8QV+LG4QwJvoGvo++jcF9BR6Nv4LvoZTgc7Pw8QwTWg9/F6 kOclwG1H0/gzvBsb0CmskUbLgHcCscQ/41WP59FNkO5ZdBM9i1vQTSZAp8PAz6jvo6/Sj1GX0Y9A 5tXUNODm0U/R27gU21EAnUXfkBgEYL3ppRxphP4WHUdP3MMyr4bfZB6jXkfa+T+g19Gbkgb2oSnk Xpx0B/8eHwWfTMcxeOFM31oYVLTRm6nXKeruM9B5Cg3D48H/DNTTdOMD23kp7AuPYAY9AxL8Eneh I8Dl1fCF8ItoAzpN/QT1oX8HuVsYLf42QoK939nX29Pd1elYvaqjfeWKtlbR3tLc1Cg0LK+vq62p rqqsKC8rtZQUFxXk5xlz+RwDm5as1agT4mNVyhiFnJHRFEZFdl50c6E8d0iWx7e1FZM+7wGEZwnC HeIAJd5PE+LcEhl3P6UAlJseoBQilMIiJdZwdaiuuIiz81zocgvPzeKBLifA0y18Pxeak+BVEizL kzrx0DEYYAZnTxtp4ULYzdlD4o6RKbu7BfjNxKqa+WavqrgIzahiAYwFKFTA+2dwwXIsAVSBvWaG QjHxZNkQbbR7hkKdXU57i95g6C8uWhFK4FukIdQssQzJm0MKiSU3SkRHX+Jmii5NHZ7VoI1uc9wQ P+RZ5wzRHpg7Rdunpg6EtOaQiW8JmfbcSoOde0NFfIs9ZCZc27sX12m/tyQOMUYNz019jGA7/NyH 92M8UYzcqPkYEVAE9U5NiTwnTrmnPLPzkxt5TsNPzcTFTfntoGHU6YRZs/Pf/ZI+JB7uD2ncI7gm ulmxuz2U1LXWGaKMIjfiAQz8NfCGKr1B279A0/lFwwgUAeoAnRoMZONfmhXQRuiEJruckT6HNurP IMFi7g9RbjJyaWFE10dGJhdGFqe7eTjN9h7nVEhmXDHE20HHX/KEJjeCPW0mR8FrQgl/0Bv4qUQt V23pl2g5kGrF0CgXYvJALTBr6QSwFDJlSiN1Ev4Qaeb0sECeNpGr5oEN4WPn7e7o346RNGDAFReF 2syRo+91hoQWAARP9IzsM6UWmOFxwxGNtkjHF7Lw/lAy37R4nkQs+2iPU5oSnRZKbg4h92B0Vshi byErc/Ypd0tEBMKL73JeQLb5mzPLOP1rNrQM9bcQ4pRmsKs8+5RzaFOIdeuHwNM2cU69IST0wwH3 805vPzE00JDpJixnkFYMUc29zvYevr1rwFkVFSQyQNjJjPYH2PBOfYQNmFwoxhjDOSk93Q+EGkBw IgB8Ux28QwpjDDwaULiEJabaVMc5sR4tUIMYIRNn97ZE6Uj/PqYMMafmtgVuctIFPs1tekO/IfIp LqJgmIsuDDNiiFLbFoZoI0QCwFHARkIRXaYRm+ecvJfv50e4kNDpJHsj6pG0HFWGpPPoWfXe11ui LFATMsDwQocoMySa9UuVG2qV+ovdtgeGVywMc1MxfHvPFGHORxkikHxFCBETFqq0esn7iT/zogec GDxa8uepGUEgvjxC3HaKXzE0xfc46yRqiCCP6PeQtRJRO27vbSougmDWNMPjg10zAj7YM+C8ANmS O9jrPENhqtnd1D+TC2POCxzkCglLESxBkg5HOoRTN3RiJHr9BQGhSWlUJiGk/uAsRhIuZgGH0eAs FcFpFnAU4GQRnCDhyAdOKW0EdAzx284NkfPZ2z8y5e4nNo5SQCPwh0OYXw7a4ZfPYEoeF1Lx3qZQ LN9E8A0E3xDBywleAZaBU3Bx0Z4pjZ3/OK2YZE0KtcBriOmD5K1AJTMYWerOKGQ5c9YZOfPzujM0 BSCaoQmaIegzCjn/Wd0ZTPA2rUFrNGgNLRQXzsXHwyNM35++0yK7TIoL1Dv/IXOEOYZMaPACKpj/ 41mlCnXkzM7/UagkkH5dRgazTm4uNWPj2lINVmtYDaXhXDq9XifjmFKG4hg3c4q5ydxh4INcsUmo Yc5mWT/eYLNo5rBl/fq59ZrrgJkrKzWbjdblVCWTQPM5uXlU+bLEilybNZtKZUoAk0DpkrMpWt+z u782CWN26Ng7h8+HPzrd1/cyVpyZeue5wczwZwk1/bs6tvzNoMUy9MJ7lg53mafjab992z/guJNf x6o3vDWjR9a0FvcI+fbJ13xj5/evJLrrnP9Q9oxsNUpCPMoVkpNbkdFt9BupjFZVqgN25GBSQOgG kHZuHGQtK8XJCRSfUwISLqeIgMyyPD5HTsSzwQZkz9inrhza/4+HxOaDV6aevvJEffhfHt21dz8v DFQs9zTlUNl7r3ylp/vZdx7ZfflYb+9XLu/53quhi57DA2bzwGGi8wNQBw/JHCCN5wJi528KeTFo FRJv8nd4ijceNZ4yUn6pCRnvGJnbRpweJ16Nx/Gz85deyy1oI62QEBPXFp8u78zSJKnjocpusDaA 3rHFbF4/Z10/PqG5vh42gswG7bISSlKuVgLzDdm0zrYck23ptHRHcsnKcltPnSH8b5imKBxHyWS0 rPrlnRsP9OVRrobR9sLinoD97pt0G7+yuTw+rlwQUvb6Bf9x590ushceFPwqVPx69NAFpIK9ZBGz uZiFJ7OwXu9SY7U6HYuUHPiWgs8S0TWapDYqqQtuTDJHOqOGcrKhwTZnJfo3j9ssWptmzmq1rCdG RHaAQXC+3BY5i5RUXQkm28nCNh3+5/AHJ05kt+1ZW7remFiclG/LivsJvfez/fTet8aXj64uUsnP yRgNV8b1vUXs4AgI/C2QlfiQQ6jAjEhdlGO/HN+QY7lSUHYqqVPKkJLap8RuJWaV+LYSTwLikvKq UsaoZTrUA5c9sJQGvH79OHyIlsfHrXPWstKkcoOOSHoEp4Mq02V333nnU1pW8+kPYN3e8GrZAJy3 DdlRr2DLTVgm3rBgiwBnaWn1t2K5yDDLWy9lXs2kSjNxZqG62pFr0DQ6klJ1yi4kl4NyG6zgTaAl 8gdONU4cCmyVHDYsjsFW843ZmFhneR2GophPwPcMOCXVBm2lIQHrtGDZSQsWkZxCJlC9W/4uYI/H 6erBTmtPrQFjqmxmz/BXNlqswy9s3fqdUgZutBRWUbKWJy6OFwg9hRU9Ndl+X2FPU0F4tXnVFsHQ uDKzeawrsyYtM2N0Q9dT/233Iz962rFuWFdpK1DkPt772b/uOB2soa9vOtidU+g8uOH0GUPPFNjO PvDLdXAj5NE6oYTVEMNJjhVvJOAEopqEz/MELN7Omc+hciQXUMa15RAXSEnWxSH1PReAkEOOhign YkBRxy2H8wEw1VBCLypIi48nl6yQXABuYDSNwx9hhqaZqld2eg725clq7n5twQmols9mc9oXnOBh v+A77qROR/yZCsP5ZqENF5B6/gMphuqIiJkgok7H7mNPstRVFltYF3uapeOyxKswLerOpBXigRCl d8YlahRq4s3EIxacef241mYxk53YlngwvegMch1Y3T3n1RVWd9aml8XrK/NGt9N1/OrW6vi4WtGu q13fyCvlv5MrX/rm3TniD3Wg/0mIi+WQXQ69XpamjEMd7Oz8HcGoRKsUGnjRacpY1FFhjRVzLpmu miiTKUe8KGKHiFNaU4ncJl1aW2pqXSsjxGvamMpulSqzgU2xpOxLOZIiS0nRdmVq8hscVguCCGu1 EicHt9YmVlvI7gA2w1Fp3gZv10iGbIYPE7XbBlweNVSFkeyWxCvpICt1JIHk5cMRJikS6KgZl+ND qx9eU9Ic/Krzt7qC2jy+siCdCb8fJ4x/3ec9MVajSOIzuez0goLi7M1elbzq9D8eLe6qz22trXDW 5ySbe/asdj/RZcSyylqHVZfA1xYntG5fY7EOHnWFd+TVmXTy43KVXDbi9fopJUVB9q5e1V7SvtEG B5k+/3vqKaYKpRLvpgrI6cfFuZJxcrIqQaQVNMM4aBfto2layCtqO0VjOp5xALeYGLla60BS8onG PfDt+2Mg6ITJySsnEbDSprPpeC3ZbgXoAOMX9/7VoeecocuX6xoyCjOWBRMPHKIefSscfuvuFUd7 jPxVrVb6BwI6BDd8OfMYikXdQrmaxgqQSamK5+JL44V4mlEOcKgUzCHG5WJ8UAzcYOYZ5jaDGUYp c2Fa6UKJUnqEU4PAAxKCTWquaKvhqgEBGqoLnSH6HJL1fvYudeeuhl7DPHYrfOJWePoWMD4Qfkh2 RNaFclEFWn8B5UCWyISMR3PwMra+g24ATZW/ChdnasWriTgx6hikFRIhzyUWODI5TYpaq7c6VCRX QxBc4iBWCITjUrIzLyTufB58hCS8vKX5TkrjkTJDyuNHyja9sKXUtWZFhhyD+4T/jaGxlmJoSmY7 s334mMcSfp+EuUZTQWN3YUVvdTaV8/DVY33JxSsqmILy2vSwR/bfex7PVRQsq9JtWdf77OU9F17j +45s2zzdy5vXflnS/RGS6yHnsCTXM9FcrxJvKu8oKaXhqOGUgfJLTchwx8DcNuCMFPFqKk6N6iB1 IdenpqFUpY7VdNIaUmA12Br+PNfjhbR+X9I3kJivwC9Gk3r4gyUpP52iKUxvjCb0bmrDYsL/L8zb 4S1cY3VJfKT+JDVUMcSKbJSPHK+nixkZRlFDhMvPN7dpTBaTw+Qy+UwnTUyutpXRdufmprDdKk1K F9Kk4/R0yf+Jl0tmRCotsKHr5khdyCwptbKwQTqeClIm0sT5DSWYWrn9jf1iz/TspslzwYq7K9Mq 1tSv3JCMlYmNW78WMLdX5lD4xZixZPv0T448/94TNf2nbhyIadneV9bQlFoy8lA1PZPVMCQ+8UQk VstPQKyuRt8i9e4dKVZD0Lsp9BGIqxYRii8WbxV9VEQV1fbW7q99r/ZWray2Fj9f+0bt+7V0by2G jqUWU2wtRrU4VHu19mYtfbIWu2snaykYgGoNSc51NV4m1WpJpGizyTvTDXk0qdeKIwUbpKtUG3H5 SJQnJYVLqiqkA9WCmqT09RdKOEjsC5FxkUihpeO0+Q3FZtGWeV9Rt+z5rXufy5BnNXe5qvofXsWH f0vICu22TOqLC73dgeaByrRIuRehMjvGmu+eXrDtaD1lF0qxeJHCfgrfgCqPEZhOhjrFhBhqH4Pd DGYZDAFlEhCXmKuMDKookuPuq6LmpFBC6ifm7T8tk2yOxK1xiFtxKB05L6C0+ZvSaaXNzn8glIEb qTkVvKogT6nToBu/FumP6nGpXtBTyQNIXioX5HSMPMmloJNd8sRoib+BVAdSlY9ItoGQQUEpAG5i laUkMqBEqBdIdGDGN89++tTdH+DwizjxB2Phnzbv+qb32p/6n/M1UD8KhT8+u455rPul8J/OPhwa r/isdfnDr0syk/vUr+A+lQR+svMCypv/r6+BkHlgYK+BnBxpVVL7M2E5IDLToJdCXslrL6J3gIGp 1CSY3Ca/adJ0yiTnTHdMVPbaSypcqsJqFauiVOkutYx3MUnR/YAOpQ2NL+6IbEkuW3rFiu5safBj frVxNvzJN2fCn5zpX38OK19+GSvPbQi/Wz7y197h50eWlY/8jXfrV72l1A+/Hv73SyP3blib3gx/ 8qLvtUn7wg2r/cnzYAu1sG857LsebbsAnQ+EJtidgdQQhQMm6wBrgq8qaQA1xA6QbThULpVPxaiS rEyxK7ewMFemcTGaWC62NJYujRViqdhYskNyByB1LxS/idXVJPXAySWSzKOZ00g3ysWIb8wGT6gg JUN+CbMQTeBmiRd2nZrNMHLxmV+fOPxPf+3S4ay4kq7da46dFDZPtdft2rbBnt/7lSt7pr7/5KrE 8C9TDjy6erg+wzrwSHvT4zs2tZvxMfcL/nrrxqc2WCyrq9m1npqVpZw6Ibuwpm9i1egxV5HZ+WR/ /tp1+pL6nGXNxawmgS2se2hXJP+2QexkIebUouMXUA3oRhXRDdgyRcot0rWKbKFoYkm4ENO5NqIv lU6UcqMDWNR31uPS+lA9JdRjSz2OFVVWHWPpyv1xIfYXYrbQUkiBEjWaLkmJRHspkvYk5UFoiepv bn0kXYxHlGhe0OI9NVYSNUI1JemRXtSjgtzQ5RE10jK2ce/ZwPA3HunVfRJXuLynvLSnPqesL9DY sn9EqAt+x+c8vqtL8z8VueVi4dCQqX24vv2pcTuuW733IUu2fazLWFyVrYrVlxkLy9hUtbqwzde3 andfsaF1bHVGvi071lZnLMrSqTXm9h2S/kjuqYTcw6FKIVsjqtV60QH3pJyUVibJodJoVBpBD5fN tEgpBfuN/u9hjsTRP8swEZuQ6zTRJEN1P/a9SUHc/72HR/9ux4qE8K/j3M7xkV90bo3HGarW3S8n dz59ee+Bd5/qqPLs70joGfzuTHjKOxTffmi0QfrtD2t/d7Z6Q6dLXfcxYiO/O12Z+gW+95NHeLX8 BERJjGLAvaM/6iCkWB5ejZrv/czzwO8kKdSHqIX5IeqV/Qp1wnOAegnxVDU6AjDB7aOz0AFZANUB Pp1Zgw4RGniOAK5TAWOEFh4EPA7Jq1Ev0NTCWBvqlPgXoRPoN7gD/y2+Tm2mrtCF9BVZtmyD7OcQ u1+Ur5Tvge97ik7F9ZhHY96WpEtFYlR+CmmQBQ1AZbNH/jWI/gSbidcs7sG9uB8M1zJ3FKaQDPmi MA31UCAKy1AyejoKMygBfSMKyyGGno3CCrQH/TAKx6Bk3BiFlSgB90XhWJBhcPHX2BK8LwrHIx9+ JQonoOVUJqyOZUroXaIGojBG2XRGFIZCmK6KwjRaTgtRWIYK6EejMIMy6W9EYTnKo/8+CivQR/QH UTgGFch+HoWVKJORReFYVMVwUTgOrWOcUTgeXWfORuEEtFf+dLPPv3tidHgkyBUMmjhraWkl1+0d 4to8wSJuxdhgCde4dSsnEQS4CW/AO7HDO1TCdaxosnc39q5wrOZGA5yHC054hrzbPBNbON+m++d3 jG70TniCo74xrsczFmjybR1qDAx6x4a8E1wx98AoR4Y/D7fGOxEgiLKS0soS2z0KQlD8wKT/QCDY xfBoIOidAOToGNdX0lPCdXqC3rEg5xkb4noXJzo2bRod9ErIQe9E0APEvuAIiL15+8RoYGh0kKwW KFncTbNvwu+LihX07vByqzzBoDfgGxsJBv01FsvOnTtLPFHiQaAtGfRts/ylseBuv3fIGxgdHoPd l4wEt23tAIHGAiD4dmlFkGapBkXfGBzS1ghNERfwejnCPgD8N3mHQDT/hG+zdzBY4psYtuwc3TJq ifAbHRu23GNDuETX+c/NhrjjQ360G02gUTSMRlAQYmsBGkQmaK1wGSxFlQB1Iy8agrYNeYCiCKAV aAyoSgBqRFvhyy3hEJB6Xmi90O6Q5hLKDpjVhOzArRH1AuxAJJKPSvQeeIJA7QFaL9oG7QTaAjgf 2vQX1++A+RuldcjIKNCPwWgP9MaAbxP0t8LMRoAHgWpM4j4BFMWSPH9pLrc4+3+Xbo1EE1ikKAP5 iP5KkO1zeSxwKP4PVvrPaShyFsMSl6DEO0I5KvHuA4oeiapTmkl0FJRWG5Ooej9nRQesuAnmE43e oxyUeAehH+HsA3gkqu3NaLtkHwGgJPMW9haAlf/8bIhNToBV+h7QFpFuh7TmKgkflGyMjI1IPT+q gWxkQTulbwnQ3M95MMq3RIK2AeX/6bwgeIxf0qNXOu9hoI2cfYnEcxucZkdUQ2OSHxANbV+yx4hu vsgGRamNeNLW+/iQkyUtmbsgfSAq/yZpnYjW/PD2gd69krZLJOywtMdROMNRgJbKR05sOIp7UJoF We7fz//LtelIcTGfj36KPudzEXViBSRyi/Q+jWVCK756F1+8izV3se9TLHyKJz8++vGpj+n/caec tdw5eYdy3caW267bvtsnb9+4zfzmFsf++lY9+8ub+ey/3qxnb9T/ou96Pd33i1mcfaaOtTTG4mzg rIE3B48ADz1/CWcLBemZ4s/peRa9j/9FVse+9+NM9t0f57Hua0evXbpGkyYEwM1rDPmfzrX0LBHa s9dU8aJ6FqcIanzxrTxWeMPUKApv5OSLs9gg8K/Xs2gWz55Xseg8Rue588J593n/eYY0R89fPX/n PDOLOSG+DejOuc9Rp85dPSf9tpJwLjZBVJ9xnaFm6IjM6agBHgc8NILLNexAwOlCQZ5JZE9bTjec Pnlapj6NhdMJKSJ6xf/K5Cv0zVfuvEJ956Vy9qXOPPYC1uMM2D6Ik/E6Vn8bq7+F38SpOAnVIRbr hAOddeyJ5/PZF+D5KjyTz+PjYgF78rnTz1HHxHJW/Sz7LPXM0Tz26afy2COHY9kvH85j1dPsNOWa 9k3vm56flgnTSami+jAWDseqRfUh9hD1V0+qWdeTuOJx8XFqBwixHZ4gPAF4TH6s92Pajz/y43/y /8ZPjfhxvx+Te1TQD0r1jbWxY6KVzcBpfem2tD6Fje6Tw+l4YK7bZWVd0G4YaGPXifns2oFd7IBY xiZZE/sYTPfJrHSfj8ZquoGmXD1Y6CkoEoWe7Bx4JaWJ3V0FbJcjk+2EJ91hclD9jlEHNYsTBZNo ZFeI6WybaGBbYdN/FEEJOMWq69NidZ/Gqu6jMOrDaJ6dxdozeiU0GqEeWg35X4VGz+lL9X69jFU3 qF3qfWqZWm1RO9Q+9RH1DfW8WhHB3lbLoHx2ITyZghk8i4/O9PaYze2zivnu9pCic20IHwwZe8hb 6BoIyQ+GUN/AWucMxl/uf3J6GjVltYesPc6QO6u/PTQEgECASQA0WTMpqKk/EAwEtweC5uj/ECIQ WkAEAtsJlqDMCyQSOhAIBoMoMiVgDiBzwBzcLs3AAKJAdHaAkBNu0T9M3tDfbg5KrAhhIEhozASK LoYkJGEjfWCFQBr4+v8C8AM4CQplbmRzdHJlYW0KZW5kb2JqCgoxOCAwIG9iago3MDA5CmVuZG9i agoKMTkgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9EQUFBQUErTGliZXJh dGlvblNhbnMtQm9sZAovRmxhZ3MgNAovRm9udEJCb3hbLTE4NCAtMzAzIDEwNjEgMTAzM10vSXRh bGljQW5nbGUgMAovQXNjZW50IDkwNQovRGVzY2VudCAtMjExCi9DYXBIZWlnaHQgMTAzMwovU3Rl bVYgODAKL0ZvbnRGaWxlMiAxNyAwIFIKPj4KZW5kb2JqCgoyMCAwIG9iago8PC9MZW5ndGggMzIz L0ZpbHRlci9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nF2STW6DMBCF95zCy3QRYTskJBJCSkmQWPRH pT0AsYcUqRjLOAtuX48nbaUuQN/Y75nnGdKqOTVm8Omrm1QLnvWD0Q7m6eYUsAtcB5MIyfSg/L2K bzV2NkmDt11mD2Nj+qkokvQt7M3eLWx11NMFHpL0xWlwg7my1UfVhrq9WfsFIxjPeFKWTEMfznnq 7HM3Qhpd60aH7cEv62D5E7wvFpiMtaAoatIw206B68wVkoLzkhV1XSZg9L89Kcly6dVn54JUBCnn 2aYMLCPvauQN8Rk5I94hb4kPyDviHDmPnG+R98QS+UAagXyk9Qz5kb4b9RWtc+QT6ffIZ+KoqYlP gQUnrpApv0SvoPwZni8of4Z3EZR/i3cUlD+PfM+/iY26dwRbhjP9GQVTN+fCGOLgY/+x84OB33/D ThZd8fkGhBeeoQplbmRzdHJlYW0KZW5kb2JqCgoyMSAwIG9iago8PC9UeXBlL0ZvbnQvU3VidHlw ZS9UcnVlVHlwZS9CYXNlRm9udC9EQUFBQUErTGliZXJhdGlvblNhbnMtQm9sZAovRmlyc3RDaGFy IDAKL0xhc3RDaGFyIDIyCi9XaWR0aHNbMzY1IDcyMiA2MTAgNjEwIDMzMyAyNzcgNjEwIDYxMCAz ODkgNTU2IDMzMyA2NjYgNjEwIDYxMCA1NTYgODg5CjI3NyAyNzcgNzIyIDc3NyA2NjYgNTU2IDU1 NiBdCi9Gb250RGVzY3JpcHRvciAxOSAwIFIKL1RvVW5pY29kZSAyMCAwIFIKPj4KZW5kb2JqCgoy MiAwIG9iago8PC9GMSAxMSAwIFIvRjIgMTYgMCBSL0YzIDIxIDAgUgo+PgplbmRvYmoKCjIzIDAg b2JqCjw8L0ZvbnQgMjIgMCBSCi9YT2JqZWN0PDwvVHI0IDQgMCBSPj4KL0V4dEdTdGF0ZTw8L0VH UzUgNSAwIFI+PgovUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDL0ltYWdlSS9JbWFnZUJdCj4+CmVu ZG9iagoKMSAwIG9iago8PC9UeXBlL1BhZ2UvUGFyZW50IDYgMCBSL1Jlc291cmNlcyAyMyAwIFIv TWVkaWFCb3hbMCAwIDc5NCA1OTVdL0dyb3VwPDwvUy9UcmFuc3BhcmVuY3kvQ1MvRGV2aWNlUkdC L0kgdHJ1ZT4+L0NvbnRlbnRzIDIgMCBSPj4KZW5kb2JqCgoyNCAwIG9iago8PC9Db3VudCAxL0Zp cnN0IDI1IDAgUi9MYXN0IDI1IDAgUgo+PgplbmRvYmoKCjI1IDAgb2JqCjw8L0NvdW50IDAvVGl0 bGU8RkVGRjAwNTMwMDZDMDA2OTAwNjQwMDY1MDAyMDAwMzE+Ci9EZXN0WzEgMCBSL1hZWiAwIDU5 NSAwXS9QYXJlbnQgMjQgMCBSPj4KZW5kb2JqCgo2IDAgb2JqCjw8L1R5cGUvUGFnZXMKL1Jlc291 cmNlcyAyMyAwIFIKL01lZGlhQm94WyAwIDAgNzk0IDU5NSBdCi9LaWRzWyAxIDAgUiBdCi9Db3Vu dCAxPj4KZW5kb2JqCgoyNiAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgNiAwIFIKL09wZW5B Y3Rpb25bMSAwIFIgL1hZWiBudWxsIG51bGwgMF0KL091dGxpbmVzIDI0IDAgUgo+PgplbmRvYmoK CjI3IDAgb2JqCjw8L0NyZWF0b3I8RkVGRjAwNDkwMDZEMDA3MDAwNzIwMDY1MDA3MzAwNzM+Ci9Q cm9kdWNlcjxGRUZGMDA0QzAwNjkwMDYyMDA3MjAwNjUwMDRGMDA2NjAwNjYwMDY5MDA2MzAwNjUw MDIwMDAzNDAwMkUwMDMyPgovQ3JlYXRpb25EYXRlKEQ6MjAxNTA2MjQwNjE5MzItMDcnMDAnKT4+ CmVuZG9iagoKeHJlZgowIDI4CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAyNDY4NyAwMDAwMCBu IAowMDAwMDAwMDE5IDAwMDAwIG4gCjAwMDAwMDE2NjMgMDAwMDAgbiAKMDAwMDAwMTY4NCAwMDAw MCBuIAowMDAwMDAxODYwIDAwMDAwIG4gCjAwMDAwMjQ5OTUgMDAwMDAgbiAKMDAwMDAwMTkwMCAw MDAwMCBuIAowMDAwMDA1MDY3IDAwMDAwIG4gCjAwMDAwMDUwODggMDAwMDAgbiAKMDAwMDAwNTI4 MyAwMDAwMCBuIAowMDAwMDA1NTc0IDAwMDAwIG4gCjAwMDAwMDU3MzkgMDAwMDAgbiAKMDAwMDAx NTYxNSAwMDAwMCBuIAowMDAwMDE1NjM3IDAwMDAwIG4gCjAwMDAwMTU4MzMgMDAwMDAgbiAKMDAw MDAxNjI1OCAwMDAwMCBuIAowMDAwMDE2NTQwIDAwMDAwIG4gCjAwMDAwMjM2MzYgMDAwMDAgbiAK MDAwMDAyMzY1OCAwMDAwMCBuIAowMDAwMDIzODYxIDAwMDAwIG4gCjAwMDAwMjQyNTQgMDAwMDAg biAKMDAwMDAyNDUwOSAwMDAwMCBuIAowMDAwMDI0NTYyIDAwMDAwIG4gCjAwMDAwMjQ4MzAgMDAw MDAgbiAKMDAwMDAyNDg4NiAwMDAwMCBuIAowMDAwMDI1MDk0IDAwMDAwIG4gCjAwMDAwMjUxOTUg MDAwMDAgbiAKdHJhaWxlcgo8PC9TaXplIDI4L1Jvb3QgMjYgMCBSCi9JbmZvIDI3IDAgUgovSUQg WyA8MDM2MEJCMDA2NzI3MEZFQzI0M0FERTI0NzY0MDc3NzI+CjwwMzYwQkIwMDY3MjcwRkVDMjQz QURFMjQ3NjQwNzc3Mj4gXQovRG9jQ2hlY2tzdW0gL0Q4REM4NTI5MDFDNjMxM0ExOEI2RjhGREUw NUYxNTY1Cj4+CnN0YXJ0eHJlZgoyNTM3NAolJUVPRgo= --001a11c27cf0031b750519436d7a-- From nobody Wed Jun 24 06:29: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 2CE2D1A9087; Wed, 24 Jun 2015 06:29:02 -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 wVKi6kAcDzdf; Wed, 24 Jun 2015 06:29:01 -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 11C7C1A9085; Wed, 24 Jun 2015 06:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EA31D25132C; Wed, 24 Jun 2015 06:29:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [209.5.235.18]) (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 806302510D3; Wed, 24 Jun 2015 06:29:00 -0700 (PDT) To: Andy Bierman , "netmod@ietf.org" , "i2rs@ietf.org" References: From: "Joel M. Halpern" Message-ID: <558AB091.6020000@joelhalpern.com> Date: Wed, 24 Jun 2015 09:28:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 13:29:02 -0000 The separations and effects shown there match my understanding. Thank you, Joel On 6/24/15 9:24 AM, Andy Bierman wrote: > Hi, > > I prepared 1 slide (based on Kent's slide). > I am trying to understand the types of data > and how they are identified in YANG and conceptually > separated for protocol access. > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Jun 24 06:35: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 CBA221A90A6; Wed, 24 Jun 2015 06:35: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 wkaICTLuekHT; Wed, 24 Jun 2015 06:35:47 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D72A1A01E7; Wed, 24 Jun 2015 06:35:47 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: "'Andy Bierman'" , , References: In-Reply-To: Date: Wed, 24 Jun 2015 09:35:45 -0400 Message-ID: <009201d0ae82$ad0a2890$071e79b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01D0AE61.25FB95D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI38j8X2xhzt+7kOgR7BWPTAddxT5ztILbw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] extended datastores slide 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, 24 Jun 2015 13:35:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0093_01D0AE61.25FB95D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Andy: I will post this slide for the i2RS meeting. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Wednesday, June 24, 2015 9:24 AM To: netmod@ietf.org; i2rs@ietf.org Subject: [i2rs] extended datastores slide Hi, I prepared 1 slide (based on Kent's slide). I am trying to understand the types of data and how they are identified in YANG and conceptually separated for protocol access. Andy ------=_NextPart_000_0093_01D0AE61.25FB95D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

I will post this slide for the i2RS meeting.

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Wednesday, June 24, 2015 9:24 AM
To: = netmod@ietf.org; i2rs@ietf.org
Subject: [i2rs] extended = datastores slide

 

Hi,

 

I = prepared 1 slide (based on Kent's slide).

I am trying to understand the types of = data

and how they are = identified in YANG and conceptually

separated for protocol = access.

 

 

 

Andy

 

------=_NextPart_000_0093_01D0AE61.25FB95D0-- From nobody Wed Jun 24 06:52:44 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392FA1A914F for ; Wed, 24 Jun 2015 06:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MHOW-_wXacrc for ; Wed, 24 Jun 2015 06:52:41 -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 3EDFA1A9163 for ; Wed, 24 Jun 2015 06:52:40 -0700 (PDT) Received: by lagx9 with SMTP id x9so26486741lag.1 for ; Wed, 24 Jun 2015 06:52:38 -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=CnJo6AhIOH3qXN+qMjW5p9aKPRLIOEzdJqDotUCjVqs=; b=C84gBhSFmsvV/EauWoG99Qg8OSluCKbdugHKjvzUz3hqfTR4TsLsDCsg/lv9efSOCF SlM+SoKYzGi7jrDB9FLX89XZQFCX82M+hULHxn90Cw2tGxX6KvVsQOFLwDlYRsx+evYZ EQTdj3DEZyUwrezuFdAWuO8FRSalGUA/Sjp0eEQbpuz1Kyu+k10ac8BTDBMgDKj3tpsT KJ68PenZ3UEV/OpNm2SxyOxaZGipusA9uQ38JQXEqvdixzJutWOucettapz3/Xn2wVk0 fXH0NHqqxB1aZeLy6JRofXIqWjU7z/w2C9QDd+FE3RPDXYfhl97c9oEmGLkcD0xCbyx6 OMKA== X-Gm-Message-State: ALoCoQkPjXTMcsA51GxcAkJG+bv1rNwTPhQbkY9YsrNzQFl6Qb4zgl324mqxOJ46Pia0s0KxDD9q MIME-Version: 1.0 X-Received: by 10.112.147.233 with SMTP id tn9mr15439036lbb.119.1435153958723; Wed, 24 Jun 2015 06:52:38 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 06:52:38 -0700 (PDT) In-Reply-To: <558AB091.6020000@joelhalpern.com> References: <558AB091.6020000@joelhalpern.com> Date: Wed, 24 Jun 2015 06:52:38 -0700 Message-ID: From: Andy Bierman To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=047d7b3a8978e87b93051943d151 Archived-At: Cc: "i2rs@ietf.org" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 13:52:43 -0000 --047d7b3a8978e87b93051943d151 Content-Type: text/plain; charset=UTF-8 Hi, thanks. A few details of the solution I am working on... 1) defaults are not used in the ephemeral datastore The default-stmt is altered for the ephemeral datastore. Default leafs are ignored (except for XPath evaluation). Otherwise the schema default would always override the configuration. 2) XPath hierarchy is based on config-stmt. config=true context node -> can reference config=true config=ephemeral context node -> can reference true + ephemeral config=false context node -> can reference true, ephemeral, false 3) must/when evaluation applies only to the datastore indicated by config-stmt config=true -> running config=ephemeral -> ephemeral config=false -> operational 4) panes of glass applied to data instances all running datastore instances are visible in the ephemeral datastore all ephemeral datastore instances are visible in the operational datastore 5) admin-foo and oper-foo can go away The instance of 'admin-temp' in the operational datastore would return the value in effect, not the desired value, so 'oper-temp' is not needed and the correlation between config, ephemeral, and operational is maintained in the common instance-identifier in all 3 datastores Andy On Wed, Jun 24, 2015 at 6:28 AM, Joel M. Halpern wrote: > The separations and effects shown there match my understanding. > Thank you, > Joel > > On 6/24/15 9:24 AM, Andy Bierman wrote: > >> Hi, >> >> I prepared 1 slide (based on Kent's slide). >> I am trying to understand the types of data >> and how they are identified in YANG and conceptually >> separated for protocol access. >> >> >> >> Andy >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> --047d7b3a8978e87b93051943d151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

thanks.
A few details of = the solution I am working on...

1) defaults are no= t used in the ephemeral datastore

The default-stmt= is altered for the ephemeral datastore.
Default leafs are ignore= d (except for XPath evaluation).
Otherwise the schema default wou= ld always override the configuration.

2) XPath hie= rarchy is based on config-stmt.

=C2=A0 config=3Dtr= ue context node -> can reference config=3Dtrue
=C2=A0 config= =3Dephemeral context node -> can reference true + ephemeral
= =C2=A0 config=3Dfalse context node -> can reference true, ephemeral, fal= se

3) must/when evaluation applies only to the dat= astore indicated by config-stmt
=C2=A0 =C2=A0 =C2=A0config=3Dtrue= -> running
=C2=A0 =C2=A0 =C2=A0config=3Dephemeral -> ephem= eral
=C2=A0 =C2=A0 =C2=A0config=3Dfalse -> operational

4) panes of glass applied to data instances
=C2= =A0 =C2=A0 all running datastore instances are visible in the ephemeral dat= astore
=C2=A0 =C2=A0 all ephemeral datastore instances are visibl= e in the operational datastore

5) admin-foo and op= er-foo can go away

=C2=A0 The instance of 'adm= in-temp' in the operational datastore would return
=C2=A0 the= value in effect, not the desired value, so 'oper-temp' is not need= ed
=C2=A0 and the correlation between config, ephemeral, and oper= ational is maintained
=C2=A0 in the common instance-identifier in= all 3 datastores



An= dy

=C2=A0 =C2=A0


On Wed, Jun 24, 2015 at = 6:28 AM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">The separations and effects shown there match= my understanding.
Thank you,
Joel

On 6/24/15 9:24 AM, Andy Bierman wrote:
Hi,

I prepared 1 slide (based on Kent's slide).
I am trying to understand the types of data
and how they are identified in YANG and conceptually
separated for protocol access.



Andy



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


--047d7b3a8978e87b93051943d151-- From nobody Wed Jun 24 07:24:00 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD9A1AC408; Wed, 24 Jun 2015 07:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRnINnj213gm; Wed, 24 Jun 2015 07:23:57 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F91AC402; Wed, 24 Jun 2015 07:23:57 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 55AA91AE0483; Wed, 24 Jun 2015 16:23:56 +0200 (CEST) Date: Wed, 24 Jun 2015 16:23:56 +0200 (CEST) Message-Id: <20150624.162356.916556588650610315.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <558AB091.6020000@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, jmh@joelhalpern.com, netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 14:23:58 -0000 Hi, Andy Bierman wrote: > Hi, > > thanks. > A few details of the solution I am working on... I would (still!) use a new statement "i2rs:ephemeral true;" to mark ephemeral nodes on config false nodes. This can be done w/o changing YANG. > 1) defaults are not used in the ephemeral datastore > > The default-stmt is altered for the ephemeral datastore. > Default leafs are ignored (except for XPath evaluation). > Otherwise the schema default would always override the configuration. I see your point, but if I create a list instance entirely in the ephemeral data store, I would assume defaults in that list instance to be used. I think the logic should be that if no value is set in the config or ephemeral, then the default value is used. The ephemeral value overrides the configured value. > 2) XPath hierarchy is based on config-stmt. > > config=true context node -> can reference config=true > config=ephemeral context node -> can reference true + ephemeral > config=false context node -> can reference true, ephemeral, false > > 3) must/when evaluation applies only to the datastore indicated by > config-stmt > config=true -> running > config=ephemeral -> ephemeral > config=false -> operational > > 4) panes of glass applied to data instances > all running datastore instances are visible in the ephemeral datastore > all ephemeral datastore instances are visible in the operational > datastore > > 5) admin-foo and oper-foo can go away Yes, but I assume that they don't *have* to go away. For example, the duplex example would still have two nodes, since the syntax is different. > The instance of 'admin-temp' in the operational datastore would return > the value in effect, not the desired value, so 'oper-temp' is not needed > and the correlation between config, ephemeral, and operational is > maintained > in the common instance-identifier in all 3 datastores /martin From nobody Wed Jun 24 07:33: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 623D91AC529 for ; Wed, 24 Jun 2015 07:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 hWh1bmYqkQ9R for ; Wed, 24 Jun 2015 07:33:16 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) (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 AA68A1AC3C6 for ; Wed, 24 Jun 2015 07:33:15 -0700 (PDT) Received: by lbbwc1 with SMTP id wc1so27598921lbb.2 for ; Wed, 24 Jun 2015 07:33:14 -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=/+60xlXRR/WU4ec0rBrB7oXhb2a85KDIH8JRmqbYhfg=; b=XcYdEHhHOQwnH7C6GbNmZ3N2ttY15dcNUqorEUR42vD2w0gCc9scBCr/w7GdgjGAzr XygjtFGORD8GZF8+zdL9dZ35crV+60xrMCV57BcqH2yrqTZ8QJUtnzDpSga45Wn/+TNr eaYl9RJ6AK+UKNfvFap2KfZ+yUgtFdxxuh0fSYODlpJLJlco9iPZs0KhJ1MIfOMj2Z08 N6QOrFptYqdbcrM8XFCL1+oDu9C8fqJOjEheolw6NJZbfIolQPZOJZToFedutPL1Dw1/ Of2asRL5zomwZswHAfUb8uHc+H+EvDQ5sxvn5k5uqYBDYfqxQfP5nh3KLO6ihVG6/INh 7RLA== X-Gm-Message-State: ALoCoQlNhcsacaexdh4F7F/SYlEw3NSpGLDP/cpsLR23KGTAv15K6ePNhHqZL9GupPpjBMknBjeu MIME-Version: 1.0 X-Received: by 10.152.116.49 with SMTP id jt17mr40188138lab.82.1435156394008; Wed, 24 Jun 2015 07:33:14 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 07:33:13 -0700 (PDT) In-Reply-To: <20150624.162356.916556588650610315.mbj@tail-f.com> References: <558AB091.6020000@joelhalpern.com> <20150624.162356.916556588650610315.mbj@tail-f.com> Date: Wed, 24 Jun 2015 07:33:13 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3677e0ff924051944636c Archived-At: Cc: "i2rs@ietf.org" , Joel Halpern , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 14:33:22 -0000 --001a11c3677e0ff924051944636c Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund wrote: > Hi, > > Andy Bierman wrote: > > Hi, > > > > thanks. > > A few details of the solution I am working on... > > I would (still!) use a new statement "i2rs:ephemeral true;" to mark > ephemeral nodes on config false nodes. This can be done w/o changing > YANG. > > > 1) defaults are not used in the ephemeral datastore > > > > The default-stmt is altered for the ephemeral datastore. > > Default leafs are ignored (except for XPath evaluation). > > Otherwise the schema default would always override the configuration. > > I see your point, but if I create a list instance entirely in the > ephemeral data store, I would assume defaults in that list instance to > be used. > > I think the logic should be that if no value is set in the config or > ephemeral, then the default value is used. The ephemeral value > overrides the configured value. > > OK > > 2) XPath hierarchy is based on config-stmt. > > > > config=true context node -> can reference config=true > > config=ephemeral context node -> can reference true + ephemeral > > config=false context node -> can reference true, ephemeral, false > > > > 3) must/when evaluation applies only to the datastore indicated by > > config-stmt > > config=true -> running > > config=ephemeral -> ephemeral > > config=false -> operational > > > > 4) panes of glass applied to data instances > > all running datastore instances are visible in the ephemeral > datastore > > all ephemeral datastore instances are visible in the operational > > datastore > > > > 5) admin-foo and oper-foo can go away > > Yes, but I assume that they don't *have* to go away. For example, the > duplex example would still have two nodes, since the syntax is > different. > I didn't say "have" -- I said "can" I think the OC folks are right that the same syntax could be used but the operational value would never be 'auto'. A separate object is better though (in this case). > > > The instance of 'admin-temp' in the operational datastore would return > > the value in effect, not the desired value, so 'oper-temp' is not > needed > > and the correlation between config, ephemeral, and operational is > > maintained > > in the common instance-identifier in all 3 datastores > > > /martin > Andy --001a11c3677e0ff924051944636c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> thanks.
> A few details of the solution I am working on...

I would (still!) use a new statement "i2rs:ephemeral true;" to ma= rk
ephemeral nodes on config false nodes.=C2=A0 This can be done w/o changing<= br> YANG.

> 1) defaults are not used in the ephemeral datastore
>
> The default-stmt is altered for the ephemeral datastore.
> Default leafs are ignored (except for XPath evaluation).
> Otherwise the schema default would always override the configuration.<= br>
I see your point, but if I create a list instance entirely in the
ephemeral data store, I would assume defaults in that list instance to
be used.

I think the logic should be that if no value is set in the config or
ephemeral, then the default value is used.=C2=A0 The ephemeral value
overrides the configured value.



=C2=A0
> 2) XPath hierarchy is based on config-stmt.
>
>=C2=A0 =C2=A0config=3Dtrue context node -> can reference config=3Dtr= ue
>=C2=A0 =C2=A0config=3Dephemeral context node -> can reference true += ephemeral
>=C2=A0 =C2=A0config=3Dfalse context node -> can reference true, ephe= meral, false
>
> 3) must/when evaluation applies only to the datastore indicated by
> config-stmt
>=C2=A0 =C2=A0 =C2=A0 config=3Dtrue -> running
>=C2=A0 =C2=A0 =C2=A0 config=3Dephemeral -> ephemeral
>=C2=A0 =C2=A0 =C2=A0 config=3Dfalse -> operational
>
> 4) panes of glass applied to data instances
>=C2=A0 =C2=A0 =C2=A0all running datastore instances are visible in the = ephemeral datastore
>=C2=A0 =C2=A0 =C2=A0all ephemeral datastore instances are visible in th= e operational
> datastore
>
> 5) admin-foo and oper-foo can go away

Yes, but I assume that they don't *have* to go away.=C2=A0 For example,= the
duplex example would still have two nodes, since the syntax is
different.
=C2=A0

I didn'= t say "have" -- I said "can"
I think the OC f= olks are right that the same syntax could be used but
the operati= onal value would never be 'auto'.=C2=A0 A separate object
is better though (in this case).


>=C2=A0 =C2=A0The instance of 'admin-temp' in the operational da= tastore would return
>=C2=A0 =C2=A0the value in effect, not the desired value, so 'oper-t= emp' is not needed
>=C2=A0 =C2=A0and the correlation between config, ephemeral, and operati= onal is
> maintained
>=C2=A0 =C2=A0in the common instance-identifier in all 3 datastores


/martin


<= /div>
Andy

--001a11c3677e0ff924051944636c-- From nobody Wed Jun 24 07:38: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 5F7611ACCFC; Wed, 24 Jun 2015 07:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAUzuXZ3QG2o; Wed, 24 Jun 2015 07:38:07 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 163A11ACD0F; Wed, 24 Jun 2015 07:38:01 -0700 (PDT) Received: from localhost (h-85-24-195-9.na.cust.bahnhof.se [85.24.195.9]) by mail.tail-f.com (Postfix) with ESMTPSA id 37F9A1AE0483; Wed, 24 Jun 2015 16:38:00 +0200 (CEST) Date: Wed, 24 Jun 2015 16:37:59 +0200 (CEST) Message-Id: <20150624.163759.1557296922779722474.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20150624.162356.916556588650610315.mbj@tail-f.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, jmh@joelhalpern.com, netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 14:38:08 -0000 Andy Bierman wrote: > On Wed, Jun 24, 2015 at 7:23 AM, Martin Bjorklund wrote: > > > Hi, > > > > Andy Bierman wrote: > > > 5) admin-foo and oper-foo can go away > > > > Yes, but I assume that they don't *have* to go away. For example, the > > duplex example would still have two nodes, since the syntax is > > different. > > > > > I didn't say "have" -- I said "can" > I think the OC folks are right that the same syntax could be used but > the operational value would never be 'auto'. A separate object > is better though (in this case). Yes, agreed; I just wanted to be sure. I think this is worth pointing out explicitly. In many cases the oper- node is not needed, but it might be. /martin From nobody Wed Jun 24 08:11: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 F1C1B1A8A1E for ; Wed, 24 Jun 2015 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 9BDC9w5mUJUY for ; Wed, 24 Jun 2015 08:11:30 -0700 (PDT) Received: from mail-la0-f47.google.com (mail-la0-f47.google.com [209.85.215.47]) (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 297871A8789 for ; Wed, 24 Jun 2015 08:11:22 -0700 (PDT) Received: by lagi2 with SMTP id i2so28036197lag.2 for ; Wed, 24 Jun 2015 08:11:20 -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=nC7W7neJ012pz/Qc4g3gUsKKQrfLkBbIL2vz+7c9M/I=; b=WAf2MUarxVmdtVhTys2KmalKINI09cYF+A0b+IPqaP0hZZU2sXFP8WF9OtyQ9GNapY iX24DcWWBWO4y16d9k3ia0lv0ni7U9LRJTMbib7Pb/cS6iDNo+MAZNAbE4vCLNz5gi/z X/nSBY7G1wJCBOttBDI5OdZToXBnlitNwc2bSneRc9Y5QIVERznYt93hbh9NfG3d+JjG 9jH0rtfgFLr+zbUtKMz2olWnWtRLC6Iip/matXxOmUzJgXlv/5sGSPQBflS4GB3b8AV2 tt2H6MkkargHsS20cSfqjOqFf6qQhFCTOBf7FshWbqcdmflANsJgMhINKB2m/5/mE2HD kksA== X-Gm-Message-State: ALoCoQkTDMMD3P1vC6fAu6dezF/iZz1Vg9s84dyx29BWBIizgmKeTatbo/zLGQj0IX8WP+jPnerh MIME-Version: 1.0 X-Received: by 10.112.41.171 with SMTP id g11mr9804429lbl.123.1435158680558; Wed, 24 Jun 2015 08:11:20 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 08:11:20 -0700 (PDT) In-Reply-To: <201506241434.t5OEYFF6035611@idle.juniper.net> References: <201506241434.t5OEYFF6035611@idle.juniper.net> Date: Wed, 24 Jun 2015 08:11:20 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=001a11346d9c59f3cc051944ebdf Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 15:11:32 -0000 --001a11346d9c59f3cc051944ebdf Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 7:34 AM, Phil Shafer wrote: > Andy Bierman writes: > >1) defaults are not used in the ephemeral datastore > > > >The default-stmt is altered for the ephemeral datastore. > >Default leafs are ignored (except for XPath evaluation). > >Otherwise the schema default would always override the configuration. > > List instances in the ephemeral datastore with no matching > instance in the committed datastore would need to have > default values from the schema. > > Think of defaults as the pane of glass that sits behind > all other planes. > > good point > >2) XPath hierarchy is based on config-stmt. > > > > config=true context node -> can reference config=true > > config=ephemeral context node -> can reference true + ephemeral > > config=false context node -> can reference true, ephemeral, false > > Are you talking about must/when statements in config false nodes? > yes -- all values of config-stmt > > I think the key point is that the committed config must be valid > without references anything else. The ephemeral config must be > valid without referencing config false nodes. > exactly -- that is what I was trying to say above > > >3) must/when evaluation applies only to the datastore indicated by > >config-stmt > > config=true -> running > > config=ephemeral -> ephemeral > > config=false -> operational > > ephemeral nodes should be able to reference config=true nodes. > An ephemeral interfaces should be able to reference a pre-configured > filter/policer. But the reverse would not be true. > > The issue is where to enforce the YANG datastore validation for must/when. The "portability" of must/when is a general problem, but more datastores makes it more complicated > >4) panes of glass applied to data instances > > all running datastore instances are visible in the ephemeral datastore > > all ephemeral datastore instances are visible in the operational > >datastore > > What is "all running datastore instances"? > All the data instances (like interfaces) are visible in the ephemeral for the purpose of XPath and path-stmt (leafref) evaluation > > >5) admin-foo and oper-foo can go away > > > > The instance of 'admin-temp' in the operational datastore would return > > the value in effect, not the desired value, so 'oper-temp' is not needed > > and the correlation between config, ephemeral, and operational is > >maintained > > in the common instance-identifier in all 3 datastores > > The issues remain: what happens when the set of possible values > varies between the operational world and the configuration world? > New notifications can be defined to let a client know when a data resource converges or diverges from the configured value. > How is that expressed in the data model? "auto" would not be an > operational value for "duplex". "none" would not be a valid > configuration value, but would be the operational value for an > empty port. > good point -- the operational instance would not exist is the status is 'none' > > Thanks, > Phil > Andy --001a11346d9c59f3cc051944ebdf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2015 at 7:34 AM, Phil Shafer <phil@juniper.net><= /span> wrote:
Andy Bierman writes:
>1) defaults are not used in the ephemeral datastore
>
>The default-stmt is altered for the ephemeral datastore.
>Default leafs are ignored (except for XPath evaluation).
>Otherwise the schema default would always override the configuration.
List instances in the ephemeral datastore with no matching
instance in the committed datastore would need to have
default values from the schema.

Think of defaults as the pane of glass that sits behind
all other planes.


good point

= =C2=A0
>2) XPath hierarchy is based on config-stmt.
>
>=C2=A0 config=3Dtrue context node -> can reference config=3Dtrue
>=C2=A0 config=3Dephemeral context node -> can reference true + ephem= eral
>=C2=A0 config=3Dfalse context node -> can reference true, ephemeral,= false

Are you talking about must/when statements in config false nodes?

yes -- all values of config-stmt
=C2= =A0

I think the key point is that the committed config must be valid
without references anything else.=C2=A0 The ephemeral config must be
valid without referencing config false nodes.


exactly -- that is what I was trying to say above

=C2=A0

>3) must/when evaluation applies only to the datastore indicated by
>config-stmt
>=C2=A0 =C2=A0 =C2=A0config=3Dtrue -> running
>=C2=A0 =C2=A0 =C2=A0config=3Dephemeral -> ephemeral
>=C2=A0 =C2=A0 =C2=A0config=3Dfalse -> operational

ephemeral nodes should be able to reference config=3Dtrue nodes.
An ephemeral interfaces should be able to reference a pre-configured
filter/policer.=C2=A0 But the reverse would not be true.



The issue is where to e= nforce the YANG datastore validation for must/when.
The "por= tability" of must/when is a general problem, but more datastores makes=
it more complicated

=C2=A0
>4) panes of glass applied to data instances
>=C2=A0 =C2=A0 all running datastore instances are visible in the epheme= ral datastore
>=C2=A0 =C2=A0 all ephemeral datastore instances are visible in the oper= ational
>datastore

What is "all running datastore instances"?
= =C2=A0

All the data instances (like interfaces) ar= e visible in the ephemeral
for the purpose of XPath and path-stmt= (leafref) evaluation

=C2=A0

>5) admin-foo and oper-foo can go away
>
>=C2=A0 The instance of 'admin-temp' in the operational datastor= e would return
>=C2=A0 the value in effect, not the desired value, so 'oper-temp= 9; is not needed
>=C2=A0 and the correlation between config, ephemeral, and operational i= s
>maintained
>=C2=A0 in the common instance-identifier in all 3 datastores

The issues remain: what happens when the set of possible values
varies between the operational world and the configuration world?


New notifications can be defined = to let a client know when a data resource
converges or diverges f= rom the configured value.

=C2=A0
How is that expressed in the data model?=C2=A0 "auto" would not b= e an
operational value for "duplex".=C2=A0 "none" would not = be a valid
configuration value, but would be the operational value for an
empty port.


good point -= - the operational instance would not exist is the status is 'none'<= /div>

=C2=A0

Thanks,
=C2=A0Phil


Andy
=C2=A0

--001a11346d9c59f3cc051944ebdf-- From nobody Wed Jun 24 10:52: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 E89C81A9154 for ; Wed, 24 Jun 2015 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWFOu5NEtVQ3 for ; Wed, 24 Jun 2015 10:52:04 -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 701A81A9144 for ; Wed, 24 Jun 2015 10:52:04 -0700 (PDT) Received: by lbnk3 with SMTP id k3so31065722lbn.1 for ; Wed, 24 Jun 2015 10:52:02 -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=d1ZEurmk1Km24UUKNj0EXm8F6A8YO/MNFKVxBkj9/9U=; b=ANpa+k8lYD7fxKVOqqVGMHZZKZ6z7lRqK6etHwPOOKV9L2bOy4qEhIhLHQ0EYKjrE3 cII7f1H9fkF9g5dSAJwYeJ4b4BpHnmoCiGBN8BkUwRUkkxIE50qn1320S2wruhWoXPNG 45yBXUmsX1WJ37dUhMAtJwfDOsNBiA5qSGfvHWFPcEyULvVoYOc92RrFqXSeSmI2CM1Y HvH6DFcDmgGTIRMrfUeXdhZsNCmKjsGygJ6eQb7PKIbxuprc6AZC1cJmkq7bxFo13znN LLwV9IbN0Yz46XGfnTqZH1EleZcnvalfJo5oAqWhgpl9Z4Uc622fmrQqp2YLEadhSmEn Vgzw== X-Gm-Message-State: ALoCoQmrfVSWc2bvwZSItOgAl2xY8oR9ikUlXXDZYyOI+xtDdqu5iAbplMPq6lHGHbVVcVQF7R8s MIME-Version: 1.0 X-Received: by 10.112.186.35 with SMTP id fh3mr40959235lbc.82.1435168322812; Wed, 24 Jun 2015 10:52:02 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Wed, 24 Jun 2015 10:52:02 -0700 (PDT) In-Reply-To: <201506241714.t5OHEndU036985@idle.juniper.net> References: <201506241714.t5OHEndU036985@idle.juniper.net> Date: Wed, 24 Jun 2015 10:52:02 -0700 Message-ID: From: Andy Bierman To: Phil Shafer Content-Type: multipart/alternative; boundary=001a1134dcc81315580519472afa Archived-At: Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 17:52:06 -0000 --001a1134dcc81315580519472afa Content-Type: text/plain; charset=UTF-8 On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer wrote: > Andy Bierman writes: > >> How is that expressed in the data model? "auto" would not be an > >> operational value for "duplex". "none" would not be a valid > >> configuration value, but would be the operational value for an > >> empty port. > > > >good point -- the operational instance would not exist is the status is > >'none' > > Why not? The interface might exist but not have an ethernet > cable plugged in. "show interfaces" would show the physical > instance, but duplex could be "none". > > OK -- good point In NETCONF terms, a new parameter or a new operation could be used to read the operational datastore. > Thanks, > Phil > Andy --001a1134dcc81315580519472afa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jun 24, 2015 at 10:14 AM, Phil Shafer <phil@juniper.net>= wrote:
Andy Bierman writes:
>> How is that expressed in the data model?=C2=A0 "auto" wo= uld not be an
>> operational value for "duplex".=C2=A0 "none" w= ould not be a valid
>> configuration value, but would be the operational value for an
>> empty port.
>
>good point -- the operational instance would not exist is the status is=
>'none'

Why not?=C2=A0 The interface might exist but not have an ethernet
cable plugged in.=C2=A0 "show interfaces" would show the physical=
instance, but duplex could be "none".



OK -- good point
<= div>
In NETCONF terms, a new <get> parameter or
a new <get-operational> operation could be used
to read = the operational datastore.
=C2=A0
Thanks,
=C2=A0Phil


Andy

--001a1134dcc81315580519472afa-- From nobody Thu Jun 25 09:35:10 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B9E1A9072; Thu, 25 Jun 2015 09:35:08 -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 3Jb_mcwsJ996; Thu, 25 Jun 2015 09:35:06 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4EC1A9066; Thu, 25 Jun 2015 09:35:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5F0141493; Thu, 25 Jun 2015 18:34:59 +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 ABsP5xeGSKqn; Thu, 25 Jun 2015 18:35: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; Thu, 25 Jun 2015 18:34:58 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A8752002C; Thu, 25 Jun 2015 18:35:02 +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 u71pGDSYWDUZ; Thu, 25 Jun 2015 18:34:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C1FF20013; Thu, 25 Jun 2015 18:35:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 17A26347AC67; Thu, 25 Jun 2015 18:35:01 +0200 (CEST) Date: Thu, 25 Jun 2015 18:35:01 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20150625163500.GB40762@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" , "i2rs@ietf.org" References: 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" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 25 Jun 2015 16:35:08 -0000 On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote: > > I prepared 1 slide (based on Kent's slide). > I am trying to understand the types of data > and how they are identified in YANG and conceptually > separated for protocol access. > I do not understand the 'config ephemeral' on the left side. I think it is the implementation (or its configuration) that decides which data models also exist in the ephemeral data store. /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 Jun 25 09:45: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 E8E611A8F49 for ; Thu, 25 Jun 2015 09:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rKIfKnZdoNF for ; Thu, 25 Jun 2015 09:45:27 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7461A9034 for ; Thu, 25 Jun 2015 09:45:25 -0700 (PDT) Received: by lbbwc1 with SMTP id wc1so49166355lbb.2 for ; Thu, 25 Jun 2015 09:45:24 -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=bywujalZOdC3dPguo7nSfXFXsjG5llcyrn7TpPIg5iE=; b=C5SUnR+dNZPxDbRtGyBELXCrefitRkiNExfvqzd1wFuhUrIU2TAZda4nZ33WOww8Cm 6bfjJwbA/TAQhrpSGDosSekaYvBJE+8szinxRWb9/l10qpbWLK5fx3W9cWQDfBv+hy1W 4/oar4BXzZrPBa5XnEIo7HLrF0jCEx73q3j0KxWX4o6YJ1ChH9z9v+4flJQRf2u0VfCm Bq6tSGEquknSkvPTT8fJn9EcUqV5RO+7WpetqfZaXfAHiULlo5eXdE9Cjyse4VsONkvJ 4v+T78M9oJSyEJs2bRwH10Ydo/21LaeZxrEfWeIhzJzTkQ6MaaMpc+OJFXFX36P9mVI+ h/XQ== X-Gm-Message-State: ALoCoQkWu5E99IdicrRzIzloWtNBN96IBsZfSPxntybLCyjW9qjcgxaO+EuzR5aUd1p4CXj2+7Mg MIME-Version: 1.0 X-Received: by 10.152.36.161 with SMTP id r1mr45730189laj.88.1435250724291; Thu, 25 Jun 2015 09:45:24 -0700 (PDT) Received: by 10.112.200.102 with HTTP; Thu, 25 Jun 2015 09:45:24 -0700 (PDT) In-Reply-To: <20150625163500.GB40762@elstar.local> References: <20150625163500.GB40762@elstar.local> Date: Thu, 25 Jun 2015 09:45:24 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , "netmod@ietf.org" , "i2rs@ietf.org" Content-Type: multipart/alternative; boundary=089e0158b5e495ded205195a59ab Archived-At: Subject: Re: [i2rs] [netmod] extended datastores slide 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, 25 Jun 2015 16:45:29 -0000 --089e0158b5e495ded205195a59ab Content-Type: text/plain; charset=UTF-8 On Thu, Jun 25, 2015 at 9:35 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote: > > > > I prepared 1 slide (based on Kent's slide). > > I am trying to understand the types of data > > and how they are identified in YANG and conceptually > > separated for protocol access. > > > > I do not understand the 'config ephemeral' on the left side. I think > it is the implementation (or its configuration) that decides which > data models also exist in the ephemeral data store. > > This is to allow for data that can only be edited in the ephemeral datastore instead of running or ephemeral datastore. It allows the XPath (and other rules) to be different than the existing rules for the running datastore. My slide did not go as far as Jeff wanted wrt/ allowing ephemeral data to reference operational data, but I think this would be OK. As Jeff pointed out, the ephemeral data does not exist until a controller creates it, unlike the persistent config that will be applied at boot-time before the operational state exists. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --089e0158b5e495ded205195a59ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jun 25, 2015 at 9:35 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierm= an wrote:
>
> I prepared 1 slide (based on Kent's slide).
> I am trying to understand the types of data
> and how they are identified in YANG and conceptually
> separated for protocol access.
>

I do not understand the 'config ephemeral' on the left side. I thin= k
it is the implementation (or its configuration) that decides which
data models also exist in the ephemeral data store.



This is to allow for data that can on= ly be edited in the ephemeral datastore
instead of running or eph= emeral datastore.=C2=A0 It allows the XPath (and other rules)
to = be different than the existing rules for the running datastore.
<= br>
My slide did not go as far as Jeff wanted wrt/ allowing ephem= eral data
to reference operational data, but I think this would b= e OK.

As Jeff pointed out, the ephemeral data does= not exist until
a controller creates it, unlike the persistent c= onfig that will be
applied at boot-time before the operational st= ate exists.



/js



Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--089e0158b5e495ded205195a59ab-- From nobody Thu Jun 25 10:02: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 07F571A92B2; Thu, 25 Jun 2015 10:02:29 -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 p_DiMen57NNV; Thu, 25 Jun 2015 10:02:28 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDFF1A92B0; Thu, 25 Jun 2015 10:02:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.187.115; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Andy Bierman'" References: <20150625163500.GB40762@elstar.local> In-Reply-To: <20150625163500.GB40762@elstar.local> Date: Thu, 25 Jun 2015 13:02:28 -0400 Message-ID: <00fa01d0af68$b86f0ed0$294d2c70$@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: AQI38j8X2xhzt+7kOgR7BWPTAddxTwJDuLianNzO9wA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide 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, 25 Jun 2015 17:02:29 -0000 Juergen: Where would you put the "config ephemeral"? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, June 25, 2015 12:35 PM To: Andy Bierman Cc: i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide On Wed, Jun 24, 2015 at 06:24:25AM -0700, Andy Bierman wrote: > > I prepared 1 slide (based on Kent's slide). > I am trying to understand the types of data and how they are > identified in YANG and conceptually separated for protocol access. > I do not understand the 'config ephemeral' on the left side. I think it is the implementation (or its configuration) that decides which data models also exist in the ephemeral data store. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Jun 25 10:12:04 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6721A92FE; Thu, 25 Jun 2015 10:12:02 -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 vm349fRkTTfh; Thu, 25 Jun 2015 10:11:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E6751A92F5; Thu, 25 Jun 2015 10:11:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BCE44136E; Thu, 25 Jun 2015 19:11: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 6WD8eQfMD1pN; Thu, 25 Jun 2015 19:11:56 +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, 25 Jun 2015 19:11:54 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1623B20031; Thu, 25 Jun 2015 19:11:58 +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 qBal91eMzAFp; Thu, 25 Jun 2015 19:11:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4719F20013; Thu, 25 Jun 2015 19:11:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 5B90B347ACEB; Thu, 25 Jun 2015 19:11:56 +0200 (CEST) Date: Thu, 25 Jun 2015 19:11:56 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20150625171155.GA40931@elstar.local> Mail-Followup-To: Susan Hares , 'Andy Bierman' , i2rs@ietf.org, netmod@ietf.org References: <20150625163500.GB40762@elstar.local> <00fa01d0af68$b86f0ed0$294d2c70$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00fa01d0af68$b86f0ed0$294d2c70$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: i2rs@ietf.org, 'Andy Bierman' , netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide 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, 25 Jun 2015 17:12:02 -0000 On Thu, Jun 25, 2015 at 01:02:28PM -0400, Susan Hares wrote: > Juergen: > > Where would you put the "config ephemeral"? > Perhaps this is not needed. /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 Jun 26 10:03: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 46E111A8945 for ; Fri, 26 Jun 2015 10:03:45 -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 rd42AZHg0m5c for ; Fri, 26 Jun 2015 10:03:42 -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 02A591A8978 for ; Fri, 26 Jun 2015 10:03:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYA64036; Fri, 26 Jun 2015 17:03:37 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 26 Jun 2015 18:03:36 +0100 Received: from DFWEML702-CHM.china.huawei.com ([10.193.5.72]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Fri, 26 Jun 2015 10:03:26 -0700 From: Linda Dunbar To: "'i2rs@ietf.org'" , "alex@cisco.com" , "Jan Medved (jmedved)" , "rovarga@cisco.com" , "nitin_bahadur@yahoo.com" , Hariharan Ananthakrishnan , "ttkacik@cisco.com" Thread-Topic: comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4g== Date: Fri, 26 Jun 2015 17:03:25 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.142] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C72B8Adfweml702chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2015 17:03:45 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C72B8Adfweml702chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alex, et al, The I2RS architecture depicts two types of interfaces: - One is the interface between Agent and Client, and - another is the interface between Agent and Routing entities. The network model and inventory are more for the interface between Agent an= d the Clients, isn't it? One single routing engine doesn't need to know th= e overall topology and inventory information of other nodes, even though so= me may do. And the /nd:network/nd:node and Termination points are more for the interfa= ce between the Agent and the Forwarding Engine, isn't it? IMHO, the information models should be oriented around the I2RS architectur= e. I.e. with description on where those information models are applicable, = making it easier to differentiate from other IETF WGs work (such as L2VPN, = L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session= . I2RS Agent is like the SDN controller, which can inform clients about the t= opology information, instruct routes to routing engine of multiple nodes, a= nd retrieve link & termination points status from each of those nodes. The "Service Overlay" in Section 3.4.8 is definitely meant for clients not = towards individual nodes. Mixing them all together make it confusing. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C72B8Adfweml702chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alex, et al,

 

The I2RS architecture depicts two types of interface= s:

-     &= nbsp;    One is the interface between Agent and Client, and =

-     &= nbsp;    another is the interface between Agent and Routing = entities.

 

 

The network model and inventory are more for the int= erface between Agent and the Clients,  isn’t it? One single rout= ing engine doesn’t need to know the overall topology and inventory in= formation of other nodes, even though some may do.

 

 

And the /nd:network/nd:node and Termination points are more for the interfac= e between the Agent and the Forwarding Engine, isn’t it?

 

IMHO, the information models should be oriented arou= nd the I2RS architecture. I.e. with description on where those information = models are applicable, making it easier to differentiate from other IETF WG= s work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session.

 

I2RS Agent is like the SDN controller, which can inf= orm clients about the topology information, instruct routes to routing engi= ne of multiple nodes, and retrieve link & termination points status fro= m each of those nodes.

 

The “Service Overlay” in Section 3.4.8 i= s definitely meant for clients not towards individual nodes. Mixing them al= l together make it confusing.

 

Cheers,

 

Linda Dunbar

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657C72B8Adfweml702chm_-- From nobody Sun Jun 28 18:16:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C371ACCF0; Wed, 24 Jun 2015 07:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fHGBoabSM1MI; Wed, 24 Jun 2015 07:36:00 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229981ACC91; Wed, 24 Jun 2015 07:35:59 -0700 (PDT) Received: from BLUPR05CA0050.namprd05.prod.outlook.com (10.141.20.20) by DM2PR05MB784.namprd05.prod.outlook.com (10.141.179.155) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 24 Jun 2015 14:35:59 +0000 Received: from BL2FFO11FD038.protection.gbl (2a01:111:f400:7c09::146) by BLUPR05CA0050.outlook.office365.com (2a01:111:e400:855::20) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Wed, 24 Jun 2015 14:35:59 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BL2FFO11FD038.mail.protection.outlook.com (10.173.161.134) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 24 Jun 2015 14:35:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 24 Jun 2015 07:35:57 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5OEZuD34077; Wed, 24 Jun 2015 07:35:56 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t5OEYFF6035611; Wed, 24 Jun 2015 10:34:16 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201506241434.t5OEYFF6035611@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Wed, 24 Jun 2015 10:34:15 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD038; 1:rpKHY1Bv7/nbDAom8GCBGZC/v0RAo3gTPMExFly1GAhCuWB66gKgUqWKO7EWTFgqs/85NL/gyJUTAZmUR9r0N7CtVV53DGu9w/GP1gNSx4NS10H2ubyziRr46R0Uia4tm8j0epULiiEp7ZWn+uVZpP7qDvPQPNrF4AO7yj5/SCCP7mmPXJe038ThpYKn0ttGGQDGoH788v+anYlfgWbePVfhJZGd2JXwquyU6y5O8Tqqt3O8Y8Q8Voh6AkEHPYjrQgjtWhWPGsG+lYxsezqe3ij0Mt1zoEm+dCZbqJVfkNKf2yHzTM7nrqz6YrHRKktyFYJSD4HfmGMQ2Bfpq4AIkw== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(164054003)(51704005)(199003)(189002)(110136002)(86362001)(77156002)(47776003)(50466002)(5001960100002)(5003600100002)(87936001)(62966003)(189998001)(106466001)(54356999)(77096005)(2950100001)(105596002)(53416004)(50986999)(46102003)(6806004)(48376002)(92566002)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB784; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB784; 2:7aWfOnq++csZjuTEzpw1lbCcKZm1vkf1gwAQYuycf2Xy8QVU1UAdZd97jlI7rXWu; 2:pPmHM9C6DxdZ1FWJYD3BvKdlV4lrfU7lhpNmdyvglL3ti3cVmCp47Wln0pEBdagVwEELpYZAKcIqOSScpgH+TrF2IYpg0jIEnIJwMfO3QEpkHFEAINMZpphakMze2SC7XYIuZMqs/rq7aySUeSs6o+TASJV/P6Q07LF6nIIrFL9Qd85XB0HEToY+Yb0e8HWgoAlujgl1CZ3p1YNwRj2tXY3+wRi02VMeq7dQOauoIDs=; 6:3M/0iV9e+RefiCpGlTyMDrwJfaSHXgMSPlcBFEQiw8ZHJp65z+5E6FnOsikTZIT6c3tQpjkNEXU6WCUm+w2tRERKmQGdnei/AMBYhIV8xI+OPeK3rf+6UvQ/ZJyqBYy+crOCfzVohe5VwSo9wxwmEvUBUs2sWTD7s8TRb79/+KEPiUVkVPHGSi9fBsgYt4AwkxioW9fkw0k8i9eH+JXisL6lkbW7walOLsFV2EbywjuRvrNN3SyB/D4vRyjplwMd7bKuTaJPytWXGt4RGAUhDaEZopD3+CrRKkSHEcPRHs4WRlH4CfyANlJLypq++FwLNQfRYWNDzaSiXYYcl6688oYq0c1Ys4h+FoviHpIGnXoVdHgGFlsCzekojnh4jaTJyBNMyrIcapPcpLQHvm9lL0YWkgr6JfCkn3iGHbH/gdjnwWpy0vmi6ykcNt0NoYliW4jPTFnc9VyJhu1mkKnol4GkCHezKpH6RJ/SSG1a36EXVpgNJUm7JbH9OrX3YZlz X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB784; 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:DM2PR05MB784; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB784; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB784; 3:RRyNjKWHCnQnfCo3kwL92fhuhe3toFatdDpgs06EnjC3DaBs8JCcJ77n4u5W7NhP6LEqIPz1owT27C3wK6gkzdyT71uRpDWH9nB0gxZ46PJjUCt7NopRzyG9YwjkG7cDNStJDxQv4rB+uM3ZDWG5ibDvMJJ+aRrOnPXOn5dzr6XkoIbp8DJ6tR/s7bio+frW+LxrvTior1frIKa/Dmlzf4IU1A5iWW5Nk0QKgtOnS4CzxyTsJGLSq2V8xezsiZsKdJGakRV5A7yzvO3mgJv4pyUMqto47OG/EK0+r1zWXAI= X-Forefront-PRVS: 061725F016 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB784; 9:s6yyKQ7NqGvYIzffftmLLUwr4JBXNMT9S0qajrs9dnmwZZTcDD6svlfXE/+cJMW5mHnKcmitDOWe1Fyeq6hbKsoD9Zg19AA7LWeIQlKgR3f6nxad2Cj8lA5JcjHaSQEgjeTjywjTINgkF7s9Ya/zLiNu3qTs8HTfpN7t5EZHolC3cRaATnlQFph5HFC3u4kRKxCBVSd+Hp2aDnRVzIV7mYilznoB0WNtjuE0zUIuvHknIZmlHThG3ejjjsdTnDYK1QrE0innPIYTEccGYYbfMWQhc58Y2Vrp9jzKabtnOHDAxC9fBFTumTvNK6dAWpNJFMgfbWVygN4KY6tCVU9jZO1VVVBIQ9aSBdmeR8+CzNZwUsIqE2cjCVy3mCxbL2DNCX/i27YnXyHn5fDnHeWOyiBjJtk1ZoygwgJZ6pvyRxMZ0eXyGF8JQGyLF8VRb/ohic/N3/cVLCgEdu5BooOJfCy/Bdru0c7zJdH4EBp//7eB0aUB0e4wT6c+Tcv0TIbZrgN5bRyWIGB7fxXiPqdmm8lU5Ljxmcf29VBmzZ36Q6e+Os3FBQEfclu5DZP8/N4e3MVLGujSt0me5KuSR/SI6sg4eVz7lvl8FfYLKwV97Ah9KZR/tjJadrU8fhqCSV0V2dWy34JTPHyRqnG+kVPNdKPiIZr+hJ7XJmktxC5POqvzpOxS/FmbqJ0eUt2Dyf1c6nRVeqhaVkxM5c/RjfA1Ye4/mLAFo03PZP2y+cK4LLFAwPotkiOOl2kgUWWq05FR4GlVK9b7pq80jNJx6gflOw==; 3:u63Mpfi6Sg2YfXHkQBfCmXZqoJPhKo1MMDMOzTALxb1ad5Gu8TDozbVdbu9sd0cKjvVPwADKwx0q7muyUXhsVLHBelOGostQAoXU9mDYvaqQDOsdA+gJkwAHXN29e3umTwUaphKLna6LIvDzifycAg== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB784; 10:zQtB4wwOd3q3WN808STyAyDb1XlB3q4CtF/HcwZ3woodktGH7/UynCxhOBDldZFVqxIIYIU2vbgaXcUFaO7rLY4gESCVK375mVViydgYsBM=; 6:Nt04jNGQySC0Ij2IoZDWSN6lyez3XCHP1a9xSwneRTm6WRKQ4v4vstwJggP3W189 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2015 14:35:58.4989 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB784 Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 18:16:45 -0700 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 14:36:01 -0000 Andy Bierman writes: >1) defaults are not used in the ephemeral datastore > >The default-stmt is altered for the ephemeral datastore. >Default leafs are ignored (except for XPath evaluation). >Otherwise the schema default would always override the configuration. List instances in the ephemeral datastore with no matching instance in the committed datastore would need to have default values from the schema. Think of defaults as the pane of glass that sits behind all other planes. >2) XPath hierarchy is based on config-stmt. > > config=true context node -> can reference config=true > config=ephemeral context node -> can reference true + ephemeral > config=false context node -> can reference true, ephemeral, false Are you talking about must/when statements in config false nodes? I think the key point is that the committed config must be valid without references anything else. The ephemeral config must be valid without referencing config false nodes. >3) must/when evaluation applies only to the datastore indicated by >config-stmt > config=true -> running > config=ephemeral -> ephemeral > config=false -> operational ephemeral nodes should be able to reference config=true nodes. An ephemeral interfaces should be able to reference a pre-configured filter/policer. But the reverse would not be true. >4) panes of glass applied to data instances > all running datastore instances are visible in the ephemeral datastore > all ephemeral datastore instances are visible in the operational >datastore What is "all running datastore instances"? >5) admin-foo and oper-foo can go away > > The instance of 'admin-temp' in the operational datastore would return > the value in effect, not the desired value, so 'oper-temp' is not needed > and the correlation between config, ephemeral, and operational is >maintained > in the common instance-identifier in all 3 datastores The issues remain: what happens when the set of possible values varies between the operational world and the configuration world? How is that expressed in the data model? "auto" would not be an operational value for "duplex". "none" would not be a valid configuration value, but would be the operational value for an empty port. Thanks, Phil From nobody Sun Jun 28 18:16: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 5D86A1A00C8; Wed, 24 Jun 2015 07:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0o6mnTJcL8pw; Wed, 24 Jun 2015 07:48:14 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0141.outbound.protection.outlook.com [207.46.100.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BE91A008A; Wed, 24 Jun 2015 07:48:14 -0700 (PDT) Received: from BY2PR05CA042.namprd05.prod.outlook.com (10.141.250.32) by DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) with Microsoft SMTP Server (TLS) id 15.1.190.14; Wed, 24 Jun 2015 14:48:13 +0000 Received: from BN1AFFO11FD011.protection.gbl (2a01:111:f400:7c10::138) by BY2PR05CA042.outlook.office365.com (2a01:111:e400:2c5f::32) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Wed, 24 Jun 2015 14:48:13 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD011.mail.protection.outlook.com (10.58.52.71) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 24 Jun 2015 14:48:12 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 24 Jun 2015 07:48:09 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5OEm8D41609; Wed, 24 Jun 2015 07:48:08 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t5OEkRQN035789; Wed, 24 Jun 2015 10:46:28 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201506241446.t5OEkRQN035789@idle.juniper.net> To: Martin Bjorklund In-Reply-To: <20150624.163759.1557296922779722474.mbj@tail-f.com> Date: Wed, 24 Jun 2015 10:46:27 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD011; 1:sEshYaY/uE2fwSgVxC4ldhDTbyZA/e3snCTQ+Wg4vKXgWSSW6qSz44TeDzJ7268cTkV0s++GTFpB2wIjEb/xi1RPlbW9OftklAehp2EwxcTM5p395A5mzYOwIzuPSRXTRHl08QHVMJDqlS3BnTKaGBMcNGFnLZEyCqs7VqYaq2Kh5zrB8bXOoikVa92DEVHI169I7LulJO1i2axbq/W91j4gklszimftqerT7xgsCE4pgFDLUJ5MmNuBHwv53tOW1CMgJjwSMGLMzQXQUL4TSspBvd/0yZvB6aO8FUS7XZwYw/X/vBWXlsEay873iO7h7g0GOmZFcS7F7Ny2FHTSgw== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(164054003)(189002)(199003)(51694002)(6806004)(86362001)(50986999)(54356999)(62966003)(87936001)(47776003)(77156002)(2950100001)(92566002)(110136002)(5003600100002)(48376002)(53416004)(106466001)(5001960100002)(50466002)(46102003)(189998001)(105596002)(77096005)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB781; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 2:6wSj7Iz/3bOOVil+CO2DB90D3G9mnT31xl4sg9tOVX6kFqsgr0C5wz2zrQgLwdFP; 2:lC5uXGOFiAxjnEE3zWXwFqP0Kd4q9xHmUNKATRBgQNrSCMQRwewGs1+PNW47BQGdcsHgRDbnz/bgwl0kcQtjVf+fpz2IrcMjj2KIiRzzkijwsJbKNSNV/mQx1Wi4SvKNXHVeamo8TLxvVWm2dhW5NwX0iNiOYyhxWyT7KPN5WZbiEyP4QItCYjzR3KMrNimD/2EW3qLzZFYYOJK4x2m1GASNxdy1QY0uDv+RL9tEEBA=; 6:uLRX2AVO6SqXnloaI84I97rSw3vaiFYzd47rOk4oGpGWla5n6K10ZCdFkfYNCzpDaSUh6bACMMx0soUGGOTjX0Y1X65BthSsvNM3/z6XXzUyHM2e+cbnrY8QOv8dscPHFjliBWVmcsc/woLI45505cNsqTaWBF3z2/5g8IqC+BReGFXbB9PBE4aHSb6g6s3mLmouELQ99JJfw6Dmo+fzs9jRhGDwYemJEVPSczkcDbGlj5nFaaV7ftX3U+VE49oWT6FVAxx5ZXJqByU51B2hHbl2iH4ZMFWJtsKz4iY73i4AR0pMUe3xAWpsp3P/PGeJKSXGLZFucSwSFAjIi7eWEg8YwF2X7aFcZmMT55ZU3hgxF16NZf0R/jz1F7av0PwmJjmcAyLtys3nm4fmBGdM1CwSzV29SsGH1ugtx2GtOd+K9p+4jPPwW7pC9wUEkCGtYBzCJtyifCa//MLyNPZrxO/McaEeyNuR6AH9DmMcZZvg7hZqP06CYTTvWwYYLsQI X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB781; 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:DM2PR05MB781; BCL:0; PCL:0; RULEID:; SRVR:DM2PR05MB781; X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 3:zloAfsKhNqk3CSKg+Y3XJS2wyhZlcj4LkHiHFdDQfRkf5u11udtIuAXkViGv1H9xagTuGxsF2TW8+4Izl3YMmQ2vVpI7d2QSSqs6bB7dtEpCki9eOdGUa259N5Jm5cb9oVtTD+dxLK71RarTymFU07fqFPT0R6OK8/eH3Rc1yMCp8wGuoRjAAs07Iznsy29dDAd2GtfTHs3Qx/pWELr3tZ9Nr+gmcqb0nW2IuERekPDRow3TVOPwTe8QYYzxzXAA1uUPREeeE5DF2kGZkT3kGQaUu6o953TWW18AN3rRQoU= X-Forefront-PRVS: 061725F016 X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 9:6oQRABzzq+WCfY31NaRafK7u8SxydQxUQP3O5YuSstEYUFlziJy/C8YtrPWnP2nnrWz8aKaTIq1+bcXF5F4Q+vd3cSKzu7PHYg6Oh2ZnwH8CR/0N5rquq7hwmCLXhO1VtmpzGZOXGLSWMsyEVmTgsGesbdcuRp+IY2xecrM2dHg68sFv1qVtMR7LHqXgKzOESvkaVBM+t6y7ARMjdAKWiYtedytdE46L66CvfdWq1kd6Q/pQWtJKUDvI4Ph8yeLPn2/OH9x7IA3NuRHSN9DsUUZaWwnK5DeuEx+X5lzIgMEbqNTKBOUrkOSrkqA8I61i+2ghxx34MVMK6rGyK+Od+JaUgoAGcik1/FGKA5j2E+hsIdpLxPL1bR2la5hlHj7qcT2QuMMPuCdYVQfpUstm0qj0BGPRkK6HeMlR3/UOm4fEcy6RHF4red/gHq3irsoq+Z7CxAku+y3aPq4uAZtBJ0BRvYnDVrGBUky45Bmshf5U7a4MzuSKkEmfXYEx7NDIHds0GtboyPzJYatdWG09l+w6LYUxaQCNwGQYZfRPHo/DDk5628zb1cytfbV8DSImlHaXaCCoNXucVIdStYm+jLyzwiBz/P8YIp9JQpuEtr7TsTrY+E8XYShogpH59c3F7hTj/PeA+M0iSMJx39oZdkQcVT3zAF9SenXeH94xnqE9nfr4CO/WJymAm+bVaIOWJ6DaFhmOd5DnlIayhMC8dKrkup+2spl6UeD5S0poruRQlShN0lx2MxgbRmk0NybvUXLbMJ/QUVytrhWmpzx/Vg==; 3:3OGR2xedJbXYkTtyyHdwW/O0+JQRyKkzX2lvpd1gYvywyyb7dfAjLimU3nADPk+dSn/LdsRT4559LzrXtI8HaNnnP9823sTWL1ksUZ/pu3hUkAarhkvJJXWAr+nHl63p42gXkPTUrFVeDdskvp/kQg== X-Microsoft-Exchange-Diagnostics: 1; DM2PR05MB781; 10:n7DMnO6VdHWcBeixMYDne4J6kQgPVDAA+GuIRx1wTIprZ+40HCbBa7zEdhm6N5Qo2Vr98XihVpVrmPrCwBj4PBYxf6410R3cz6pU8smKcGQ=; 6:qGxM4xCO1VTBpvdFAJPpJxzsYyFYkxFzhgjqChUPV6WjmB6MvBNSxWV6iEh29fFn X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2015 14:48:12.0666 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB781 Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 18:16:45 -0700 Cc: i2rs@ietf.org, andy@yumaworks.com, netmod@ietf.org Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 14:48:16 -0000 Martin Bjorklund writes: >Yes, agreed; I just wanted to be sure. I think this is worth pointing >out explicitly. In many cases the oper- node is not needed, but it >might be. Would we be better of having YANG statements that detail the way the model changes between config and operational modes? Otherwise the tie-in between the oper-leaf and config-leaf needs to be modeled. Thanks, Phil From nobody Sun Jun 28 18:16: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 DCE491ACEC6; Wed, 24 Jun 2015 10:16:36 -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 Kx0HRCGrD6JT; Wed, 24 Jun 2015 10:16:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0101.outbound.protection.outlook.com [207.46.100.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F2E1A8BC0; Wed, 24 Jun 2015 10:16:35 -0700 (PDT) Received: from BLUPR05CA0041.namprd05.prod.outlook.com (10.141.20.11) by BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 24 Jun 2015 17:16:34 +0000 Received: from BN1BFFO11FD035.protection.gbl (2a01:111:f400:7c10::1:170) by BLUPR05CA0041.outlook.office365.com (2a01:111:e400:855::11) with Microsoft SMTP Server (TLS) id 15.1.201.16 via Frontend Transport; Wed, 24 Jun 2015 17:16:34 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.18) by BN1BFFO11FD035.mail.protection.outlook.com (10.58.144.98) with Microsoft SMTP Server (TLS) id 15.1.201.10 via Frontend Transport; Wed, 24 Jun 2015 17:16:33 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 24 Jun 2015 10:16:32 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t5OHGUD22003; Wed, 24 Jun 2015 10:16:31 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t5OHEndU036985; Wed, 24 Jun 2015 13:14:50 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201506241714.t5OHEndU036985@idle.juniper.net> To: Andy Bierman In-Reply-To: Date: Wed, 24 Jun 2015 13:14:49 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD035; 1:FJBdVZzBD1xhK7jqyxgi9IngzKDR7npkq6OA5h4T+pb0XKg5MNXwHPaQ3u2Gzgw5/FNp19aNcMDZ+Wm/HcveyXevcQJFtu43isvcxxfxq1dLzLWeX/5y6qm5Wf0EJ+fqcoh2tfEiPDBvRFTGJkAFZnBC/UKKxwzXR2UE930vjpPk387RUbg1nMIZzbaH/94rJKHkMaRlSJj9/daABgM8W/lNFCfXhaY2JEWAX2Y/a1aXq01zS3g9TUuOsxzlf2xqDVa+mdE+4Y/4wwD5PAj9oIdALvp0J6p65rMoYlub9q+DT/cJryNzyjM8+BDtKD0yxv1BOF3JUVUu/GPolcT3Eg== X-Forefront-Antispam-Report: CIP:66.129.239.18; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(164054003)(51704005)(189002)(199003)(87936001)(46102003)(76506005)(106466001)(47776003)(86362001)(6806004)(77156002)(62966003)(54356999)(50986999)(92566002)(53416004)(50466002)(48376002)(5003600100002)(5001920100001)(77096005)(189998001)(105596002)(5001960100002)(2950100001)(110136002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB706; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB706; 2:jHatMoXNqFMrUB80gTfl6bGHn9cea1prstsTBGYmRVxoR4YeFGwNiyKy5IdlWpQn; 3:8v7QAvNNKwsEBbdguq4fsEnC3AbnJWVbRab/xppKYWsrMCbtZROoSsAGmdmktltlHZIqK28rBfLk2GB7FU2P6wYK6+HXyQQ70fleXD54unK+JV4QsSjgxi/yrOqFBe2UEs6SJTfoor4zO9NcQCSpqOquXZQpNexufe6eREPSXyTL9PH2QzYy5O3QNVrSqaYdd/Wx4BDtKDMykPoC/uYRyiXj2y6AJtV5xkgPbE1Qvkc=; 20:PzTam0txxA+lkEPXi4nSWXzmwQtxJp8S1kexG0wI/ymEehxHqDYFlTWWMmZB3dbac2ocCoXvyHL/B8mzKHFG4Iq4vZI0r3mLaUydKvtxwxUC6ACM4BvY9PXOxQw/UgKM5g8HpZ8xy9FFVeBMvXW6+xygGB8ErzneWPjc9Y26L4c23uOXHYw/39WHU2Tu4V3iR6x9/iMglPIIN4WI6NZgsYcs5BVHI7OvXnK6BQY6CHFPefTBtEWNpo85Z4Avx5TQPWoPba3Q84D1zGNjK2ZQvc0W4Nxgp9spvPSqFPXkLt3lOH6yIIuhoqKx/QdFf7MDklDWorzleCEeOShoEZTQU2XEEhdWj7uM8JMnlLG8RRoiJfHv3kydh3ivbb1itgZqYC4SHGlMMvx1oNmdeQe4BuMQFkhO9wtFATeZt2uKDIcLaQYnIr+mcX5jDrEd2pd0auBhTE40WR0JF1kZQcAw7ZlE/b0T7jC/4RVKZsvOo4MxHZLQ1TFR9/njdfMfY1Pk X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB706; 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:BLUPR05MB706; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB706; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB706; 4:AETYKrrVXDU8P3QbLbDXFlgk9EWqtE8nr8rpd5Ohv1OAzHg/2uj9qZ2sqwPV0ZOQEDtR/JeP/pieHNJzRoRYm1sbh42ZIuMDUsyU8E7PWI+t5A+DO5n8uH6SapSdGfD59yiP0p9wSHZM3p9K0311k4Iu/xo9Qpxj6KJ3xhGbtGnGnmUqNa1+7ITcBv/ZmXRnT29E/W4QtdYgH0RI9rtZUti8oqeEIuH3sT+nf3AMEQWRLDCO1qbY52CgidNPij7f+lMuEtumM68otRFpnZ27aLouqx+iw5TIdKP5LukGoCs= X-Forefront-PRVS: 061725F016 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB706; 23:Opp7Zrwu8PEj1IIznP3kQuO4PgQLoC0c47CLItayIRE+PISZBj0eSl4vVojHecT8R78FbdMtnKMmW7FA/6/PYn1Dx3I7sTcMf2mV9RXBdyfDVt9gCxFevxiBIy4LEDxNxZJxanjPX+fMXdlpLkPr1IZYqCSaM+fmDmfnNpuaAD8r2CmYOc8HBMYXD12NnqWUH0FlPu/294v+M6qe9AuD0DpbqmeLgO8JvmQdJzukRpSpzU8n0VKoW+6kCo9pxgU2Q2zrMew8Cjb8cWT/WOEbbJ+2C+jRNEtXmslt5B3ELimyDY2kUgaKVEhQ7t1gYhXmz2btuccRknwi6wvGbYp6zO8yDpcgw+EodjJiQBlWwuTlAPI8k6+/BxPNI9LmBayNZoXq73LeKqBpiaK+k/nZJD4nSqJ0Ki7HREVSRikBlbGVWjfS5FuvMXAv+j7J2+5gJyP6lA5Y0iESoRV2schVqMW3LSI+W+GvxV/S5N6KPGB/otKt9K5CO55HeK8l/mZwDug8wQLOmb8kymv073+O2Yp2s2mZ+7IQCOqH1+MjB5ndRLWMBuh7guVQwO2r0OrjtlISKqCsuq0jQG9+V8wfbyrobTirRw9SkhbsYOjIkHTKxxBILkoE7Ph27d01RmaXo7TViFH3JwEwzcwywRKxDr2m2tLAaLV1SrCkQpnG2x24RHUq0BKK14vJ//jqdeT5k7qdgUgG+1PlrKhx1JnZ7ZRbRjagDdTXNNf0vCz35oNfIftehoyEb7fUG3HrPbEu5uz3ZBNwDAqzqZwReVO4dmAQKNWfgkHs6TkZDnAUjco=; 5:vorA4gSIgo7ggMsP7HfHzortc1WCUT+Hebl8+CRjbiUBJG8fJsnk8Q/cmjkIH9xaVs6/ECmZAHg7KEAFsusfhp2Flg91+ERfmy24pfHV8kVQ3p0UG4xREyEJekHACX1iwNb2he6N06TLi0un5JJ+4w== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB706; 24:SRIZAL3DioxD5Qf6qj72GgNcJtZOX6GiLai8McZDN8oR88B5JYdwAhrM+ar8dBf3sTBXeMPpots2soZkIyTCzZdzP/2PewG0SMtMROqw/00=; 20:aDoSQZjWUTNjAjI9EPiCbd7njLMHad1cg4GJdi2sEoLYEzdbpLRf4Q9KB+A5yUOVTzMTddV20M3nWaWBlwN4oA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Jun 2015 17:16:33.5108 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB706 Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 18:16:45 -0700 Cc: "i2rs@ietf.org" , "Joel M. Halpern" , "netmod@ietf.org" Subject: Re: [i2rs] [netmod] extended datastores slide 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, 24 Jun 2015 17:16:37 -0000 Andy Bierman writes: >> How is that expressed in the data model? "auto" would not be an >> operational value for "duplex". "none" would not be a valid >> configuration value, but would be the operational value for an >> empty port. > >good point -- the operational instance would not exist is the status is >'none' Why not? The interface might exist but not have an ethernet cable plugged in. "show interfaces" would show the physical instance, but duplex could be "none". Thanks, Phil From nobody Sun Jun 28 18:16: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 AC57D1B2D08; Thu, 25 Jun 2015 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=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 YHep7wOhqKo3; Thu, 25 Jun 2015 16:43:42 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E081B2D05; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) Received: by padev16 with SMTP id ev16so58038595pad.0; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=b45Eok58qtbYvm5jmXNHl33E1D/lK8NHJ4p489jRVkM=; b=znOB1BzNsZOtFApeu9xmjRsuFUzIkotVICWe7yep/3OQ/ESx3d1KPkBFi9L9CRVmSA Myg61BKXEqa1BCzmvcZ4YhZ5cWdYUMvV5ZWjSR6KvR90ol3wXjpnBH2XC4d6FgV9JetJ O7ae9PR01Etl5KuhjIn3IbhH/pRKqsZV0uiAdRavNIUPKNaELKtSeMsI6zUAcM1rJL/e WOSaMlw7/0opKeuukQrdgvq9COGYbxxxcHsj23RSbsRQotT0YkpbAZCheCvVlP/VI5EM Tzw/TGRHE4Q5VsguLBFQ4Yhg47StKboWzKEbJuwBgJnq8tTHWGeFZyIPJSNypE6Y6cw6 bBlw== X-Received: by 10.66.119.136 with SMTP id ku8mr224953pab.93.1435275821599; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) Received: from [128.107.125.67] (dhcp-128-107-125-67.cisco.com. [128.107.125.67]) by mx.google.com with ESMTPSA id fr2sm31240768pdb.22.2015.06.25.16.43.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jun 2015 16:43:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Thu, 25 Jun 2015 16:43:31 -0700 From: alagalah To: , , , "groupbasedpolicy-dev@lists.opendaylight.org" , opendaylight sfc Message-ID: Thread-Topic: IETF 93 Prague Hackathon - OpenDaylight GroupBasedPolicy and ServiceFunctionChaining Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518095418_12881009" Archived-At: X-Mailman-Approved-At: Sun, 28 Jun 2015 18:16:45 -0700 Subject: [i2rs] IETF 93 Prague Hackathon - OpenDaylight GroupBasedPolicy and ServiceFunctionChaining 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, 25 Jun 2015 23:43:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3518095418_12881009 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We are excited to welcome you to participate in, and are honored to be able to offer, our portion of the IETF 93 =AD Prague Hackathon, Jul 18-19. Our proposed ideas for the event are: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Hackathons/IETF= P rague15 You can register at the link above or directly at: https://www.ietf.org/hackathon/93-hackathon.html You can find out more about GroupBasedPolicy (GBP) and ServiceFunctionChaining (SFC) at our respective OpenDaylight project wikis. https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP) https://wiki.opendaylight.org/view/Service_Function_Chaining:Main We hope to see you there! --B_3518095418_12881009 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
We are excited to wel= come you to participate in, and are honored to be able to offer, our portion= of the IETF 93 – Prague Hackathon, Jul 18-19.

Our proposed ideas for the event are:


You ca= n find out more about GroupBasedPolicy (GBP) and ServiceFunctionChaining (SF= C) at our respective OpenDaylight project wikis.


We hope to see you there!
--B_3518095418_12881009-- From nobody Mon Jun 29 01:28: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 3D0391A87CD for ; Mon, 29 Jun 2015 01:28: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 SU6-hgaw0tC4 for ; Mon, 29 Jun 2015 01:28: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 101821A87CC for ; Mon, 29 Jun 2015 01:28: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 680A312E2; Mon, 29 Jun 2015 10:28: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 bxBs13jQfhoZ; Mon, 29 Jun 2015 10:28:06 +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; Mon, 29 Jun 2015 10:28:06 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B21202002B; Mon, 29 Jun 2015 10:28:06 +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 iKeNjyXfJ7yp; Mon, 29 Jun 2015 10:28:06 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 008DB20013; Mon, 29 Jun 2015 10:28:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9876734E35DF; Mon, 29 Jun 2015 10:28:02 +0200 (CEST) Date: Mon, 29 Jun 2015 10:28:02 +0200 From: Juergen Schoenwaelder To: Linda Dunbar Message-ID: <20150629082802.GA33258@elstar.local> Mail-Followup-To: Linda Dunbar , "'i2rs@ietf.org'" , "alex@cisco.com" , "Jan Medved (jmedved)" , "rovarga@cisco.com" , "nitin_bahadur@yahoo.com" , Hariharan Ananthakrishnan , "ttkacik@cisco.com" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 08:28:11 -0000 Linda, according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. /js On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > Alex, et al, > > The I2RS architecture depicts two types of interfaces: > > - One is the interface between Agent and Client, and > > - another is the interface between Agent and Routing entities. > > > The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. > > > And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? > > IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. > > I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. > > The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. > > Cheers, > > Linda Dunbar > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 29 07:46: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 742C41ACCF0 for ; Mon, 29 Jun 2015 07:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fB75C8SISjlx for ; Mon, 29 Jun 2015 07:46:49 -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 8474E1ACCE2 for ; Mon, 29 Jun 2015 07:46:48 -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 BUM88635; Mon, 29 Jun 2015 14:46:43 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 15:46:42 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Mon, 29 Jun 2015 07:46:31 -0700 From: Linda Dunbar To: Juergen Schoenwaelder Thread-Topic: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCTiu8AAAGTW+A= Date: Mon, 29 Jun 2015 14:46:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> In-Reply-To: <20150629082802.GA33258@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:46:50 -0000 Juergen,=20 One I2RS agent can interface with multiple routing elements.=20 The network view (which consists of multiple nodes, i.e. topology) has to b= e over multiple nodes. Therefore, it is the interface between client and Ag= ent. Whereas, there are commands to individual routing element.=20 Linda -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, June 29, 2015 3:28 AM To: Linda Dunbar Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.co= m; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda, according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a ro= uting element. I am not sure your understanding "I2RS Agent is like the SDN= controller" is consistent with the architecture document. /js On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > Alex, et al, >=20 > The I2RS architecture depicts two types of interfaces: >=20 > - One is the interface between Agent and Client, and >=20 > - another is the interface between Agent and Routing entities. >=20 >=20 > The network model and inventory are more for the interface between Agent = and the Clients, isn't it? One single routing engine doesn't need to know = the overall topology and inventory information of other nodes, even though = some may do. >=20 >=20 > And the /nd:network/nd:node and Termination points are more for the inter= face between the Agent and the Forwarding Engine, isn't it? >=20 > IMHO, the information models should be oriented around the I2RS architect= ure. I.e. with description on where those information models are applicable= , making it easier to differentiate from other IETF WGs work (such as L2VPN= , L3VPN, or SFC). I recall there were some debates at the Dallas I2RS sessi= on. >=20 > I2RS Agent is like the SDN controller, which can inform clients about the= topology information, instruct routes to routing engine of multiple nodes,= and retrieve link & termination points status from each of those nodes. >=20 > The "Service Overlay" in Section 3.4.8 is definitely meant for clients no= t towards individual nodes. Mixing them all together make it confusing. >=20 > Cheers, >=20 > Linda Dunbar >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 29 07:53: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 B76C51ACDCF for ; Mon, 29 Jun 2015 07:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLuknOMs6iaL for ; Mon, 29 Jun 2015 07:53:17 -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 B62481ACDCE for ; Mon, 29 Jun 2015 07:53: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 DC3A810FB; Mon, 29 Jun 2015 16:53:14 +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 TimelofrXD40; Mon, 29 Jun 2015 16:53:13 +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; Mon, 29 Jun 2015 16:53:13 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF3C32002B; Mon, 29 Jun 2015 16:53:13 +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 ln-8vg2s886M; Mon, 29 Jun 2015 16:53:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60EBA20013; Mon, 29 Jun 2015 16:53:12 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4980334E4948; Mon, 29 Jun 2015 16:53:12 +0200 (CEST) Date: Mon, 29 Jun 2015 16:53:11 +0200 From: Juergen Schoenwaelder To: Linda Dunbar Message-ID: <20150629145311.GA2525@elstar.local> Mail-Followup-To: Linda Dunbar , "'i2rs@ietf.org'" , "alex@cisco.com" , "Jan Medved (jmedved)" , "rovarga@cisco.com" , "nitin_bahadur@yahoo.com" , Hariharan Ananthakrishnan , "ttkacik@cisco.com" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> User-Agent: Mutt/1.4.2.3i Archived-At: Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 14:53:18 -0000 Linda, can you please point to the place where this is defined? I do read this in draft-ietf-i2rs-architecture-09: 6. I2RS Agent Role and Functionality The I2RS Agent is part of a routing element. As such, it has relationships with that routing element as a whole, and with various components of that routing element. 6.1. Relationship to its Routing Element /js On Mon, Jun 29, 2015 at 02:46:31PM +0000, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > > Alex, et al, > > > > The I2RS architecture depicts two types of interfaces: > > > > - One is the interface between Agent and Client, and > > > > - another is the interface between Agent and Routing entities. > > > > > > The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. > > > > > > And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? > > > > IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. > > > > I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. > > > > The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. > > > > Cheers, > > > > Linda Dunbar > > > > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Jun 29 09:24: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 388B21AD190 for ; Mon, 29 Jun 2015 09:24:27 -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 rl9m82oZ4885 for ; Mon, 29 Jun 2015 09:24:24 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197BE1AD1A6 for ; Mon, 29 Jun 2015 09:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13100; q=dns/txt; s=iport; t=1435595061; x=1436804661; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=EBitmhe0RbENbXV/dhEJeWagPuZa8WG0IquqZpgE5aY=; b=gBeYH8q6wKPr7r2TLJfWRG+70C4Y9YxdCWFKzHBRkheXzIxIOrXbPxSv UaVMJGZZJ1zNNhnKRyLcVAAnaq877bBLJEPdC426JYYFy91Gp+LGst72P rv1PihmL6hfIvgXX1aAfX5nAOfq65uyJeqRDNiF+lOMTvrrx8UEmb5C8b U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C0AwCCcJFV/5hdJa1bgkVMVF8GrhyOfgmHXgKBOzgUAQEBAQEBAYEKhCIBAQEELUUXAgEIEQEDAQELHQcyEwEDBggBAQQBEgiIEgMSyRoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCTYIINwGDF4EUAQSFWgqLQ4JdAYU7hDyDF49mgz6DXSaDem+BRoECAQEB X-IronPort-AV: E=Sophos;i="5.13,699,1427760000"; d="scan'208,217";a="163880967" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 29 Jun 2015 16:24:20 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5TGOK6L019195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 16:24:20 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 11:24:20 -0500 From: "Alexander Clemm (alex)" To: Linda Dunbar , "'i2rs@ietf.org'" , "Jan Medved (jmedved)" , "Robert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco)" , "nitin_bahadur@yahoo.com" , "Hariharan Ananthakrishnan" , "Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIES at Cisco)" Thread-Topic: comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCVCZaA Date: Mon, 29 Jun 2015 16:24:18 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.204.27] Content-Type: multipart/alternative; boundary="_000_DBC595ED2346914F9F81D17DD5C32B571DBCF7B0xmbrcdx05ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 16:24:27 -0000 --_000_DBC595ED2346914F9F81D17DD5C32B571DBCF7B0xmbrcdx05ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, thank you for your comments. Yes, the model concerns interactions between agents and clients. The nodes= in the model refer to the entities that are referred to in the topology - = typically the hosting device as a whole, not just the forwarding engine wit= hin the device. The architecture document you mention includes a descripti= on of a topology manager in section 5.1; this model will address the need o= f such application. The service overlay indicates one way in which the model can be used. It i= s intended as an example that illustrates the flexibility of the model. On= e key aspect concerns the ability to represent vertical layering relationsh= ips; the example shows that the same overlay could map onto several underla= ys, which is a requirement e.g. when you want to represent a "physical" lay= ering along with logical layering, to know e.g. which physical node/device = is supporting a gibven overlay node, without the need to iteratively trave= rse through multiple layers. I am not sure I understand your comment that= it "is definitely meant for clients not towards individual nodes". It is = intended to represent relationships between nodes in layered topologies; it= would be exposed by an agent to a client. --- Alex From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Friday, June 26, 2015 10:03 AM To: 'i2rs@ietf.org'; Alexander Clemm (alex); Jan Medved (jmedved); Robert V= arga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco); nitin_bahadur@yahoo.com= ; Hariharan Ananthakrishnan; Tony Tkacik -X (ttkacik - PANTHEON TECHNOLOGIE= S at Cisco) Subject: comments to draft-ietf-i2rs-yang-network-topo-01 Alex, et al, The I2RS architecture depicts two types of interfaces: - One is the interface between Agent and Client, and - another is the interface between Agent and Routing entities. The network model and inventory are more for the interface between Agent an= d the Clients, isn't it? One single routing engine doesn't need to know th= e overall topology and inventory information of other nodes, even though so= me may do. And the /nd:network/nd:node and Termination points are more for the interfa= ce between the Agent and the Forwarding Engine, isn't it? IMHO, the information models should be oriented around the I2RS architectur= e. I.e. with description on where those information models are applicable, = making it easier to differentiate from other IETF WGs work (such as L2VPN, = L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session= . I2RS Agent is like the SDN controller, which can inform clients about the t= opology information, instruct routes to routing engine of multiple nodes, a= nd retrieve link & termination points status from each of those nodes. The "Service Overlay" in Section 3.4.8 is definitely meant for clients not = towards individual nodes. Mixing them all together make it confusing. Cheers, Linda Dunbar --_000_DBC595ED2346914F9F81D17DD5C32B571DBCF7B0xmbrcdx05ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

thank you for your com= ments. 

 

Yes, the model concern= s interactions between agents and clients.  The nodes in the model ref= er to the entities that are referred to in the topology – typically t= he hosting device as a whole, not just the forwarding engine within the device.  The architecture document you mention incl= udes a description of a topology manager in section 5.1; this model will ad= dress the need of such application. 

 

The service overlay in= dicates one way in which the model can be used.  It is intended as an = example that illustrates the flexibility of the model.  One key aspect= concerns the ability to represent vertical layering relationships; the example shows that the same overlay could map onto seve= ral underlays, which is a requirement e.g. when you want to represent a = 220;physical” layering along with logical layering, to know e.g. whic= h physical node/device is supporting a gibven overlay node,  without the need to iteratively traverse through multi= ple layers.   I am not sure I understand your comment that it = 220;is definitely meant for clients not towards individual nodes”.&nb= sp; It is intended to represent relationships between nodes in layered topologies; it would be exposed by an agent to a client.   =

 

--- Alex

 

From: Linda Dunbar [mailto:linda.dunbar@huawe= i.com]
Sent: Friday, June 26, 2015 10:03 AM
To: 'i2rs@ietf.org'; Alexander Clemm (alex); Jan Medved (jmedved); R= obert Varga -X (rovarga - PANTHEON TECHNOLOGIES at Cisco); nitin_bahadur@ya= hoo.com; Hariharan Ananthakrishnan; Tony Tkacik -X (ttkacik - PANTHEON TECH= NOLOGIES at Cisco)
Subject: comments to draft-ietf-i2rs-yang-network-topo-01=

 

Alex, et al,

 

The I2RS architecture depicts two types of interface= s:

-     &= nbsp;    One is the interface between Agent and Client, and =

-     &= nbsp;    another is the interface between Agent and Routing = entities.

 

 

The network model and inventory are more for the int= erface between Agent and the Clients,  isn’t it? One single rout= ing engine doesn’t need to know the overall topology and inventory in= formation of other nodes, even though some may do.

 

 

And the /nd:network/nd:node and Termination points are more for the interfac= e between the Agent and the Forwarding Engine, isn’t it?

 

 

IMHO, the information models should be oriented arou= nd the I2RS architecture. I.e. with description on where those information = models are applicable, making it easier to differentiate from other IETF WG= s work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session.

 

I2RS Agent is like the SDN controller, which can inf= orm clients about the topology information, instruct routes to routing engi= ne of multiple nodes, and retrieve link & termination points status fro= m each of those nodes.

 

The “Service Overlay” in Section 3.4.8 i= s definitely meant for clients not towards individual nodes. Mixing them al= l together make it confusing.

 

 

Cheers,

 

Linda Dunbar

 

 

--_000_DBC595ED2346914F9F81D17DD5C32B571DBCF7B0xmbrcdx05ciscoc_-- From nobody Mon Jun 29 11:01:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624401B2C1C for ; Mon, 29 Jun 2015 11:01:46 -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 qrkXkEwfk4WW for ; Mon, 29 Jun 2015 11:01:44 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D611B2C28 for ; Mon, 29 Jun 2015 11:01:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3E1164C14E2; Mon, 29 Jun 2015 11:01:38 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [207.106.66.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 039E74C14C7; Mon, 29 Jun 2015 11:01:36 -0700 (PDT) To: Linda Dunbar , Juergen Schoenwaelder References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> From: "Joel M. Halpern" Message-ID: <559187F6.9020108@joelhalpern.com> Date: Mon, 29 Jun 2015 14:01:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:01:46 -0000 Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, and an agent may be communicating with multiple clients. But it is still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >> >> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > From nobody Mon Jun 29 12:57:31 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39C1A882A for ; Mon, 29 Jun 2015 11:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbDEaEmG-62K for ; Mon, 29 Jun 2015 11:33:14 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4FD91A88C4 for ; Mon, 29 Jun 2015 11:33:02 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t5TIWoru032117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 14:32:50 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 29 Jun 2015 14:32:50 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Jun 2015 14:32:49 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1104.000; Mon, 29 Jun 2015 14:32:49 -0400 From: Igor Bryskin To: "Joel M. Halpern" , Linda Dunbar , Juergen Schoenwaelder Thread-Topic: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCNQZwAAA0354AABs6xAAAK7y5g Date: Mon, 29 Jun 2015 18:32:49 +0000 Message-ID: <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> In-Reply-To: <559187F6.9020108@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-29_04:2015-06-29,2015-06-29,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Mon, 29 Jun 2015 12:57:30 -0700 Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 18:33:16 -0000 I agree with Joel, To answer Linda's question: if I2RS agent manages/represnts multiple physic= al devices, the interface between the agent and the devices is out of scope= of I2RS. Note that such interface needs to be standardized only if one con= siders a scenario where an I2RS agent controls devices from different vendo= rs. IMHO this scenario is unlikely, and at least for now it is safe to assu= me that said interface is private. Cheers, Igor -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 29, 2015 2:01 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan = Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen is correct that by the I2RS definition an I2RS Agent is part of, an= d associated with, a single routing element. It is true that the routing element may itself be a controller supporting a= nd interacting with multiple forwarding elements. That is not required, an= d not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is= that the relationship between I2RS Clittns and I2rS agents is N:M. That i= s, a client may be working with multiple agents,=20 and an agent may be communicating with multiple clients. But it is=20 still the case that the agent is collocated with the routing system, and is= not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to= be over multiple nodes. Therefore, it is the interface between client and = Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved);=20 > rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan;=20 > ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a = routing element. I am not sure your understanding "I2RS Agent is like the S= DN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent= and the Clients, isn't it? One single routing engine doesn't need to know= the overall topology and inventory information of other nodes, even though= some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the inte= rface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architec= ture. I.e. with description on where those information models are applicabl= e, making it easier to differentiate from other IETF WGs work (such as L2VP= N, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS sess= ion. >> >> I2RS Agent is like the SDN controller, which can inform clients about th= e topology information, instruct routes to routing engine of multiple nodes= , and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients n= ot towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Jun 29 14:05:55 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 8BAD31B3442 for ; Mon, 29 Jun 2015 14:05:54 -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 auGtTBXAym84 for ; Mon, 29 Jun 2015 14:05:52 -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 0642F1B3417 for ; Mon, 29 Jun 2015 14:05:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYD18645; Mon, 29 Jun 2015 21:05:46 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 22:05:46 +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; Mon, 29 Jun 2015 14:05:33 -0700 From: Linda Dunbar To: "'i2rs@ietf.org'" , "nitin_bahadur@yahoo.com" , "ronf@juniper.net" , "'Sriganesh Kini'" , "Jan Medved (jmedved)" Thread-Topic: comments to draft-ietf-i2rs-rib-info-model-06 Thread-Index: AdCwanh9/lHnkcOzRqmlfO63ByTnFQCF/jRQAAso7SA= Date: Mon, 29 Jun 2015 21:05:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C886AB@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.110] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657C886ABdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [i2rs] comments to draft-ietf-i2rs-rib-info-model-06 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, 29 Jun 2015 21:05:54 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657C886ABdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nitin, et al, I have some questions and comments to the draft-ietf-i2rs-rib-info-model-06= : Section 6: The "" in this model has ". Does i= t mean that the is one logical slice on ONE router? (wh= ich makes great sense to me). But in Section 2.2 Routing Instance can be across a set of routers (e.g. L3= VPN, L2VPN), which gives the impression that "Routing Instance" can be a l= ogical network. Is it the intent? Section 2.1: Reverse Path Forwarding (RPF) is commonly used for preventing = loops of multicast traffic. The unicast RPF can't really limit malicious tr= affic. If RIB has entry for xxx.xxx.0.0/16, any addresses (even the malicio= us ones) with the prefix xxx.xxx would match. Section 2.4.3: What is the difference between "Logical Tunnel" and "Tunnel = Encap"? Both have MPLS tunnel as an example. Section 2.4.4: Special Nexthops: is "RECEIVE" option meant for Agent to i= nform a network device to "receive" a packet that is not supposed to be des= tined to the device? The examples given, such as "protocol packets" or "OAM= packets", are all supposed to be terminated by the device. You don't need = to instructions for those packets to be received. Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657C886ABdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Nitin, et al,

 =

I have some questions an= d comments to the draft-ietf-i2rs-rib-info-model-06:

 

 

Section 6: The “<= ;routing-instance>” in this model has  “<ROUTER_ID&g= t;. Does it mean that the <routing instance> is one logical slice on = ONE router?  (which makes great sense to me).

 

But in Section 2.2 Routin= g Instance can be across a set of routers (e.g. L3 VPN, L2VPN), which gives= the impression that “Routing Instance” can be a logical networ= k.  Is it the intent?

 

Section 2.1: Reverse Path= Forwarding (RPF) is commonly used for preventing loops of multicast traffi= c. The unicast RPF can’t really limit malicious traffic. If RIB has e= ntry for xxx.xxx.0.0/16, any addresses (even the malicious ones) with the prefix xxx.xxx would match.

 

 

Section 2.4.3: What is th= e difference between "Logical Tunnel" and "Tunnel Encap"= ;? Both have MPLS tunnel as an example.

 

 

Section 2.4.4: Special Ne= xthops: is “RECEIVE” option  meant for  Agent to info= rm a network device to “receive” a packet that is not supposed = to be destined to the device? The examples given, such as “protocol p= ackets” or “OAM packets”, are all supposed to be terminated by the dev= ice. You don’t need to instructions for those packets to be received.

 

 

Cheers,

Linda Dunbar<= /span>

--_000_4A95BA014132FF49AE685FAB4B9F17F657C886ABdfweml701chm_-- From nobody Tue Jun 30 09:12:55 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 DB67A1B3438 for ; Mon, 29 Jun 2015 14:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb5C2nxiczQe for ; Mon, 29 Jun 2015 14:02:15 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE6A1B341B for ; Mon, 29 Jun 2015 14:02:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYD18500; Mon, 29 Jun 2015 21:02:12 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 29 Jun 2015 22:02:11 +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; Mon, 29 Jun 2015 14:01:59 -0700 From: Linda Dunbar To: Igor Bryskin , "Joel M. Halpern" , Juergen Schoenwaelder Thread-Topic: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCTiu8AAAGTW+AAEnM+AAABGJaAAAoSm9A= Date: Mon, 29 Jun 2015 21:01:59 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.137.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 09:12:53 -0700 Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:02:17 -0000 Joel, Igor, Juergen,=20 Thanks for the feedback. Actually I always thought I2RS Agent is within a s= ingle routing engine until reading the "I2RS Topology" draft.=20 I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specificat= ion for information exchange between a routing engine and its client. It re= flects one single node's RIBs associated with multiple Routing Instances su= pported by the routing engine.=20 But the "I2RS Topology", which is also a very good specification describing= the network view of topologies (which consists of multiple nodes and links= among them), is more suited for the entity that manages multiple routing n= odes.=20 RIBs of one routing engine and "topology of multiple routing engines" defin= itely represent different perspectives: one is node view, another one is th= e network view.=20 =20 In order to make I2RS widely adopted by the industry, it is very important = not to make it too complicated. Routing is not simple to start with, theref= ore, it becomes especially more important to keep I2RS specification simple= and to the point.=20 Therefore, I suggest to have a paragraph in the "network-topo" draft to des= cribe that this is for the network view, it is for clients who manage/monit= or multiple routing engines.=20 My two cents.=20 Linda=20 -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com]=20 Sent: Monday, June 29, 2015 1:33 PM To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan = Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 I agree with Joel, To answer Linda's question: if I2RS agent manages/represnts multiple physic= al devices, the interface between the agent and the devices is out of scope= of I2RS. Note that such interface needs to be standardized only if one con= siders a scenario where an I2RS agent controls devices from different vendo= rs. IMHO this scenario is unlikely, and at least for now it is safe to assu= me that said interface is private. Cheers, Igor -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 29, 2015 2:01 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan = Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen is correct that by the I2RS definition an I2RS Agent is part of, an= d associated with, a single routing element. It is true that the routing element may itself be a controller supporting a= nd interacting with multiple forwarding elements. That is not required, an= d not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is= that the relationship between I2RS Clittns and I2rS agents is N:M. That i= s, a client may be working with multiple agents,=20 and an agent may be communicating with multiple clients. But it is=20 still the case that the agent is collocated with the routing system, and is= not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to= be over multiple nodes. Therefore, it is the interface between client and = Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved);=20 > rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan;=20 > ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a = routing element. I am not sure your understanding "I2RS Agent is like the S= DN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent= and the Clients, isn't it? One single routing engine doesn't need to know= the overall topology and inventory information of other nodes, even though= some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the inte= rface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architec= ture. I.e. with description on where those information models are applicabl= e, making it easier to differentiate from other IETF WGs work (such as L2VP= N, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS sess= ion. >> >> I2RS Agent is like the SDN controller, which can inform clients about th= e topology information, instruct routes to routing engine of multiple nodes= , and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients n= ot towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 09:12:56 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBE31B3450 for ; Mon, 29 Jun 2015 14:06:35 -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 1892_BQtKIFb for ; Mon, 29 Jun 2015 14:06:33 -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 1238A1B3445 for ; Mon, 29 Jun 2015 14:06:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EFB83251EDD; Mon, 29 Jun 2015 14:06:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (wsip-72-214-234-138.om.om.cox.net [72.214.234.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 9CF34251D04; Mon, 29 Jun 2015 14:06:28 -0700 (PDT) To: Linda Dunbar , Igor Bryskin , Juergen Schoenwaelder References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> From: "Joel M. Halpern" Message-ID: <5591B349.2000102@joelhalpern.com> Date: Mon, 29 Jun 2015 17:06:17 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 09:12:53 -0700 Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 21:06:35 -0000 You may recall that I have expressed concern about many times about how the network topology draft fits the I2RS scope. It is still not clear to me that it is an I2RS item, although it is clearly useful for things talking to the I2RS Agent. Yours, Joel On 6/29/15 5:01 PM, Linda Dunbar wrote: > Joel, Igor, Juergen, > > Thanks for the feedback. Actually I always thought I2RS Agent is within a single routing engine until reading the "I2RS Topology" draft. > > I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specification for information exchange between a routing engine and its client. It reflects one single node's RIBs associated with multiple Routing Instances supported by the routing engine. > > But the "I2RS Topology", which is also a very good specification describing the network view of topologies (which consists of multiple nodes and links among them), is more suited for the entity that manages multiple routing nodes. > > RIBs of one routing engine and "topology of multiple routing engines" definitely represent different perspectives: one is node view, another one is the network view. > > > In order to make I2RS widely adopted by the industry, it is very important not to make it too complicated. Routing is not simple to start with, therefore, it becomes especially more important to keep I2RS specification simple and to the point. > > Therefore, I suggest to have a paragraph in the "network-topo" draft to describe that this is for the network view, it is for clients who manage/monitor multiple routing engines. > > My two cents. > > Linda > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, June 29, 2015 1:33 PM > To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > I agree with Joel, > > To answer Linda's question: if I2RS agent manages/represnts multiple physical devices, the interface between the agent and the devices is out of scope of I2RS. Note that such interface needs to be standardized only if one considers a scenario where an I2RS agent controls devices from different vendors. IMHO this scenario is unlikely, and at least for now it is safe to assume that said interface is private. > > Cheers, > Igor > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, June 29, 2015 2:01 PM > To: Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. > > It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, > and an agent may be communicating with multiple clients. But it is > still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. > > Yours, > Joel > > On 6/29/15 10:46 AM, Linda Dunbar wrote: >> Juergen, >> >> One I2RS agent can interface with multiple routing elements. >> >> The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. >> >> Linda >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, June 29, 2015 3:28 AM >> To: Linda Dunbar >> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; >> ttkacik@cisco.com >> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> Linda, >> >> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. >> >> /js >> >> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>> Alex, et al, >>> >>> The I2RS architecture depicts two types of interfaces: >>> >>> - One is the interface between Agent and Client, and >>> >>> - another is the interface between Agent and Routing entities. >>> >>> >>> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >>> >>> >>> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >>> >>> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >>> >>> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >>> >>> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >>> >>> Cheers, >>> >>> Linda Dunbar >>> >>> >> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 30 09:12: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 35FE11B3392 for ; Mon, 29 Jun 2015 22:41:37 -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 hXu3FC2m7Glc for ; Mon, 29 Jun 2015 22:41:34 -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 283791B3106 for ; Mon, 29 Jun 2015 22:41:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5E80AFE6; Tue, 30 Jun 2015 07:41:31 +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 Z31RILoSak0N; Tue, 30 Jun 2015 07:41: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; Tue, 30 Jun 2015 07:41:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9A312002B; Tue, 30 Jun 2015 07:41:29 +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 C1iUKX-f2fS9; Tue, 30 Jun 2015 07:41:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DD9E620013; Tue, 30 Jun 2015 07:41:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ADE7B34E52D6; Tue, 30 Jun 2015 07:41:24 +0200 (CEST) Date: Tue, 30 Jun 2015 07:41:24 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20150630054124.GA4083@elstar.local> Mail-Followup-To: "Joel M. Halpern" , Linda Dunbar , Igor Bryskin , "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved (jmedved)" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5591B349.2000102@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 09:12:53 -0700 Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , Igor Bryskin , Linda Dunbar , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 05:41:37 -0000 I have been in the same boat but some people thought it is really important to do a generic topology model in I2RS so here we go. /js On Mon, Jun 29, 2015 at 05:06:17PM -0400, Joel M. Halpern wrote: > You may recall that I have expressed concern about many times about how > the network topology draft fits the I2RS scope. It is still not clear > to me that it is an I2RS item, although it is clearly useful for things > talking to the I2RS Agent. > > Yours, > Joel > > On 6/29/15 5:01 PM, Linda Dunbar wrote: > >Joel, Igor, Juergen, > > > >Thanks for the feedback. Actually I always thought I2RS Agent is within a > >single routing engine until reading the "I2RS Topology" draft. > > > >I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good > >specification for information exchange between a routing engine and its > >client. It reflects one single node's RIBs associated with multiple > >Routing Instances supported by the routing engine. > > > >But the "I2RS Topology", which is also a very good specification > >describing the network view of topologies (which consists of multiple > >nodes and links among them), is more suited for the entity that manages > >multiple routing nodes. > > > >RIBs of one routing engine and "topology of multiple routing engines" > >definitely represent different perspectives: one is node view, another one > >is the network view. > > > > > >In order to make I2RS widely adopted by the industry, it is very important > >not to make it too complicated. Routing is not simple to start with, > >therefore, it becomes especially more important to keep I2RS specification > >simple and to the point. > > > >Therefore, I suggest to have a paragraph in the "network-topo" draft to > >describe that this is for the network view, it is for clients who > >manage/monitor multiple routing engines. > > > >My two cents. > > > >Linda > > > >-----Original Message----- > >From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > >Sent: Monday, June 29, 2015 1:33 PM > >To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > >Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > >Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > >Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > > >I agree with Joel, > > > >To answer Linda's question: if I2RS agent manages/represnts multiple > >physical devices, the interface between the agent and the devices is out > >of scope of I2RS. Note that such interface needs to be standardized only > >if one considers a scenario where an I2RS agent controls devices from > >different vendors. IMHO this scenario is unlikely, and at least for now it > >is safe to assume that said interface is private. > > > >Cheers, > >Igor > > > >-----Original Message----- > >From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > >Sent: Monday, June 29, 2015 2:01 PM > >To: Linda Dunbar; Juergen Schoenwaelder > >Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan > >Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > >Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > > >Juergen is correct that by the I2RS definition an I2RS Agent is part of, > >and associated with, a single routing element. > > > >It is true that the routing element may itself be a controller supporting > >and interacting with multiple forwarding elements. That is not required, > >and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity > >is that the relationship between I2RS Clittns and I2rS agents is N:M. > >That is, a client may be working with multiple agents, > >and an agent may be communicating with multiple clients. But it is > >still the case that the agent is collocated with the routing system, and > >is not in a separate controller from the routing system. > > > >Yours, > >Joel > > > >On 6/29/15 10:46 AM, Linda Dunbar wrote: > >>Juergen, > >> > >>One I2RS agent can interface with multiple routing elements. > >> > >>The network view (which consists of multiple nodes, i.e. topology) has to > >>be over multiple nodes. Therefore, it is the interface between client and > >>Agent. Whereas, there are commands to individual routing element. > >> > >>Linda > >>-----Original Message----- > >>From: Juergen Schoenwaelder > >>[mailto:j.schoenwaelder@jacobs-university.de] > >>Sent: Monday, June 29, 2015 3:28 AM > >>To: Linda Dunbar > >>Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > >>rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; > >>ttkacik@cisco.com > >>Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > >> > >>Linda, > >> > >>according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a > >>routing element. I am not sure your understanding "I2RS Agent is like the > >>SDN controller" is consistent with the architecture document. > >> > >>/js > >> > >>On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > >>>Alex, et al, > >>> > >>>The I2RS architecture depicts two types of interfaces: > >>> > >>>- One is the interface between Agent and Client, and > >>> > >>>- another is the interface between Agent and Routing entities. > >>> > >>> > >>>The network model and inventory are more for the interface between Agent > >>>and the Clients, isn't it? One single routing engine doesn't need to > >>>know the overall topology and inventory information of other nodes, even > >>>though some may do. > >>> > >>> > >>>And the /nd:network/nd:node and Termination points are more for the > >>>interface between the Agent and the Forwarding Engine, isn't it? > >>> > >>>IMHO, the information models should be oriented around the I2RS > >>>architecture. I.e. with description on where those information models > >>>are applicable, making it easier to differentiate from other IETF WGs > >>>work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at > >>>the Dallas I2RS session. > >>> > >>>I2RS Agent is like the SDN controller, which can inform clients about > >>>the topology information, instruct routes to routing engine of multiple > >>>nodes, and retrieve link & termination points status from each of those > >>>nodes. > >>> > >>>The "Service Overlay" in Section 3.4.8 is definitely meant for clients > >>>not towards individual nodes. Mixing them all together make it confusing. > >>> > >>>Cheers, > >>> > >>>Linda Dunbar > >>> > >>> > >> > >>>_______________________________________________ > >>>i2rs mailing list > >>>i2rs@ietf.org > >>>https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > > > >_______________________________________________ > >i2rs mailing list > >i2rs@ietf.org > >https://www.ietf.org/mailman/listinfo/i2rs > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jun 30 09:12: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 647021A8F4A for ; Tue, 30 Jun 2015 05:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9huN5HIn12l for ; Tue, 30 Jun 2015 05:48:54 -0700 (PDT) Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E6F1A8F4B for ; Tue, 30 Jun 2015 05:48:54 -0700 (PDT) Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id t5UCmiTR004107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 08:48:45 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by atl-srv-mail10.atl.advaoptical.com (172.16.5.39) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 30 Jun 2015 08:48:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com (172.16.5.45) by ATL-SRV-MBX1.advaoptical.com (172.16.5.45) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 30 Jun 2015 08:48:44 -0400 Received: from ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1]) by ATL-SRV-MBX1.advaoptical.com ([fe80::6433:f8f:ea41:a6e1%14]) with mapi id 15.00.1104.000; Tue, 30 Jun 2015 08:48:44 -0400 From: Igor Bryskin To: "Joel M. Halpern" , Linda Dunbar , Juergen Schoenwaelder Thread-Topic: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Thread-Index: AdCwMgP7koKmgoRuTAydW/gz/SRv4gCNQZwAAA0354AABs6xAAAK7y5g///a+ICAAAE0gP//VgFA Date: Tue, 30 Jun 2015 12:48:43 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> In-Reply-To: <5591B349.2000102@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.5.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-06-30_06:2015-06-29,2015-06-30,1970-01-01 signatures=0 Archived-At: X-Mailman-Approved-At: Tue, 30 Jun 2015 09:12:53 -0700 Cc: "nitin_bahadur@yahoo.com" , "'i2rs@ietf.org'" , "ttkacik@cisco.com" , Hariharan Ananthakrishnan , "rovarga@cisco.com" , "alex@cisco.com" , "Jan Medved \(jmedved\)" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 12:48:57 -0000 Hi Joel, I agree that there is a difference as to how we deal with RIB and topologie= s. RIB is a property of a single physical device, while topologies (both ro= uting/reachability and TE) are always network-wide. However, for some appli= cations it is important to extract topologies from a layer 3 switch as they= are, for example, learned by the switch's routing protocols. I think of I2= RS as a unified interface to a routing system to get everything the system = exposes to the outside world. Hence I2RS is a right interface IMHO to extra= ct topologies from a given physical switch. Furthermore, if an I2RS agent represents/manages multiple devices (e.g. SD= N controller), it may expose abstract topologies (instead or in addition to= its native topologies ) customized on per client basis. If one assumes tha= t said clients can (re-)configure themselves the abstract topologies, then = we have the same issues as we have with RIB (conflicting (re-)configuration= s of a given abstract topology, client priorities and ephemeral state). So = why not to resolve all these issues in a similar way ? Cheers, Igor -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, June 29, 2015 5:06 PM To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan = Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 You may recall that I have expressed concern about many times about how=20 the network topology draft fits the I2RS scope. It is still not clear=20 to me that it is an I2RS item, although it is clearly useful for things=20 talking to the I2RS Agent. Yours, Joel On 6/29/15 5:01 PM, Linda Dunbar wrote: > Joel, Igor, Juergen, > > Thanks for the feedback. Actually I always thought I2RS Agent is within a= single routing engine until reading the "I2RS Topology" draft. > > I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specific= ation for information exchange between a routing engine and its client. It = reflects one single node's RIBs associated with multiple Routing Instances = supported by the routing engine. > > But the "I2RS Topology", which is also a very good specification describi= ng the network view of topologies (which consists of multiple nodes and lin= ks among them), is more suited for the entity that manages multiple routing= nodes. > > RIBs of one routing engine and "topology of multiple routing engines" def= initely represent different perspectives: one is node view, another one is = the network view. > > > In order to make I2RS widely adopted by the industry, it is very importan= t not to make it too complicated. Routing is not simple to start with, ther= efore, it becomes especially more important to keep I2RS specification simp= le and to the point. > > Therefore, I suggest to have a paragraph in the "network-topo" draft to d= escribe that this is for the network view, it is for clients who manage/mon= itor multiple routing engines. > > My two cents. > > Linda > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, June 29, 2015 1:33 PM > To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Harihara= n Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > I agree with Joel, > > To answer Linda's question: if I2RS agent manages/represnts multiple phys= ical devices, the interface between the agent and the devices is out of sco= pe of I2RS. Note that such interface needs to be standardized only if one c= onsiders a scenario where an I2RS agent controls devices from different ven= dors. IMHO this scenario is unlikely, and at least for now it is safe to as= sume that said interface is private. > > Cheers, > Igor > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, June 29, 2015 2:01 PM > To: Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Harihara= n Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Juergen is correct that by the I2RS definition an I2RS Agent is part of, = and associated with, a single routing element. > > It is true that the routing element may itself be a controller supporting= and interacting with multiple forwarding elements. That is not required, = and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity = is that the relationship between I2RS Clittns and I2rS agents is N:M. That= is, a client may be working with multiple agents, > and an agent may be communicating with multiple clients. But it is > still the case that the agent is collocated with the routing system, and = is not in a separate controller from the routing system. > > Yours, > Joel > > On 6/29/15 10:46 AM, Linda Dunbar wrote: >> Juergen, >> >> One I2RS agent can interface with multiple routing elements. >> >> The network view (which consists of multiple nodes, i.e. topology) has t= o be over multiple nodes. Therefore, it is the interface between client and= Agent. Whereas, there are commands to individual routing element. >> >> Linda >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, June 29, 2015 3:28 AM >> To: Linda Dunbar >> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; >> ttkacik@cisco.com >> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> Linda, >> >> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a= routing element. I am not sure your understanding "I2RS Agent is like the = SDN controller" is consistent with the architecture document. >> >> /js >> >> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>> Alex, et al, >>> >>> The I2RS architecture depicts two types of interfaces: >>> >>> - One is the interface between Agent and Client, and >>> >>> - another is the interface between Agent and Routing entities. >>> >>> >>> The network model and inventory are more for the interface between Agen= t and the Clients, isn't it? One single routing engine doesn't need to kno= w the overall topology and inventory information of other nodes, even thoug= h some may do. >>> >>> >>> And the /nd:network/nd:node and Termination points are more for the int= erface between the Agent and the Forwarding Engine, isn't it? >>> >>> IMHO, the information models should be oriented around the I2RS archite= cture. I.e. with description on where those information models are applicab= le, making it easier to differentiate from other IETF WGs work (such as L2V= PN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS ses= sion. >>> >>> I2RS Agent is like the SDN controller, which can inform clients about t= he topology information, instruct routes to routing engine of multiple node= s, and retrieve link & termination points status from each of those nodes. >>> >>> The "Service Overlay" in Section 3.4.8 is definitely meant for clients = not towards individual nodes. Mixing them all together make it confusing. >>> >>> Cheers, >>> >>> Linda Dunbar >>> >>> >> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Tue Jun 30 12:19: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 2D1EF1A8829 for ; Tue, 30 Jun 2015 12:19:43 -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 JNBubt5-ZAtB for ; Tue, 30 Jun 2015 12:19:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD331A87C5 for ; Tue, 30 Jun 2015 12:19:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Linda Dunbar'" , , , "'Jan Medved \(jmedved\)'" , , , "'Hariharan Ananthakrishnan'" , References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> Date: Tue, 30 Jun 2015 15:18:57 -0400 Message-ID: <03b901d0b369$a04e5310$e0eaf930$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03BA_01D0B348.193FC050" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7WiqpNWxBIcu2yr4V7yppvS4EEp5wCoHg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:19:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03BA_01D0B348.193FC050 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Linda and all: I apologize for the delay in responding to this email. I will answer this train of messages one at a time. I apologize if there are any duplicates. The time for comments on the scope of the I2RS draft-ietf-i2rs-yang-network-topo-01 draft was the adoption time period. The WG has adopted this draft and its direction of a topology with service, L3, L2, and L1. You are correct that the topology independent RIB and Filter-FIB are different than the protocol independent virtual topologies. The I2RS use cases we captured had many virtual topologies with L1 to Service level. The virtual use case routing systems do know the full topology - from Layer 1 to Service to reasonably plan the topology changes. The ospf/isis pass link state topology (link, nodes, etc) in BGP because it is useful for a central unit that does topology calculation. The I2RS protocol independent topology (L1, L2, L3, and Service) is similar to this existing work in BGP. I suspect it will be useful central unit that does topology calculation. If this unit is an SDN controller - that is an implementation detail to I2RS. I2RS could write additional nodes or links or termination points into that virtual topology. At this point, there is no request from the data models to write back the protocol independent information to the routing system. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, June 26, 2015 1:03 PM To: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Alex, et al, The I2RS architecture depicts two types of interfaces: - One is the interface between Agent and Client, and - another is the interface between Agent and Routing entities. The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. Cheers, Linda Dunbar ------=_NextPart_000_03BA_01D0B348.193FC050 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda and all:

 

I apologize for the = delay in responding to this email.   I will answer this train = of messages one at a time. I apologize if there are any duplicates. =

<chair hat on>

The time for comments on = the scope of the I2RS draft-ietf-i2rs-yang-network-topo-01 draft was the = adoption time period.   The WG has adopted this draft and its = direction of a topology with service, L3, L2, and L1.   You = are correct that the topology independent RIB and Filter-FIB are = different than the protocol independent virtual topologies.   = The I2RS use cases we captured had many virtual topologies with L1 to = Service level. 

</chair hat off>

<technical hat on> =

The virtual use case  routing systems do = know the full topology – from Layer 1 to Service to reasonably = plan the topology changes.  The ospf/isis pass link state topology = (link, nodes, etc) in  BGP because it is useful for a central unit = that does topology calculation.  The I2RS protocol independent = topology (L1, L2, L3, and Service) is similar to this existing work in = BGP.  I suspect it will be useful  central unit that does = topology calculation.  

 

If this unit is an SDN = controller – that is an implementation detail to I2RS. =

 

I2RS could write = additional nodes or links or termination points into that virtual = topology.   At this point, there is no request from the data = models to write back the protocol independent information to the routing = system.   

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Friday, June 26, 2015 1:03 PM
To: = 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); = rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; = ttkacik@cisco.com
Subject: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01

 

Alex, et al, =

 

The I2RS architecture depicts two types of interfaces: =

-          = One is the interface between Agent and Client, = and

-          = another is the interface between Agent and = Routing entities.

 

 

The network = model and inventory are more for the interface between Agent and the = Clients,  isn’t it? One single routing engine doesn’t = need to know the overall topology and inventory information of other = nodes, even though some may do.

 

 

And the /nd:network/nd:node = and Termination points are more for the interface between the = Agent and the Forwarding Engine, isn’t it?

 

 

IMHO, the information models should be oriented = around the I2RS architecture. I.e. with description on where those = information models are applicable, making it easier to differentiate = from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there = were some debates at the Dallas I2RS session.

 

I2RS Agent = is like the SDN controller, which can inform clients about the topology = information, instruct routes to routing engine of multiple nodes, and = retrieve link & termination points status from each of those nodes. =

 

The “Service Overlay” in Section 3.4.8 is = definitely meant for clients not towards individual nodes. Mixing them = all together make it confusing.

 

 

Cheers, =

 

Linda Dunbar

 

 

------=_NextPart_000_03BA_01D0B348.193FC050-- From nobody Tue Jun 30 12:23:26 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550991A8AFE for ; Tue, 30 Jun 2015 12:23:24 -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 8B4IRdywnHWJ for ; Tue, 30 Jun 2015 12:23:23 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ACA1A8ABB for ; Tue, 30 Jun 2015 12:23:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Linda Dunbar'" , "'Juergen Schoenwaelder'" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> Date: Tue, 30 Jun 2015 15:23:06 -0400 Message-ID: <03c601d0b36a$318ffe50$94affaf0$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt2eShjIMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: nitin_bahadur@yahoo.com, i2rs@ietf.org, ttkacik@cisco.com, 'Hariharan Ananthakrishnan' , rovarga@cisco.com, alex@cisco.com, "'Jan Medved \(jmedved\)'" Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 19:23:24 -0000 Linda and Juergen: The I2RS client may talk to multiple I2RS agents on multiple nodes or an I2RS client may talk to only one I2RS agent on one node. Whether the I2RS client maintains a network-wide view or a single device view is up to the I2RS client's implementation. The I2RS client to I2RS agent protocol deals with the protocol between one I2RS client and one I2RS Agent which may exist over multiple transport connections. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 29, 2015 10:47 AM To: Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen, One I2RS agent can interface with multiple routing elements. The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. Linda -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, June 29, 2015 3:28 AM To: Linda Dunbar Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda, according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. /js On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > Alex, et al, > > The I2RS architecture depicts two types of interfaces: > > - One is the interface between Agent and Client, and > > - another is the interface between Agent and Routing entities. > > > The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. > > > And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? > > IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. > > I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. > > The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. > > Cheers, > > Linda Dunbar > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 13:23:47 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBA1B2D34 for ; Tue, 30 Jun 2015 13:23:45 -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 tRKwnn4gNY0P for ; Tue, 30 Jun 2015 13:23:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4401B2D33 for ; Tue, 30 Jun 2015 13:23:42 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> In-Reply-To: Date: Tue, 30 Jun 2015 16:23:37 -0400 Message-ID: <041701d0b372$a611ea60$f235bf20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0418_01D0B351.1F01D100" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgI1BHvMnl6IasA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 20:23:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0418_01D0B351.1F01D100 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Linda and all: I apologize for the delay in responding to this email. I will answer this train of messages one at a time. I apologize if there are any duplicates. The time for comments on the scope of the I2RS draft-ietf-i2rs-yang-network-topo-01 draft was the adoption time period. The WG has adopted this draft and its direction of a topology with service, L3, L2, and L1. You are correct that the topology independent RIB and Filter-FIB are different than the protocol independent virtual topologies. The I2RS use cases we captured had many virtual topologies with L1 to Service level. The virtual use case routing systems do know the full topology - from Layer 1 to Service to reasonably plan the topology changes. The ospf/isis pass link state topology (link, nodes, etc) in BGP because it is useful for a central unit that does topology calculation. The I2RS protocol independent topology (L1, L2, L3, and Service) is similar to this existing work in BGP. I suspect it will be useful central unit that does topology calculation. If this unit is an SDN controller - that is an implementation detail to I2RS. I2RS could write additional nodes or links or termination points into that virtual topology. At this point, there is no request from the data models to write back the protocol independent information to the routing system. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Friday, June 26, 2015 1:03 PM To: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Alex, et al, The I2RS architecture depicts two types of interfaces: - One is the interface between Agent and Client, and - another is the interface between Agent and Routing entities. The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. Cheers, Linda Dunbar ------=_NextPart_000_0418_01D0B351.1F01D100 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Linda and all:

 

I apologize for the = delay in responding to this email.   I will answer this train = of messages one at a time. I apologize if there are any duplicates. =

<chair hat on>

The time for comments on = the scope of the I2RS draft-ietf-i2rs-yang-network-topo-01 draft was the = adoption time period.   The WG has adopted this draft and its = direction of a topology with service, L3, L2, and L1.   You = are correct that the topology independent RIB and Filter-FIB are = different than the protocol independent virtual topologies.   = The I2RS use cases we captured had many virtual topologies with L1 to = Service level. 

</chair hat off>

<technical hat on> =

The virtual use case  routing systems do = know the full topology – from Layer 1 to Service to reasonably = plan the topology changes.  The ospf/isis pass link state topology = (link, nodes, etc) in  BGP because it is useful for a central unit = that does topology calculation.  The I2RS protocol independent = topology (L1, L2, L3, and Service) is similar to this existing work in = BGP.  I suspect it will be useful  central unit that does = topology calculation.  

 

If this unit is an SDN = controller – that is an implementation detail to I2RS. =

 

I2RS could write = additional nodes or links or termination points into that virtual = topology.   At this point, there is no request from the data = models to write back the protocol independent information to the routing = system.   

 

Sue =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Linda Dunbar
Sent: Friday, June 26, 2015 = 1:03 PM
To: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); = rovarga@cisco.com; nitin_bahadur@yahoo.com; = Hariharan Ananthakrishnan; ttkacik@cisco.com
Subject: [i2rs] comments to = draft-ietf-i2rs-yang-network-topo-01

 

Alex, et al, =

 

The I2RS architecture depicts two types of interfaces: =

-          = One is the interface between Agent and Client, = and

-          = another is the interface between Agent and = Routing entities.

 

 

The network = model and inventory are more for the interface between Agent and the = Clients,  isn’t it? One single routing engine doesn’t = need to know the overall topology and inventory information of other = nodes, even though some may do.

 

 

And the /nd:network/nd:node = and Termination points are more for the interface between the = Agent and the Forwarding Engine, isn’t it?

 

 

IMHO, the information models should be oriented = around the I2RS architecture. I.e. with description on where those = information models are applicable, making it easier to differentiate = from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there = were some debates at the Dallas I2RS session.

 

I2RS Agent = is like the SDN controller, which can inform clients about the topology = information, instruct routes to routing engine of multiple nodes, and = retrieve link & termination points status from each of those nodes. =

 

The “Service Overlay” in Section 3.4.8 is = definitely meant for clients not towards individual nodes. Mixing them = all together make it confusing.

 

 

Cheers, =

 

Linda Dunbar

 

 

------=_NextPart_000_0418_01D0B351.1F01D100-- From nobody Tue Jun 30 13:29: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 3E2F81B2DB6 for ; Tue, 30 Jun 2015 13:29:47 -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 9eu3Yk8oLpWG for ; Tue, 30 Jun 2015 13:29:46 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F242E1B2DB2 for ; Tue, 30 Jun 2015 13:29:45 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Linda Dunbar'" , "'Juergen Schoenwaelder'" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> In-Reply-To: Date: Tue, 30 Jun 2015 16:29:36 -0400 Message-ID: <000d01d0b373$7c541300$74fc3900$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0Ci5CmT541zzow Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 20:29:47 -0000 Linda and Juergen: The I2RS client may talk to multiple I2RS agents on multiple nodes or an I2RS client may talk to only one I2RS agent on one node. Whether the I2RS client maintains a network-wide view or a single device view is up to the I2RS client's implementation. The I2RS client to I2RS agent protocol deals with the protocol between one I2RS client and one I2RS Agent which may exist over multiple transport connections. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 29, 2015 10:47 AM To: Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen, One I2RS agent can interface with multiple routing elements. The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. Linda -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, June 29, 2015 3:28 AM To: Linda Dunbar Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda, according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. /js On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > Alex, et al, > > The I2RS architecture depicts two types of interfaces: > > - One is the interface between Agent and Client, and > > - another is the interface between Agent and Routing entities. > > > The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. > > > And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? > > IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. > > I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. > > The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. > > Cheers, > > Linda Dunbar > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:06:24 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761E91A1A92 for ; Tue, 30 Jun 2015 14:06:23 -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 kdUrKwigLt4w for ; Tue, 30 Jun 2015 14:06:22 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE581A1A90 for ; Tue, 30 Jun 2015 14:06:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: , "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> In-Reply-To: Date: Tue, 30 Jun 2015 17:06:20 -0400 Message-ID: <006501d0b378$9d30c190$d79244b0$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0Ci5CmT5412f6g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:06:23 -0000 Forwarding to I2RS list due to list restriction. Sue -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, June 30, 2015 3:23 PM To: 'Linda Dunbar'; 'Juergen Schoenwaelder' Cc: 'nitin_bahadur@yahoo.com'; 'i2rs@ietf.org'; 'ttkacik@cisco.com'; 'Hariharan Ananthakrishnan'; 'rovarga@cisco.com'; 'alex@cisco.com'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda and Juergen: The I2RS client may talk to multiple I2RS agents on multiple nodes or an I2RS client may talk to only one I2RS agent on one node. Whether the I2RS client maintains a network-wide view or a single device view is up to the I2RS client's implementation. The I2RS client to I2RS agent protocol deals with the protocol between one I2RS client and one I2RS Agent which may exist over multiple transport connections. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 29, 2015 10:47 AM To: Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen, One I2RS agent can interface with multiple routing elements. The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. Linda -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Monday, June 29, 2015 3:28 AM To: Linda Dunbar Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; ttkacik@cisco.com Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda, according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. /js On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: > Alex, et al, > > The I2RS architecture depicts two types of interfaces: > > - One is the interface between Agent and Client, and > > - another is the interface between Agent and Routing entities. > > > The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. > > > And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? > > IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. > > I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. > > The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. > > Cheers, > > Linda Dunbar > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:06: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 A9DBA1A1AE3; Tue, 30 Jun 2015 14:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Eymkubt07Yu; Tue, 30 Jun 2015 14:06:42 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::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 C08A91A1ADB; Tue, 30 Jun 2015 14:06:40 -0700 (PDT) Received: by pdbci14 with SMTP id ci14so12309793pdb.2; Tue, 30 Jun 2015 14:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=YK+LYEiwGkO5fsdhE8iG7NdlYogXfBaxteSzLretNCQ=; b=eHBLUCwedxc5ywrLGi8/9vI4LWW5OXRA2dMcSlEC11ob4jalWRhsoZSK2CGsMI8IU7 T3o7CXkiEBHfB5JISZZL/HV1BKSObQV2FKSag9aRba44ZQrv80Dy61efio2zWoFWMC0j S++ocdISd2OVcwZJE8rrIAvSjRQ9l/SVMvjG32vQJhZJTie4P5HpeHW7T6QhJjsJF5QY e7EgOZR/Ix6jiIbgZYkm3c9EBWsg6f79QVqO3+llaQknySe6MPaHNRfyDXKizp5b/11T hTKKV8UdbhBYdnlp95Bt2bj/eMZwKWfM1rJqbIoHWyHp9BuVRmG4ExhQY8MBF30RMJnm Bkcg== X-Received: by 10.66.249.1 with SMTP id yq1mr46365173pac.3.1435698399851; Tue, 30 Jun 2015 14:06:39 -0700 (PDT) Received: from ?IPv6:2001:420:290:1266:8188:3b9c:b5d1:be1b? ([2001:420:290:1266:8188:3b9c:b5d1:be1b]) by mx.google.com with ESMTPSA id vl1sm46770397pab.21.2015.06.30.14.06.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jun 2015 14:06:38 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Mahesh Jethanandani In-Reply-To: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> Date: Tue, 30 Jun 2015 12:43:31 -0700 Message-Id: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, "BRUNGARD, DEBORAH A" , Netconf , NETMOD Working Group Subject: Re: [i2rs] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:06:46 -0000 --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Susan, The NETCONF WG acknowledges the receipt of the requirements. These requirements need to be discussed in front of the NETCONF WG. = Would suggest that i2rs WG present these requirements in front of the = NETCONF WG during IETF 93 in Prague to kick start discussion within the = WG. Please let us know how much time you (or someone from i2rs) would = need to present the requirements. Thanks. > On Jun 23, 2015, at 11:19 AM, Susan Hares wrote: >=20 > Netconf Working Group:=20 > =20 > The I2RS WG would like to pass you a set of requirements for the I2RS = protocol, and asks that you provide an analysis by IETF 93 on whether = NETCONF or RESTCONF can meet these requirements. We expect that these = requirements may require changes to the either NETCONF or RESTCONF. =20 > =20 > The I2RS architecture document (draft-ietf-i2rs-architecture-09 = ) = provides a high-level overview of the I2RS protocol. The I2RS has = compiled the following documents to provide the additional details on = the requirements for the protocols.=20 > =20 > 1) draft-ietf-i2rs-ephemeral-state-00 = =20 > 2) draft-ietf-i2rs-pub-sub-requirements-02 = =20= > 3) draft-ietf-i2rs-traceability-03 = =20 > =20 > The draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for I2RS. = In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of = detailed requirements on how the I2RS WG sees the I2RS protocol = operating. These detailed requirements are to be seen as suggestions on = what type of solution the I2RS WG would like to see, but I2RS WG is = asking the NETCONF WG to provide its best designed protocol. Please = note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =20 > =20 > The I2RS protocol is driven by data-models. The approved data models = for protocol independent services are: > - draft-ietf-i2rs-rib-data-model-00 = > - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 = (released later this week) > - Topology model which is a composite of: > o Generic topology model: draft-ietf-i2rs-yang-network-topo-01 = =20 > o L3 topology model: draft-ietf-i2rs-yang-l3-topology-00 = =20 > o L2 topology model: draft-ietf-i2rs-yang-l2-network-topology-00 = =20 > o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 > o Service topology model: = draft-hares-i2rs-service-topo-yang-model-00 (released on Wednesday) > =20 > At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. = Estimated rates of transfer and timing requirements for these modules = are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki = - under the protocol = requirements table.=20 > =20 > We hope that NETCONF WG can provide some initial feedback on these = requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the = 6/24 interim at 10:00-11:30am ET to provide a time for any participate = in the I2RS, netconf, or netmod group to ask additional questions on = these requirements.=20 > =20 > Sue Hares=20 > =20 > Interim time: 10:00-11:30am ET > Date 6/24/2015 > Webex:=20 > = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d0f= = > =20 > agenda:=20 > =20 > 10:00 =E2=80=93 10:05 =E2=80=93 Bash Agenda > 10:05 =E2=80=93 10:20- - review of requirements from > draft-ietf-i2rs-ephemeral-state-00 > draft-ietf-i2rs-pub-sub-requirements-02 > draft-ietf-i2rs-traceability-03 > Timing requirements=20 > =20 > 10:20 =E2=80=93 10:30 Review of requirements for mutual = authentication, > and transaction in draft-hares-auth-trans-01 requirements=20 > =20 > 10:30- 11:30 Open discussion for I2RS Requirements=20 > =20 > Proceedings and slides can be found at:=20 > = http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html = = > =20 > Sue Hares=20 > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Susan,

The = NETCONF WG acknowledges the receipt of the requirements.

These requirements need = to be discussed in front of the NETCONF WG. Would suggest that i2rs WG = present these requirements in front of the NETCONF WG during IETF 93 in = Prague to kick start discussion within the WG. Please let us know how = much time you (or someone from i2rs) would need to present the = requirements.

Thanks.

On Jun 23, 2015, at 11:19 AM, = Susan Hares <shares@ndzh.com> wrote:

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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_D4B66922-6925-4751-AD43-941A1D78CBE5-- From nobody Tue Jun 30 14:07: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 6B3C61B2C41 for ; Tue, 30 Jun 2015 14:07:08 -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 Ov-SIi6qRa6k for ; Tue, 30 Jun 2015 14:07:07 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CD51B2DAD for ; Tue, 30 Jun 2015 14:07:04 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:06:57 -0400 Message-ID: <006701d0b378$b38e01a0$1aaa04e0$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0BsDd2nAIKJeLLnixjywA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Joel M. Halpern'" , 'Juergen Schoenwaelder' , 'Linda Dunbar' Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:07:08 -0000 Forwarding to list. -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, June 30, 2015 3:26 PM To: 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen Schoenwaelder' Cc: 'nitin_bahadur@yahoo.com'; 'i2rs@ietf.org'; 'ttkacik@cisco.com'; 'Hariharan Ananthakrishnan'; 'rovarga@cisco.com'; 'alex@cisco.com'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Joel and Juergen: My understand of the draft-ietf-i2rs-architecture aligns with yours. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 29, 2015 2:01 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, and an agent may be communicating with multiple clients. But it is still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; > ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >> >> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:07: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 2681F1A1B0D for ; Tue, 30 Jun 2015 14:07:32 -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 9W30gdKe1Qsk for ; Tue, 30 Jun 2015 14:07:30 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A7F1AC416 for ; Tue, 30 Jun 2015 14:07:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:07:20 -0400 Message-ID: <006901d0b378$c0f259e0$42d70da0$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0BsDd2nAF8Y5x2AmbX9zyeHZtJoA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Igor Bryskin' Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:07:32 -0000 Forwarding to list -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, June 30, 2015 3:29 PM To: 'Igor Bryskin'; 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen Schoenwaelder' Cc: 'nitin_bahadur@yahoo.com'; 'i2rs@ietf.org'; 'ttkacik@cisco.com'; 'Hariharan Ananthakrishnan'; 'rovarga@cisco.com'; 'alex@cisco.com'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Igor: You are correct. The interaction between the I2RS agent to routing systems is considered out of scope of the I2RS protocol and I2RS WG. IETF I2RS proprietary I2RS client ------ I2RS agent----------------routing system Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Monday, June 29, 2015 2:33 PM To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 I agree with Joel, To answer Linda's question: if I2RS agent manages/represnts multiple physical devices, the interface between the agent and the devices is out of scope of I2RS. Note that such interface needs to be standardized only if one considers a scenario where an I2RS agent controls devices from different vendors. IMHO this scenario is unlikely, and at least for now it is safe to assume that said interface is private. Cheers, Igor -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 29, 2015 2:01 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, and an agent may be communicating with multiple clients. But it is still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; > ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >> >> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:07:56 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8EA1A1A90 for ; Tue, 30 Jun 2015 14:07:55 -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 WPWxP1FJS774 for ; Tue, 30 Jun 2015 14:07:53 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632041A1ADB for ; Tue, 30 Jun 2015 14:07:36 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> In-Reply-To: Date: Tue, 30 Jun 2015 17:07:39 -0400 Message-ID: <006b01d0b378$cc1c5280$6454f780$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0BsDd2nAF8Y5x2AiRn3B0B23PIqJ4Q00oA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:07:55 -0000 Forwarding to list. Sue -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, June 30, 2015 3:31 PM To: 'Linda Dunbar'; 'Igor Bryskin'; 'Joel M. Halpern'; 'Juergen Schoenwaelder' Cc: 'nitin_bahadur@yahoo.com'; 'i2rs@ietf.org'; 'ttkacik@cisco.com'; 'Hariharan Ananthakrishnan'; 'rovarga@cisco.com'; 'alex@cisco.com'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Linda: Thank you for the feedback on the draft-ietf-i2rs-yang-network-topo-01 draft. This is useful feedback to the authors as we try to explain the I2RS work to customers. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Monday, June 29, 2015 5:02 PM To: Igor Bryskin; Joel M. Halpern; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Joel, Igor, Juergen, Thanks for the feedback. Actually I always thought I2RS Agent is within a single routing engine until reading the "I2RS Topology" draft. I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specification for information exchange between a routing engine and its client. It reflects one single node's RIBs associated with multiple Routing Instances supported by the routing engine. But the "I2RS Topology", which is also a very good specification describing the network view of topologies (which consists of multiple nodes and links among them), is more suited for the entity that manages multiple routing nodes. RIBs of one routing engine and "topology of multiple routing engines" definitely represent different perspectives: one is node view, another one is the network view. In order to make I2RS widely adopted by the industry, it is very important not to make it too complicated. Routing is not simple to start with, therefore, it becomes especially more important to keep I2RS specification simple and to the point. Therefore, I suggest to have a paragraph in the "network-topo" draft to describe that this is for the network view, it is for clients who manage/monitor multiple routing engines. My two cents. Linda -----Original Message----- From: Igor Bryskin [mailto:IBryskin@advaoptical.com] Sent: Monday, June 29, 2015 1:33 PM To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 I agree with Joel, To answer Linda's question: if I2RS agent manages/represnts multiple physical devices, the interface between the agent and the devices is out of scope of I2RS. Note that such interface needs to be standardized only if one considers a scenario where an I2RS agent controls devices from different vendors. IMHO this scenario is unlikely, and at least for now it is safe to assume that said interface is private. Cheers, Igor -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Monday, June 29, 2015 2:01 PM To: Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, and an agent may be communicating with multiple clients. But it is still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. Yours, Joel On 6/29/15 10:46 AM, Linda Dunbar wrote: > Juergen, > > One I2RS agent can interface with multiple routing elements. > > The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. > > Linda > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, June 29, 2015 3:28 AM > To: Linda Dunbar > Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); > rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan Ananthakrishnan; > ttkacik@cisco.com > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Linda, > > according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. > > /js > > On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >> Alex, et al, >> >> The I2RS architecture depicts two types of interfaces: >> >> - One is the interface between Agent and Client, and >> >> - another is the interface between Agent and Routing entities. >> >> >> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >> >> >> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >> >> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >> >> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >> >> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >> >> Cheers, >> >> Linda Dunbar >> >> > >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:08:38 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65371A1AA2 for ; Tue, 30 Jun 2015 14:08:36 -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 IqSA-KO1EA4I for ; Tue, 30 Jun 2015 14:08:34 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9965D1B2C4A for ; Tue, 30 Jun 2015 14:08:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: References: <4A95BA014132FF49AE685FAB4B9F17F657C72B8A@dfweml702-chm> <20150629082802.GA33258@elstar.local> <4A95BA014132FF49AE685FAB4B9F17F657C852B2@dfweml701-chm> <559187F6.9020108@joelhalpern.com> <5762f5baf8d840b0a09df29ae8febbe2@ATL-SRV-MBX1.advaoptical.com> <4A95BA014132FF49AE685FAB4B9F17F657C8868F@dfweml701-chm> <5591B349.2000102@joelhalpern.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:08:16 -0400 Message-ID: <006d01d0b378$e2283e40$a678bac0$@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: AQF7WiqpNWxBIcu2yr4V7yppvS4EEgGnDlOxAxm4dt0BsDd2nAF8Y5x2AiRn3B0CQlqQWAGdvyq8AitH+Zqd71QAUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: comments to draft-ietf-i2rs-yang-network-topo-01 X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:08:36 -0000 Forwarding to I2RS list. -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Tuesday, June 30, 2015 3:59 PM To: 'Igor Bryskin'; 'Joel M. Halpern'; 'Linda Dunbar'; 'Juergen Schoenwaelder' Cc: 'nitin_bahadur@yahoo.com'; 'i2rs@ietf.org'; 'ttkacik@cisco.com'; 'Hariharan Ananthakrishnan'; 'rovarga@cisco.com'; 'alex@cisco.com'; 'Jan Medved (jmedved)' Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Igor and Joel: I agree with Igor. See the draft-ietf-idr-ls-distribution debates. The argument in these debates is that it was better to pull the information regarding topologies from key nodes within the routing topologies. If you disagree, I encourage you to debate this for the draft-ietf-idr-ls-distribution rather than just for I2RS. If you agree with the draft-ietf-idr-ls-distribution, then the I2RS creation of a topology that is network-wide within a specific node is the same concept. I agree with Igor that I2RS should be modify these topologies beyond by combining learned topologies plus ephemerally configured topologies. However, the exact combination must be spelled out in the I2RS data module. Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Igor Bryskin Sent: Tuesday, June 30, 2015 8:49 AM To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 Hi Joel, I agree that there is a difference as to how we deal with RIB and topologies. RIB is a property of a single physical device, while topologies (both routing/reachability and TE) are always network-wide. However, for some applications it is important to extract topologies from a layer 3 switch as they are, for example, learned by the switch's routing protocols. I think of I2RS as a unified interface to a routing system to get everything the system exposes to the outside world. Hence I2RS is a right interface IMHO to extract topologies from a given physical switch. Furthermore, if an I2RS agent represents/manages multiple devices (e.g. SDN controller), it may expose abstract topologies (instead or in addition to its native topologies ) customized on per client basis. If one assumes that said clients can (re-)configure themselves the abstract topologies, then we have the same issues as we have with RIB (conflicting (re-)configurations of a given abstract topology, client priorities and ephemeral state). So why not to resolve all these issues in a similar way ? Cheers, Igor -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Monday, June 29, 2015 5:06 PM To: Linda Dunbar; Igor Bryskin; Juergen Schoenwaelder Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan Medved (jmedved) Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 You may recall that I have expressed concern about many times about how the network topology draft fits the I2RS scope. It is still not clear to me that it is an I2RS item, although it is clearly useful for things talking to the I2RS Agent. Yours, Joel On 6/29/15 5:01 PM, Linda Dunbar wrote: > Joel, Igor, Juergen, > > Thanks for the feedback. Actually I always thought I2RS Agent is within a single routing engine until reading the "I2RS Topology" draft. > > I see draft-ietf-i2rs-rib-info-model-06 as a very clear and good specification for information exchange between a routing engine and its client. It reflects one single node's RIBs associated with multiple Routing Instances supported by the routing engine. > > But the "I2RS Topology", which is also a very good specification describing the network view of topologies (which consists of multiple nodes and links among them), is more suited for the entity that manages multiple routing nodes. > > RIBs of one routing engine and "topology of multiple routing engines" definitely represent different perspectives: one is node view, another one is the network view. > > > In order to make I2RS widely adopted by the industry, it is very important not to make it too complicated. Routing is not simple to start with, therefore, it becomes especially more important to keep I2RS specification simple and to the point. > > Therefore, I suggest to have a paragraph in the "network-topo" draft to describe that this is for the network view, it is for clients who manage/monitor multiple routing engines. > > My two cents. > > Linda > > -----Original Message----- > From: Igor Bryskin [mailto:IBryskin@advaoptical.com] > Sent: Monday, June 29, 2015 1:33 PM > To: Joel M. Halpern; Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; > Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan > Medved (jmedved) > Subject: RE: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > I agree with Joel, > > To answer Linda's question: if I2RS agent manages/represnts multiple physical devices, the interface between the agent and the devices is out of scope of I2RS. Note that such interface needs to be standardized only if one considers a scenario where an I2RS agent controls devices from different vendors. IMHO this scenario is unlikely, and at least for now it is safe to assume that said interface is private. > > Cheers, > Igor > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, June 29, 2015 2:01 PM > To: Linda Dunbar; Juergen Schoenwaelder > Cc: nitin_bahadur@yahoo.com; 'i2rs@ietf.org'; ttkacik@cisco.com; > Hariharan Ananthakrishnan; rovarga@cisco.com; alex@cisco.com; Jan > Medved (jmedved) > Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 > > Juergen is correct that by the I2RS definition an I2RS Agent is part of, and associated with, a single routing element. > > It is true that the routing element may itself be a controller supporting and interacting with multiple forwarding elements. That is not required, and not discussed, by I2RS. As far as I2RS is concerned, the multiplicity is that the relationship between I2RS Clittns and I2rS agents is N:M. That is, a client may be working with multiple agents, > and an agent may be communicating with multiple clients. But it is > still the case that the agent is collocated with the routing system, and is not in a separate controller from the routing system. > > Yours, > Joel > > On 6/29/15 10:46 AM, Linda Dunbar wrote: >> Juergen, >> >> One I2RS agent can interface with multiple routing elements. >> >> The network view (which consists of multiple nodes, i.e. topology) has to be over multiple nodes. Therefore, it is the interface between client and Agent. Whereas, there are commands to individual routing element. >> >> Linda >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Monday, June 29, 2015 3:28 AM >> To: Linda Dunbar >> Cc: 'i2rs@ietf.org'; alex@cisco.com; Jan Medved (jmedved); >> rovarga@cisco.com; nitin_bahadur@yahoo.com; Hariharan >> Ananthakrishnan; ttkacik@cisco.com >> Subject: Re: [i2rs] comments to draft-ietf-i2rs-yang-network-topo-01 >> >> Linda, >> >> according to draft-ietf-i2rs-architecture-09, an I2RS agent is part of a routing element. I am not sure your understanding "I2RS Agent is like the SDN controller" is consistent with the architecture document. >> >> /js >> >> On Fri, Jun 26, 2015 at 05:03:25PM +0000, Linda Dunbar wrote: >>> Alex, et al, >>> >>> The I2RS architecture depicts two types of interfaces: >>> >>> - One is the interface between Agent and Client, and >>> >>> - another is the interface between Agent and Routing entities. >>> >>> >>> The network model and inventory are more for the interface between Agent and the Clients, isn't it? One single routing engine doesn't need to know the overall topology and inventory information of other nodes, even though some may do. >>> >>> >>> And the /nd:network/nd:node and Termination points are more for the interface between the Agent and the Forwarding Engine, isn't it? >>> >>> IMHO, the information models should be oriented around the I2RS architecture. I.e. with description on where those information models are applicable, making it easier to differentiate from other IETF WGs work (such as L2VPN, L3VPN, or SFC). I recall there were some debates at the Dallas I2RS session. >>> >>> I2RS Agent is like the SDN controller, which can inform clients about the topology information, instruct routes to routing engine of multiple nodes, and retrieve link & termination points status from each of those nodes. >>> >>> The "Service Overlay" in Section 3.4.8 is definitely meant for clients not towards individual nodes. Mixing them all together make it confusing. >>> >>> Cheers, >>> >>> Linda Dunbar >>> >>> >> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Jun 30 14:16:31 2015 Return-Path: X-Original-To: i2rs@ietfa.amsl.com Delivered-To: i2rs@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA59F1B2E69; Tue, 30 Jun 2015 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoEyHFXdm96z; Tue, 30 Jun 2015 14:16:26 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0441B32B1; Tue, 30 Jun 2015 14:16:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: "'Mahesh Jethanandani'" References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> In-Reply-To: Date: Tue, 30 Jun 2015 17:16:20 -0400 Message-ID: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01D0B358.7BC9EFB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLnS3sq9A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: Rtg-yang-coord@ietf.org, i2rs@ietf.org, 'NETMOD Working Group' , 'Netconf' , "'BRUNGARD, DEBORAH A'" Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 21:16:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0076_01D0B358.7BC9EFB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mahesh:=20 =20 Ok. I thought you were going to review the requirement documents and = give I2RS an initial guess. We have present these at 3 I2RS interims, = and the slides are online. I will send the minutes to the netconf = working group for their review.=20 =20 The presentation of the requirements will need the following time:=20 =20 1) 10 top requirements =E2=80=93 5-10 minutes [Sue Hares]=20 2) Ephemeral state =E2=80=93 15 minutes [Jeff Haas]=20 3) Pub/sub requirements =E2=80=93 10-15 minutes [Eric Voit] 4) Traceability [ 10-15 minutes]=20 5) Security [10 minutes] [Sue Hares and Joel Halpern] 6) Review of I2RS models [5 minutes]=20 7) =20 If you have heard pub/sub and traceability requirements, you may delete = this from timeline.=20 =20 Sue Hares=20 =20 From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf = Of Mahesh Jethanandani Sent: Tuesday, June 30, 2015 3:44 PM To: Susan Hares Cc: Rtg-yang-coord@ietf.org; i2rs@ietf.org; BRUNGARD, DEBORAH A; = Netconf; NETMOD Working Group Subject: Re: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol = and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) =20 Susan, =20 The NETCONF WG acknowledges the receipt of the requirements. =20 These requirements need to be discussed in front of the NETCONF WG. = Would suggest that i2rs WG present these requirements in front of the = NETCONF WG during IETF 93 in Prague to kick start discussion within the = WG. Please let us know how much time you (or someone from i2rs) would = need to present the requirements. =20 Thanks. =20 On Jun 23, 2015, at 11:19 AM, Susan Hares wrote: =20 Netconf Working Group:=20 =20 The I2RS WG would like to pass you a set of requirements for the I2RS = protocol, and asks that you provide an analysis by IETF 93 on whether = NETCONF or RESTCONF can meet these requirements. We expect that these = requirements may require changes to the either NETCONF or RESTCONF. =20 =20 The I2RS architecture document ( = = draft-ietf-i2rs-architecture-09) provides a high-level overview of the = I2RS protocol. The I2RS has compiled the following documents to = provide the additional details on the requirements for the protocols.=20 =20 1) = = draft-ietf-i2rs-ephemeral-state-00=20 2) = = draft-ietf-i2rs-pub-sub-requirements-02=20 3) = = draft-ietf-i2rs-traceability-03 =20 =20 The draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for I2RS. = In addition, the draft-ietf-i2rs-ephemeral-state-00 contains an set of = detailed requirements on how the I2RS WG sees the I2RS protocol = operating. These detailed requirements are to be seen as suggestions on = what type of solution the I2RS WG would like to see, but I2RS WG is = asking the NETCONF WG to provide its best designed protocol. Please = note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =20 =20 The I2RS protocol is driven by data-models. The approved data models = for protocol independent services are: - = = draft-ietf-i2rs-rib-data-model-00 - Filter-Based RIBS: draft-kini-i2rs-fb-rib-data-model.00 = (released later this week) - Topology model which is a composite of: o Generic topology model: = = draft-ietf-i2rs-yang-network-topo-01=20 o L3 topology model: = = draft-ietf-i2rs-yang-l3-topology-00=20 o L2 topology model: = draft-ietf-i2rs-yang-l2-network-topology-00=20 o L1 Topology model: draft-zhang-i2rs-l1-topo-yang-model-01 (-02 = released later this week).=20 o Service topology model: draft-hares-i2rs-service-topo-yang-model-00 = (released on Wednesday) =20 At this time, none of the Topology models utilize Traffic engineering. = It is anticipated that these models will support traffic engineering. = Estimated rates of transfer and timing requirements for these modules = are at: = http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the protocol = requirements table.=20 =20 We hope that NETCONF WG can provide some initial feedback on these = requirements by IETF 93 at the Tuesday I2RS session. I2RS will use the = 6/24 interim at 10:00-11:30am ET to provide a time for any participate = in the I2RS, netconf, or netmod group to ask additional questions on = these requirements.=20 =20 Sue Hares=20 =20 Interim time: 10:00-11:30am ET Date 6/24/2015 Webex:=20 = = https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7be61cb17b0008a3c52069d0= f =20 agenda:=20 =20 10:00 =E2=80=93 10:05 =E2=80=93 Bash Agenda 10:05 =E2=80=93 10:20- - review of requirements from draft-ietf-i2rs-ephemeral-state-00 draft-ietf-i2rs-pub-sub-requirements-02 draft-ietf-i2rs-traceability-03 Timing requirements=20 =20 10:20 =E2=80=93 10:30 Review of requirements for mutual = authentication, and transaction in draft-hares-auth-trans-01 requirements=20 =20 10:30- 11:30 Open discussion for I2RS Requirements=20 =20 Proceedings and slides can be found at:=20 = = http://www.ietf.org/proceedings/interim/2015/06/24/i2rs/proceedings.html =20 Sue Hares=20 =20 =20 _______________________________________________ netmod mailing list netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod =20 Mahesh Jethanandani mjethanandani@gmail.com =20 =20 =20 ------=_NextPart_000_0076_01D0B358.7BC9EFB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Mahesh:

 

Ok. =C2=A0I thought you were going to review the requirement = documents and give I2RS an initial guess.=C2=A0 We have present these at = 3 I2RS interims, and the slides are online.=C2=A0 I will send the = minutes to the netconf working group for their review. =

 

The presentation of the requirements will need the following time: =

 

1)      = 10 top requirements =E2=80=93 5-10 minutes [Sue Hares] =

2)      = Ephemeral state =E2=80=93 15 minutes [Jeff Haas] =

3)      = Pub/sub requirements =E2=80=93 10-15 minutes [Eric = Voit]

4)      = Traceability [ 10-15 minutes]

5)      = Security [10 minutes] [Sue Hares and Joel = Halpern]

6)      = Review of I2RS models [5 minutes]

7)      =  

If you have heard pub/sub and traceability requirements, you may = delete this from timeline.

 

Sue Hares

 

From:= = Rtg-yang-coord [mailto:rtg-yang-coord-bounces@ietf.org] On Behalf Of = Mahesh Jethanandani
Sent: Tuesday, June 30, 2015 3:44 = PM
To: Susan Hares
Cc: Rtg-yang-coord@ietf.org; = i2rs@ietf.org; BRUNGARD, DEBORAH A; Netconf; NETMOD Working = Group
Subject: Re: [Rtg-yang-coord] [netmod] Requirements for = I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am = ET)

 

Susan,

 

The NETCONF WG acknowledges the receipt of the = requirements.

 

These requirements need to be discussed in front of = the NETCONF WG. Would suggest that i2rs WG present these requirements in = front of the NETCONF WG during IETF 93 in Prague to kick start = discussion within the WG. Please let us know how much time you (or = someone from i2rs) would need to present the = requirements.

 

Thanks.

 

On Jun 23, 2015, at 11:19 AM, Susan Hares <shares@ndzh.com> = wrote:

 

Netconf = Working Group: 

 =

The I2RS = WG would like to pass you a set of requirements for the I2RS protocol, = and asks that you provide an analysis by IETF 93 on whether NETCONF or = RESTCONF can meet these requirements.   We expect that these = requirements may require changes to the either NETCONF or = RESTCONF.  

 =

The I2RS = architecture document (<= span = style=3D'font-size:11.5pt;color:#3D22B3;background:white;text-decoration:= none'>draft-ietf-i2rs-architecture-09) provides a = high-level overview of the I2RS  protocol.  The I2RS has = compiled the following documents to provide the additional details on = the requirements for the protocols. 

 =

 =

The = draft-ietf-i2rs-ephemeral-state-00 contains the results of the = discussion from the 6/10 interim and the top 10 requirements for = I2RS.  In addition, the draft-ietf-i2rs-ephemeral-state-00 contains = an set of detailed requirements on how the I2RS WG sees the I2RS = protocol operating.  These detailed requirements are to be seen as = suggestions on what type of solution the I2RS WG would like to see, but = I2RS WG is asking the NETCONF WG to provide its best designed = protocol.  Please note as part of these detailed requirement the = draft-ietf-i2rs-ephemeral-states-00 contains the idea of using metadata = to record secondary identity. =   

 =

The I2RS = protocol is driven by data-models.  The approved data models for = protocol independent services are:

-        = ;  draft-ietf-i2rs-rib-data-model-00

<= /div>

-        = ;  Filter-Base= d RIBS:  draft-kini-i2rs-fb-rib-data-model.00 (released later = this week)=

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

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

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

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

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

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

 =

At this = time, none of the Topology models utilize Traffic engineering.  It = is anticipated that these models will support traffic engineering. =  Estimated rates of transfer and timing requirements for these = modules are at: http://trac.tools.ietf.org/wg/i2rs/trac/wiki - under the = protocol requirements table. 

 =

We hope = that NETCONF WG can provide some initial feedback on these requirements = by IETF 93 at the Tuesday I2RS session.   I2RS will use the = 6/24 interim at 10:00-11:30am ET  to provide a time for any = participate in the I2RS, netconf, or netmod group to ask additional = questions on these requirements. 

 =

Sue = Hares 

 =

Interim = time: 10:00-11:30am ET

Date = 6/24/2015

Webex: 

https://ietf.webex.com/ietf/j.php?MTID=3Dm4260bee7= be61cb17b0008a3c52069d0f

 =

agenda: 

 =

10:00 = =E2=80=93 10:05 =E2=80=93 Bash Agenda

10:05 = =E2=80=93 10:20- -  review of requirements = from

draft-ietf-= i2rs-ephemeral-state-00

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

draft-ietf-= i2rs-traceability-03

Timing = requirements 

 =

10:20 = =E2=80=93 10:30    Review of requirements for mutual = authentication,

and = transaction in  draft-hares-auth-trans-01 requirements 

 =

10:30- = 11:30     Open discussion for I2RS Requirements 

 =

Proceedings= and slides can be found at: 

http://www.ietf.org/proceedings/interim/2015/06/24= /i2rs/proceedings.html

 =

Sue = Hares 

 =

 =

__________= _____________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

=

 

Mahesh Jethanandani

 

 

 

------=_NextPart_000_0076_01D0B358.7BC9EFB0-- From nobody Tue Jun 30 15:11:45 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 BEB451B3315 for ; Tue, 30 Jun 2015 15:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.054 X-Spam-Level: X-Spam-Status: No, score=-99.054 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPRoaYXpzoWm for ; Tue, 30 Jun 2015 15:11:43 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1293B1B330A for ; Tue, 30 Jun 2015 15:11:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.134; From: "Susan Hares" To: Date: Tue, 30 Jun 2015 18:11:44 -0400 Message-ID: <011a01d0b381$c000b7d0$40022770$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_011B_01D0B360.38F22510" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdCzgW2lNX0EgaxVS/yVlw7Qjlj/tA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, 'Alia Atlas' Subject: [i2rs] I2RS interim on 7/1/2015 at 10:00 - 11:30am EDT - Agenda and webex information X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:11:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_011B_01D0B360.38F22510 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I2RS interim meeting 7/1/2015 time: 10:00-11:30am ET Agenda: 1) Agenda bashing [10:00-10:05] 2) FB-RIB base model [10:05 - 10:20] [draft-kini-i2rs-fb-fib-info-model-01] 3) Example Policy models that plug-in [10:20-10:35]] ACL policy model [draft-ietf-netmod-acl-model-03] routing policy model [draft-shaikh-rtgwg-policy-model-00] generic policy model [Sue Hares] [draft-hares-bnp-eca-00.txt] SFC traffic model [draft-dunbar-i2rs-fbrib-sfc-filters] 4) Discussion: [10:35 -10:45 ] 5) Service Topology model [10:45-11:00] [draft-hares-i2rs-service-topo-data-model] Example protocol specific topology model: SFF toplogy model [11:00 - 11:10] 6)Service topology discussion [11:10 - 11:30] i2rs interim 7/1/2015 Wednesday, July 1, 2015 10:00 am | Eastern Daylight Time (New York, GMT-04:00) | 2 hrs [interim web-ex available at 9:30 for speakers to check audio] Join WebEx meeting https://ietf.webex.com/ietf/j.php?MTID=m01b6aeeeb1b8701466c0ec6ebb11a301 Meeting number: 319 797 760 Meeting password: models.security 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: 319 797 760 ------=_NextPart_000_011B_01D0B360.38F22510 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I2RS interim = meeting 7/1/2015

 

time: = 10:00-11:30am ET

 

Agenda: =

1) Agenda bashing = [10:00-10:05]

2) FB-RIB base model = [10:05 - 10:20]

   [draft-kini-i2rs-fb-fib-info-model-01= ]

  

3) Example Policy models that plug-in = [10:20-10:35]]

   ACL = policy model 

   [draft-ietf-netmod-acl-model-03]=

   routing policy model =

   [draft-shaikh-rtgwg-policy-model-00]<= o:p>

   generic policy model = [Sue Hares]

   = [draft-hares-bnp-eca-00.txt]

  =

   SFC traffic model =

   [draft-dunbar-i2rs-fbrib-sfc-filters]=

 

4) Discussion: [10:35 -10:45 ]

 

5) Service = Topology model [10:45-11:00]

    = [draft-hares-i2rs-service-topo-data-model]

    

    Example protocol specific = topology model:
      SFF toplogy model = [11:00 - 11:10]

 

6)Service = topology discussion [11:10 – 11:30]

 

 

i2rs interim = 7/1/2015

Wednesday, July 1, 2015 =

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

[interim web-ex available at 9:30 = for speakers to check audio]

 

=

Join WebEx meeting

https://ietf.webex.com/ietf/j.php?MTID=3Dm01b6aeeeb1b8701466c0= ec6ebb11a301

 

Meeting = number:            319 = 797 760

Meeting = password:         = models.security

 

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: 319 797 = 760

------=_NextPart_000_011B_01D0B360.38F22510-- From nobody Tue Jun 30 15:13: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 73E861B3317; Tue, 30 Jun 2015 15:13:48 -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 ulGayuEvAWcB; Tue, 30 Jun 2015 15:13:45 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E9B1B3313; Tue, 30 Jun 2015 15:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61472; q=dns/txt; s=iport; t=1435702425; x=1436912025; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tjhHoEQRxgW3RYGGcDYhd1sTUgeHWTSMXCa73+bIz7M=; b=kjKFZLfSzzDGGAzeqkl+V2xpq7M7IIVO2Goh/iV8UGa+T1zs2f8rQ4qI XTqg13Lo6W95nYuJE5uH1+2ckzVUvZPptW0AlVmwNSUW64Gx7ytDvgMA9 DHXYmul0vi4FRDuG3S7iyTIIeZeyCW3wMyT2ydMap2sH9sbRCE5xW5DO3 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A0BQByFJNV/5JdJa1BEQmCRUxUXwaDGLoAKgmBSBkBC4UsSgIcgTo4FAEBAQEBAQGBCoQiAQEBBAEBASAKQQsQAgEIDgMBAwEBCxYBAgQDAgICHwYLFAMGCAIEAQkEBQgBEod/AxINOrImkQcNhXMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0qCTYFdKy0EBgGCaC+BFAWRKYJeAYRZhRqBZIE5RINOi1eHGhEVggwcFYE9bwGBRYECAQEB X-IronPort-AV: E=Sophos;i="5.15,380,1432598400"; d="scan'208,217";a="164434195" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2015 22:13:29 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5UMDSCg026310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 22:13:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.147]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 17:13:21 -0500 From: "Eric Voit (evoit)" To: Susan Hares , "'Mahesh Jethanandani'" Thread-Topic: [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) Thread-Index: AQISFdXuYb8FEw5zRd6nzKGMwfXW3QKbN0DLnS3sq9CAAAbrEA== Date: Tue, 30 Jun 2015 22:13:21 +0000 Message-ID: References: <00d901d0ade1$194280e0$4bc782a0$@ndzh.com> <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> In-Reply-To: <007501d0b37a$02d6fbd0$0884f370$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.118.56.228] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "Rtg-yang-coord@ietf.org" , "i2rs@ietf.org" , 'NETMOD Working Group' , "'BRUNGARD, DEBORAH A'" , "Alexander Clemm \(alex\)" , 'Netconf' Subject: Re: [i2rs] [Rtg-yang-coord] [netmod] Requirements for I2RS protocol and I2RS interim (6/24/2015 at 10:00 - 11:30am ET) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 22:13:48 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBwcmVzZW50ZWQgUHViU3ViIOKAmC0wMeKAmSByZXF1aXJlbWVudHMgaW4gTkVUQ09ORiBhdCBJ RVRGIDkyLiAgICBDaGFuZ2VzIGluIOKAmC0wMuKAmSBhcmUgbGlrZWx5IG5vdCBlbm91Z2ggZm9y IGEgc3BlYWtpbmcgc2xvdC4NCg0KV2hhdCBtaWdodCBiZSBpbnRlcmVzdGluZyBmb3IgYSBORVRD T05GIHNwZWFraW5nIHNsb3QgaXMgYW4gYW5hbHlzaXMgb2Ygd2hhdCByZXF1aXJlbWVudHMgZnJv bSDigJxkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHPigJ0gYXJlIG1ldCBieSDi gJxkcmFmdC1jbGVtbS1uZXRjb25mLXlhbmctcHVzaOKAnS4gICAoRHVyaW5nIElFVEYgOTIsIE5F VENPTkYgcmV2aWV3ZWQgZHJhZnQtY2xlbW0uIFRoZXJlIHdhcyBhIHN0cmF3bWFuIHBvbGwgKDEy IHllcywgMCBubykgd2hlcmUgdGhlIFdHIGluZGljYXRlZCBpbnRlcmVzdC4pDQoNCldvdWxkIE5F VENPTkYgd2FudCBBbGV4IG9yIEkgdG8gc3BlYWsgb24gYSByZXF1aXJlbWVudHMtdG8tdGVjaG5v bG9neSBjb21wYXJpc29uIGluIFByYWd1ZT8NCg0KRXJpYw0KDQpGcm9tOiBSdGcteWFuZy1jb29y ZCBbbWFpbHRvOnJ0Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT dXNhbiBIYXJlcw0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSA1OjE2IFBNDQpUbzogJ01h aGVzaCBKZXRoYW5hbmRhbmknDQpDYzogUnRnLXlhbmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0 Zi5vcmc7ICdORVRNT0QgV29ya2luZyBHcm91cCc7ICdOZXRjb25mJzsgJ0JSVU5HQVJELCBERUJP UkFIIEEnDQpTdWJqZWN0OiBSZTogW1J0Zy15YW5nLWNvb3JkXSBbbmV0bW9kXSBSZXF1aXJlbWVu dHMgZm9yIEkyUlMgcHJvdG9jb2wgYW5kIEkyUlMgaW50ZXJpbSAoNi8yNC8yMDE1IGF0IDEwOjAw IC0gMTE6MzBhbSBFVCkNCg0KTWFoZXNoOg0KDQpPay4gIEkgdGhvdWdodCB5b3Ugd2VyZSBnb2lu ZyB0byByZXZpZXcgdGhlIHJlcXVpcmVtZW50IGRvY3VtZW50cyBhbmQgZ2l2ZSBJMlJTIGFuIGlu aXRpYWwgZ3Vlc3MuICBXZSBoYXZlIHByZXNlbnQgdGhlc2UgYXQgMyBJMlJTIGludGVyaW1zLCBh bmQgdGhlIHNsaWRlcyBhcmUgb25saW5lLiAgSSB3aWxsIHNlbmQgdGhlIG1pbnV0ZXMgdG8gdGhl IG5ldGNvbmYgd29ya2luZyBncm91cCBmb3IgdGhlaXIgcmV2aWV3Lg0KDQpUaGUgcHJlc2VudGF0 aW9uIG9mIHRoZSByZXF1aXJlbWVudHMgd2lsbCBuZWVkIHRoZSBmb2xsb3dpbmcgdGltZToNCg0K DQoxKSAgICAgIDEwIHRvcCByZXF1aXJlbWVudHMg4oCTIDUtMTAgbWludXRlcyBbU3VlIEhhcmVz XQ0KDQoyKSAgICAgIEVwaGVtZXJhbCBzdGF0ZSDigJMgMTUgbWludXRlcyBbSmVmZiBIYWFzXQ0K DQozKSAgICAgIFB1Yi9zdWIgcmVxdWlyZW1lbnRzIOKAkyAxMC0xNSBtaW51dGVzIFtFcmljIFZv aXRdDQoNCjQpICAgICAgVHJhY2VhYmlsaXR5IFsgMTAtMTUgbWludXRlc10NCg0KNSkgICAgICBT ZWN1cml0eSBbMTAgbWludXRlc10gW1N1ZSBIYXJlcyBhbmQgSm9lbCBIYWxwZXJuXQ0KDQo2KSAg ICAgIFJldmlldyBvZiBJMlJTIG1vZGVscyBbNSBtaW51dGVzXQ0KDQo3KQ0KSWYgeW91IGhhdmUg aGVhcmQgcHViL3N1YiBhbmQgdHJhY2VhYmlsaXR5IHJlcXVpcmVtZW50cywgeW91IG1heSBkZWxl dGUgdGhpcyBmcm9tIHRpbWVsaW5lLg0KDQpTdWUgSGFyZXMNCg0KRnJvbTogUnRnLXlhbmctY29v cmQgW21haWx0bzpydGcteWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWFoZXNoIEpldGhhbmFuZGFuaQ0KU2VudDogVHVlc2RheSwgSnVuZSAzMCwgMjAxNSAzOjQ0IFBN DQpUbzogU3VzYW4gSGFyZXMNCkNjOiBSdGcteWFuZy1jb29yZEBpZXRmLm9yZzxtYWlsdG86UnRn LXlhbmctY29vcmRAaWV0Zi5vcmc+OyBpMnJzQGlldGYub3JnPG1haWx0bzppMnJzQGlldGYub3Jn PjsgQlJVTkdBUkQsIERFQk9SQUggQTsgTmV0Y29uZjsgTkVUTU9EIFdvcmtpbmcgR3JvdXANClN1 YmplY3Q6IFJlOiBbUnRnLXlhbmctY29vcmRdIFtuZXRtb2RdIFJlcXVpcmVtZW50cyBmb3IgSTJS UyBwcm90b2NvbCBhbmQgSTJSUyBpbnRlcmltICg2LzI0LzIwMTUgYXQgMTA6MDAgLSAxMTozMGFt IEVUKQ0KDQpTdXNhbiwNCg0KVGhlIE5FVENPTkYgV0cgYWNrbm93bGVkZ2VzIHRoZSByZWNlaXB0 IG9mIHRoZSByZXF1aXJlbWVudHMuDQoNClRoZXNlIHJlcXVpcmVtZW50cyBuZWVkIHRvIGJlIGRp c2N1c3NlZCBpbiBmcm9udCBvZiB0aGUgTkVUQ09ORiBXRy4gV291bGQgc3VnZ2VzdCB0aGF0IGky cnMgV0cgcHJlc2VudCB0aGVzZSByZXF1aXJlbWVudHMgaW4gZnJvbnQgb2YgdGhlIE5FVENPTkYg V0cgZHVyaW5nIElFVEYgOTMgaW4gUHJhZ3VlIHRvIGtpY2sgc3RhcnQgZGlzY3Vzc2lvbiB3aXRo aW4gdGhlIFdHLiBQbGVhc2UgbGV0IHVzIGtub3cgaG93IG11Y2ggdGltZSB5b3UgKG9yIHNvbWVv bmUgZnJvbSBpMnJzKSB3b3VsZCBuZWVkIHRvIHByZXNlbnQgdGhlIHJlcXVpcmVtZW50cy4NCg0K VGhhbmtzLg0KDQpPbiBKdW4gMjMsIDIwMTUsIGF0IDExOjE5IEFNLCBTdXNhbiBIYXJlcyA8c2hh cmVzQG5kemguY29tPG1haWx0bzpzaGFyZXNAbmR6aC5jb20+PiB3cm90ZToNCg0KTmV0Y29uZiBX b3JraW5nIEdyb3VwOg0KDQpUaGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHBhc3MgeW91IGEgc2V0 IG9mIHJlcXVpcmVtZW50cyBmb3IgdGhlIEkyUlMgcHJvdG9jb2wsIGFuZCBhc2tzIHRoYXQgeW91 IHByb3ZpZGUgYW4gYW5hbHlzaXMgYnkgSUVURiA5MyBvbiB3aGV0aGVyIE5FVENPTkYgb3IgUkVT VENPTkYgY2FuIG1lZXQgdGhlc2UgcmVxdWlyZW1lbnRzLiAgIFdlIGV4cGVjdCB0aGF0IHRoZXNl IHJlcXVpcmVtZW50cyBtYXkgcmVxdWlyZSBjaGFuZ2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBv ciBSRVNUQ09ORi4NCg0KVGhlIEkyUlMgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IChkcmFmdC1pZXRm LWkycnMtYXJjaGl0ZWN0dXJlLTA5PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy1hcmNoaXRlY3R1cmUvPikgcHJvdmlkZXMgYSBoaWdoLWxldmVsIG92ZXJ2 aWV3IG9mIHRoZSBJMlJTICBwcm90b2NvbC4gIFRoZSBJMlJTIGhhcyBjb21waWxlZCB0aGUgZm9s bG93aW5nIGRvY3VtZW50cyB0byBwcm92aWRlIHRoZSBhZGRpdGlvbmFsIGRldGFpbHMgb24gdGhl IHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29scy4NCg0KMSkgICAgICBkcmFmdC1pZXRmLWky cnMtZXBoZW1lcmFsLXN0YXRlLTAwPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGUvPg0KMikgICAgICBkcmFmdC1pZXRmLWkycnMt cHViLXN1Yi1yZXF1aXJlbWVudHMtMDI8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLz4NCjMpICAgICAgZHJhZnQtaWV0 Zi1pMnJzLXRyYWNlYWJpbGl0eS0wMzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMtdHJhY2VhYmlsaXR5Lz4NCg0KVGhlIGRyYWZ0LWlldGYtaTJycy1lcGhl bWVyYWwtc3RhdGUtMDAgY29udGFpbnMgdGhlIHJlc3VsdHMgb2YgdGhlIGRpc2N1c3Npb24gZnJv bSB0aGUgNi8xMCBpbnRlcmltIGFuZCB0aGUgdG9wIDEwIHJlcXVpcmVtZW50cyBmb3IgSTJSUy4g IEluIGFkZGl0aW9uLCB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBjb250 YWlucyBhbiBzZXQgb2YgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIG9uIGhvdyB0aGUgSTJSUyBXRyBz ZWVzIHRoZSBJMlJTIHByb3RvY29sIG9wZXJhdGluZy4gIFRoZXNlIGRldGFpbGVkIHJlcXVpcmVt ZW50cyBhcmUgdG8gYmUgc2VlbiBhcyBzdWdnZXN0aW9ucyBvbiB3aGF0IHR5cGUgb2Ygc29sdXRp b24gdGhlIEkyUlMgV0cgd291bGQgbGlrZSB0byBzZWUsIGJ1dCBJMlJTIFdHIGlzIGFza2luZyB0 aGUgTkVUQ09ORiBXRyB0byBwcm92aWRlIGl0cyBiZXN0IGRlc2lnbmVkIHByb3RvY29sLiAgUGxl YXNlIG5vdGUgYXMgcGFydCBvZiB0aGVzZSBkZXRhaWxlZCByZXF1aXJlbWVudCB0aGUgZHJhZnQt aWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZXMtMDAgY29udGFpbnMgdGhlIGlkZWEgb2YgdXNpbmcg bWV0YWRhdGEgdG8gcmVjb3JkIHNlY29uZGFyeSBpZGVudGl0eS4NCg0KVGhlIEkyUlMgcHJvdG9j b2wgaXMgZHJpdmVuIGJ5IGRhdGEtbW9kZWxzLiAgVGhlIGFwcHJvdmVkIGRhdGEgbW9kZWxzIGZv ciBwcm90b2NvbCBpbmRlcGVuZGVudCBzZXJ2aWNlcyBhcmU6DQotICAgICAgICAgIGRyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC0wMDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvPg0KLSAgICAgICAgICBGaWx0ZXItQmFz ZWQgUklCUzogIGRyYWZ0LWtpbmktaTJycy1mYi1yaWItZGF0YS1tb2RlbC4wMCAocmVsZWFzZWQg bGF0ZXIgdGhpcyB3ZWVrKQ0KLSAgICAgICAgICBUb3BvbG9neSBtb2RlbCB3aGljaCBpcyBhIGNv bXBvc2l0ZSBvZjoNCm8gICBHZW5lcmljIHRvcG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMt eWFuZy1uZXR3b3JrLXRvcG8tMDE8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1pMnJzLXlhbmctbmV0d29yay10b3BvLz4NCm8gICBMMyB0b3BvbG9neSBtb2RlbDog ZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3ktMDA8aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLXlhbmctbDMtdG9wb2xvZ3kvPg0KbyAgIEwyIHRv cG9sb2d5IG1vZGVsOiBkcmFmdC1pZXRmLWkycnMteWFuZy1sMi1uZXR3b3JrLXRvcG9sb2d5LTAw PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwy LW5ldHdvcmstdG9wb2xvZ3kvPg0KbyAgIEwxIFRvcG9sb2d5IG1vZGVsOiBkcmFmdC16aGFuZy1p MnJzLWwxLXRvcG8teWFuZy1tb2RlbC0wMSAoLTAyIHJlbGVhc2VkIGxhdGVyIHRoaXMgd2Vlayku DQpvICAgU2VydmljZSB0b3BvbG9neSBtb2RlbDogZHJhZnQtaGFyZXMtaTJycy1zZXJ2aWNlLXRv cG8teWFuZy1tb2RlbC0wMCAocmVsZWFzZWQgb24gV2VkbmVzZGF5KQ0KDQpBdCB0aGlzIHRpbWUs IG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRyYWZmaWMgZW5naW5lZXJpbmcu ICBJdCBpcyBhbnRpY2lwYXRlZCB0aGF0IHRoZXNlIG1vZGVscyB3aWxsIHN1cHBvcnQgdHJhZmZp YyBlbmdpbmVlcmluZy4gIEVzdGltYXRlZCByYXRlcyBvZiB0cmFuc2ZlciBhbmQgdGltaW5nIHJl cXVpcmVtZW50cyBmb3IgdGhlc2UgbW9kdWxlcyBhcmUgYXQ6IGh0dHA6Ly90cmFjLnRvb2xzLmll dGYub3JnL3dnL2kycnMvdHJhYy93aWtpIC0gdW5kZXIgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50 cyB0YWJsZS4NCg0KV2UgaG9wZSB0aGF0IE5FVENPTkYgV0cgY2FuIHByb3ZpZGUgc29tZSBpbml0 aWFsIGZlZWRiYWNrIG9uIHRoZXNlIHJlcXVpcmVtZW50cyBieSBJRVRGIDkzIGF0IHRoZSBUdWVz ZGF5IEkyUlMgc2Vzc2lvbi4gICBJMlJTIHdpbGwgdXNlIHRoZSA2LzI0IGludGVyaW0gYXQgMTA6 MDAtMTE6MzBhbSBFVCAgdG8gcHJvdmlkZSBhIHRpbWUgZm9yIGFueSBwYXJ0aWNpcGF0ZSBpbiB0 aGUgSTJSUywgbmV0Y29uZiwgb3IgbmV0bW9kIGdyb3VwIHRvIGFzayBhZGRpdGlvbmFsIHF1ZXN0 aW9ucyBvbiB0aGVzZSByZXF1aXJlbWVudHMuDQoNClN1ZSBIYXJlcw0KDQpJbnRlcmltIHRpbWU6 IDEwOjAwLTExOjMwYW0gRVQNCkRhdGUgNi8yNC8yMDE1DQpXZWJleDoNCmh0dHBzOi8vaWV0Zi53 ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW00MjYwYmVlN2JlNjFjYjE3YjAwMDhhM2M1MjA2OWQw Zg0KDQphZ2VuZGE6DQoNCjEwOjAwIOKAkyAxMDowNSDigJMgQmFzaCBBZ2VuZGENCjEwOjA1IOKA kyAxMDoyMC0gLSAgcmV2aWV3IG9mIHJlcXVpcmVtZW50cyBmcm9tDQpkcmFmdC1pZXRmLWkycnMt ZXBoZW1lcmFsLXN0YXRlLTAwDQpkcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMt MDINCmRyYWZ0LWlldGYtaTJycy10cmFjZWFiaWxpdHktMDMNClRpbWluZyByZXF1aXJlbWVudHMN Cg0KMTA6MjAg4oCTIDEwOjMwICAgIFJldmlldyBvZiByZXF1aXJlbWVudHMgZm9yIG11dHVhbCBh dXRoZW50aWNhdGlvbiwNCmFuZCB0cmFuc2FjdGlvbiBpbiAgZHJhZnQtaGFyZXMtYXV0aC10cmFu cy0wMSByZXF1aXJlbWVudHMNCg0KMTA6MzAtIDExOjMwICAgICBPcGVuIGRpc2N1c3Npb24gZm9y IEkyUlMgUmVxdWlyZW1lbnRzDQoNClByb2NlZWRpbmdzIGFuZCBzbGlkZXMgY2FuIGJlIGZvdW5k IGF0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDYvMjQv aTJycy9wcm9jZWVkaW5ncy5odG1sDQoNClN1ZSBIYXJlcw0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkNCm1qZXRoYW5h bmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4NCg0KDQoNCg== --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsN CgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxs b29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox ODkyMzAyNTU1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTMyNDQyNzg3MiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5JIHByZXNlbnRlZCBQdWJTdWIg4oCYLTAx4oCZIHJlcXVpcmVtZW50cyBpbiBORVRDT05GIGF0 IElFVEYgOTIuJm5ic3A7Jm5ic3A7ICZuYnNwO0NoYW5nZXMgaW4g4oCYLTAy4oCZIGFyZSBsaWtl bHkgbm90IGVub3VnaCBmb3IgYSBzcGVha2luZyBzbG90LiZuYnNwOyZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5XaGF0IG1pZ2h0IGJlIGludGVyZXN0aW5nIGZvciBhIE5FVENPTkYgc3BlYWtpbmcgc2xvdCBp cyBhbiBhbmFseXNpcyBvZiB3aGF0IHJlcXVpcmVtZW50cyBmcm9tIOKAnGRyYWZ0LWlldGYtaTJy cy1wdWItc3ViLXJlcXVpcmVtZW50c+KAnSBhcmUgbWV0IGJ5IOKAnGRyYWZ0LWNsZW1tLW5ldGNv bmYteWFuZy1wdXNo4oCdLiZuYnNwOyZuYnNwOw0KIChEdXJpbmcgSUVURiA5MiwgTkVUQ09ORiBy ZXZpZXdlZCBkcmFmdC1jbGVtbS4gVGhlcmUgd2FzIGEgc3RyYXdtYW4gcG9sbCAoMTIgeWVzLCAw IG5vKSB3aGVyZSB0aGUgV0cgaW5kaWNhdGVkIGludGVyZXN0Lik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldvdWxkIE5F VENPTkYgd2FudCBBbGV4IG9yIEkgdG8gc3BlYWsgb24gYSByZXF1aXJlbWVudHMtdG8tdGVjaG5v bG9neSBjb21wYXJpc29uIGluIFByYWd1ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUnRnLXlhbmctY29vcmQgW21haWx0bzpydGct eWFuZy1jb29yZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdXNhbiBI YXJlczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDU6MTYgUE08YnI+ DQo8Yj5Ubzo8L2I+ICdNYWhlc2ggSmV0aGFuYW5kYW5pJzxicj4NCjxiPkNjOjwvYj4gUnRnLXlh bmctY29vcmRAaWV0Zi5vcmc7IGkycnNAaWV0Zi5vcmc7ICdORVRNT0QgV29ya2luZyBHcm91cCc7 ICdOZXRjb25mJzsgJ0JSVU5HQVJELCBERUJPUkFIIEEnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbUnRnLXlhbmctY29vcmRdIFtuZXRtb2RdIFJlcXVpcmVtZW50cyBmb3IgSTJSUyBwcm90b2Nv bCBhbmQgSTJSUyBpbnRlcmltICg2LzI0LzIwMTUgYXQgMTA6MDAgLSAxMTozMGFtIEVUKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1haGVzaDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Pay4gJm5ic3A7SSB0aG91Z2h0IHlv dSB3ZXJlIGdvaW5nIHRvIHJldmlldyB0aGUgcmVxdWlyZW1lbnQgZG9jdW1lbnRzIGFuZCBnaXZl IEkyUlMgYW4gaW5pdGlhbCBndWVzcy4mbmJzcDsgV2UgaGF2ZSBwcmVzZW50IHRoZXNlIGF0IDMg STJSUw0KIGludGVyaW1zLCBhbmQgdGhlIHNsaWRlcyBhcmUgb25saW5lLiZuYnNwOyBJIHdpbGwg c2VuZCB0aGUgbWludXRlcyB0byB0aGUgbmV0Y29uZiB3b3JraW5nIGdyb3VwIGZvciB0aGVpciBy ZXZpZXcuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgcmVxdWlyZW1lbnRzIHdpbGwgbmVl ZCB0aGUgZm9sbG93aW5nIHRpbWU6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjEwIHRvcCByZXF1aXJlbWVudHMg4oCTIDUtMTAgbWludXRlcyBbU3VlIEhhcmVzXQ0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIpPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RXBoZW1lcmFsIHN0YXRlIOKAkyAx NSBtaW51dGVzIFtKZWZmIEhhYXNdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Myk8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5QdWIvc3ViIHJlcXVpcmVtZW50cyDigJMgMTAtMTUgbWludXRlcyBbRXJpYyBWb2l0XTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj40KTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRyYWNlYWJpbGl0eSBbIDEwLTE1IG1pbnV0 ZXNdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NSk8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWN1cml0eSBbMTAgbWlu dXRlc10gW1N1ZSBIYXJlcyBhbmQgSm9lbCBIYWxwZXJuXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj42KTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJldmlldyBvZiBJMlJTIG1vZGVscyBbNSBtaW51dGVzXQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjcpPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3UgaGF2ZSBoZWFyZCBwdWIvc3Vi IGFuZCB0cmFjZWFiaWxpdHkgcmVxdWlyZW1lbnRzLCB5b3UgbWF5IGRlbGV0ZSB0aGlzIGZyb20g dGltZWxpbmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+U3VlIEhhcmVzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJ0Zy15YW5nLWNvb3JkIFs8 YSBocmVmPSJtYWlsdG86cnRnLXlhbmctY29vcmQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnJ0 Zy15YW5nLWNvb3JkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5N YWhlc2ggSmV0aGFuYW5kYW5pPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMzAsIDIw MTUgMzo0NCBQTTxicj4NCjxiPlRvOjwvYj4gU3VzYW4gSGFyZXM8YnI+DQo8Yj5DYzo8L2I+IDxh IGhyZWY9Im1haWx0bzpSdGcteWFuZy1jb29yZEBpZXRmLm9yZyI+UnRnLXlhbmctY29vcmRAaWV0 Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aTJyc0BpZXRmLm9yZyI+DQppMnJzQGlldGYub3Jn PC9hPjsgQlJVTkdBUkQsIERFQk9SQUggQTsgTmV0Y29uZjsgTkVUTU9EIFdvcmtpbmcgR3JvdXA8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdGcteWFuZy1jb29yZF0gW25ldG1vZF0gUmVxdWly ZW1lbnRzIGZvciBJMlJTIHByb3RvY29sIGFuZCBJMlJTIGludGVyaW0gKDYvMjQvMjAxNSBhdCAx MDowMCAtIDExOjMwYW0gRVQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5TdXNhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlIE5FVENP TkYgV0cgYWNrbm93bGVkZ2VzIHRoZSByZWNlaXB0IG9mIHRoZSByZXF1aXJlbWVudHMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhlc2UgcmVxdWlyZW1l bnRzIG5lZWQgdG8gYmUgZGlzY3Vzc2VkIGluIGZyb250IG9mIHRoZSBORVRDT05GIFdHLiBXb3Vs ZCBzdWdnZXN0IHRoYXQgaTJycyBXRyBwcmVzZW50IHRoZXNlIHJlcXVpcmVtZW50cyBpbiBmcm9u dCBvZiB0aGUgTkVUQ09ORiBXRyBkdXJpbmcgSUVURiA5MyBpbiBQcmFndWUgdG8ga2ljayBzdGFy dCBkaXNjdXNzaW9uIHdpdGhpbiB0aGUgV0cuDQogUGxlYXNlIGxldCB1cyBrbm93IGhvdyBtdWNo IHRpbWUgeW91IChvciBzb21lb25lIGZyb20gaTJycykgd291bGQgbmVlZCB0byBwcmVzZW50IHRo ZSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5PbiBKdW4gMjMsIDIwMTUsIGF0IDExOjE5IEFNLCBTdXNhbiBIYXJlcyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNoYXJlc0BuZHpoLmNvbSI+c2hhcmVzQG5kemguY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+TmV0Y29uZiBXb3JraW5nIEdyb3VwOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRv IHBhc3MgeW91IGEgc2V0IG9mIHJlcXVpcmVtZW50cyBmb3IgdGhlIEkyUlMgcHJvdG9jb2wsIGFu ZCBhc2tzIHRoYXQgeW91IHByb3ZpZGUgYW4gYW5hbHlzaXMgYnkgSUVURiA5MyBvbiB3aGV0aGVy IE5FVENPTkYNCiBvciBSRVNUQ09ORiBjYW4gbWVldCB0aGVzZSByZXF1aXJlbWVudHMuJm5ic3A7 Jm5ic3A7IFdlIGV4cGVjdCB0aGF0IHRoZXNlIHJlcXVpcmVtZW50cyBtYXkgcmVxdWlyZSBjaGFu Z2VzIHRvIHRoZSBlaXRoZXIgTkVUQ09ORiBvciBSRVNUQ09ORi4mbmJzcDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIEkyUlMgYXJjaGl0 ZWN0dXJlIGRvY3VtZW50ICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS41cHQ7Y29sb3I6IzNEMjJCMztiYWNrZ3JvdW5kOndoaXRlO3RleHQtZGVjb3JhdGlvbjpub25l Ij5kcmFmdC1pZXRmLWkycnMtYXJjaGl0ZWN0dXJlLTA5PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+KSZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5wcm92aWRlcw0KIGEgaGlnaC1sZXZlbCBvdmVydmll dyBvZiB0aGUgSTJSUyAmbmJzcDtwcm90b2NvbC4mbmJzcDsgVGhlIEkyUlMgaGFzIGNvbXBpbGVk IHRoZSBmb2xsb3dpbmcgZG9jdW1lbnRzIHRvIHByb3ZpZGUgdGhlIGFkZGl0aW9uYWwgZGV0YWls cyBvbiB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgcHJvdG9jb2xzLjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjEpPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1pMnJzLWVwaGVt ZXJhbC1zdGF0ZS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7 YmFja2dyb3VuZDojRjlGOUY5O3RleHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMt ZXBoZW1lcmFsLXN0YXRlLTAwPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDojRjlGOUY5Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4yKTwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wdWItc3ViLXJlcXVpcmVtZW50cy8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuNXB0O2NvbG9yOiMzRDIyQjM7YmFja2dyb3VuZDojRjlGOUY5O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5kcmFmdC1pZXRmLWkycnMtcHViLXN1Yi1yZXF1aXJlbWVudHMt MDI8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOiNGOUY5 RjkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRl bnQ6LS4yNWluIj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjMpPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Nv bG9yOiMzRDIyQjM7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQt aWV0Zi1pMnJzLXRyYWNlYWJpbGl0eS0wMzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJh bC1zdGF0ZS0wMCBjb250YWlucyB0aGUgcmVzdWx0cyBvZiB0aGUgZGlzY3Vzc2lvbiBmcm9tIHRo ZSA2LzEwIGludGVyaW0gYW5kIHRoZSB0b3AgMTAgcmVxdWlyZW1lbnRzIGZvciBJMlJTLiZuYnNw OyBJbiBhZGRpdGlvbiwNCiB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZS0wMCBj b250YWlucyBhbiBzZXQgb2YgZGV0YWlsZWQgcmVxdWlyZW1lbnRzIG9uIGhvdyB0aGUgSTJSUyBX RyBzZWVzIHRoZSBJMlJTIHByb3RvY29sIG9wZXJhdGluZy4mbmJzcDsgVGhlc2UgZGV0YWlsZWQg cmVxdWlyZW1lbnRzIGFyZSB0byBiZSBzZWVuIGFzIHN1Z2dlc3Rpb25zIG9uIHdoYXQgdHlwZSBv ZiBzb2x1dGlvbiB0aGUgSTJSUyBXRyB3b3VsZCBsaWtlIHRvIHNlZSwgYnV0IEkyUlMNCiBXRyBp cyBhc2tpbmcgdGhlIE5FVENPTkYgV0cgdG8gcHJvdmlkZSBpdHMgYmVzdCBkZXNpZ25lZCBwcm90 b2NvbC4mbmJzcDsgUGxlYXNlIG5vdGUgYXMgcGFydCBvZiB0aGVzZSBkZXRhaWxlZCByZXF1aXJl bWVudCB0aGUgZHJhZnQtaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZXMtMDAgY29udGFpbnMgdGhl IGlkZWEgb2YgdXNpbmcgbWV0YWRhdGEgdG8gcmVjb3JkIHNlY29uZGFyeSBpZGVudGl0eS4gJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+VGhlIEkyUlMgcHJvdG9jb2wgaXMgZHJpdmVuIGJ5IGRhdGEtbW9kZWxz LiZuYnNwOyBUaGUgYXBwcm92ZWQgZGF0YSBtb2RlbHMgZm9yIHByb3RvY29sIGluZGVwZW5kZW50 IHNlcnZpY2VzIGFyZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtaTJycy1yaWItZGF0YS1tb2RlbC8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2Nv bG9yOiMzRDIyQjM7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWRlY29yYXRpb246bm9uZSI+ZHJhZnQt aWV0Zi1pMnJzLXJpYi1kYXRhLW1vZGVsLTAwPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5GaWx0ZXItQmFzZWQNCiBSSUJTOiZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy MjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+ZHJhZnQta2luaS1pMnJzLWZiLXJpYi1kYXRhLW1vZGVs LjAwIChyZWxlYXNlZCBsYXRlciB0aGlzIHdlZWspPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndo aXRlIj5Ub3BvbG9neQ0KIG1vZGVsIHdoaWNoIGlzIGEgY29tcG9zaXRlIG9mOjwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7 YmFja2dyb3VuZDp3aGl0ZSI+R2VuZXJpYw0KIHRvcG9sb2d5IG1vZGVsOiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8vIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91bmQ6d2hp dGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLW5ldHdvcmstdG9w by0wMTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hp dGUiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi0uMjVpbiI+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pm88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+TDMNCiB0b3BvbG9neSBtb2Rl bDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS41cHQ7Y29sb3I6IzNEMjJCMztiYWNrZ3JvdW5kOiNGOUY5Rjk7dGV4dC1kZWNvcmF0aW9u Om5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLWwzLXRvcG9sb2d5LTAwPC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDojRjlGOUY5Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPkwyDQogdG9wb2xvZ3kgbW9kZWw6Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5ldHdvcmstdG9wb2xv Z3kvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtjb2xvcjojM0QyMkIzO2JhY2tncm91 bmQ6d2hpdGU7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRyYWZ0LWlldGYtaTJycy15YW5nLWwyLW5l dHdvcmstdG9wb2xvZ3ktMDA8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjti YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxLjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dyb3Vu ZDp3aGl0ZSI+TDENCiBUb3BvbG9neSBtb2RlbDo8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0LXpoYW5nLWky cnMtbDEtdG9wby15YW5nLW1vZGVsLTAxICgtMDINCiByZWxlYXNlZCBsYXRlciB0aGlzIHdlZWsp LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50 Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+ Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5TZXJ2aWNl DQogdG9wb2xvZ3kgbW9kZWw6PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFmdC1oYXJlcy1pMnJzLXNlcnZpY2Ut dG9wby15YW5nLW1vZGVsLTAwDQogKHJlbGVhc2VkIG9uIFdlZG5lc2RheSk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BdCB0aGlz IHRpbWUsIG5vbmUgb2YgdGhlIFRvcG9sb2d5IG1vZGVscyB1dGlsaXplIFRyYWZmaWMgZW5naW5l ZXJpbmcuJm5ic3A7IEl0IGlzIGFudGljaXBhdGVkIHRoYXQgdGhlc2UgbW9kZWxzIHdpbGwgc3Vw cG9ydCB0cmFmZmljIGVuZ2luZWVyaW5nLiAmbmJzcDtFc3RpbWF0ZWQNCiByYXRlcyBvZiB0cmFu c2ZlciBhbmQgdGltaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlc2UgbW9kdWxlcyBhcmUgYXQ6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL3dnL2kycnMvdHJhYy93aWtpIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9pMnJzL3RyYWMvd2lr aTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPi0NCiB1bmRlciB0aGUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzIHRhYmxlLjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBob3BlIHRoYXQg TkVUQ09ORiBXRyBjYW4gcHJvdmlkZSBzb21lIGluaXRpYWwgZmVlZGJhY2sgb24gdGhlc2UgcmVx dWlyZW1lbnRzIGJ5IElFVEYgOTMgYXQgdGhlIFR1ZXNkYXkgSTJSUyBzZXNzaW9uLiZuYnNwOyZu YnNwOyBJMlJTIHdpbGwgdXNlIHRoZSA2LzI0DQogaW50ZXJpbSBhdCAxMDowMC0xMTozMGFtIEVU ICZuYnNwO3RvIHByb3ZpZGUgYSB0aW1lIGZvciBhbnkgcGFydGljaXBhdGUgaW4gdGhlIEkyUlMs IG5ldGNvbmYsIG9yIG5ldG1vZCBncm91cCB0byBhc2sgYWRkaXRpb25hbCBxdWVzdGlvbnMgb24g dGhlc2UgcmVxdWlyZW1lbnRzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5TdWUgSGFyZXM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SW50ZXJpbSB0aW1lOiAxMDowMC0xMTozMGFtIEVUPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGF0 ZSA2LzI0LzIwMTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5XZWJleDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bTQyNjBiZWU3YmU2MWNiMTdiMDAwOGEzYzUyMDY5ZDBmIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tNDI2MGJlZTdiZTYx Y2IxN2IwMDA4YTNjNTIwNjlkMGY8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmFnZW5kYTo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+MTA6MDAg4oCTIDEwOjA1 IOKAkyBCYXNoIEFnZW5kYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjEwOjA1IOKAkyAxMDoyMC0gLSZuYnNwOyByZXZpZXcgb2YgcmVxdWly ZW1lbnRzIGZyb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW47dGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFm dC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1pMnJzLXB1Yi1zdWItcmVxdWlyZW1lbnRzLTAyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5k ZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZHJhZnQtaWV0Zi1pMnJzLXRy YWNlYWJpbGl0eS0wMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbjt0ZXh0LWluZGVudDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRp bWluZyByZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluO3RleHQtaW5kZW50Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ MTA6MjAg4oCTIDEwOjMwJm5ic3A7Jm5ic3A7Jm5ic3A7IFJldmlldyBvZiByZXF1aXJlbWVudHMg Zm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5hbmQgdHJhbnNhY3Rpb24gaW4gJm5ic3A7ZHJhZnQtaGFyZXMtYXV0aC10cmFu cy0wMSByZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+MTA6MzAtIDExOjMwICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO09wZW4g ZGlzY3Vzc2lvbiBmb3IgSTJSUyBSZXF1aXJlbWVudHM8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UHJvY2VlZGluZ3MgYW5kIHNsaWRlcyBjYW4g YmUgZm91bmQgYXQ6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8yMDE1 LzA2LzI0L2kycnMvcHJvY2VlZGluZ3MuaHRtbCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTUvMDYvMjQvaTJycy9w cm9jZWVkaW5ncy5odG1sPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWUgSGFyZXM8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJy Pg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6cHVycGxlIj5uZXRtb2RAaWV0Zi5vcmc8L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5NYWhlc2ggSmV0aGFuYW5kYW5pPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0 aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_EF64FF31F4C4384DBCE5D513A791C2B121B00EE1xmbalnx11ciscoc_--