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
