Alvaro:
Resolution works for me. I've uploaded a version -15 removing the safe definition and using your text instead. Sue From: Alvaro Retana (aretana) [mailto:[email protected]] Sent: Friday, April 22, 2016 9:09 AM To: Susan Hares; 'The IESG' Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT) On 4/22/16, 12:18 AM, "Susan Hares" <[email protected]> wrote: Sue: Hi! I have released a -14 of the architecture document. The only one I did not really address is #j. Comments on changes are in red. . Let me know if this is a major issue. No, is not a major issue. I do have one comment below. Thanks! Alvaro. . ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have some comments; I would consider the first two as significant/major, while the others are minor comments and nits that came up as I was reading (not always linearly). A. There are a couple of places where operations are characterized as "safe" (1.1 and 6.4.1 - see below), but no explanation as to what "safe" means. It seems to me that these mentions of "safe" go beyond authentication and even authorization to perform a specific operation, to the content of the operation itself. I would like to see some discussion about how to achieve it, and/or (at least) what the impact may be. - 1.1: "I2RS will only permit modification of state that would be safe, conceptually, to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned." - 6.4.1: "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 or per-context. This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state. Conceptually, this can be handled by having the I2RS Agent communicate with a RIB Manager as a separate routing source." Resolution: see addition of Safe modification of routing state via I2RS Sorry, but the definition doesn't work for me. This is what you added: safe modification of routing state via I2RS: are I2RS ephemeral configuration changes which which modify local configuration rather than the direct modification of protocol-internal state. Direct modifications to protocol-internal state may have unsafe consequences. The definition above (first sentence) basically describes any modification (of local configuration) -- I still fail to understand the "safe" characterization. Back to the 1.1 text (see above). Given the new definition, I would propose to change the text to: NEW> I2RS will only permit modification of state that would be possible to modify via local configuration; no direct manipulation of protocol-internal dynamically determined data is envisioned. Similar for 6.4.1: OLD> This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources, so as to safely change the system state. NEW> This functionality, exposed via an I2RS Service, must interact smoothly with the same mechanisms that the routing element already uses to handle RIB input from multiple sources.. In other words, take "safe" out because it leads to confusion.
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
