An Architecture for the Interface to the Routing System
draft-ietf-i2rs-architecture-15

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."

B. Section 3. (Key Architectural Properties) says that "some architecture properties such as performance and scaling are not described below because they are discussed in [I-D.ietf-i2rs-problem-statement]".  However, as I mentioned in my review of I-D.ietf-i2rs-problem-statement [1], that document has a very, very sparse treatment of performance and scalability to even attempt to call it a "Key Architectural Property".

C. Section 1.1. (Drivers for the I2RS Architecture) says: "I2RS is described as an asynchronous programmatic interface, the key properties of which are described in Section 5 of [I-D.ietf-i2rs-problem-statement]."  Why isn't I-D.ietf-i2rs-problem-statement a Normative Reference?   It is considered to define the properties of the I2RS which are used in building the architecture.

D. Section 4 (Security Considerations) mentions the "I2RS security requirements", but there is no reference to draft-ietf-i2rs-protocol-security-requirements.

E. s/I2RSS/I2RS

F. There's a orphan "In addition, the" in 1.2.

G. Systems and sub-systems.  The text mentions "routing system", "Internet routing system" and "routing subsystem" many times (obviously!), but there is no description of what these terms mean — I'm sure many/most of the readers have an opinion of what these are, but I think it might be good to add something to the terminology section specially because statements like this are made: "state on a routing element beyond what is contained in the routing subsystem"; that way there is no questions as to what is in the routing system, or sub-system and what is not (at least for this document).

H. 3.2. (Extensibility) talks about the initial scope of I2RS (without references).  To extend the usability of this document, I would suggest that the statements of this section be made independent of the fact that the initial scope may be narrow.  IOW, I think you may want the protocol/data model to be extensible regardless of the size of the initial scope (even if boiling the ocean to start with, there will always be opportunities for extensions later).

I. s/an definition/a definition

J. If out of scope, I don't really see the value of 5.1. (Example Network Application: Topology Manager).  However, Section 5 does say that these types of "models are, at least initially, out of scope for I2RS" -- as I mentioned above, if this architecture is meant for the long run (not just the initial scope of the i2rs WG), then the 3rd architecture is valuable to illustrate.  IOW, the WG charter can control the scope, the architecture should be thought out for the long term.

K. s/to be to be/to be

L. Many protocols (routing-related and otherwise) are mentioned without references.

M. I don't think you need both of these references: "Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])".


[1] https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/ballot/#alvaro-retana

I'm happy to leave this to the INT and RTG ADs.  I have no objection after a quick run-through.

Russ Housley's Gen-ART review raised the following question and editorial comments. I believe it would be useful for the authors to think about the question at least, but I have not seen a response yet:

---

Minor Concerns:

Section 4.2 talks about authorization.  I would expect policy to
dictate that some writes come from a specific source, but it is
unclear to me whether I2RS can require that a particular write
request arrive on a particular channel.  Is this desirable?  If so,
please expand the discussion of authorization to cover this point.


Nits:

Sometimes you say "i2rs architecture", but it should say "I2RS
architecture" to be consistent throughout the document.

Sometimes you say "I2RS Agent" and other times you say "I2RS agent".
Please pick one and use it consistently.

Sometimes you say "I2RS Client" and other times you say "I2RS client".
Please pick one and use it consistently.

Section 3: s/ may may vary based / may vary based /

Section 6.3: s/ the yang data model / the YANG data model /

Section 6.4.2: some bullets have periods, but others do not.

Section 7.1: s/ Yang / YANG / (more than one place)

fred and benoit did quite a good job on this one.

In this text:

7.1.  One Control and Data Exchange Protocol

   The I2RS
   protocol may need to use several underlying transports (TCP, SCTP
   (stream control transport protocol), DCCP (Datagram Congestion
   Control Protocol)), with suitable authentication and integrity
   protection mechanisms.  These different transports can support
   different types of communication (e.g. control, reading,
   notifications, and information collection) and different sets of
   data.  Whatever transport is used for the data exchange, it must also
   support suitable congestion control mechanisms.  The transports
   chosen should be operator and implementor friendly to ease adoption.
   
I echo Benoit's question about defining multiple underlying transports. I suspect you'll need to pick one mandatory-to-implement transport protocol, and when everyone has to support that one, I'd be surprised to see implementations that support more than one transport protocol unless the mandatory-to-implement transport protocol is seriously broken in some scenarios.

- If i2rs were used to control home networks, then that would
raise more privacy issues, e.g. the agent's IP address can be
privacy sensitive. Would it be useful to rule that out of
scope? E.g. to say that i2rs SHOULD NOT be used where the
agent/router in question is specific to one person or home?

- section 2: security role, hmm..... Do netconf/restconf have
the concept of mapping identifiers to roles? If not, that
might be tricky to graft on. Not sure.

- section 4: "Mutual authentication between the I2RS Client
and I2RS Agent is required. " yay! thanks:-) Even better if
you did s/Mutual/Strong mutual/ to prevent someone saying that
TCP-MD5 is good enough.

- section 4: "The primary communication channel that is used
for client authentication and then used by the client to write
data requires integrity, confidentiality and replay
protection." yay! again! :-)

- section 4: "Other communications via I2RS may not require
integrity, confidentiality, and replay protection.  For
instance, if an I2RS Client subscribes to an information
stream of prefix announcements from OSPF, those may require
integrity but probably not confidentiality or replay
protection." sorry, boo! :-) 

It's often unsafe to mix and match differently protected sets
of data between the same sets of entities. I think you'd be
better off there saying that the requirements may
*exceptionnally* differ but usually only because of e.g. some
level of broadcast or multicast being part of the story, where
we don't have good usable security solutions today. (This is
not a DISCUSS because I think the protocol work will end up
saying "just use TLS always" as that'll be simpler and better,
so I hope this'll be a non-issue. If you know already that
there's some other plan in place, then please say so we can
chat now and avoid a trickier discussion later.) 

- section 4: I think you're heading here towards use of TLS
and not object level security. Is that right? If so, would it
be useful to say so? (Just so as to correctly set expectations
for later.)

- 7.7: Would it be useful to say that the relevant information
here is only about network state and stastics and not about
connections (e.g. who spoke to whom) or payloads?  That might
save some discussions about RFC2804 later on.

Hi there,

Firstly, I support Alvaro's two significant comments, especially with regards to the outcomes of the I2RS initiated change. My reading of the draft is that the resulting architecture espouses to judge intent, or the very least the outcome of the intent, as safe. How? Apologies if I read more into this than intended, please help clarify.

I only saw one nit that hadn't been noticed in other comments.
Section 3: para, last sentence. "may may"

Thanks