Benoit:
I've released a version 14 which hopefully answers all your questions. Immediately below, is my copy of the resolutions I made. After I made these resolutions, I reviewed the resulting text for clarity, and made some final tweaks. Let me know if version 14 is closer to what you want to see. I'm working on making sure all requirements documents are revised so that you can view those as well. Sue ---------------------------------------------------------------------- Benoit Claise COMMENT: ---------------------------------------------------------------------- A couple of points, not all of them are minor (I've been wondering: COMMENT or DISCUSS. Let's go for a COMMENT) - "Second is the access to structured information and state that is frequently not directly configurable". I have a hard time reconciling the NETMOD state definition, for example from https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-04 It would be good if the terminology were aligned. [Since this document and the op-state discussion is still fluid, I am concerned about utilizing these terms in this document going toward RFC. I have encountered lots of problems utilizing these at IETF 95. I agree in the need to align to the NETMOD op-state, but I do not think this statement is the appropriate place. This I2RS architecture assumes a data-model driven protocol where the data-models are defined in Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis]), and associated Yang based model drafts ([RFC6991], [RFC7223], [RFC7224], [RFC7277], [RFC7317]). " RFC 6020 is YANG 1.0, not YANG 1.1 I2RS is YANG 1.0 or YANG 1.1? I hope YANG 1.1 btw, this "YANG" not "Yang" Yang 1.1, I've removed YANG 1.0. - Are the two sentences redundant? As can be seen in Figure 1, an I2RS client can communicate with multiple I2RS agents. An I2RS client may connect to one or more I2RS agents based upon its needs. Changed to: As can be seen in Figure 1, the I2RS client can communicate with multiple I2RS agents. There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for transferring data-models whose content is not explicitly implemented or understood. Reading that second sentence multiple times, I still fail to understand. Model-driven on one side, but you want data-models whose content is not explicitly implemented or understood. Really confused. Wow.. You are right. New / There are several key benefits for I2RS in using model-driven architecture and protocol(s). First, it allows for data-model focused processing of management data that provides modular implication in I2RS Clients and I2RS Agents. The I2RS client only needs to implement the models the I2RS client is able to access. The I2RS Agent only needs to implement the data models the I2RS Agent supports. / Two of the existing protocols which the which may be re-used are NETCONF [RFC6241] and RESTCONF [I-D.ietf-netconf-restconf]. "may be reused". What does it mean? I was hoping that an architecture documents would at least tell me which protocols are used. New/ As an architecture, I2RS has been designed to reuse existing protocols that carry network management information. Two of the existing protocols which the which are being reused are NETCONF [RFC6241] and RESTCONF [draft-ietf-netconf-restconf]. / 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) Comment: Hopefully, I have specified NETCONF/RESTCONF and YANG 1.1 carefully in -14.txt 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.) Again, I read that sentence multiple times, and could not understand it - editorial changed to: (Note: This notification will on be sent by the I2RS Agent to I2RS Clients which are known by the I2RS agent after a reboot. How the I2RS Agent retains the knowledge of these I2RS clients is out of scope of this architecture. ) - 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? Comment to Benoit: These are features of the routing system as the charter says. 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? Comment to Benoit: For some streams, we will need to define both mandatory and optional transports. For the first revision, we will only define the transports that are acceptable to NETCONF and RESTCONF. Text added: The transports that the I2RS protocol can run over will be specified in the I2RS protocol, and in the I2RS protocol each transport protocol as either mandatory to implement or optional to implement. Fred Baker's review done in earlier protocol. From: Benoit Claise [mailto:[email protected]] Sent: Thursday, March 24, 2016 6:54 AM To: 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) 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
