On 6/5/14, 4:29 PM, Jeffrey Haas wrote:
http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
Have you read the architecture draft?
Do you think it is ready to be published as a RFC?
(Ditto.)
Here is a list of my previous comments that didn't get addressed in the
text or on the list.
In section 1.1, the first paragraph states:
...Second is the access to structured information and state that is
frequently not directly configurable...
Then in paragraph four:
...I2RS will only permit modification of state that would be safe,
conceptually, to modify via local configuration...
While you do use the word "conceptually," it's hard to conceive of
something that is at the same time safe to modify via the configuration
but is not exposed via the configuration. That is, how would one know
what is safe? This might benefit from an early example to clarify what
is meant and perhaps it is good enough to drop the bit about modifiable
via local configuration and just say that modification of protocol
internal state is out of scope.
===
In section 1.2, the new text helps to show how App, Client, and Agent
fit together, but I wonder if this same new text wouldn't benefit from a
statement that App to Client communication is out of scope. That is,
you state that the Client and Agent communicate via an asynchronous
protocol, but nothing is said about, for example, how apps C, D, E
communicate with Client P. You do mention this further down in the doc,
so it's a minor thing, but perhaps worth a sentence here.
===
Section 2, in the I2RS Client paragraph, I can't get my head around this
text:
Based on the information and the policy oriented interactions, the
I2RS client may also interact with I2RS agents to modify the state
of the routing system the client interacts with to achieve
operational goals.
The first part makes sense, but then it starts to sound muddled, at
least to me. Maybe you want to say:
Based on the information and the policy oriented interactions, the
I2RS client may also interact with I2RS agents to modify the state
of the routing system in order to achieve operational goals.
===
Section 4. While streaming OSPF prefix announcements MAY NOT require
confidentiality, some users may want it. Paragraph 4 starts out, Other
communications via I2RS will not... I think this should say may not
just to make it clear that this can be optional based on specific
environmental requirements.
===
Section 7.1. This is mainly an editorial, but in looking back at things
like NETCONF over BEEP, one goal might be to make sure the transport
chosen is both operator and implementor friendly in terms of ease of
adoption.
===
Section 7.5. Would a supervisory application work in this case? I
suppose it could if it shared the same ID, but that wouldn't work for
multiple applications. Likely a better approach would be to allow the
Client to accept some meta-instructions at the beginning of a session as
to what to do if the app goes away (as you state in paragraph 4).
Thanks.
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
