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

From: "Alvaro Retana" <[email-masked]>
Date: Tue, 15 Mar 2016 06:01:23 -0700

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Mar 2016 14:26:41 -0400

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:[email-masked]] 
Sent: Tuesday, March 15, 2016 9:01 AM
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Alvaro Retana's No Objection on draft-ietf-i2rs-architecture-13: (with COMMENT)

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

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 

[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/

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]

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 15 Mar 2016 19:50:29 +0000

On 3/15/16, 2:26 PM, "iesg on behalf of Susan Hares"
<[email-masked] on behalf of [email-masked]> wrote:

Sue:

Hi!

...
>>"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-require
>ments/
>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?

The point I was trying to make is that the use of "safe" in the text I
quoted (1.1 and 6.4.1) seems to not be the "safe" used in security:
authentication, authorization, encryption, etc.  For example, the text in
1.1 says that "I2RS will only permit modification of state that would be
safe" -- note that the *modification* is what is characterized as safe,
the action itself!

The text above made me think about the result of that modification and
whether that was considered "safe" in the network -- and what would that
be, which is why I asked.  As an simple example, consider a modification
that would result in the connection to the Client to be lost (adding a
route for that destination with an action to drop) -- while the identity,
authentication, integrity, authorization, etc. may all check out correctly
(I.e. The interaction is secure!), it is obviously not what I would
characterize as a "safe" modification.

Maybe I'm reading too much into it...  ???

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

My preferred solution, given that I-D.ietf-i2rs-problem-statement doesn't
really say anything about performance and scaling anyway, is to add the
discussion in Section 3 of this document.

>   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
>
>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?

Note that my comment was around the fact that the text mentions
performance and scaling as key architectural properties (of the
architecture) and there is no discussion related to them.  What you point
to above are requirements/scaling efforts for specific
operations/mechanisms -- which clearly don't represent the architectural
view that the other items in Section 3 do.

Again, my preference is to see Key Architectural Properties discussed
where they belong: in the architecture document.

>If so, I am glad to do it.  This question is also included in the top.

It is common practice to do so.  I think that many are well-known and may
not need a reference, but not all are included in the RFC Editor
Abbreviation List.  I'll let you make the call.

https://www.rfc-editor.org/materials/abbrev.expansion.txt

...
>        regular and simple fashion/

That works for me.

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Mar 2016 16:19:19 -0400

Alvaro: 

On "A" - and the sections in 1.1 and 6.4.1 you quoted - it is either I2RS
data model safe, I2RS protocol safe, I2RS environment safe, or safe for the
routing system.   The text implies the last one safe for the routing system
protocols and RIBs.  That's an architecture big-picture comment.  If you
read more beyond that .. you are reading out of context (IMHO). 

On B - you would like to place architecture qualities of the large data
flows outbound (e.g. pub-sub), and large data flows inbound (e.g. large
updates) in the architecture document.  I'm fine with this approach since
I2RS is actively working on these features.  On this topic, I want to
validate the approach and my text with my co-authors (give me a few hours). 

On L:, I'll add all the RFCs in -14 that are not abbreviation and work with
the RFC editor to make sure we are aligned with her policy. 

On H:, I'll use that text. 

What I owe you is the joint resolution for "B" in the problem and
architecture statement.   Let me know if "A" answers works for you. 

Sue 

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2016 3:50 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: Re: Alvaro Retana's No Objection on
draft-ietf-i2rs-architecture-13: (with COMMENT)

Sue:

Hi!

...
>>"safe" (1.1 and 6.4.1 < see below), but no >explanation as to what 
>>authentication and even >authorization to perform a specific 
>>operation, to the content of the operation itself.  I would like to 
>>see some

safe" -- note that the *modification* is what is characterized as safe, the
action itself!

The text above made me think about the result of that modification and
whether that was considered "safe" in the network -- and what would that be,
which is why I asked.  As an simple example, consider a modification that
would result in the connection to the Client to be lost (adding a route for
that destination with an action to drop) -- while the identity,
authentication, integrity, authorization, etc. may all check out correctly
(I.e. The interaction is secure!), it is obviously not what I would
characterize as a "safe" modification.

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

>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?

Note that my comment was around the fact that the text mentions performance
and scaling as key architectural properties (of the
architecture) and there is no discussion related to them.  What you point to
above are requirements/scaling efforts for specific operations/mechanisms --
which clearly don't represent the architectural view that the other items in
Section 3 do.

Again, my preference is to see Key Architectural Properties discussed where
they belong: in the architecture document.

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

That works for me.

Thanks!

Alvaro.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Tue, 15 Mar 2016 21:11:12 +0000

On 3/15/16, 4:19 PM, "iesg on behalf of Susan Hares"
<[email-masked] on behalf of [email-masked]> wrote:

>validate the approach and my text with my co-authors (give me a few

No, I don't *want* to put anything in the document.  Let's start form the
beginning...

The text in 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]".
>From this text I assume that performance and scaling are important --
which is why they're called out in this section.

I don't think that I-D.ietf-i2rs-problem-statement says anything, that can
be called a "Key Architectural Property", about performance and scaling.

If the description of performance and scaling as "key architectural
properties" is not in I-D.ietf-i2rs-problem-statement, then it should be
somewhere, right?  I said my preference is to describe them in the
architecture document, but the decision of where to put it is yours.  I
don't want to add anything to the document that you didn't already mention
should be considered as a "key architectural property".  The details of
what this description looks like are up to you.

...
> 
>Let me know if "A" answers works for you.

It honestly didn't give me a warm, fuzzy feeling, but I'm ok with that.

Please keep in mind that none of my comments are blocking this document.

Thanks!

Alvaro.

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 15 Mar 2016 17:24:57 -0400

Alvaro: 

Your comments always matter to me whether the comments are blocking or not.
(smile).   

On you not getting "warm fuzzies" on these two documents - my real concern
is that we are doing the right thing in the work.  I think I know what you
want in the document.  Let me talk this over with my other co-authors.   

We are really trying to address the scaling and performance on the
outbound/inbound side in data flow, and within the process in the amount of
resources spent on the router.  This impacts the data models and the
protocol.   I'll catch up with you via phone or at IETF to talk more about
this.  

Sue 

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2016 5:11 PM
To: Susan Hares; 'The IESG'
Cc: [email-masked]; [email-masked]; [email-masked];

Sue:
 
>updates) in the architecture document.  I'm fine with this approach 
>since I2RS is actively working on these features.  On this topic, I 
>want to validate the approach and my text with my co-authors (give me a 
>few hours).

If the description of performance and scaling as "key architectural
properties" is not in I-D.ietf-i2rs-problem-statement, then it should be
somewhere, right?  I said my preference is to describe them in the
architecture document, but the decision of where to put it is yours.  I
don't want to add anything to the document that you didn't already mention
should be considered as a "key architectural property".  The details of what
this description looks like are up to you.

...

Thanks!

Alvaro.