Benoit and Joel:
I have altered the abstract in version 14 as indicated in my earlier email, and addressed all of Benoit's comments. Please review the diff between: draft-ietf-i2rs-architecture-13 and draft-ietf-i2rs-architecture-14. Let me know if you have any additional comments. Sue From: Benoit Claise [mailto:[email protected]] Sent: Thursday, March 24, 2016 9:03 AM To: Joel M. Halpern; Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] Benoit Claise's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) Joel, Thanks, that's helpful. 1. Let's look at the charter The I2RS working group works to develop a high-level architecture that describes the basic building-blocks necessary to enable the specific use cases, and that will lead to an understanding of the abstract informational models and requirements for encodings and protocols for the I2RS interfaces. 2. Let's review the draft abstract This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system. It describes the basic architecture, the components, and their interfaces with particular focus on those to be standardized as part of the Interface to Routing System (I2RS). Reading 1., I understand your point of view. However, I read 2. as this draft is about "we are using pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem." I reviewed the draft content looking for 1., and could not find it. Do you understand my confusion? Regards, Benoit Benoit, you seem to be looking for a level of specificity in the architecture that the working group never intended. The charter calls for a high level architecture. I believe your comment calls out an interesting gap in the charter, as there is no document called out which actually says "we are using pieces X, Y, and Z, in ways A, B, and C, to solve the I2RS problem." We could have tried to use the architecture document for that, but the intention was to use the architecture document to guide the selection of protocol and mechanisms. Yours, Joel On 3/24/16 6:53 AM, Benoit Claise wrote: Sue, >Two of the existing protocols which the > which may be re-used are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]. editorial "may be reused". / I will check with RFC editor (some people say reused /re-used). What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. On my side this architecture is flexible (NETCONF or RESTCONF), on the other side unclear (YANG 1.0 or YANG1.1), and in some cases, a complete specification (for example the notification) Sue: NETCONF and RESTCONF will be supported as part of the I2RS protocols. The architecture does out rule out other data transfer protocols, but says the WG will design I2RS as a higher level protocol that combines other protocols (NETCONF/RESTCONF + x). This is what I could not understand with the draft sentence: "Two of the existing protocols which the which may _be re-used_ are NETCONF [RFC6241] and RESTCONF > [I-D.ietf-netconf-restconf]." Sure many things could be reused. I'm expecting from an architecture document to explain which pieces are used and how they are used. The I2RS requirements documents and protocol strawman will state is if any other protocols will be used for a particular version of I2RS with a particular scope for data modules. Probably, my issue stems from the fact that I2RS produces an architecture before fixing requirements. I am sorry if this is not what you excepted, but it was my direction from my AD on how to approach this work. At this time, we are closing in on the last of the requirements documents - the requirements for other data flows. draft-hares-i2rs-dataflow-req-02 that gives the potential scope of data flows, but IMO the first version of the I2RS is likely to stay with just NETCONF/RESTCONF with ephemeral state, push pub/sub support, syslog module library, and some yang changes. To handle I2RS Agent failure, the I2RS Agent must use two different notifications. NOTIFICATION_I2RS_AGENT_STARTING: This notification signals to the I2RS Client(s) that the associated I2RS Agent has started. It includes an agent-boot-count that indicates how many times the I2RS Agent has restarted since the associated routing element restarted. The agent-boot-count allows an I2RS Client to determine if the I2RS Agent has restarted. (Note: This notification will be only transmitted to I2RS clients which are know in some way after a reboot.) No comment on "the I2RS Agent _must _use two different notifications"? This one is clear spec. - editorial: Optionally, a routing element may permit a priority to be to be.... For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. Again, I read that sentence multiple times, and could not understand it Sue: Reasonable editorial comment. This was added to address another comment, But it looks like we broken something. Text change below. Old/ Optionally, a routing element may permit a priority to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the I2RS ephemeral state always wins for a data model, if there is an I2RS ephemeral state value it is installed instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / New: Optionally, a routing element may permit a priority to be to be to be to be configured on the device for the Local Configuration mechanism interaction with the I2RS model. The policy mechanism would compare the I2RS client's priority with that priority assigned to the Local Configuration in order to determine whether Local Configuration or I2RS wins. For the case when the configured priority of the I2RS ephemeral Is higher than the Local Configuration's policy, the The I2RS ephemeral state value it is installed remove "it" instead of the local configuration state. The local configuration information is stored so that if/when I2RS client removes I2RS ephemeral state the local configuration state can be restored. / figure 2. "The initial services included in the I2RS architecture are as follows." Are these really the initial services for I2RS. I2RS is really dealing with all these: interfaces, policy, QoS, ... Maybe I should review the I2RS charter? Sue: Our charter is wide, but only ephemeral layer deep. Due to the excellent people in the NETCONF/NETMOD, routing area (rtgwg) and TEAS - we are focusing on allowing ephemeral to be added to any data model. I2RS WG is focused first on the I2RS protocol and protocol independent modules. After this, I2RS purpose is to simply support other WGs in creating data modules with ephemeral state. The I2RS protocol may need to use several underlying transports (TCP, SCTP (stream control transport protocol), DCCP (Datagram Congestion Control Protocol)), with suitable authentication and integrity protection mechanisms Do you really want to have define transports? Sue: We indicate that I2RS will use these protocols. Each protocol we mention has to be then validated with requirements (see protocol security requirement and security environment requirements). So I2RS will publish a second architecture doc when the requirements are validated and the protocols (transport, config, notifications) are finally selected? Regards, Benoit _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs .
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
