Joe - few comments in response... 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.
:: It seems pretty clear that this calls for intermediating routing data (for instance, through an RR) to ensure that certain adjustments can be met without manipulating protocol internal state directly. That definition may remain insufficient, however, as there are certain cases where operations which do modify protocol internal state could be demonstrably safe... === 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. === :: "Streaming OSPF prefix announcements" is a ... interesting way to look at this. If we were only referring to externals and summaries... maybe. But add the intra-area and TE LSAs into the mix; this is something that few if any operators would want to share publicly. If we didn't try to carry data other than link state changes in OSPF the LSDB really ought to be pretty static over time... It seems to me that integrity of the view of the topology is very important, and notification of link-state changes from a known starting point may be an efficient way to doing that. Anyway ... back to work for me. Thanks y'all. -RH On Wed, Feb 12, 2014 at 11:39 PM, Joe Marcus Clarke <[email protected]>wrote: > On 2/10/14, 3:19 PM, [email protected] wrote: > > In going through the -01/-02 draft, I have a few comments. > > 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 6.2.1. Minor nit: > > OLD text: > > ...that an I2RS Agent has unexpected failed... > > NEW text: > > ...that an I2RS Agent has unexpectedly failed... > > === > > Section 6.2.1. I don't know if this needs to be said in the document or > left to an implementor, but if the I2RS Agent can ensure state is preserved > until the routing element reboots, then a cache of state may need to be > kept by the Agent. If it dies and restarts, then it can read that cache > and restore state. I bring this up because if you think of something like > OSPF as an I2RS Agent, if the OSPF process dies, you wouldn't expect its > routes to stick around. However, when it restarts, it could restore the > last known set of routes back into the routing element. > > In this manner it might be safer if the Agent dies and cannot restart for > whatever reason. That would prevent a potentially bad route from getting > stuck in the routing element until a reboot. > > Just a thought. I think the new text is good in that you account for the > case where an Agent failure will cause ephemeral state to disappear, but > the "should" case is for this state to remain. Clarifying how that could > work might be a nice thing. > > === > > Section 6.4.5.1.3.1 (ASN.1 anyone?). Minor nit: > > OLD text: > > ...The simplest relationship is that one object instances is initialized... > > NEW text: > > ...The simplest relationship is that one object instance is initialized... > > === > > 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). > > Joe > > > >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Interface to the Routing System >> Working Group of the IETF. >> >> Title : An Architecture for the Interface to the >> Routing System >> Authors : Alia Atlas >> Joel Halpern >> Susan Hares >> Dave Ward >> Thomas D. Nadeau >> Filename : draft-ietf-i2rs-architecture-01.txt >> Pages : 29 >> Date : 2014-02-10 >> >> Abstract: >> This document describes an architecture for a standard, programmatic >> interface for state transfer in and out of the Internet's routing >> system. It describes the basic architecture, the components, and >> their interfaces with particular focus on those to be standardized as >> part of I2RS. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-i2rs-architecture-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-architecture-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
