Joel: Follow-up on this stream after IETF. In many ways, the protocol strawman is the document which proposes using pieces X, Y, and Z in ways A, B, and C to solve the I2RS problem. Perhaps, the protocol strawman should have a section that summarizes the requirements and solutions.
Sue -----Original Message----- From: Joel M. Halpern [mailto:[email protected]] Sent: Thursday, March 24, 2016 8:17 AM To: Benoit Claise; 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) 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
