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

["Susan Hares" <[e-mail]>]

Alvaro: 

On your major points, and on "L" - I have a few questions.  On the rest, I will correct in -14.  Please see #H to preview the text, and confirm it works for you.   

Shall I update to -14.txt tonight even if I have not heard from you? 

Sue 

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

The definition of "safe" from a security viewpoint was a sufficient enough discussion that two I2RS requirements documents were created: 
1) defining "safe" protocol  - https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/
2) defining "safe" environment - https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/

The definition of "safe" specifically also depends on the protocol(s) selected to be combined for the I2RS higher level protocol and the "safe" environment.   Do you want these two documents back-fitted to the architecture or are you looking for something different? 

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

Response: I sent you a question about what you wanted for the problem statement.  I am holding the problem statement because you have not responded to the scaling.   We have the following things you can see in other documents:

- The I2RS pub-sub requirements documents look toward the scaling of large data via the publication and subscription mechanisms.   draft-ietf-i2rs-pub-sub-requirements

- Potential ability to allow minimal checking on the upload of the local RIB (in discussion) 
       draft-ietf-i2rs-usecase-reqs-summary
       draft-hares-i2rs-dataflow-req 

These are scaling efforts for the inbound/outbound data flows.   Other reviewers had considered these specifics were not valid in the problem statement, but perhaps we can work through a compromise where we discuss the problem of large data inputs/outputs in a constructive manner.  Can you suggest any text? 
 

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

Sue: Do you really want all the protocols lists in the diagrams to be reference?
If so, I am glad to do it.  This question is also included in the top.


-----Original Message-----
From: Alvaro Retana [mailto:[e-mail]] 
Sent: Tuesday, March 15, 2016 9:01 AM
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

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."
[Sue: Please see above] 

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

[Sue: Please see above] 

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.

[Sue]: We can make it normative.  I will release a version with this change. 

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

[Sue]: We will include both draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-protocol-security-environment-reqs in that list. 

E. s/I2RSS/I2RS

[Sue]: Thank you for this error.  I will change in -14 

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

[Sue]: Thank you.  I will change in -14 

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

Sue:  We will add something in the terminology section in -14. 

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

Sue:  I agree.  

How about this change: 

Old /   The scope of the I2RS work  is being restricted in the interests of
   achieving a deliverable and deployable result.  The I2RS Working
   Group is modeling only a subset of the data of interest.  It is
   clearly desirable for the data models defined in the I2RS to be
   useful in more general settings.  It should be easy to integrate data
   models from the I2RS with other data.  Other work should be able to
   easily extend it to represent additional aspects of the network
   elements or network systems.  This reinforces the criticality of
   designing the data models to be highly extensible, preferably in a
   regular and simple fashion./

New / The scope of I2RS work is being designed in phases to provide 
         deliverable and deployable results at every phase.   Each 
         phase will have a specific set of requirements, and
        the I2RS protocol and data models will progress toward these requirements.
        Therefore, it is clearly desirable for the I2RS data models
        to be easily and highly extensible to represent additional aspects of the network elements 
        or network systems.   It should be easy to integrate data
       models from the I2RS with other data.  This reinforces the criticality of
       designing the data models to be highly extensible, preferably in a
        regular and simple fashion/


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

Sue: I will correct in version 14. 

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

Sue: Do you really want all the protocols lists in the diagrams to be reference?
If so, I am glad to do it.  This question is also included in the top. 

M. I don't think you need both of these references: "Yang 1.1 ([RFC6020]), Yang 1.1 ([I-D.ietf-netmod-rfc6020bis])".
Sue: This is an error:   Yang 1.0 [RFC6020] and Yang 1.1 [I-D.ietf-netmod-rfc-6020bis].  I will correct this -14.txt

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