On 4/22/16, 12:18 AM, "Susan Hares" <[email protected]<mailto:[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
