Hi Joe, I'm sorry I missed this set of comments earlier. Responses in-line.
Alia On Fri, Jun 6, 2014 at 5:33 PM, Joe Marcus Clarke <[email protected]> wrote: > 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. > [Alia] Many of the aspects of the RIB information model aren't generally exposed via configuration but are safe to expose. The full sentence is: "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." I like the first part because it helps scope what I2RS can do; the second part is more specific. I really don't think an example is useful here; it'd derail the document. > === > > 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. > [Alia] I've added in " The details of how applications communicate with a remote client is out of scope for I2RS." to the second paragraph in 1.2. > > === > > 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. > [Alia] Agreed it was awkwardly worded. Changed to "Based on the information and the policy oriented interactions, the I2RS client may also interact with I2RS agents to modify the state of their associated routing systems 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. > [Alia] Sure - changed to "may not" from "will not". The point of the paragraph is to point out different security requirements on the transport may apply - not to target what they are or which information may be targeted. > === > > 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. > [Alia] Sure - added to the end of the paragraph "The transports chosen should be operator and implementor friendly to ease adoption." [Alia] I also updated this paragraph to refer to the WG's decision to base I2RS on NETCONF and RESTCONF. > === > > 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). > [Alia] Yes, a supervisory application could work. This section changed in -03, but please wait until I publish -04 and then comment on that. Thanks for the review! I really do appreciate your careful and thoughtful work. Alia > > Thanks. > > Joe > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
