[i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

["Alvaro Retana" <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-i2rs-architecture-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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