[i2rs] Alvaro Retana's Abstain on draft-ietf-i2rs-problem-statement-10: (with COMMENT)

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

Alvaro Retana has entered the following ballot position for
draft-ietf-i2rs-problem-statement-10: Abstain

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-problem-statement/



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

I had a hard time deciding on the value of this document as a standalone
RFC.  I came to the conclusion that the valuable pieces (specifically
Section 5) would serve a better purpose as part of the i2rs Architecture
document (draft-ietf-i2rs-architecture).  If this document is to be
published I won't stand in the way, I'm ABSTAINing instead.  I put more
specific comments below.


The document contains a mixture of what I think are broad and vague
requirements ("needs" and "key aspects") for an I2RS Protocol, along with
a general picture of what an i2rs can/should be (which seems to step into
the WG's charter in some places).

Maybe I can't see it, but the document expresses "needs" without explicit
justification (e.g. "the need…real-time security threat
responsiveness…more dynamically manage and program routing
systems…support rapid control and analytics…automate even the simplest
operations…support real-time, asynchronous interactions using efficient
data models and encodings that are based on and extend those previously
defined…learn topology, network analytics, and existing state from the
network as well as to create or modify routing information and network
paths…feedback loop…data-model driven interface to the routing
system…precisely control routing and signaling state based upon policy or
external measures…dynamically configure policies and parameter values for
the various routing and signaling protocols based upon application-level
policy decisions…detailed topological state that provides more
information than the current functional status…") or details of what is
expected, or a clear comparison to the current state (the Appendix is not
referenced in the main text, nor is it comprehensive).

It is unclear to me whether all those "needs" are requirements, or how
they are translated into them.  The last "need" mentioned above does
present the current state of the art (BGP-LS) and it provides examples of
missing information, but without indicating if anything is required. 
Other requirement-like statements not associated with "needs" are equally
unclear: "…providing the ability for an application to dynamically
request that measurements be taken and data delivered is important."  I
think everyone can agree that it is important, but is it a necessary
characteristic of the I2RS protocol (or maybe something else?)?

Section 5 seems to spell out requirements for an I2RS Protocol, but the
aspects listed/discussed I think fall short of providing strict
guidance.


The term "I2RS" is sometimes used without a modifier (client, agent,
protocol, etc.), not making it clear what the term is referring to.  Some
of the missing modifiers seem obvious, but others seem to be potentially
referring to the WG itself and trying to define what the scope or charter
should be — that is obviously better served in the charter itself.  For
example:

* "…the I2RS scope…"  Is that within the scope of the I2RS protocol, the
WG, ??   One piece of text mentions "…outside the I2RS scope for
standardization."   That makes me think that the answer is the i2rs WG,
but then it makes me wonder why we need this document to clarify the WG's
charter.

Then there are also explicit references to what the WG should do; again,
better served by the charter itself.

* "The I2RS Working Group must select the suitable protocol(s) to carry
messages between the I2RS Clients and I2RS Agent."  Even though it may be
implicit, there's no explicit action in the i2rs WG charter to select a
protocol, and of course no mention of clients/agents (as those are
described in the Architecture).

* "The I2RS Working Group must identify or define a set of meaningful
data-models for information in the routing system and in a topology
database."  I think this is already part of the charter.

* "One set of data-models that I2RS should focus on is for interacting
with the RIB layer…"   The charter mentions something similar.

* "At a minimum, within the I2RS scope…"  The scope of the WG, or are you
talking about something else that hasn't been defined?

* "I2RS will define needed information and data models…"


Finally, it also worries me that other documents put too much stock in
this one, relying on it to provide guidance in places where it falls
short.  For example:  draft-ietf-i2rs-architecture says in Section 3.
(Key Architectural Properties) that "some architecture properties such as
performance and scaling are not described below because they are
discussed in [I-D.ietf-i2rs-problem-statement]".  

* The word "performance" doesn't exist in
draft-ietf-i2rs-problem-statement, but there are aspects (in Section 5)
that resemble it: "should be able to handle a considerable number of
operations per second", "within a sub-second time-scale, it should be
possible to complete simple operations"…  I wouldn't call those Key
Architectural Properties.

* There is some sparse treatment of scaling: "For example, for scaling,
some exported data or events may be better sent directly from the
forwarding plane…", or "Scalable, Filterable Information Access:  To
extract information in a scalable fashion that is more easily used by
applications, the ability to specify filtering constructs…is very
valuable."  Again, not what I would call Key Architectural Properties.