Problem Statement for the Interface to the Routing System
RFC 7920

Note: This ballot was opened for revision 09 and is now closed.

Deborah Brungard Yes

(Jari Arkko) No Objection

(Ben Campbell) No Objection

Comment (2016-02-17 for -10)
No email
send info
I am sympathetic to the argument that this doesn't need to be published as an RFC. But I'm not going to block or abstain about that this late in the process.

I share Alvaro's other concern that there are a lot of assertions of "need" that do not seem to be supported by the text. They tend towards passive voice (e.g. "it is desirable", "is needed", "there is a need" ), which obscures who actually has these needs. I'd like to see more explanation of the "who" and the "why" for these needs.

The security considerations seem to say "security is important", and that authentication an authorization are required. I'd like to see more actual threat analysis.

(Spencer Dawkins) No Objection

(Stephen Farrell) No Objection

Comment (2016-02-15 for -10)
No email
send info
- section 1: "different vendors' routing systems" seems like
it's assuming that there is only one vendor involved in each
box. I don't think that's consistent with what's behind i2rs so
re-wording there might be better. 

- figure 1: I'm sure you'll fix the page break

- confidentiality for i2rs protocol: if I can watch i2rs traffic
I can probably infer what policies are being used and use that
to better attack networks. I think you could easily strengthen
the wording there and that'd be better.  If one has a way to
securely authenticate endpoints, then you can almost as easily
ensure confidentiality. 

- general question: We know that govts target network admins.
What are we doing to make i2rs traffic less easily used as a
selector? (e.g. make sure it could work over Tor?)

- the secdir review [1] called out some nits you may want to
consider (if you did already thanks, I didn't check in detail)


(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2016-02-17 for -10)
No email
send info
I have sympathy with Álvaro's position, and thought about abstaining as well, but in the end I did find that the discussion in Sections 1 thru 4 has archival value, as guidance to people who are eventually reading the set of I2RS documents.  Sure, this could all be part of the architecture document, but if the working group's decision is to separate it out, I'm OK with that.

(Martin Stiemerling) No Objection

(Benoît Claise) Abstain

Comment (2016-02-18 for -10)
No email
send info
I basically agree with Alvaro's points. On top of that, a problem statement in 2016 when the charter was done in 2012 ... hmm ... 
If (parts of) the content needs be published, it should be in the arch document. Figure 1 is architecture anyway, right?
And ... a problem statement with a normative reference to an architecture. Really?

Alissa Cooper Abstain

Comment (2016-02-17 for -10)
No email
send info
Agree with Brian.

(Brian Haberman) Abstain

Comment (2016-02-17 for -10)
No email
send info
My position on these types of documents should be pretty clear at this point. The parts that do have archival value should be published as a part of a protocol specification or architecture document.

(Terry Manderson) Abstain

Comment (2016-02-17 for -10)
No email
send info
I'm not going to stand in the way of this document being published.

I am taking an abstain position as it is my preference that the informative rationale which guides the i2rs solution space should be in the Architecture document and what remains can exist as a living WG document for participants to reflect upon - that in itself need not be published as an RFC.

Alvaro Retana Abstain

Comment (2016-02-15 for -10)
No email
send info
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.

(Alia Atlas) Recuse